Authorisation-based user classification inflates SAP FUE counts by 50 to 150 percent, so a benchmark bought before you normalise your own units prices an inflated quantity at a fair rate

SAP publishes no FUE list price, which means the only number that exists is the one on your quote. If that quote was built from legacy licence archaeology and authorisation objects rather than measured activity, you can win the rate argument and still overpay by half, because you negotiated the wrong quantity. Normalise per FUE, per document, per support euro and per capacity unit first, then buy the benchmark.

Prepared by Redress Compliance · September 9, 2026 · SAP advisory. RISE, S/4HANA and ECC renewal engagements 2024 to 2026.

There is no single SAP price, and the vendor benefits every time a buyer talks as if there is. Your spend resolves into four separate unit economics, and each one has a different owner inside SAP, a different escalation path, and a different amount of give. Per FUE is where the sales team lives.

Per document is where Digital Access sits, quietly attached to volumes nobody in procurement measured. Per support euro on the owned on-prem base is a finance annuity that moves only if you shrink the base.

Per capacity unit (HANA memory, compute, storage under RISE) is where infrastructure sizing gets converted into subscription line items. If you hand a benchmarking firm one blended number, you get one blended answer, and it will be right about the rate and useless about the bill.

Two mechanics decide whether your FUE arithmetic is honest. First, the ratios are fixed: 1 FUE equals 1 Advanced user, 5 Core users, or 30 Self-Service users, and Developer Access consumes 2 FUE each. Nobody negotiates those.

Classification and rate are the only levers, which is why the classification fight matters more than the rate fight. Second, under RISE the highest monthly FUE count in the measurement period governs.

Build your baseline on peak month, not the twelve-month average, or you will price a quantity you never actually contract to and discover the delta at true-up.

On the document side, the $0.40 per document reference circulating in 2026 sits at the top of a range where published benchmarks put unit pricing between roughly €0.003 and €0.12 depending on document type, volume tier, and how hard the buyer pushed.

That is a fortyfold spread, which tells you the number is a negotiated artifact, not a price.

Practical sequence: express all four as rates, then compare yourself against the FUE benchmark bands buyers actually reach. A rate at the bottom of the band on a count inflated 80% is worse than a mid-band rate on a clean count.

Whoever owns the ECC-to-FUE mapping owns the deal. SAP's proposal does not arrive with a blank quantity field waiting for your input.

It arrives with the FUE count already derived from legacy licence archaeology, classified upward at every ambiguity, because classification is driven by assigned authorisation objects rather than measured activity.

A user with a display-only role that happens to carry a write-capable authorisation object gets counted Advanced.

Multiply that across a decade of role sprawl and you get the number the independent tooling vendors keep reporting: authorisation-based classification runs 50% to 150% above usage-based classification. That is not an edge case. In our engagements it is the base case.

The response is to arrive with your own count and make SAP disprove it. Run the STAR report (SAP Note 3113382) before any commercial conversation. It shows internally how activity converts into FUEs, which means you can identify and execute the reductions before SAP freezes a number in a proposal.

Pair it with authorisation object cleanup, because the report tells you where the inflation lives and the cleanup is what makes the lower number defensible.

The arithmetic is worth doing on a napkin. Take a 1,250-user population weighting to 123.3 FUEs, written 124 on the order form: 50 Advanced, 200 Core, 1,000 Self-Service. Every user you move from Advanced to Core removes 0.8 FUE. Advanced to Self-Service removes roughly 0.97 FUE.

Reclassify 30 of those 50 Advanced users down to Core and you take 24 FUEs out of the count, roughly 19% of the total, before you have said one word about rate. At a mid-band monthly rate that is real annual money, and unlike a discount it does not decay at renewal.

Expect SAP to respond by questioning your methodology, offering to "validate" your count with their own tooling, and warning that under-classification creates audit exposure.

That last point is the pressure and it is manageable: STAR output plus role documentation is evidence, and evidence shifts burden. Get your count locked and defensible, then bring the external rate evidence in without exposing the source.

Rate and quantity are not equally contestable, and SAP knows which side of that asymmetry it is standing on.

The rate is semi-public: third-party benchmarks circulate a $140 to $220 per FUE per month corridor, deal teams compare notes, and an account executive can defend a number inside that band to their desk without escalation. Quantity is private.

Nobody outside your organisation knows how many of your 1,250 users genuinely need Advanced authorisations, and SAP's own classification method (authorisations assigned, not activity performed) systematically resolves ambiguity upward. That is the whole game.

Discounting the rate costs SAP a percentage of a number it helped construct; conceding the count costs SAP the number itself.

So watch what happens when you arrive with a benchmark and no unit normalisation. You say the market pays $155. The account team says, reasonably, that they can get to $150 with a five-year term and a max success attach.

You have won the rate argument by a genuine 20 to 25 percent against the top of the band. You have also just priced 210 FUEs that should have been 130, because the mapping came from legacy licence archaeology rather than the STAR report. At $150 the inflated count costs $378,000 a year.

