The Definitive Guide to Org Levels in SAP Role Design

What Are Organizational Levels?

In SAP's authorization model, organizational levels (org levels) are special authorization fields that represent your company's structural hierarchy — company codes, plants, sales organizations, purchasing organizations, controlling areas, and more.

Unlike regular authorization field values that are maintained directly inside authorization objects, org levels sit in a separate layer. When you create a derived role from a master role, the only values that change between the master and derived copies are the org level values. Everything else — the transaction codes, the authorization objects, the activity values — stays identical.

This is the foundation of SAP's scalable role architecture. A single master role can spawn dozens of derived roles, each scoped to a different company code, plant, or sales area. One design, many deployments.

Master Roles, Derived Roles & the Org Level Connection

SAP's role architecture follows a parent-child model. The master role defines what a user can do — which transactions, which authorization objects, which activity values (create, change, display). The derived role defines where they can do it — which company code, which plant, which sales organization.

The connection between them is the org level. When you derive a role, SAP copies the entire authorization profile from the master — but leaves the org level fields blank. You then fill in the org values specific to that derived role. This means the master role should never contain hardcoded org level values. If it does, every derived role inherits that restriction, defeating the purpose of the entire architecture.

This architecture is critical for Segregation of Duties (SoD) compliance. When auditors review roles, they look at the master role design first. If the master is clean — proper activity restrictions, no wildcards in sensitive objects, no conflicting transactions — then every derived role automatically inherits that clean design. Break the master, and you break every derived role downstream.

Complete Org Level Reference Table

The following table lists the most common organizational levels in SAP ECC and S/4HANA, their authorization objects, the module they belong to, and their sensitivity classification. This is the reference your role design team should have pinned to the wall.

Sensitivity Classification — Which Org Levels Matter Most

Not all org levels carry equal risk. Misassigning a Division (SPART) is an inconvenience. Misassigning a Company Code (BUKRS) or Purchasing Organization (EKORG) is a potential SOX finding with financial impact. Understanding this hierarchy is the difference between a secure system and an audit disaster.

The 7 Costliest Org Level Mistakes

1. Hardcoding Org Values in the Master Role

If you maintain BUKRS = 1000 directly in the master role, every derived role inherits that value. Now you can't scope a derived role to Company Code 2000 without overriding the master — which defeats the entire purpose. The master role should have org level fields blank (set as organizational level, not hardcoded).

2. Using Wildcards in Sensitive Org Levels

Setting BUKRS = * or EKORG = * gives access across the entire corporate structure. This is the single most common cause of SoD violations in procurement and finance. It's also the first thing auditors check.

3. Forgetting Org Levels When Adding New Authorization Objects

When you add a new transaction to a master role, SAP proposes default authorization objects. If those objects contain org level fields, you must ensure they're flagged as organizational levels — not maintained as regular values. If you accidentally hardcode them, the derived role model breaks silently.

4. Inconsistent Org Level Combinations Across Related Roles

A user with BUKRS = 1000 in their FI role but EKORG = * in their MM role can create purchase orders for all purchasing orgs but only post invoices for one company code. This mismatch creates SoD exposures that are hard to detect in standard reporting.

5. Not Using Derived Roles at All

Some organizations create separate standalone roles for each company code — Z_FI_AP_1000, Z_FI_AP_2000, Z_FI_AP_3000 — without a master/derived relationship. When a change is needed (adding a new transaction, adjusting an activity value), it must be made in every single copy independently. In a 50-company-code landscape, this is a governance nightmare.

6. Mixing Functional and Org-Level Scope in One Role

A role called Z_PROCUREMENT_ALL_PLANTS that contains both MM and FI authorizations with WERKS = * and BUKRS = * is too broad to derive cleanly. The fix: separate by functional area first (procurement vs. finance), then derive by org level.

7. Ignoring HR Org Levels

PERSA (Personnel Area) and MOLGA (Country Grouping) in HR authorization object P_ORGIN control access to the most sensitive data in SAP — employee salaries, personal IDs, bank details. Yet many organizations treat HR roles as an afterthought, assigning broad access because "HR needs to see everything." Under GDPR, this is a data protection violation.

Best Practices Checklist

PFCG Walkthrough — Setting Org Levels Correctly

Here's the step-by-step process for maintaining org levels correctly in PFCG. This walkthrough assumes you already have a master role with transactions assigned.

── STEP 1: Open Master Role ──
PFCG → Enter master role name (e.g., Z_FI_AP_INVOICE)
     → Click Change

── STEP 2: Go to Authorizations Tab ──
Click Authorizations tab → Click "Change Authorization Data"
     → The authorization tree opens

── STEP 3: Check Org Level Assignments ──
Click Org Levels button (globe icon, top toolbar)
     → This opens the Organizational Level Maintenance screen
     → You see all org level fields relevant to this role

── STEP 4: Verify Fields Are Marked as Org Levels ──
Each field should show: "Maintained at Organizational Level"
     → If a field shows a hardcoded value → THIS IS WRONG
     → Remove the value → Mark it as organizational level

── STEP 5: Save and Generate the Master Role ──
Save → Generate (Shift+F5)
     → Master role is now clean

── STEP 6: Create Derived Role ──
PFCG → Enter derived role name (e.g., Z_FI_AP_INVOICE_1000)
     → Click Create → Select "Derive from"
     → Enter master role name → Enter

── STEP 7: Maintain Org Levels in Derived Role ──
Go to Authorizations tab → Click "Change Authorization Data"
     → Click Org Levels button
     → NOW enter the specific values:
       BUKRS = 1000
       WERKS = 1000
       EKORG = 1000

