SAP FUE Licensing: 2026 User Count Calculation

SAP fixes the FUE ratios and leaves you the only two things that move: which bucket each user sits in, and what you pay per unit. This page works both, from a 1,250 person population through to an annual subscription line, plus the floor, the ECC mapping, and the clauses that decide what happens when the count drifts.

Model it first with our SAP FUE calculator.

Key takeaways

The ratios are fixed. One advanced user is 1 FUE, five core users are 1 FUE, thirty self service users are 1 FUE, one developer is 2 FUE.
What is negotiable is the bucket each user sits in and the price per FUE. Never the ratio.
SAP publishes no FUE price. The only rate that exists is the one on your quote.
The private edition base package carries a floor. On the order forms we read it is 35 FUE.
No SAP table converts ECC named user types into FUE. That mapping is a proposal, and it is priced.
One FUE is pooled. It buys one advanced seat, or five core seats, or thirty self service seats.
Going over is billed on an extra order form and can be back billed to the month you crossed.
Going under is not refunded, and it does not lower the renewal baseline unless you wrote that right in.
Classify from usage evidence, then spend the finding at renewal, because there is no mid term reduction.

This guide is for SAP procurement leaders and license managers sizing a cloud subscription in 2026. Read it with the SAP licensing guide and the S/4HANA user types guide. It pairs with an independent SAP license compliance review.

How does the SAP FUE metric actually work?

FUE replaces counting named users one for one. SAP weights each user by the role they hold, then totals the weighted figures to set your contracted FUE count. SAP describes its cloud ERP on the S/4HANA product pages.

Are the FUE conversion ratios negotiable?

No. SAP's cloud terms fix the conversion and we have never seen a signed order form move it: one advanced user is 1 FUE, five core users are 1 FUE, thirty self service users are 1 FUE, one developer is 2 FUE. A negotiation round spent on the ratio is a round gone. Two things do move. Which bucket each user sits in moves, and the price you pay per FUE moves.

Developer, 2 FUE each: the heaviest unit in the model. One ID, two units, and the ID does not have to log in to be counted.
Advanced user, 1 FUE each: create, change, configure, full functional access. SAP's default landing for anything that used to be a Professional user.
Core user, 0.2 FUE each: five to one. Operational transactions inside a defined scope.
Self service user, 0.0333 FUE each: thirty to one. Own data, requests, approvals, reporting.

One naming trap before you search your contract. SAP's own paperwork calls the unit a Full Use Equivalent. Most account teams say Full User Equivalent out loud, and so does most of the market. Same unit. Search the PDF for both phrases and for the bare string FUE, because the definition that binds you sits in the Service Description Document for RISE with SAP S/4HANA Cloud, private edition, not in the deck the ratios were shown to you on.

How do you work a FUE calculation?

Take each population, multiply by its ratio, then add the results. A site with 50 advanced, 200 core, and 1,000 self service users lands far below 1,250 once the light weighting applies.

What does a worked FUE example look like?

The table below shows how a large raw headcount collapses into a much smaller weighted total. The light tier carries most of the headcount but little of the cost.

FUE calculation on a 1,250 person population, at SAP's fixed ratios

User type	Headcount	Fixed FUE per user	Weighted FUE
Advanced	50	1.0	50
Core	200	0.2	40
Self service	1,000	0.0333 (30 to 1)	33.3
Total	1,250	n/a	123.3, written as 124

Two things that table hides. First, 1,000 divided by 30 is 33.3, not 33, so the honest weighted total is 123.3. Every RISE order form we have read states FUE as a whole number, so this population is written as 124 FUE unless somebody argues the rounding. That unit is small money and a useful first read on whether your account team rounds toward you. Second, the 124 is pooled. Nothing in the contract ties those units to the named people in the table.

What does one FUE actually cost?

SAP does not publish a price for FUE. There is no public price list for RISE with SAP S/4HANA Cloud, private edition, no per unit rate on sap.com, and no part number you can look up the way you can look up an Oracle processor license. The only real number is the one on your quote, which is why so many buyers model the FUE count beautifully and then have nothing to multiply it by.