At $200 on a normalised count it costs $312,000. The buyer who lost the rate fight and won the quantity fight is 17 percent cheaper, and their per-unit number looks worse in every internal report.

Handing over the benchmark early does something worse than waste it. It tells SAP exactly which lever you intend to pull, and a competent account team will pre-concede that lever to close off the other one.

Once the rate is conceded to something defensible, every subsequent conversation about user counts becomes a conversation about reopening a price you already accepted. You have converted quantity from an open question into a settled assumption.

This is why the discipline of proving a benchmark without naming its source matters less as an anti-leak measure and more as a sequencing measure: the benchmark should arrive after the quantity is locked, as the last argument, not the first.

There is a second reason the sequence is not optional. Under RISE, FUE consumption is measured monthly and the highest month governs. Your baseline is a peak, not an average, and the peak is set by role design you control.

Every user moved from Advanced to Core removes 0.8 FUE; Advanced to Self-Service removes roughly 0.97. Cleanup work done before the count is contracted converts directly into contracted units.

The same work done after signature converts into shelfware you keep paying for until the next renewal, because the order form does not shrink when your authorisations do.

The 50 to 150 percent inflation that authorisation-based classification produces is only negotiable while it is contestable, and it is only contestable while you hold usage evidence SAP does not have. That evidence has a shelf life.

Once SAP's mapping becomes the shared working document (once it is in the business case, in the board slide, in the CFO's approved capex number) reducing it looks like the buyer changed their mind rather than the vendor overcounted.

The window is roughly the ninety days before SAP builds the proposal, not the ninety days after.

Sequence it: normalise your own units, then buy the benchmark to price those units, then negotiate. Reversed, a benchmark is a rate argument attached to a quantity SAP authored, and the per-unit bands buyers actually reach become a ceiling on your savings rather than a floor under your price.

A strong outcome looks like this in numbers: contracted FUEs within 10 percent of your own STAR-derived peak, a per-FUE rate anywhere in the $150 to $185 range, and a written classification methodology in the order documentation that references measured activity.

Buyers who get all three typically land 30 to 45 percent below SAP's opening total value, and almost none of that comes from the rate line.

On ECC, stop negotiating the 22 percent. It has held through every review cycle we have seen across 2024 and 2025, it is standard across SAP's installed base, and an account executive has no authority to move it. The variable that does move is the base it multiplies.

In our engagement experience the pattern is consistent with the published estimates: 10 to 25 percent of the annual maintenance fee sits on licences that are shelfware or formally retired but never removed from the schedule.

That is the negotiable line, and it is negotiable through documentation rather than argument.

The compounding maths is what makes this urgent rather than housekeeping. At 22 percent annually, cumulative support passes the original licence value in under five years, and the base rarely shrinks on its own because retired licences stay on the bill unless somebody removes them.

Layer the indexation on top: SAP adjusted support fees from 1 January 2026 by local CPI capped at 5.0 percent, following 3.3 percent in 2023 and 5.0 percent from 2024 onward. Every euro of shelfware you leave in the base in December gets indexed in January and indexed again the year after.

Scrubbing the base before the adjustment date is worth more than winning any argument about the cap, though the 3 to 5 percent uplift cap reality still belongs in the contract.

Do not model lapsing as an exit. Leaving SAP support and returning later triggers back maintenance and reinstatement charges that can reach 150 to 200 percent of the lapsed amount, which turns a two-year cost saving into a permanent premium.

Treat termination-for-convenience on specific line items as the real instrument: SAP will resist partial termination because it protects the base, and that resistance is the clearest signal you have found the right lever.

A strong outcome is a base 12 to 20 percent lighter going into the renewal, documented line by line, before the FUE conversation starts.

Treat the deadline calendar as a set of priced options, not as a countdown. Each date on SAP's roadmap has a number attached, and once you attach that number your baseline absorbs the deadline instead of your negotiating posture doing it.

Extended maintenance for Business Suite 7 runs three years from the start of 2028 to the end of 2030 at a premium of two percentage points on the maintenance basis.

Crowe's read is that this lands as a 9 to 12 percent total cost increase in practice, and it stacks on top of SAP's index-linked support adjustment, capped at 5.0 percent for 2026 and for the two cycles before it.

So the honest line item is not "extended maintenance is available." It is: three years at roughly 10 percent above a base already compounding at up to 5 percent a year, priced against whatever your migration would otherwise cost in the same window.

Eligibility is the part that decides whether you have that option at all. Extended maintenance is open to EHP 6 to 8 customers only.

If you sit on EHP 0 to 5, you have no extended maintenance path, but you can upgrade into EHP 6 to 8 and push your deadline to 31 December 2027 while buying eligibility. Cost that upgrade explicitly.

It is a comparatively cheap purchase of optionality, and optionality is what SAP's account team is trying to remove from your model.

The Compatibility Pack transition period closed on 31 May 2026, so that variable is settled and should stop appearing in your risk register as though it were still moving.