── STEP 8: Generate Derived Role ──
Save → Generate (Shift+F5)
     → Derived role is ready for assignment

Using SAP GRC for Org Level Governance

If your organization runs SAP GRC Access Control, you already have a powerful framework for governing org level assignments — but most companies underutilize it. GRC isn't just for SoD checks and firefighter logs. Its Access Request Management (ARM) and Business Role Management (BRM) modules can enforce org level discipline at scale.

GRC ARM — Controlling Org Values at Request Time

When a user requests access through GRC ARM (transaction GRAC_SPM or the Fiori launchpad), the request form can be configured to require specific org level values. Instead of a requester saying "I need the AP Invoice role," ARM forces them to specify which company code, which purchasing organization, and which plant. The system then maps the request to the correct derived role automatically.

This eliminates a major source of errors: requesters asking for "the same role as my colleague" without realizing the colleague's role is scoped to a different company code. With ARM, the org level is explicit in the request, visible to the approver, and auditable end-to-end.

GRC BRM — Org Level Rules in Role Design

Business Role Management allows you to define organizational rules at the business role level. A business role like "Accounts Payable Clerk" can be configured with org level conditions — when a manager requests this role for a user, BRM automatically selects the correct derived technical role based on the user's organizational assignment (company code from HR master data, cost center, plant, etc.).

This is powerful because it removes the human decision about which derived role to assign. The mapping is rule-based: User in Company Code 1000 → gets Z_FI_AP_INVOICE_1000. User in Company Code 2000 → gets Z_FI_AP_INVOICE_2000. No manual selection, no misassignment.

GRC ARA — SoD Checks That Include Org Levels

The Access Risk Analysis (ARA) module can be configured to evaluate SoD conflicts at the organizational level, not just at the transaction level. This is a critical distinction. Two users might both have access to FB60 (Post Vendor Invoice) and F110 (Payment Run) — which is a classic SoD conflict. But if one user's role is scoped to Company Code 1000 and the other is scoped to Company Code 2000, the risk is mitigated because they operate in different organizational contexts.

ARA's org level rules (configured in NWBC → Access Rule Maintenance) let you define organizational mitigations — reducing false positives in SoD reporting by recognizing that org-level separation can be a valid compensating control. Without this, SoD reports are noisy with conflicts that don't represent real business risk.

SharePoint-Based Org Data Approvals — A Best Practice

Here's a pattern that the best-run SAP security teams use but rarely talk about: maintaining org level master data in SharePoint (or a similar collaboration platform) with formal approval workflows, rather than making org level decisions ad-hoc inside PFCG.

Why SharePoint?

The problem with maintaining org levels purely in PFCG is that there's no built-in approval trail for which org values should go into which derived role. SAP logs the technical change (who changed the role, when), but not the business decision behind it. When an auditor asks "Who approved giving the Chennai plant team access to the Mumbai plant's inventory?" — the answer shouldn't be "the Basis admin decided during a Friday ticket."

SharePoint (or Microsoft Lists, or any workflow-enabled platform) provides the governance layer that PFCG lacks:

Org Level Master List — A central SharePoint list that maps every derived role to its approved org level values. Columns include: Role Name, Company Code, Plant, Purchasing Org, Sales Org, Business Justification, Approved By, Approval Date. This becomes the single source of truth.

Change Request Workflow — When a business unit needs a new derived role or a change to existing org values (e.g., "Add Plant 3000 to the procurement role for the new factory"), they submit a request through a SharePoint/Power Automate workflow. The request routes to the data owner (typically a finance controller for company code changes, a plant manager for plant changes, an HR business partner for personnel area changes) for approval.

Segregation of Approval — The person requesting the org level change should never be the same person implementing it in PFCG. SharePoint workflows enforce this naturally: the business owner approves, the security team implements, and the audit trail shows both steps clearly.

Periodic Recertification — Set up quarterly recertification flows where data owners review their org level assignments and confirm they're still valid. This catches stale access — a user who transferred from Company Code 1000 to 2000 six months ago but still has their old derived role assigned.

How AI Is Changing Role Governance

Traditionally, validating org levels across hundreds of roles has been a manual, spreadsheet-driven exercise. Security teams export role data from AGR_1251, cross-reference against organizational structures in T001 (company codes), T024E (purchasing orgs), and TVKO (sales orgs), and flag anomalies by hand. In organizations with 500+ roles, this takes weeks.

AI-powered platforms like SyntaAI are changing this. Instead of exporting and comparing spreadsheets, SyntaAI's security agent connects directly to your SAP system and runs automated checks across your entire role landscape:

Wildcard Detection — Scans AGR_1251 for any role where sensitive org level fields (BUKRS, EKORG, VKORG, PERSA) contain *. Flags the role, lists the affected users, and calculates the risk exposure.

Org Level Consistency Checking — Compares org values across all roles assigned to a single user. If a user has BUKRS = 1000 in their FI role but EKORG = * in their MM role, the agent flags the inconsistency and explains the SoD exposure in plain language.

Derived Role Governance — Identifies standalone roles that should be master/derived, detects master roles with hardcoded org values, and finds derived roles that have drifted from their master (manual changes to authorization data that bypass the derivation).

Custom vs. Standard Role Ratio — Analyzes the balance between Z/Y custom roles and SAP-standard roles. A high custom ratio often indicates governance gaps — too many one-off roles built for individual requests rather than following a structured design.

License Impact Analysis — Evaluates how org level assignments in roles affect SAP RISE FUE licensing. Overly broad roles (with create/change activities in advanced authorization objects) inflate license costs. SyntaAI identifies which specific org level + activity combinations are driving users into higher license tiers — and shows you how to fix it.