What we can give you is our own file. Across the RISE order forms we read in 2024 and 2025, the base package was quoted before discount in a band of roughly USD 130 to 190 per FUE per month, and the signed net rate on multi year commitments above 500 FUE landed in a band of roughly USD 70 to 120. Both bands are observed from a small sample of order forms, not published rates. They move with region, term length, scope, and whether Premium or Premium Plus sits on the base. Use them to smell test a quote. Do not put them in a business case.

Everything priced below uses USD 100 per FUE per month as a round modeling rate, so you can drop in the net rate from your own order form and redo every line in your head.

Is there a minimum FUE count?

Yes, and it decides whether the optimization work is worth doing at all. The private edition base package carries a floor, and on the order forms we have read that floor is 35 FUE. You pay it whether or not your weighted total reaches it. Find the number in your own Service Description Document before you model anything, because nobody on the sell side volunteers that your reclassification project stops paying below it.

Take a smaller estate: 12 advanced users, 40 core users, 300 self service users. That weights to 12 + 8 + 10, which is 30 FUE. Billed at a 35 FUE floor you pay for five units nobody uses, so 5 × USD 100 × 12 = USD 6,000 a year. Under the floor, further reclassification buys you nothing. Above it, every unit you take out is cash.

What does the 1,250 person example cost?

The worked example above stops at 124 FUE, which is exactly where the interesting part starts. Here is the rest of it at the modeling rate.

Scenario for the same 1,250 people	Arithmetic at USD 100 per FUE per month	Annual subscription
Defensible weighted total	124 × 100 × 12	$148,800
Everyone licensed as advanced	1,250 × 100 × 12	$1,500,000
Carrying 20 percent over classification	149 × 100 × 12	$178,800
Carrying 35 percent over classification	168 × 100 × 12	$201,600
Annual gap you are defending	$178,800 or $201,600 minus $148,800	$30,000 to $52,800
Same gap across a five year term	$30,000 × 5 and $52,800 × 5	$150,000 to $264,000

Substitute your own rate and the shape holds. At USD 150 per FUE per month the same gap is USD 45,000 to USD 79,200 a year. The rate is not the point. The point is that the over classification sitting in most estates is worth six figures across a term and is invisible on the order form, because the order form shows one number.

Two of the percentages on this page look like one number counted twice. They are not. Over classification inflates the total by 20 to 35 percent above what the evidence supports, and taking that off an already inflated total is a 17 to 26 percent cut. Reclassification recovers 10 to 25 percent in practice, because part of the gap turns out to be real usage you cannot argue away and part of it belongs to people who leave the project before you finish.

One more piece of arithmetic to carry into the room. One FUE buys one advanced seat, or five core seats, or thirty self service seats, and you can move people between buckets during the term as long as the weighted total stays at or under the commit. That makes reclassification an internal exchange rather than a purchase. Move 100 users from advanced to core and you free 100 minus 20, so 80 FUE. At the modeling rate that is 80 × 100 × 12 = USD 96,000 a year, or 2,400 self service seats you never have to buy.

Put your own numbers on this. The free SAP calculator prices your RISE FUE conversion, the modeled per FUE corridor, and Digital Access document costs, then hands you a two page executive summary you can forward to your CFO. No account, no sales call. Run the SAP calculator →

How do ECC named user types map to FUE?

SAP publishes no conversion table from ECC named user types to FUE. Ask for the official one and you will be handed a slide. Every conversion is drafted by the account team, priced into the deal, then signed on your order form, which makes the mapping the most negotiable number in a RISE conversion and the one buyers most often accept as though it were arithmetic.

The opening proposal is reliably generous to SAP. Below is the map SAP typically opens with, next to the landing the usage evidence usually supports, stated per 100 users of each legacy type so you can scale it against your own counts. Legacy type names follow the price list terms used in the SAP licensing guide.

