SAP licenses represent a significant cost item for any organization running SAP S/4HANA. The FUE (Full Use Equivalent) model has introduced a new measurement logic compared to the traditional Named User License (NUL) used in SAP ECC — and with it, new complexities: how do you correctly calculate the number of FUEs required? Where do you start? And what are the most common mistakes?

On top of this, there is a frequently underestimated topic: user account management. Every user account has a cost — direct or indirect — and shortcuts such as shared accounts introduce risks that go well beyond any apparent savings.

This guide brings together everything you need to tackle the FUE topic in a structured way: from the contract to the calculation, through to the operational management of access.

What Are SAP FUEs?

FUE stands for Full Use Equivalent — not Full User Equivalent or Full Usage Equivalent, as it is sometimes incorrectly referred to. It is a metric introduced by SAP to measure license consumption based on the type of system usage, rather than a simple count of named users.

The FUE model applies primarily to SAP S/4HANA systems and replaces the previous Named User License (NUL) system used in SAP ECC OnPremise. The underlying concept works like a token: one FUE can be spent to purchase one advanced license (1:1 ratio), or used to cover multiple lower-tier user licenses.

FUE User Types and Conversion Ratios

There are four main user classifications, each with a different conversion ratio:

• Advanced — 1 FUE = 1 user (1:1 ratio). Covers users with broad authorizations, IT staff with administrative access, and users with profiles such as SAP_ALL.
• Core / Functional — 1 FUE = 5 users (1:5 ratio). Typically operational users with access to specific processes, such as goods receipt or service transactions.
• Self-Service / Productivity — 1 FUE = 30 users (1:30 ratio). Users with limited usage, typically accessing Employee Self-Service functionalities.
• Developer — 1 Developer consumes 2 FUEs (2:1 ratio).

In short: the broader a user's authorizations, the more FUEs they consume. Optimizing the authorization model also means optimizing license costs — but without distorting user profiles purely for the sake of savings.

Where to Start with FUE Calculations

The correct starting point is always the contract you have signed with SAP. Different price lists exist depending on the product type, and FUEs have slightly different names and codes from one contract to another — while maintaining the same underlying logic.

Contract Types and FUE Codes by Product

Below are the main contract types with their corresponding user codes:

SAP S/4HANA Enterprise Management

• HA — Developer Access
• HB — Professional Use
• HC — Functional Use
• HD — Productivity Use

SAP S/4HANA Private Cloud Edition

• GA — Development Access
• GB — Advanced Use
• GC — Core Use
• GD — Self-Service Use

SAP ERP Private Cloud Edition

• IA — Development Access
• IB — Advanced Use
• IC — Core Use
• ID — Self-Service Use

SAP HANA Enterprise Cloud Classic

• KA — Developer User
• KB — Professional User
• KD — Employee User
• KE — ESS User
• KF — ESS Core User

SAP HANA Enterprise Cloud – SAP S/4HANA

• LA — Development Access
• LB — Professional Use
• LC — Functional Use
• LD — Productivity Use

Each price list has its own codes, but the classification logic is consistent: identify the user's type of usage and apply the corresponding conversion ratio.

How to Technically Calculate the Number of FUEs

SAP provides standard tools for the calculation:

• S/4HANA OnPremise and Private Cloud: transactions USMM or SLAW (and their more recent equivalents).
• S/4HANA Public Cloud: the SAP for Me application.
• During migration from ECC: SAP provides a dedicated simulation program (OSS note 3113382) that estimates the licenses required based on users' current authorizations.

This last point is particularly important: the simulation program reads existing authorizations to estimate FUEs. If the authorization model is not aligned with the least privilege principle (need-to-know), the calculation will return a higher number of FUEs than actually necessary.

7 Key Points in FUE Calculation and Management

1. The Number of Users Is Not the Number of FUEs

Knowing how many users access SAP is a necessary but insufficient data point. The FUE count depends on the classification of each individual user, not on the total headcount. You need to analyze the authorizations of every profile to determine the corresponding usage type.

2. Process Structure Directly Influences FUE Count

The choice between centralized and decentralized processes has a direct impact on license costs. For example, if purchasing or accounting activities are distributed across multiple departments, more users will have access to functionalities classified as Functional (1:5 ratio), increasing the total FUEs required.

3. Without Historical Data, Use an Empirical Rule of Thumb

If you do not have historical usage data, upfront calculation is challenging. As a rough benchmark: on average, users classified as Professional account for between 40% and 60% of active users. This is a starting estimate, not a certainty — but it is useful for building an initial budget.

4. SAP_ALL Is Always Professional — No Exceptions

Any user holding the SAP_ALL profile is automatically classified as Advanced/Professional (1:1 ratio), since they hold all system authorizations. No user in the production environment should have this profile — neither for security reasons nor for license cost reasons.

5. IT Staff Tend to Have High Classifications

System administrators and IT users frequently access functionalities with broad authorizations, which typically places them in the Advanced category (1:1). This is an element to plan for explicitly — not something to discover after the fact.

6. The Controlling Area Requires Specific Attention

Controlling users often have access to authorization objects that SAP classifies as "full," precisely because of the cross-functional nature of their activities. Here too, the risk is a higher-than-expected classification if user profiles are not analyzed in advance.

