FUE Levers Through Authorization Roles: How Role Design Directly Affects License Costs

When you assign a role with Advanced authorization to a user in S/4HANA, that user counts as an Advanced User, even if they never invoke that authorization. The assigned role determines the FUE type, not actual usage. The implication is clear: role design is not purely an IT security concern. It is a direct governance moment for the FUE base and, by extension, for the contract price across the entire term.

---

1. Authorization-Based Classification: The Core Mechanic

In S/4HANA Cloud, users are classified by their authorizations, not by their usage behavior. The underlying logic follows Role-Based Access Control (RBAC): each user is assigned roles, each role maps to a FUE type, and the highest authorization in a user's role combination determines their FUE type.

This is the structural difference from usage-based classification. A usage-based model would have SAP measure which transactions a user actually executes. Authorization-based classification measures what a user could execute. In S/4HANA Cloud, the authorization-based model applies.

The consequence is direct: every role scoped broader than actual need generates FUE costs that the user's real work does not justify.

In the Private Cloud Edition (PCE), this mechanism becomes even more pronounced. SAP triggers metering monthly and automatically. Whatever authorization is recorded in the system feeds into metering results every single month. The governance moment for authorizations does not arise once a year at audit time; it arises twelve times a year, whether it is acted on or not.

---

2. What an Oversized Role Costs: A Worked Example

The four FUE types carry clearly defined conversion weights:

User Type	FUE Weight	Cost Relative to Advanced
Advanced	1.0	Baseline
Core	0.2	1/5 of Advanced costs
Self-Service	0.033	approx. 1/30 of Advanced costs
Developer	contract-specific	check your contract

A user classified as Advanced who only needs Core functionality consumes 0.8 FUE more than necessary. Moving from Advanced to Self-Service saves 0.967 FUE per user.

A concrete example: an organization has 80 users classified as Advanced. A structured role analysis reveals that 30 of them actually need Core-level access and that Self-Service is sufficient for 20 more.

• 30 users moved from Advanced to Core: 30 x 0.8 = 24.0 FUE released
• 20 users moved from Advanced to Self-Service: 20 x 0.967 = 19.3 FUE released
• Total: 43.3 FUE reduction with no change in headcount

In an organization with a FUE pool of 150, that is nearly 29 percent of the pool freed up through role optimization alone. In a renewal context, this is the difference between a FUE pool that must be expanded and one that aligns with actual requirements.

---

3. Three Common Role Design Mistakes and Their FUE Impact

Mistake 1: Blanket Roles by Department

Roles are assigned at the department level rather than by work profile. Every member of a purchasing department receives the "Purchasing_Standard" role, which includes Advanced authorizations because certain specialists require them. Clerks who only enter purchase orders are therefore classified as Advanced, even though Core would be sufficient.

The pattern: roles are assigned based on organizational membership, not on actual functional need. This is administratively simpler, but it structurally inflates FUE costs. The FUE impact is rarely explicitly evaluated when a new role is created or an existing one is extended.

Mistake 2: Role Creep Through Exception Decisions

A Self-Service user needs one-time access to a transaction requiring Core authorization. The quickest fix is an add-on role. The task is done, and the role stays. Another user needs similar access and gets the same role. Eighteen months later, 40 users carry roles that, in combination, amount to Core authorization, even though the original license plan assumed Self-Service.

The FUE difference between Self-Service (0.033) and Core (0.2) is 0.167 FUE per user. Across 40 affected users, that is 6.7 FUE charged against the pool every month, with no conscious decision ever made to incur that cost.

Mistake 3: Developer Roles Without FUE Review

Developer users carry a contract-specific FUE weight that varies significantly depending on contract version. Some contract formulations set one Developer at 0.5 FUE; others set it at 2.0 FUE. With 20 developers, the difference can reach 30 FUE, which can translate into six-figure cost implications.

The mistake is failing to look up the Developer weight in your own contract and instead assuming a generic figure in FUE calculations. The actual contract wording determines the weight, not any generally communicated rule.

---

4. Optimization Steps Before the PCE Metering Cycle