ECC named user type	SAP's opening map	FUE per 100 users	Landing the usage evidence usually supports	FUE per 100 users	FUE freed per 100
Professional User	Advanced, 1 to 1	100	Core, 5 to 1, for the display and approval population	20	80
Limited Professional	Core, 5 to 1	20	Self service, 30 to 1, for request only users	3.3	16.7
Employee User	Core, 5 to 1	20	Self service, 30 to 1	3.3	16.7
Employee Self Service (ESS)	Self service, 30 to 1	3.3	Self service. Already correct	3.3	0
Developer User	Developer, 1 to 2	200	Developer. The money is in deleting dormant IDs, not reclassifying live ones	200	0 by reclassification, 2 per ID deleted

Read the last column as the prize per 100 users, and claim it only where the evidence claims it for you. A Professional user who posts journal entries is an advanced user, and arguing otherwise loses you the room for the rest of the meeting. The ESS row sits in the table to make exactly that point: it is already where it belongs and there is nothing in it to take.

The developer row is the expensive one and the one nobody checks. At 2 FUE each, 100 developer IDs consume 200 FUE, which is 200 × 100 × 12 = USD 240,000 a year at the modeling rate, more than the entire 1,250 person population in the worked example. Reclassification will not help you there, because a developer is a developer. Deletion will. One dormant developer ID is 2 FUE, and 2 FUE is 60 self service seats.

Where the evidence comes from

Three sources, all inside systems you already run, all exportable before SAP asks a single question.

SU01, License Data tab: the contractual user type on each account, stored in table USR06, field LIC_TYPE. That one field is what your bill is computed from, and in most estates it was set years ago by whoever created the account.
Table USR02, field TRDAT: last logon date per user. Sort it and the dormant population falls out in an afternoon. Dormant IDs are the cheapest FUE you will ever remove, because nobody has to be told anything.
ST03N, the workload monitor: transaction and app profile per user across a period you choose, with STAD behind it for record level detail. This is what turns "she is a Professional user" into "she ran four display transactions in ninety days".

Then run the count yourself before SAP does. Private edition is the same ABAP stack you run today, so the measurement still comes out of USMM, consolidated through LAW or SLAW where you have more than one system. Our reference on those tools is the USMM, LAW, SLAW and STAR guide.

Where do buyers overpay on FUE?

The common error is classifying staff too high. An approver who only signs off requests does not need an advanced license, yet many contracts carry exactly that mismatch. SAP RISE pricing context sits on the RISE with SAP pages.

How do you optimize the FUE count?

Map real usage against role definitions, then move each user to the lowest role that fits. The exercise is unglamorous, but it routinely takes double digit percentages off the weighted total.

Pull usage data: see what each user actually does.
Match to role: assign the lightest role that covers the work.
Document the basis: keep evidence for the next true up.

What happens if you go over the FUE commit, or under it?

The commit is a purchase quantity, not a technical cap. Nothing stops user 125 from logging in and nothing tells you it happened. The excess surfaces at the measurement, months later, in a conversation you did not schedule.

When does SAP actually count?

Read your order form rather than assuming annual. The measurement obligation, the reporting cadence and SAP's separate verification right sit in three different documents: the Order Form, the Service Description Document, and the General Terms and Conditions for SAP Cloud Services. The GTC is a versioned PDF with a version stamp in its footer, and the version that binds you is the one in force on the date you signed, not the one posted on the SAP trust center today. Get the signed set as PDFs, check the footer stamps against what you were shown, and file them where the next SAM manager will find them.

What happens	What the standard order form does about it	Cost on a 124 FUE commit at USD 100 per FUE per month	The clause that fixes it
You run 10 FUE over for eight months	Nothing until the measurement, then an additional order form, potentially back billed to the month you crossed	10 × 100 × 12 = $12,000 a year, plus 8 × $1,000 = $8,000 back billed	Charges start at the new order form date
You run 20 FUE under for two years	Nothing. No credit, no refund, no mid term reduction	20 × 100 × 12 = $24,000 a year, so $48,000 across the two years	Annual reduction right with 90 days notice
Renewal quoted on the 124 you committed, not the 104 you used	The renewal baseline is the prior commit	$148,800 against $124,800, so $24,000 a year of air and $72,000 across a three year renewal	Renewal quantity set from the latest measurement
Mid term you prove 30 advanced users are core	No mid term reduction. You bank the evidence and wait	30 × (1.0 − 0.2) = 24 FUE, so $28,800 a year until your next reduction date	Reclassification is not a breach, plus the reduction right

