Named User and FUE: Understanding the Two Worlds of SAP Licensing

SAP licenses on-premise and cloud systems under different metrics. On-premise, the named user principle applies: every person with SAP access requires an individually assigned license of a specific type. In the cloud, specifically in RISE with SAP and GROW with SAP, the FUE model applies: customers purchase a pool of Full Use Equivalents and distribute them internally across user types. Organizations with both models in their portfolio need to understand both mechanics and have a clear picture of what the transition from named user to FUE means for ongoing governance.

1. Named User: Core Principle and License Types

The named user principle is straightforward: every individual who accesses SAP requires a named license. Concurrent-user models, where a fixed number of simultaneous users is licensed, do not exist in the SAP world.

License types differ significantly in scope and price. For ECC systems, five primary types apply:

Professional User grants full, unrestricted access to all modules and transactions. Power users, controllers, module consultants, and administrators typically fall into this category. List price is in the range of USD 3,000 one-time, plus annual maintenance of approximately 22 percent (source: Redress Compliance, SAP Product and Pricing Definitions).

Limited Professional User allows restricted access to defined modules or functions. Warehouse staff, purchasing clerks, or accountants with a limited transaction scope map to this type. List price is approximately USD 1,500 one-time.

Employee Self-Service (ESS) covers basic self-service tasks: time recording, travel expense reporting, and access to HR master data. This type is typically purchased in bulk packages.

Developer User enables access to ABAP Workbench and development tools. Important: Developer Users may be used exclusively for development purposes, not for productive business processes.

Test User is governed by contract terms and is reserved for QA teams and test automation in test and QA systems.

With S/4HANA On-Premise, SAP updated the nomenclature. The five categories are now: Professional User, Functional User (equivalent to the former Limited Professional), Productivity User, Self-Service User, and Developer User. The underlying logic remains the same, though SAP revised the assignment of certain transactions to user types in 2025. For migrations and contract reviews, a direct comparison of the current role-to-user-type mapping against the previous version is worthwhile.

The compliance requirement under the named user model is clear: every user type must be individually compliant. A user assigned a Limited type who executes Professional transactions is underlicensed regardless of how many unused Professional licenses exist in the same system.

2. FUE: Pool-Based Model and Conversion Weights

The FUE model (Full Use Equivalent) operates on a different principle: customers purchase a pool of FUE units and distribute them internally across user types. As long as the weighted sum of all users stays within the purchased FUE pool, the organization is compliant. Internal role shifts, for example from Advanced to Core, require no renegotiation with SAP, provided FUE headroom exists (source: SAP Community, RISE with SAP FUE Concept).

The four FUE user types and their weights:

User Type	FUE Weight	Users per FUE
Advanced	1.0	1
Core	0.2	5
Self-Service	0.033	approx. 30
Developer	contract-specific	contract-specific

The cost relationship makes classification the decisive planning parameter: one Advanced User equals 5 Core Users or approximately 30 Self-Service Users in FUE weight. Put differently, one Advanced User costs 30 times more in license terms than one Self-Service User and 5 times more than one Core User (source: redresscompliance.com, FUE Licensing Explained).

The Developer type warrants particular attention. In practice, different weightings appear across contract versions: some contract language calculates 0.5 FUE per developer, others 2.0 FUE per developer. With 20 developers, that is a difference of up to 30 FUEs, which can reach six figures. The specific contract must be reviewed before any calculation on this basis is made.

The formula for FUE demand is:

Total FUEs = (Advanced x 1.0) + (Core x 0.2) + (Self-Service x 0.033)

The result is rounded up.

A concrete example: 50 Advanced Users, 100 Core Users, and 300 Self-Service Users yield 80 FUE. If the same organization licensed all 450 users as Advanced, 450 FUE would be required. Correct classification reduces demand by more than 80 percent in this example (sources: SAP Community Blog by SAP: RISE with SAP FUE concept, RISE SDG v11-2024).

3. Cost Relationships: Why Classification Is the Most Important Governance Moment

The greatest optimization potential in the FUE model lies in classification quality. When a user is licensed as Advanced but actually uses only Core functionality, 0.8 FUE per user are consumed without that additional demand being justified by actual usage.

Correct classification according to actual functional scope is mandatory under the SAP Service Description Guide. Advanced classification applies by default when no explicit classification is in place. Organizations that classify all users as Advanced by default pay structurally more than necessary. Optimization begins with analyzing which users actually execute which transactions, not which permissions they theoretically hold (sources: RISE SDG v11-2024, SAP Community Blog by SAP).

The FUE model offers a structural advantage over the named user model: a surplus in one type can compensate for additional demand in another, as long as the total pool is not exceeded. This flexibility is a governance moment in the usage domain that can be planned and leveraged proactively. The prerequisite is that FUE consumption is reconciled against the contractual FUE pool on an ongoing basis, not just once a year.

One structurally important contract aspect: most RISE contracts prohibit reducing the FUE count during the contract term. Organizations that purchase too many FUEs pay for unused capacity until the next renewal. The initial FUE calculation is therefore one of the most consequential decisions in the contract context. A true-up/true-down clause that allows adjustment after 18 to 24 months is negotiable and should be actively addressed during contract negotiations.

