The FUE Problem Nobody Talks About
If you manage SAP licensing, you have likely encountered the pain of Full Use Equivalent (FUE) counts that seem to spiral out of control. Every indirect access, every role assignment, every authorization object can silently inflate your FUE consumption — and with it, your licensing costs.
The truth is: most organizations are over-consuming FUEs not because of genuine usage, but because of how roles are designed and assigned. The good news? SAP gives us the exact tables we need to diagnose and fix this. In this article, I will walk you through how to use AGR_1251, AGR_USERS, AGR_DEFINE, and the SAP Ruleset file to identify the roles and users driving higher FUE consumption — and how to bring those numbers down using the 1/* ratio concept.
Understanding FUE in the SAP Licensing Context
Full Use Equivalent(FUE) is SAP’s metric for measuring the weighted value of system access a user consumes. Under the SAP Digital Access model, each named user is classified into user types (Professional, Limited Professional, Developer, etc.), and each type carries a specific FUE weight.
FUE Weights by User Type:
| User Type | FUE Weight | Typical Access Level |
| Professional | 1.0 | Full transactional access |
| Limited Professional | 0.5 | Restricted transactional |
| Developer | 1.0 | ABAP development access |
| Test User | 1.0 | Full access in test systems |
| Employee (Self-Service) | 0.0286 (1/35) | ESS only |
| Functional User | Varies (1/*) | Ratio-based classification |
The key insight: if a user is classified as a Professional (1.0 FUE) when their actual usage pattern qualifies for a lower-weighted type, your organization is bleeding FUEs unnecessarily.
The Four Key Data Sources
1. AGR_DEFINE — The Role Master
AGR_DEFINE is the foundation. It contains the master definition of every role in the system. Each record represents a single role with its administrative metadata.
Key fields: AGR_NAME (Role name), PARENT_AGR (Composite parent role), CREATE_USR (Creator), CREATE_DAT (Creation date), CREATE_TIM (Creation time).
Why it matters for FUE: AGR_DEFINE lets you identify composite roles that bundle multiple single roles. When a user is assigned a composite role, they inherit all child roles — and every authorization object within them. This is often where FUE inflation begins silently.
2. AGR_1251 — The Authorization DNA
AGR_1251 stores the authorization data at the field-value level for every role. This is where you see exactly what each role is authorized to do.
Key fields: AGR_NAME (Role name), OBJECT (Authorization object), AUTH (Authorization), FIELD (Authorization field), LOW (From value), HIGH (To value), DELETED (Deletion flag).
Why it matters for FUE: The authorization objects within a role determine its “weight” in the licensing engine. Roles with broad objects like S_TCODE with value * (all transactions) or high-privilege objects like S_DEVELOP push users into Professional classification. By analyzing AGR_1251, you can identify which specific authorization values are causing the FUE escalation.
3. AGR_USERS — The Role-User Bridge
AGR_USERS maps roles to users. It tells you exactly who has which role, and when the assignment is valid.
Key fields: AGR_NAME (Role name), UNAME (Username), FROM_DAT (Valid from), TO_DAT (Valid to), EXCLUDE (Exclusion flag).
Why it matters for FUE: This is where you quantify impact. Once you identify a “heavy” role in AGR_1251, AGR_USERS tells you how many users are affected. A role with S_DEVELOP assigned to 200 users means 200 users are potentially classified as Professional (1.0 FUE each).
4. SAP Ruleset File — The Classification Engine
The SAP Ruleset file (typically an XML or configuration file provided by SAP) defines the rules that map authorization objects and values to user types. It is the bridge between what a user CAN do (authorizations) and what they ARE (user type classification).
- It specifies which authorization objects trigger which user type classification
- It defines the precedence rules when a user has multiple qualifying authorizations
- It contains the mapping logic: Object + Field + Value range = User Type
Why it matters for FUE: The ruleset is literally the scoring algorithm. Without understanding it, you are optimizing blind. By cross-referencing AGR_1251 data against the ruleset, you can predict exactly which roles will push users into higher FUE tiers before you even look at user assignments.
The Diagnostic Workflow: From Tables to Actionable Insights
Step 1: Extract and Cross-Reference
Start by pulling data from all four sources and joining them:
- AGR_DEFINE → Get all active roles and identify composite vs. single roles
- AGR_1251 → For each role, extract authorization objects and field values
- SAP Ruleset → Map each authorization object/value combination to its user type trigger
- AGR_USERS → Count affected users per role
Step 2: Identify High-Impact Roles
Look for roles where:
- The authorization values match Professional-tier rules in the ruleset
- The role is assigned to a large number of users (high user count in AGR_USERS)
- The role contains wildcard (*) values in sensitive authorization objects
- The role is a composite bundling multiple high-privilege single roles
The formula for impact scoring is straightforward:
FUE Impact = (Users Assigned) × (FUE Weight of Triggered User Type)
Step 3: Apply the 1/* Ratio Technique
This is where the optimization happens. The 1/* ratio concept works on the principle that not every authorization needs to grant full access. Instead of assigning wildcard (*) values that trigger Professional classification, you restrict the values to match the user’s actual need — which may qualify them for a lower user type.
The ratio logic: If a role grants access to ALL transactions (S_TCODE = *), it triggers Professional (1.0 FUE). But if you restrict S_TCODE to only the 5 specific transactions the user actually needs, the ruleset may classify that access as Limited Professional (0.5 FUE) or even lower. The ratio of 1 user / specific transactions instead of 1 user / all transactions (*) is the core of the 1/* concept.
Worked Example: Before and After Optimization
Scenario: The Over-Provisioned Finance Team
Let us walk through a real-world scenario. A finance department has 150 users assigned to a composite role called Z_FIN_MASTER_ROLE.
Before Optimization
| Analysis Point | Table/Source | Finding | FUE Impact |
| Role Definition | AGR_DEFINE | Composite role with 8 child roles | — |
| Auth Object S_TCODE | AGR_1251 | Value = * (all T-codes) | Triggers Professional |
| Auth Object S_DEVELOP | AGR_1251 | ACTVT = 01, 02, 03 | Triggers Developer |
| Ruleset Classification | SAP Ruleset | Professional (highest tier wins) | 1.0 FUE per user |
| User Count | AGR_USERS | 150 active users assigned | 150.0 total FUEs |
Total FUE consumption: 150 users × 1.0 FUE = 150.0 FUEs
After Optimization (1/* Ratio Applied)
Actions taken:
- Decomposed Z_FIN_MASTER_ROLE composite role into purpose-specific single roles
- Replaced S_TCODE = * with specific transaction codes (FB01, FB02, FB03, FK01, FK02, FBL1N, FBL3N, FBL5N)
- Removed S_DEVELOP entirely (finance users do not need development access)
- Re-analyzed against SAP Ruleset: 120 of 150 users now qualify as Limited Professional
| User Group | Count | FUE Weight | Total FUEs | Classification |
| Power Users (still need broad access) | 30 | 1.0 | 30.0 | Professional |
| Standard Finance Users | 120 | 0.5 | 60.0 | Limited Professional |
| TOTAL | 150 | — | 90.0 | — |
FUE Reduction: 150.0 → 90.0 = 40% reduction in FUE consumption
This 60 FUE reduction translates directly into licensing cost savings. At typical SAP pricing, this can represent significant annual savings for just one department.
The 1/* Ratio Concept: A Deeper Look
The 1/* ratio is not just about replacing wildcards. It is a systematic approach to right-sizing authorization granularity:
| Ratio Pattern | Meaning | FUE Impact |
| 1/1 | One user = One specific authorization | Lowest possible FUE (most restrictive) |
| 1/N | One user = N specific authorizations | Lower FUE (targeted access) |
| 1/* | One user = ALL authorizations (wildcard) | Highest FUE (unrestricted access) |
The goal is to move users from 1/* (unrestricted) to 1/N (targeted) wherever possible. Each move down the ratio spectrum potentially reclassifies the user to a lower FUE weight.
Practical Implementation Checklist
- Audit AGR_1251 for wildcard values: Query all roles where FIELD = ‘TCD’ and LOW = ‘*’ in S_TCODE, or any HIGH value ranges that are unnecessarily broad
- Cross-reference with the Ruleset: Map each wildcard authorization to its user type trigger in the ruleset file. Focus on objects that trigger Professional or Developer classification
- Quantify with AGR_USERS: Count affected users per role. Prioritize roles with the highest (user count × FUE weight) product
- Analyze actual usage via ST03N or STAD: Determine which transactions users actually execute. The gap between ‘authorized’ and ‘actually used’ is your optimization space
- Redesign roles with specific values: Replace * with explicit transaction lists. Create role variants for different access levels within the same business function
- Validate against Ruleset: Re-check the modified roles against the ruleset to confirm the expected user type reclassification
- Document in AGR_DEFINE: Ensure new role names and composite structures clearly indicate their FUE-optimized purpose
Essential SQL/SE16N Queries for Your Analysis
Find all roles with wildcard T-code access:
Table: AGR_1251 | OBJECT = ‘S_TCODE’ | FIELD = ‘TCD’ | LOW = ‘*’
Count users per high-privilege role:
Table: AGR_USERS | Group by AGR_NAME | Count UNAME | Where TO_DAT >= SY-DATUM
Identify composite role structures:
Table: AGR_DEFINE | Where PARENT_AGR IS NOT INITIAL
Conclusion: Stop Paying for Access Nobody Uses
The organizations that get this right are the ones that treat role design as a licensing lever, not just a security mechanism. Every wildcard you eliminate, every composite role you decompose, and every user you reclassify brings you closer to an optimized FUE footprint.
Start with the highest-impact roles (most users × highest FUE weight), apply the 1/* ratio analysis, and work your way down. The savings are there — you just need to look in the right tables.