The words to get into the order form

None of these are exotic, and every one is cheaper to ask for before signature than to argue for after.

Incremental FUE at the signed net rate: additional units for the remaining term at the rate you negotiated, not at SAP's then current rate. Without it, your growth is priced off a table you have never seen.
Charges start at the new order form date: this kills back billing to the month you crossed the line. On a 10 FUE overage found eight months late, that single clause is worth USD 8,000 at the modeling rate.
Annual reduction right: a stated percentage you may drop at each anniversary or renewal on 90 days notice. We ask for 15 to 20 percent and typically land 10 to 15 percent.
Renewal quantity from the latest measurement: the renewal baseline is your measured position, not your prior commit. This is the anti ratchet clause and the one SAP resists hardest.
Reclassification is not a breach: an explicit statement that moving a user between FUE buckets on documented evidence needs no SAP consent and triggers no re pricing.
Escalator cap: RISE paper carries an annual increase, in our experience in the 3 to 7 percent band. Cap the annual figure and the cumulative figure across the term, in the same sentence.

One warning on the reduction right. Fifteen percent of a 124 FUE commit is 18.6 units, so 18 in whole FUE, which does not cover the 24 units the reclassification in the table above actually found. Ask for the reduction right as the greater of the percentage or your most recent measured position, and ask for it in the same round as the escalator cap so SAP has to price the pair together.

How does FUE play into a RISE renewal?

RISE bundles are quoted in FUE, so the classification feeds straight into the renewal price. Walking in with a defensible, optimized count changes the starting position before discount talks begin.

The conversion is a proposal wearing the clothes of a calculation

Buyers treat the ECC to FUE conversion as arithmetic. Take the named user list, drop each type into the matching bucket, read off the total, then go and negotiate the discount. That is precisely how the account team needs it treated, because the account team wrote the mapping and nobody audits it before signature. On the populations Fredrik Filipsson worked in 2024 and 2025, the straight mapping ran 20 to 35 percent above what the usage evidence supported, and almost all of the gap sat in Professional users who had not opened a create or change transaction in a year. So concede the ratios in the first minute, since they will not move, and spend the whole meeting on the bucket. Every 100 users you shift from advanced to core is 80 FUE, USD 96,000 a year at USD 100 per FUE per month, and that argument is won with an ST03N export rather than an opinion.

Open plan office with staff working at desks — Most of the headcount sits in the lightest tier, where the weighting, and therefore the cost, is smallest.

30 to 40

FUE populations worked, 2024 to 2025

20 to 35%

Typical over classification gap

FUE floor on the base package order forms we read

Source: Redress Compliance advisory engagement file, 2024 to 2025. The 35 FUE figure is the base package floor written on the private edition order forms in that file, not a published SAP rate. Confirm the floor on your own Service Description Document.

One dormant developer ID costs two FUE. That is sixty self service seats you are buying so that nobody has to clean a user list.

What to do next

Export the full named user list with current role assignments.
Pull actual usage data for each user over a representative period.
Reclassify every user to the lowest role that fits the work.
Recalculate the weighted FUE total on the corrected mix.
Compare the optimized total against your contracted figure.
Build the gap into your renewal or true up position.
Find the FUE floor in your Service Description Document before you model anything.
Price the gap at the net per FUE rate on your own order form, not at a benchmark band.
Put the reduction right, the incremental rate hold and the escalator cap on the table in one round.
Re run the review before each renewal as roles change.

White Paper · SAP

SAP named user licenses. The user classification audit

Read it free.