The 2031 to 2033 transition option is where the calendar becomes an actual price. Customers who signed by end of 2025 can adopt it in 2031 on commercially equivalent terms to their then-existing subscription. Sign in 2026 and you carry a standard 20 percent uplift when you switch.

It is purchasable from 2028, usable 2031 to 2033, and only in combination with the max success plan. That last clause is the tell: SAP is bundling premium services into the escape hatch, so the 20 percent is not the whole delta.

Now the counter-leverage. At end 2024, only 39 percent of SAP's 35,000 ECC customers had bought transition licences, and Gartner projects more than 13,000 still running ECC in 2030.

SAP cannot walk away from that installed base, and it knows the 2028 to 2030 window is where the revenue actually lands.

A strong outcome is a signed price that assumes you may not move until 2029, with the extended maintenance premium capped in writing and the 5 percent indexation negotiated down toward the 3 percent band that buyers are reaching on uplift caps.

The same five distortions repeat across 2024 to 2026 reviews. First, FUE counts arrive pre-built from legacy licence archaeology, classified upward at every ambiguity, because nobody on the buyer side has usage evidence to contest them.

Second, digital access first estimates come in 30 to 60 percent high, and DAAP conversions signed inside a renewal lock that surplus in at 30 to 50 percent above real volume, on multi-year paper.

Third, adoption credits of 50 to 90 percent get deployed precisely when the quantity is inflated: the credit makes an inflated unit count feel cheap in year one, then expires while the quantity persists.

Fourth, on-prem support bases carry 10 to 25 percent shelfware, and the rate holds at 22 percent while the base never shrinks.

Fifth, and quietly expensive, the naming split: SAP's paperwork says Full Use Equivalent, the market says Full User Equivalent, and the binding definitions live in the Service Description Document behind the order form, not in the deck your team reviewed.

A strong outcome is quantified before you ever ask for a benchmark. Run authorisation cleanup and land a 25 to 40 percent FUE reduction against SAP's opening count, on evidence you can show. Cut the digital access estimate by a third or more and refuse a DAAP conversion inside a renewal cycle.

Retire the shelfware line and take 10 to 15 percent off the support base. Then buy the benchmark, compare your normalised ACV per FUE against the bands buyers are actually reaching, and negotiate the rate on a quantity you can defend.

Rate discipline on an inflated quantity is a losing trade every time.

Related advisory: the full topic guide.

What is an SAP price baseline and why build one before benchmarking?

A price baseline restates your current SAP spend as unit rates: cost per FUE per month, cost per digital access document, support cost per euro of owned licence, and cost per capacity unit.

Without it, an external benchmark can only tell you whether your rate is competitive, not whether your quantity is real. Since authorisation-based classification typically inflates FUE counts by 50 to 150 percent, the quantity error is usually the larger of the two.

How do I calculate my current cost per FUE?

Take the annual contract value attributable to the S/4HANA Cloud private edition or RISE subscription, exclude infrastructure and services line items, and divide by the contracted FUE count on the order form. Compare the result against the $140 to $220 per FUE per month corridor third parties cite.

Remember SAP publishes no official FUE rate, so this corridor is indicative rather than a list price you can quote back.

How does SAP convert my users into FUEs?

The ratios are fixed: 1 FUE equals one Advanced Use user, five Core Use users, or thirty Self-Service Use users, and Developer Access consumes 2 FUE. Only the classification of each user and the negotiated rate move.

Because SAP classifies on assigned authorisations rather than actual activity, users who only approve or view are frequently counted as Advanced.

What is the STAR report and why does it matter in a negotiation?

STAR (SAP Note 3113382) lets you review internally how user activity converts into Full User Equivalents before SAP builds a count for you. Running it lets you arrive with your own evidenced FUE number and shift the burden onto SAP to disprove it.

Each user you reclassify from Advanced to Core removes 0.8 FUE, and Advanced to Self-Service removes roughly 0.97 FUE.

Should I use average or peak FUE consumption for my baseline?

Peak. Under RISE with SAP, FUE consumption is measured monthly and the highest monthly count in the period governs the bill. A baseline built on the twelve-month average will understate what you are actually contracted to pay for, and will collapse the first time SAP produces its own measurement.

How much does SAP typically overstate digital access documents?

Across 2024 and 2025 digital access reviews, SAP's first estimate ran 30 to 60 percent above the measured document count, usually because it drew on historic volumes and double-counted follow-on documents.

Buyers who sign a DAAP conversion inside a renewal without independent measurement routinely lock in 30 to 50 percent more document volume than they need. Read-only access is generally outside the document count.

Is the 22 percent SAP support rate negotiable?

Rarely. The rate holds in almost every review, but the base does not, and 10 to 25 percent of the annual fee typically sits on shelfware and retired licences that stayed on the bill.

Scrub the base before the January CPI-linked adjustment, capped at 5.0 percent for 2026, applies to it, and factor in that leaving support and returning later can cost 150 to 200 percent of the lapsed amount.