The FUE Licensing Pitfall in SAP S/4HANA: Why Improper HR Authorizations Can Cost Us a Lot of Money
The topic of “authorization-based licensing” and the transition to the Full Usage Equivalent (FUE) model in SAP S/4HANA is a pressing concern for many companies. What sounds like a flexible simplification in theory often turns out to be a massive financial risk in practice—especially in the area of SAP Human Capital Management (HCM / H4S4).
Anyone preparing for the migration to S/4HANA should no longer view licensing as merely a contractual issue. From now on, it is a technical authorization issue. To ensure that an imprecise role and authorization concept does not end up costing you dearly, you must thoroughly understand the rules of the new SAP world.
From Named User to Point Pool: The FUE Licensing Model
In the traditional SAP ECC environment, licensing was rigid but straightforward. You purchased dedicated user licenses (“Named User”), such as Professional, Limited Professional, or Employee. These were permanently assigned to employees.
With SAP S/4HANA—whether on-premises or as part of a RISE with SAP cloud model—this structure is being phased out. It is replaced by the Full Usage Equivalent (FUE). An FUE is no longer a single license, but rather a kind of universal currency or points budget. As a company, you purchase a pool of FUE points and can flexibly allocate them across four different user types.
The crux lies in the different weighting factors (ratios) used to allocate the user types against the FUE budget:
| User Type in S/4HANA | FUE Weighting | Equivalent / Conversion |
|---|---|---|
| Developer User | 2.0 FUE | 1 Developer uses 2.0 FUE points. |
| Advanced User | 1.0 FUE | 1 Power User uses 1.0 FUE point. |
| Core User | 0.20 FUE | 5 Core Users together use 1.0 FUE point. |
| Self-Service User | 0.033 FUE | 30 Self-Service Users share 1.0 FUE point. |
The advantage: If roles and requirements within the company change, the points can be reallocated flexibly.
The disadvantage: If employees unintentionally move into a higher category, the FUE budget is used up in record time.
The STAR Framework: Potential Meets Reality
However, this fundamental system change affects not only the mathematical conversion but also the way SAP measures license compliance. Welcome to Authorization-Based Licensing via the STAR Framework!
- In the past (ECC): During system measurements and audits, what a user actually did in the system (usage history, transactions performed) was often the decisive factor.
- Today (S/4HANA): The STAR framework rigorously and purely digitally measures what a user could theoretically do based on their assigned roles.
It no longer matters to the license auditor whether an employee hasn’t clicked on a transaction in three years. As soon as the authorization object is active in their profile, the STAR framework strikes without mercy.
A classic real-world example is the “convenience” feature in Basis administration. If a user is quickly assigned the authorization object S_DEVELOP (for ABAP development) or S_TRANSPRT (for transport) as part of a project or support request and the authorization is not subsequently revoked, the system automatically classifies this user as a Developer User (2.0 FUE) or Advanced User (1.0 FUE) in the next audit. This is a critical error that can multiply the license costs for that single user in the blink of an eye.
The Focus: SAP HCM and the ESS/MSS Trap
Why is this licensing system particularly important in the context of SAP HCM or H4S4?
The reason lies in what is known as “mass headcount.” In traditional ERP modules such as Finance (FI) or Purchasing (MM), usually only a limited portion of the workforce (the traditional desk-based employees) is involved. In HR, however, due to the widespread adoption of Employee Self-Services (ESS) and Manager Self-Services (MSS), virtually every single employee in the company is a registered SAP user.
From production workers on rotating shifts to nursing staff in hospitals to executive management: Everyone accesses the system to view pay stubs, submit vacation requests, or record working hours.
Conceptually speaking, these thousands of ESS employees are perfect self-service users. With a weighting of 0.033 FUE per person, they place hardly any strain on the license budget (30 employees share one FUE point).
The Mathematical Nightmare of Improperly Defined HR Roles
Let’s assume that a medium-sized company has 3,000 employees who access their pay stubs exclusively online via ESS.
- Target state: 3,000 users × 0.033 FUE = 100 FUE points.
If an error creeps into the design of HR roles—for example, because legacy ECC roles were migrated without being checked (“Lift & Shift”) or because ESS users were mistakenly granted access to classic maintenance transactions (such as PA20 or PA30 instead of pure Fiori apps)—the STAR framework escalates these users’ permissions.
Even small, improperly configured authorization objects in the HR environment (e.g., incompletely restricted objects such as P_ORGIN or general system authorizations) can cause the system to classify the user as a Core User or even an Advanced User.
- Core User Classification Scenario: 3,000 users × 0.20 FUE = 600 FUE points.
- Advanced User Classification Scenario: 3,000 users × 1.0 FUE = 3,000 FUE points.
A single structural flaw in the HR role concept causes the licensing requirement in this example to skyrocket from 100 to as many as 3,000 FUE points! Since FUEs are defined—particularly in cloud contracts (such as RISE)—as a minimum purchase commitment for the entire contract term, and “downscaling” during the term is virtually impossible, this can quickly result in avoidable additional costs in the six- to seven-digit euro range.
Technical Analysis: SAP Note 3113382 as a Lifeline
To prevent precisely this financial fiasco, SAP has made SAP Note 3113382 available. This note includes the “SAP S/4HANA User Simulation / FUE Projection Authorization Table” and provides the technical logic for report /SDF/HANA_BW_FUE.
Using this tool, companies can run an accurate simulation on their old ECC system. The report analyzes the current role catalog and clearly shows how many FUE points the company would consume after an S/4HANA migration, based on the current authorization status.
Important for practical use: The note in the system must be up to date. Since SAP continuously refines and updates the mapping of authorization objects to FUE classes, only a completely up-to-date note provides reliable figures for upcoming contract negotiations.
Best Practices: How to Protect Your SAP Budget
Anyone planning to migrate to S/4HANA or H4S4 should firmly incorporate the following three steps into their roadmap:
- No “Lift & Shift” for Roles: Never migrate old ECC roles to the new system without testing them first. Use the S/4HANA migration as an opportunity to radically streamline authorization structures that have evolved over time.
- Consistent Focus on Fiori in HR: To ensure that ESS/MSS users in the HCM area remain firmly in the cost-effective “Self-Service” category (0.033 FUE), they should access the system exclusively via standardized SAP Fiori apps. Avoid direct access to classic backend transactions in the SAP GUI.
- Conduct regular mock audits: Do not wait for SAP’s official system assessment. Use the report from Note 3113382 regularly in advance to identify and correct discrepancies, orphaned profiles, or misclassifications early on.
Conclusion
The FUE licensing model in SAP S/4HANA offers modern flexibility, but penalizes administrative negligence more severely than ever before. Particularly in the HCM environment, where user numbers are naturally extremely high, the authorization concept becomes a direct cost driver. Only those who precisely understand and maintain their roles and the underlying authorization objects can ensure a financially successful migration. Role maintenance is no longer just a tedious IT project—it is active risk management for the entire company.
Are you interested in this topic or do you have a question? Feel free to contact us anytime!