Read the white paper

FUE counts drift every quarter as roles change. Ongoing SAP license management services keep the conversion honest between renewals.

Need help? Try our AI agents. Ask the SAP licensing AI agent → Scoped to one vendor and one problem. Runs in your browser.

Frequently asked questions

What is a Full User Equivalent in SAP licensing?

A Full User Equivalent, or FUE, is a weighted unit SAP uses to count cloud users. Each named user maps to a role type, and each type carries a conversion ratio that sets its share of the total.

How do you calculate the FUE count?

Classify every user by the role they hold, apply the conversion ratio for that type, then add the weighted figures. A few advanced users plus many light users lands well below a raw headcount.

Which user types weigh the most in the FUE model?

Developers are heaviest at 2 FUE each. Advanced users count 1 FUE each. Core users count five to one, so 0.2 FUE each, and self service users count thirty to one, so 0.0333 FUE each. One developer ID therefore costs the same as sixty self service users.

Why does FUE matter for SAP cloud contracts?

FUE is the metric SAP uses to price S/4HANA Cloud and many RISE bundles. Misclassifying users inflates the FUE total and the cost, so accurate classification is the largest single lever.

Can you reduce your FUE total without removing users?

Yes. Reclassifying users to the lowest role that fits their actual work lowers the weighted total. Many buyers carry advanced licenses for staff who only run reports or approve requests.

How much can reclassification save?

Across our benchmarks it commonly cuts the weighted FUE total by 10 to 25 percent, and the saving comes from light users wrongly licensed as core or advanced years earlier. On the 1,250 person example on this page that is a 149 FUE order form against a 124 FUE order form, so $178,800 against $148,800 a year at USD 100 per FUE per month.

Is FUE used outside of RISE?

FUE prices S/4HANA Cloud and many RISE bundles. The same weighted logic frames how SAP expects cloud user populations to be counted across its current commercial models.

How often should you review the FUE classification?

Review it before every renewal and after any major rollout. Roles drift as projects end and teams change, so a classification set two years ago rarely matches current usage.

Are SAP's FUE conversion ratios negotiable?

No. SAP's cloud terms fix them at one advanced user to 1 FUE, five core users to 1 FUE, thirty self service users to 1 FUE, and one developer to 2 FUE. We have not seen a signed order form move a ratio. What moves is which bucket each user sits in and the price you pay per FUE, so spend the meeting there.

Does SAP publish an ECC to FUE conversion table?

No. There is no standard table. Every conversion from ECC named user types into FUE buckets is drafted by the account team, priced into the deal and signed on your order form. Treat the first map you are shown as an opening position rather than arithmetic, and answer it with transaction evidence from ST03N and last logon dates from table USR02.

Is there a minimum FUE count on RISE with SAP?

Yes. The private edition base package carries a floor, and on the order forms we have read that floor is 35 FUE. You pay it whether or not your weighted total reaches it, so a population that weights to 30 FUE is still billed at 35. Confirm the floor in your own Service Description Document before you model anything.

What does one FUE cost?

SAP publishes no list price for FUE, so the only rate that exists is the one on your quote. Across the RISE order forms we read in 2024 and 2025 the base package quoted before discount sat in a band of roughly USD 130 to 190 per FUE per month, and signed net rates on multi year commitments above 500 FUE sat in a band of roughly USD 70 to 120. Both are observed from our own file, not published rates.

What happens if you use more FUE than you contracted?

Nothing stops the users. The excess surfaces at the system measurement and SAP issues an additional order form. Two terms decide the damage: whether incremental FUE carry your signed net rate, and whether the charge starts at the new order form or is back billed to the month you crossed. Both are negotiable before signature and neither is after.

Can you reduce the FUE count at renewal?

Only if you wrote the right in. The renewal quote is built from your committed quantity, not your measured usage, so under consumption carries forward at full price. We ask for a 15 to 20 percent reduction right with 90 days notice and typically land 10 to 15 percent. Ask for it as the greater of that percentage or your latest measured position.