SAP FUE Optimization: Cut License Costs Through Smarter Authorization Management

SAP's shift to Full Use Equivalent (FUE) licensing has caught many organizations off guard. Under RISE with SAP and S/4HANA contracts, your license costs are no longer based on named user types alone - they're driven by what authorizations your users could execute, not what they actually do. The tool SAP uses to determine this classification is the STAR ruleset (S/4HANA Trusted Authorization Review), and its approach has a surprising consequence: it systematically overestimates your license needs.

The STAR ruleset classifies nearly 3,000 authorization object-field combinations into license tiers - Advanced Use, Core Use, and Self-Service. If a user holds even a single authorization that maps to the Advanced tier, their entire license is classified at that level, regardless of whether they ever use that capability. The result? Organizations routinely see their FUE counts inflated by 50% to 150% compared to what their actual usage would justify.

One documented case illustrates the stakes: a company with fewer than 100 professional users in ECC ran the STAR report and received an estimate requiring thousands of licenses under the new model. Before remediation, submitting that report to SAP would have exposed the business to £4.5 million in unnecessary licensing costs.

But here's what makes this problem solvable: the STAR ruleset itself has significant gaps. It doesn't cover 100% of the contractual license type definitions. It doesn't differentiate consistently between core usage and engine usage. And critically, it classifies based on assigned authorizations rather than executable or used capabilities. This leniency - or rather, this blunt approach - creates a clear optimization opportunity for organizations willing to do the analysis work.

This article walks through a systematic approach to FUE optimization using MTC Skopos, from initial license classification analysis through to usage-based remediation.

Understanding the FUE licensing model

Before getting into optimization, it's worth understanding how FUE classification actually works.

License tiers and FUE weights

Under the FUE model, each user is classified into a license type based on their authorization profile:

The total FUE count determines your contract cost. A user classified as Advanced Use costs roughly six times more than a Self-Service user. This means every unnecessary Advanced classification directly inflates your bill.

How STAR determines classification

The STAR report (program SLIM_USER_CLF_HELP, detailed in SAP Note 3113382) works by:

1. Reading each user's assigned roles and profiles
2. Extracting all authorization objects and field values from those roles
3. Matching those values against the STAR classification ruleset
4. Assigning the highest matching license tier to each user

The key problem: this is a ceiling-based approach. One authorization object value matching the Advanced tier promotes the entire user to Advanced - even if that authorization was inherited from a composite role, never used, or technically unexecutable due to missing complementary authorizations.

Step 1: Identify license types triggered by user roles

The first step in any FUE optimization is understanding your current position - which users are classified at which tier and why.

Import the STAR ruleset into MTC Skopos

The SAP STAR ruleset is essentially a list of authorization object-field value combinations mapped to license types. This structure is directly analogous to a Critical Action ruleset - a set of rules that identify specific capabilities based on authorization assignments.

In MTC Skopos, you can import the STAR ruleset as a Critical Action ruleset:

1. Download the STAR classification list from SAP Note 3113382
2. Structure it as a Critical Action ruleset where each rule maps an authorization object + field value combination to its corresponding license type (Advanced, Core, Self-Service)
3. Import the ruleset into MTC Skopos

Each rule in the STAR classification becomes an action in the ruleset. For example:

Run the analysis

With the STAR ruleset loaded and your SAP user/role data extracted, run the Critical Action analysis in MTC Skopos. The output tells you:

• Per user: Which license type is triggered, and by which specific authorization(s)
• Per role: Which roles contain authorizations that trigger higher-tier classifications
• Distribution: How many users fall into each license tier

This gives you the baseline - your "as-is" FUE position before any optimization.

Identify quick wins

The initial analysis typically reveals several categories of overclassification:

• Users with a single Advanced authorization inherited from a broad composite role they don't need
• Roles containing wildcard values (e.g., ACTVT = *) that match Advanced-level activities the role was never intended to grant
• Test or template users with full access profiles still active
• Departed employees or service accounts classified as full users

Step 2: Improve the STAR ruleset with your authorization concept

The standard STAR ruleset has a fundamental limitation: it evaluates authorization objects in isolation, without considering whether those objects are actually linked to executable transactions or applications in your system. This is where SU24 data becomes critical.

Why SU24 matters for FUE optimization

Transaction SU24 (and its underlying tables USOBT_C and USOBX_C) defines which authorization objects are checked when a specific transaction code or application is executed. This is your system's authorization concept - the mapping between "what a user can launch" and "what authorization checks are performed."

The STAR ruleset checks authorization objects regardless of whether they're linked to any transaction the user can actually run. But in practice, an authorization object value only matters if:

1. The user has access to a transaction or Fiori app that checks that object
2. The check is actually active (maintained in SU24 as "check" or "check and maintain")
3. The field values in the user's role match the values that trigger the higher license tier

Build an enhanced STAR ruleset

By combining the STAR classification with your SU24 data, you can build a more precise ruleset that only flags authorizations when they're linked to executable transactions:

1. Extract SU24 data - Export the contents of USOBT_C and USOBX_C from your SAP system. These tables map every transaction code and Fiori app to the authorization objects they check at runtime.

2. Cross-reference with STAR classifications - For each STAR rule (authorization object + field value → license type), check whether that authorization object is linked to a transaction or app in your SU24 data.

3. Build transaction-level rules - Instead of rules that say "if user has auth object X with value Y → Advanced," create rules that say "if user has transaction T + auth object X with value Y → Advanced."

This transforms the ruleset from a blunt authorization-only check into a context-aware classification that considers executable access.

Example - Before (standard STAR):

Rule: M_BEST_BSA with ACTVT = 01 → Advanced Use
Result: Any user with this auth value is classified as Advanced,
        even if they have no transaction that checks M_BEST_BSA

After (enhanced with SU24):

Rule: ME21N + M_BEST_BSA with ACTVT = 01 → Advanced Use
Rule: ME22N + M_BEST_BSA with ACTVT = 02 → Advanced Use
Rule: F0842A + M_BEST_BSA with ACTVT = 01 → Advanced Use (Fiori)
Result: Only users who can actually execute PO transactions
        AND hold the triggering auth values are classified as Advanced

Import the enhanced ruleset into MTC Skopos

Load this improved ruleset as a new Critical Action ruleset in MTC Skopos. The structure now includes the transaction or app as part of each action's definition, making the analysis more precise.

Run the analysis again with the enhanced ruleset and compare results with the baseline from Step 1. The difference represents users who were overclassified by the standard STAR approach - they hold authorization values that match Advanced or Core tiers, but have no way to actually execute the functions those values relate to.

Step 3: Build a license-trigger ruleset for ongoing monitoring

With the enhanced STAR ruleset in place, you can now do ongoing license management. But to make it actionable, you need to structure it as a monitoring ruleset that clearly identifies who triggers what license type and through which role.

Structure the ruleset by license type

Organize your Critical Action ruleset into categories that map to license tiers:

📁 FUE License Classification Ruleset
├── 📁 Advanced Use Triggers
│   ├── FI - Financial Document Posting
│   ├── FI - Asset Management
│   ├── MM - Purchase Order Processing
│   ├── MM - Invoice Verification
│   ├── SD - Sales Order Processing
│   ├── HR - Payroll Processing
│   └── ...
├── 📁 Core Use Triggers
│   ├── Time Management
│   ├── Basic Reporting
│   ├── Approval Workflows
│   └── ...
└── 📁 Self-Service Triggers
    ├── Leave Requests
    ├── Expense Claims
    ├── Personal Data Maintenance
    └── ...

Analyze the results

Running this ruleset in MTC Skopos produces a clear map:

Pay special attention to users like MBROWN in the example above - classified as Advanced because of a general-purpose role (Z_GENERAL) that happens to contain vendor maintenance authorizations. This is the classic overclassification pattern: a role assigned for one purpose carrying authorization baggage that inflates the license tier.

Identify remediation targets

From the analysis, build a prioritized remediation list:

1. High impact: Users classified as Advanced who only need Core or Self-Service access
2. Easy wins: Users triggered by a single role that can be replaced or trimmed
3. Broad impact: Roles assigned to many users that contain unnecessary Advanced-level authorizations
4. Structural issues: Composite roles or reference roles that cascade Advanced authorizations to users who don't need them

Step 4: Use usage data to validate removals

This is where FUE optimization moves from theory to evidence-based action. Removing authorizations to reduce license tiers is only safe if those authorizations aren't actually needed. Usage data provides the proof.

Extract usage data

SAP provides several sources of usage information:

• Transaction usage statistics (ST03N, STAD) - which transactions each user has executed
• Fiori app usage - launchpad analytics showing which apps are accessed
• Authorization trace (STAUTHTRACE / ST01) - which authorization objects were actually checked during user sessions

MTC Skopos can ingest this usage data and cross-reference it against the license-trigger analysis from Step 3.

The did-do analysis for FUE

MTC Skopos's did-do analysis capability is directly applicable to FUE optimization. For each user flagged with a higher-tier license classification, the analysis goes beyond simple transaction execution logs - it also examines change documents to determine whether the user actually made changes through the triggering transaction.

This distinction is critical for FUE optimization. The STAR ruleset classifies based on the ability to perform create/change activities (ACTVT = 01, 02). But if a user executes a transaction without ever making changes, it raises a clear question: do they actually need create/change access, or would display-only access (ACTVT = 03) be sufficient? Display-only access typically maps to a lower license tier.

For each user flagged with a higher-tier license classification, the analysis answers:

• Did the user execute the transaction or app that triggers the classification?
• Did the user actually make changes? Change documents (CDHDR/CDPOS) reveal whether executions resulted in actual create/change activity
• If executed but no changes made, could a display-only transaction or restricted authorization values serve the same purpose?
• If never executed, is there a business justification for retaining the access at all?

Notice the difference between MBROWN and PTAYLOR. Both are candidates for reclassification, but for different reasons. MBROWN never even opened the transaction - the authorization can be removed entirely. PTAYLOR executes F110 occasionally but never posts changes - they're likely using it to review payment proposals. Replacing the create/change authorization with display-only access achieves the same business outcome while dropping the license tier.

Similarly, DKIM runs ME22N (Change Purchase Order) 45 times but never saves a change - they're clearly using it as a lookup tool. Switching their role to ME23N (Display Purchase Order) removes the Advanced-level trigger entirely.

Make evidence-based decisions

For each overclassified user, you now have four data points:

1. What authorization triggers the classification (from the STAR/Critical Action analysis)
2. Which role grants that authorization (from the role-level analysis)
3. Whether the user executes the triggering transaction (from usage data)
4. Whether the user actually makes changes (from change documents)

This creates three distinct remediation paths:

• No execution - Remove the authorization or role entirely. The user doesn't need it.
• Execution without changes - Replace create/change access with display-only access, or adjust the authorization object values (e.g., restrict ACTVT to 03 instead of *). The user gets the same visibility without triggering the higher license tier.
• Execution with changes - The authorization is justified. Keep it and document the business need.

Users who hold Advanced-level authorizations but never execute the corresponding transactions are strong candidates for role removal. Users who execute but never make changes are candidates for authorization value adjustment - restricting to display-only access drops their license classification without impacting their actual work.

Quantify the savings

For each user reclassified from Advanced to Core, you save approximately 0.5 FUE. From Advanced to Self-Service, approximately 0.83 FUE. At typical RISE with SAP pricing, each FUE saved translates directly to annual cost reduction.

For an organization with 1,000 users where 30% are overclassified as Advanced:

The exact figures depend on your contract terms, but the direction is clear: every unnecessary Advanced classification is money left on the table.

Putting it all together: the FUE optimization workflow

The complete workflow using MTC Skopos:

Phase 1: Assess

1. Import the standard SAP STAR ruleset as a Critical Action ruleset
2. Run the analysis against your user/role data
3. Document your baseline FUE position

Phase 2: Enhance

4. Extract SU24 data (USOBT_C/USOBX_C) from your SAP system
5. Cross-reference STAR classifications with SU24 to build an enhanced ruleset
6. Re-run the analysis - compare with baseline to identify overclassifications

Phase 3: Analyze

7. Structure the ruleset by license tier for clear reporting
8. Identify which users, roles, and authorizations trigger each classification
9. Prioritize remediation targets by impact and complexity

Phase 4: Validate

10. Import usage data (transaction logs, Fiori analytics)
11. Run did-do analysis to confirm which capabilities are actually used
12. Build an evidence-based remediation plan

Phase 5: Remediate

13. Adjust roles to remove unnecessary Advanced-level authorizations
14. Re-run the analysis to confirm reclassification
15. Document changes for audit trail and SAP review

Phase 6: Monitor

16. Run the FUE classification analysis periodically (monthly under RISE)
17. Flag new overclassifications as roles change
18. Track FUE count trends against your contract baseline

Why this matters now

Under RISE with SAP, FUE consumption is measured monthly, and the highest monthly count in your contract period can be used as the billing baseline for license true-up. This means overclassification isn't just an occasional audit issue - it's a continuous cost problem.

Organizations that optimize proactively - before submitting STAR results to SAP - consistently achieve FUE reductions of 30% to 50% compared to the raw STAR output. That's not optimization through tricks or loopholes; it's simply aligning your license classification with reality.

The STAR ruleset tells SAP what your users could do based on their authorizations. Your job is to make sure those authorizations reflect what users actually need to do - and MTC Skopos gives you the analysis framework to prove it.

Related articles

• Building an Effective SoD Ruleset for S/4HANA
• Understanding Did-Do Analysis for SAP Access Risk
• Advanced SoD Remediation with MTC Skopos
• SAP SoD Tools Comparison