7. Flexible Workflow Can Raise User Classification

SAP S/4HANA's Flexible Workflow may require authorization objects linked to the Professional user type. Incorrect parameterization leads to higher classifications than necessary. This process must be carefully reviewed and configured before the final FUE calculation is performed.

Shared SAP User Accounts: Apparent Savings with Real Costs

Every SAP user account has a cost — whether under a Named User or FUE model. Faced with this cost, some organizations resort to shared accounts: multiple people accessing the system with the same credentials. This practice is still common, particularly for managing external supplier access, and is perceived as a way to reduce operational costs.

In reality, the risks it introduces far outweigh any savings achieved.

The Concrete Risks of Shared SAP User Accounts

• Inability to attribute actions to a specific individual. If multiple people use the same account, the system log records actions but cannot identify who actually performed them. In the event of an audit, error, or incident, this gap is critical.
• Password shared among multiple people. The password of a shared account is known to everyone who uses it, rendering any individual authentication mechanism ineffective.
• Broad profiles driven by operational necessity. Because a shared account must serve people with different roles, it tends to accumulate wide-ranging authorizations. This increases the risk of unnecessary access and, under the FUE model, can raise the license classification.
• No control over who actually accesses the system. Informal credential sharing makes it impossible to know whether the people accessing the system are only those formally authorized.
• Contractual non-compliance with SAP. Shared use of a user account may constitute a violation of SAP license terms, with consequences in the event of an audit (see also the topic of Multiple Logon).

7 Best Practices for Correct SAP User Account Management

1. Create Only the User Accounts That Are Actually Needed in Production

Not every member of a team needs a SAP user account in the production system. In a group of 50 people, often only a subset has an operational need for direct access. Defining this perimeter reduces costs and simplifies management.

2. Use Screen Sharing for Verification Activities

Many system checks do not require direct access: they can be carried out via screen sharing with the user experiencing the issue, or through a dedicated IT account. There is no need to create a new user account for every one-off verification request.

3. Set Expectations Early on Resolution Timelines

If the organization is accustomed to receiving immediate support through shared access, moving to a model of individual accounts requires proactive change management. Issue resolution timelines and procedures will change: this needs to be communicated in advance, not after the transition.

4. Structure Access by Functional Area or Macro-Area

Defining access profiles by functional area (procurement, finance, logistics, etc.) makes it possible to maintain control even as the number of users grows. It is easier to manage and more defensible in an audit than accounts created on a case-by-case basis.

5. Prioritize Single Sign-On Over Local Credentials

Where possible, adopt Single Sign-On (SSO) systems: they reduce the number of credentials to manage, improve the user experience, and enable centralized access management — including streamlined revocation procedures when needed.

6. Evaluate the Adoption of a PAM Platform

For privileged access — particularly for IT staff and system administrators — consider adopting a Privileged Access Management (PAM) solution or a Firefighter tool. These platforms allow every privileged access event to be tracked, approved, and recorded, reducing risk and improving auditability.

7. Factor in the True Cost of Managing External Supplier Access

Supplier and external collaborator user account management is often the context in which shared accounts proliferate. Creating individual accounts for dozens of external users has a cost — but it also has value: in terms of security, traceability, and contractual compliance. This trade-off must be addressed explicitly, not avoided.

FUE and User Management: Two Sides of the Same Problem

FUE calculation and user account management are not separate topics: they directly influence each other. An incorrect authorization model generates more FUEs than necessary. Shared or poorly managed accounts introduce security risks and contractual non-compliance. And in both cases, the consequences are paid retroactively — at audit time or at contract renewal.

The right approach is to tackle both topics in a structured, preventive way: starting from the contract, analyzing users' actual authorizations, applying the least privilege principle, and adopting appropriate tools for privileged access control.

Frequently Asked Questions on SAP FUE and User Management

What does FUE mean in SAP?

FUE stands for Full Use Equivalent. It is the metric introduced by SAP for license calculation in S/4HANA, based on each user's type of system usage — not on a simple count of named user accounts.

What is the difference between FUE and Named User License?

The Named User License (NUL) model counts named users regardless of how they use the system. The FUE model introduces a classification by usage type (Advanced, Core, Self-Service, Developer) with different conversion ratios. The result: users with limited usage cost less in FUE terms than users with broad system access.

How do you calculate the number of FUEs required?

Start from the SAP contract to identify the applicable user codes, then analyze each user's authorizations to determine their classification. For S/4HANA OnPremise and Private Cloud, use transactions USMM or SLAW; for Public Cloud, use the SAP for Me application. During migration from ECC, a simulation program is available via OSS note 3113382.

Are shared user accounts permitted in SAP?

No. Shared use of a SAP user account may constitute a violation of SAP license contractual terms, in addition to introducing significant security risks: inability to attribute actions to a specific individual, shared passwords, overly broad profiles, and no effective control over actual system access.

What can be done to optimize FUE costs without distorting user profiles?

FUE optimization comes from aligning the authorization model with the least privilege principle: removing unnecessary authorizations, reviewing IT staff profiles, verifying Flexible Workflow parameterization, and analyzing Controlling area user profiles. The goal is not to reduce authorizations purely to cut license costs, but to have a model that accurately reflects actual system usage.