A Full Use Equivalent (FUE) is SAP's blended user metric for S/4HANA Cloud and RISE, and it converts every license type into one number using fixed ratios: Advanced Use counts 1:1, Core Use 1:5, Self-Service Use 1:30. The arithmetic is simple. The exposure is in the mapping. SAP decides which of your users land in which category, and a single misclassification across thousands of seats can move a contract by hundreds of FUE. This guide sets out how the count works, the published ratios, and where buyers reclaim FUE that was double counted.
FUE replaced the older Named User price list for cloud agreements. Under classic ECC the question was how many Professional and Limited Professional users you held. Under RISE and S/4HANA Cloud the question is how many FUE you have committed to, and FUE is the line item on the order form that everything else hangs from. Understanding the conversion table is the difference between a defensible commitment and a padded one. The metric sits alongside the older named user rules covered in our SAP named user licensing guide, and both feed the same audit measurement.
The four FUE categories and their ratios
SAP groups cloud users into four use types, and each carries a published conversion weight that turns raw headcount into FUE. The Advanced category is the expensive one at 1:1, while Self-Service users dilute at 30 to 1.
| Use type | Conversion ratio | FUE per 100 users | Typical role |
|---|---|---|---|
| Advanced Use | 1 : 1 | 100 FUE | Finance, controlling, full transactional authoring |
| Core Use | 1 : 5 | 20 FUE | Procurement operatives, warehouse, line managers |
| Self-Service Use | 1 : 30 | 3.33 FUE | Time entry, leave requests, expense submission |
| Developer Use | 1 : 1 | 100 FUE | ABAP and extension developers on the platform |
The categories are cumulative in capability. An Advanced user can do everything a Core or Self-Service user can, so SAP measures by the highest authorization a person holds, not by what they do on an average day. That single rule is where most over-counting begins. A manager who approves one purchase order a quarter can be pulled into Core Use because the approval authorization exists in the role, even though the same person spends every other hour in Self-Service tasks.
The classification lever: FUE is set by the highest authorization object a user can reach, not by observed behavior. Splitting composite roles so that occasional approvers are not permanently carried as Core Use is the most reliable way to reduce FUE, and it is fully inside the rules. On a 4,000-seat estate, moving 600 misclassified users from Core to Self-Service removes roughly 100 FUE.
A worked FUE calculation
Consider a 5,000-person S/4HANA population. The same people produce wildly different FUE counts depending on how authorizations are mapped. The table shows a defensible mapping against a padded one.
| Population segment | Headcount | Padded mapping | Defensible mapping |
|---|---|---|---|
| Finance and controlling | 400 | 400 Advanced = 400 FUE | 400 Advanced = 400 FUE |
| Procurement and logistics | 900 | 900 Core = 180 FUE | 650 Core, 250 Self-Service = 138 FUE |
| Line managers (approvals only) | 700 | 700 Core = 140 FUE | 700 Self-Service = 23 FUE |
| General workforce (time and expense) | 3,000 | 3,000 Self-Service = 100 FUE | 3,000 Self-Service = 100 FUE |
| Total | 5,000 | 820 FUE | 661 FUE |
The gap of 159 FUE on this single estate is entirely a function of role design, not of any change to what the business does. At a representative cloud rate, that gap is a six-figure annual difference carried for the full RISE term. The same discipline that controls named user counts under ECC controls FUE under cloud, and the audit tooling that measures it is described in our SAP license audit guide.
FUE, digital access, and indirect use
FUE covers human users only. Machine and system access is priced separately through SAP Digital Access, which counts documents rather than seats. A buyer who consolidates human users into a clean FUE count can still face a large indirect access claim if external systems create sales orders, invoices, or material documents in S/4HANA. The two metrics are independent, and SAP measures both. The document-based model and its nine document types are set out in our SAP digital access and indirect versus digital access guides.
The practical risk is double payment. A third-party CRM that writes orders into SAP can be charged once as digital access documents and, if its service account is also classified as a named user, a second time inside the FUE count. Mapping every technical account and clarifying whether it is a human FUE or a digital access source is a core step before any RISE signature.
FUE blocks and the commitment trap
SAP sells FUE in committed blocks on the RISE order form, and the commitment is a floor, not a ceiling. You pay for the contracted FUE whether or not every seat is filled, and growth above the block is billed at a higher unit rate than the original commitment. Over-committing at signature to win a headline discount is the most common and most expensive FUE error.
The disciplined approach is to commit to the verified current FUE plus a modest, contractually capped growth lane, then negotiate the unit price for additions in advance so that expansion does not reset the buyer's position. Conversion credits from existing ECC licenses can offset the initial block, and the rules for that offset are covered in our S/4HANA conversion credits guide. For the full commercial picture of RISE bundles, see the SAP RISE advisory page.
Audit timing matters: SAP can remeasure FUE during the term. If role sprawl has pushed Self-Service users into Core Use since signature, the next measurement raises the count and the bill. A quarterly internal FUE review, run with the same logic SAP applies, keeps the count honest and removes audit surprises. Our SAP optimization practice runs this as a standing service.
FUE versus the legacy named user price list
FUE did not appear from nowhere. It is the cloud-era replacement for the older named user price list that still governs ECC, and the two count the same people through different lenses. Under the legacy model, a buyer held discrete quantities of Professional, Limited Professional, and Employee licenses, each a separate line item with its own price. Under FUE, those distinctions collapse into a single weighted number, which is simpler to administer but harder to audit, because the conversion happens inside SAP's mapping rather than on a visible price list.
This matters at conversion. A buyer moving from ECC to S/4HANA Cloud carries an existing named user position that must be translated into FUE, and the translation ratio is negotiable. A generous translation preserves the value of the old licenses against the new commitment; a poor one strands it. Buyers who treat the FUE conversion as a clerical step rather than a negotiation routinely leave entitlement on the table. The legacy types that feed this translation are detailed in our SAP named user licensing guide, and the credit mechanics are in S/4HANA conversion credits.
The practical step is to baseline the ECC named user position first, classify every user to the lowest defensible legacy type, and only then convert to FUE. Converting an over-classified ECC estate produces an over-stated FUE count, because the inflation carries straight through the ratio. Cleaning the source data before conversion is the single most valuable preparation for a RISE move.
The five common FUE counting mistakes
Most FUE over-statements come from a small set of repeatable errors, and each is correctable before signature. The table sets out the five seen most often and the fix for each.
| Mistake | Effect | Correction |
|---|---|---|
| Approvers carried as Core Use | Inflates the 1:5 band | Split composite roles, move to Self-Service |
| Dormant accounts in the count | Pays FUE for leavers | Deactivate before measurement |
| Technical accounts as human FUE | Double counts with digital access | Reclassify service accounts |
| Over-stated growth commitment | Pays for empty seats | Commit to verified current plus capped lane |
| Developer users mis-sized | 1:1 band applied too widely | License only active platform developers |
The developer band deserves attention because it carries the expensive 1:1 ratio. Organizations frequently grant the developer authorization broadly to technical staff who never write ABAP or build extensions, and each of those users lands in the most costly FUE category. Restricting genuine developer authorization to the people who actually develop, and moving the rest to Core or Self-Service, removes FUE at the highest unit weight. The same authorization discipline that controls the named user count controls this, and the audit that measures it is described in our SAP license audit guide.
Non-production systems and FUE
FUE applies to the systems where productive work happens, but development, test, and sandbox environments raise their own questions. A user who exists only to test configuration should not consume the same FUE as a productive finance user, yet poorly governed environments replicate productive authorizations into test systems and inflate the count. Keeping non-production user populations clean, and confirming the contract scope for sandbox access, prevents test environments from quietly adding FUE.
The contract should be explicit about which environments are in FUE scope and which are covered under separate development or test terms. Where this is left vague, SAP measurement can sweep non-productive users into the productive count. Clarifying environment scope at signature, alongside the human-versus-machine separation, closes the last common source of FUE inflation before a RISE commitment is made. For the full commercial framing, see the SAP RISE advisory page.
Sizing the growth lane
The single most expensive FUE decision after classification is how much growth to commit to at signature. SAP encourages a generous growth block by attaching the headline discount to the larger number, and the larger number then becomes a floor the buyer pays for whether the seats fill or not. A 661 FUE estate that commits to 900 FUE for a better unit price pays for 239 phantom FUE every year of the term.
The disciplined structure commits to the verified current FUE plus a modest growth lane sized to the actual hiring and rollout plan, with the unit price for additions fixed in advance so expansion does not reset the negotiation. Where SAP wants a larger commitment, the buyer can trade term length or a reference for the discount rather than buying empty FUE. The benchmark discounts that anchor this trade are in our SAP discount benchmarks guide, and the renewal-timing discipline that sequences the commitment is in our SAP renewal strategy guide.
FUE is also remeasured during the term, so an over-committed block cannot be quietly recovered if seats go unused, while an under-committed one is topped up at the agreed addition price. That asymmetry, easy to add and hard to remove, is the reason a tight initial commitment beats a generous one. A quarterly internal FUE review keeps the real count visible so the next true-up is a known number rather than a surprise.
What to do before you sign a RISE FUE commitment
Three moves protect the number. First, baseline the real authorization profile of every user and map to the lowest defensible category, not the one SAP proposes. Second, separate human FUE from machine access so digital access is not double counted. Third, cap the unit price for FUE growth in the contract so expansion is predictable. Done together, these typically cut an opening RISE quote by 20 to 35 percent without removing any business capability.
FUE is a clean metric once the mapping is understood, and the mapping is negotiable evidence, not a fixed fact. For the full vendor context see the complete SAP licensing guide and the SAP advisory practice. For hands-on modeling, our software licensing advisory service builds the FUE baseline against your live system.