Role optimizations that take effect after a metering cutoff only improve the following month's result. To make the governance moment for authorizations work predictably in your favor, you need to complete optimizations before the next metering run.

The following approach has proven effective in practice:

Step 1: Capture the Authorization Structure

Activate SAM4U Enhanced Usage Tracking and let it run for at least 30 days. This provides an actual usage baseline per user. In parallel, run a STAR analysis (S/4HANA Trusted Authorization Review) internally. It shows which authorizations are assigned.

Important: raw STAR data reflects assigned authorizations, not used ones. It should not be used unverified as the basis for external communications. Only cross-referencing STAR results with SAM4U usage data produces a reliable picture.

Step 2: Validate FUE Types Against Work Profiles

For each user type, ask: does the measured FUE type match the user's actual work profile? The relevant questions:

• Which transactions does this user actually execute, and which FUE type do they require?
• Are there roles that include Advanced authorizations even though the functions used are at Core or Self-Service level?
• Have role assignments been made since the last review without evaluating their FUE impact?

SAM4U's "Optimized Opportunities" function automatically identifies specific downgrade candidates. Authorization Simulation (available from Q4/2025 onward) lets you assess the FUE effect of a planned role change before implementing it.

Step 3: Clean Up Roles Technically

Remove authorizations that are assigned but consistently unused. Replace blanket roles that are scoped broader than needed with work-profile-specific roles. Limit role assignments technically to the level actually required, rather than defaulting to a broader profile when in doubt.

This step requires coordination between IT/Basis, the relevant business unit, and, where applicable, the Contract Manager. The FUE impact of every role change should be part of the review process.

Step 4: Complete Optimizations Before the Metering Cutoff

Anchor the next PCE metering run in your calendar and schedule clean-up work so it takes effect beforehand. Validate the next metering result against your own calculation and document any deviations.

Step 5: Establish a Governance Rhythm

The governance moment for authorizations is not a one-time project; it is an ongoing operational standard. A quarterly role review as a fixed checkpoint in your governance rhythm ensures role creep is caught early and does not accumulate across multiple metering cycles.

---

Frequently Asked Questions

Why does authorization determine FUE type rather than actual usage?

S/4HANA Cloud applies an authorization-based classification model: a user's FUE type is determined by the roles and authorizations assigned to them, not by the transactions they actually execute. What a user could do is the measuring criterion, not what they actually do.

How large is the FUE difference between user types in practice?

Advanced (1.0 FUE) is five times more expensive than Core (0.2 FUE) and roughly thirty times more expensive than Self-Service (0.033 FUE). The saving per user when downgrading from Advanced to Core is 0.8 FUE; from Advanced to Self-Service, 0.967 FUE; from Core to Self-Service, 0.167 FUE.

Can I reduce FUE during the contract term by optimizing roles?

Role optimizations reduce FUE consumption and therefore improve the headroom situation within the current pool. Reducing the contractually agreed FUE pool size mid-term is not possible under most RISE contracts. Optimizations therefore primarily serve as negotiating leverage for the next renewal, not as an immediate cost reduction.

What is the right first step if I don't know my current authorization status?

Install SAM4U (SAP Note 3646933) in your customer system and activate Enhanced Usage Tracking. This builds the usage baseline per user. Run a STAR analysis internally in parallel and compare both results. That comparison shows where assigned authorizations and actual need have drifted apart.

---

Related Articles

• Authorizations and FUE Costs: How Role Design Determines the License Base: An in-depth look at PCE metering, role creep, and a structured governance rhythm
• SAP License Management and the Maturity Model: Pillar Overview: Authorization-based classification in the context of overall license governance

---

Next Steps

If you want to integrate the governance moment for authorizations into your ongoing contract management in a structured way, start with a baseline assessment of your current role structure and its FUE implications. The Contract Check provides a structured starting point: it captures the license base, evaluates classification gaps, and makes optimization potential in the authorization area visible. Fixed price EUR 7,900, four weeks.

To schedule an initial conversation, contact Bernhard Mändle: Book a meeting