4. Hybrid Landscapes: On-Premise and RISE in Parallel

Many organizations run on-premise and cloud systems side by side. In this setup, named user licensing and FUE licensing operate simultaneously, requiring separate governance for both dimensions.

On the on-premise side: USMM measures named users per system, LAW consolidates and deduplicates across systems. The compliance check occurs at the type level: is every user type individually compliant?

On the cloud side: PCE Metering captures FUE consumption automatically each month based on assigned entitlements. The compliance check occurs at the pool level: does the weighted sum of all users stay within the purchased FUE pool?

The challenge in hybrid landscapes is the coordinated governance of both metrics. Migrating a named user into a RISE system also changes the license metric for that user. What counted as Limited Professional in ECC may count as Core or Advanced FUE in RISE, depending on the actual role assignment in the new system. A migration analysis that evaluates the FUE implication of every planned user transfer is part of structured migration governance.

5. What Changes When Moving from Named User to FUE

The shift from the named user model to the FUE model changes not just the license metric but also the requirements for ongoing governance.

Under the named user model, correct type assignment is central: which user has which type, and is that type justified by the transactions they execute? The governance moment lies in classification quality and in the cleanup of inactive accounts.

Under the FUE model, an entitlement dimension is added: in S/4HANA Cloud, user type is determined not by actual usage but by assigned entitlement. A user assigned a role with Advanced permissions is counted as an Advanced User regardless of whether they actually use that permission. Role design is therefore a direct license cost lever that does not exist in the same form under the named user model.

The monthly PCE Metering cycle sharpens the time requirement: compliance issues become visible up to 12 times faster under the FUE model with cloud metering than in an on-premise context where measurement occurs once a year. This requires a monthly governance rhythm that was sufficient annually under the named user model.

6. Three Common Classification Errors and How They Arise

Most classification errors arise not from intentional misrepresentation but from structural causes: missing lifecycle processes, gradual permission creep, and insufficient documentation. The challenge lies in system complexity, not with the people working within it.

Error 1: Blanket Advanced is the most common and most costly pattern. Organizations without a structured user analysis assign Advanced or Professional permissions to all users because precise differentiation seems burdensome. The result is a systematically inflated FUE base. Since mid-term reductions are generally not possible in RISE contracts, this error is locked in until the next renewal.

Error 2: Role Creep describes the gradual expansion of permissions beyond the licensed level. A Self-Service User receives additional roles for a specific process step that de facto contain Core permissions. Under the FUE model, they are counted as a Core User from that point on, even though only a small-scale need exists. Without ongoing monitoring, role creep accumulates over months before it becomes visible in metering results.

Error 3: Inactive Accounts are counted by USMM under the named user model regardless of whether the user has accessed the system in the past two years. In organizations without a structured offboarding process, 10 percent or more of countable accounts are inactive. The established governance threshold for cleanup is 90 days without login (source: SAP-Named-User-License-Types, governance recommendations).

All three errors can be addressed through a structured governance rhythm: quarterly self-audits, ongoing monitoring of FUE consumption, and a defined threshold for cleaning up inactive accounts. The license maturity model in Pillar 6 describes what is concretely required at each level to move from reactive classification to active governance.

FAQ

What is the difference between Named User and FUE?

Named User is the classic license metric for on-premise systems: every person with SAP access requires an individually assigned license of a specific type. FUE (Full Use Equivalent) is the license metric for RISE with SAP and GROW with SAP: customers purchase a pool of weighted units and distribute them internally across user types. The essential difference lies in the compliance check: under the named user model, every type must be individually compliant. Under the FUE model, compliance is assessed at the pool level, meaning the weighted sum of all users must not exceed the purchased FUE pool.

What FUE types exist and how are they weighted?

Advanced User: 1.0 FUE. Core User: 0.2 FUE (5 Core Users = 1 FUE). Self-Service User: 0.033 FUE (approx. 30 Self-Service Users = 1 FUE). Developer User: contract-specific, in practice 0.5 or 2.0 FUE depending on the contract version. The specific contract must be reviewed.

Can I reduce FUEs during the contract term?

In most RISE contracts, a mid-term reduction of the FUE count is excluded. Organizations that purchase too many FUEs pay for unused capacity until renewal. A true-up/true-down clause allowing adjustment after 18 to 24 months is negotiable.

What happens to my license base when moving from ECC to S/4HANA?

The nomenclature changes, and SAP made adjustments to the mapping of roles to user types in 2025. Certain transactions that counted as Limited Professional in ECC may require Professional in S/4HANA. A reclassification analysis before go-live is advisable.

How many users actually need Advanced access?

In practice, typically only 10 to 20 percent of all users in an organization need Advanced access. Organizations that do not analyze the precise distribution pay structurally more than necessary.

Next Steps

If you want to assess Named User and FUE in your own SAP portfolio in a structured way, the Contract Review offers a structured starting point: capture the current state of the license base, identify classification gaps, evaluate optimization potential. Four weeks, fixed price: EUR 7,900.

Further articles in this series: