SAP does not licence by installs, servers or CPUs. It licences named users by access rights — and the licence you assign does not restrict what the user can do. That single asymmetry is where SAP overspend comes from.
The SAP licensing model has a reputation for being among the most complex and costly to manage. The reputation is earned, and the reason is structural rather than incidental.
Most software vendors calculate licence fees by counting something countable: active and inactive users, or servers, or CPUs. SAP named user licensing is based on access rights.
Roles determine access rights. What a user can do inside SAP determines the licence type they require.
Customers are required to allocate a licence to each user in SAP. Here is the part that catches people: the licence you allocate does not restrict the user’s access rights. The two are decoupled. Nothing stops you assigning a low-cost licence type to a user whose roles permit far more, and nothing stops you assigning an expensive one to a user who barely logs in.
Both errors cost money, in opposite directions:
Because the system does not enforce the relationship, it will not tell you which error you have made. You have to work it out by comparing what each user’s roles actually permit against what they have been assigned — for every user, across every system.
SAP software is high value and widely used. Without precise knowledge of how the systems are set up and configured, the manual effort required to manage it properly is enormous.
The predictable consequence is that SAP gets left out. Enterprise Software Asset Management and software licence optimisation programmes routinely cover Microsoft, and then stop short of SAP because SAP looks like a specialist problem requiring specialist people.
That exclusion is expensive. It leaves the single most costly publisher in most organisations outside the one discipline designed to control publisher cost — and the inefficiency it produces is not random. It is systematic, it compounds annually, and it grows with headcount.
Against that technical background sits a commercial reality worth stating plainly.
The SAP market is mature. Growth in a mature market does not come from selling the same product to new customers at the same rate, so mature software vendors look elsewhere — and compliance is one of the places they look. This is not unique to SAP; it is the general behaviour of large publishers with established customer bases and complex agreements.
You do not need a statistic to act on this. You need only accept that the party who wrote the ambiguous clause is the party who benefits from resolving it, and that they will resolve it at a moment of their choosing rather than yours. The defence is having your own position, computed from your own data, before the conversation starts.
The true-up is the visible cost, and it is usually the smaller one.
The disruption is the rest. An audit consumes the time of the people who understand your SAP configuration — which is a short list, and the same short list that everything else depends on. Data has to be gathered, positions reconciled, and explanations constructed for decisions taken years ago by people who have left.
Putting the people, processes and technology in place to avoid that can look daunting. It is worth it for a reason beyond audit defence: the same information that protects you in an audit is the information that lets you optimise. You are not paying for insurance. You are paying for a cost model you did not previously have.
Editor’s note, July 2026. This post was written in 2016. SAP introduced its document-based Digital Access model in 2018, which licences indirect use by counting the documents created rather than the people behind the integration. It changes how indirect use is licensed; it does not change the named user analysis described here, which still governs your direct users.
The optimisation mechanic in SAP is specific, and it is worth understanding before you evaluate any tool.
Users are assigned licence types. Their roles determine what they can actually do. Their usage records show what they actually did. Where a user holds a Professional licence but their roles and usage are consistent with Limited Professional, that user can be reclassified downwards. The same applies from Limited Professional to Employee.
Two things make this worth doing at scale rather than opportunistically. First, the default assignment in SAP is Professional — so users who were simply never classified are sitting on the most expensive type by omission, not by need. Second, maintenance is charged as a proportion of licence value, so a reclassification reduces the recurring cost as well as the one-off, every year thereafter.
The number of users affected is usually larger than anyone expects, because nobody has ever looked.
CerteroX SAM carries a dedicated SAP licence engine, one of six publisher engines in the product alongside Microsoft, Oracle, IBM, Adobe and Salesforce.
It reads SAP without touching production. A non-invasive ABAP connector pulls named users de-duplicated across systems, along with roles, role groups, engines and authorisation definitions. Reading the authorisation layer is what makes role-based analysis possible at all — without it you are comparing licence assignments to nothing.
It proposes the licence type each user should hold. Priority-ordered Analysis Rules apply your agreement’s definitions to each user’s roles and authorisations, and return current, suggested and optimal positions side by side. That is the reclassification exercise above, computed rather than estimated.
It measures usage. AppsMonitor records first-used and last-used dates and reports a utilisation figure over a rolling 90-day window, so dormant accounts and never-used licences are a list rather than an assumption.
It holds the position continuously. The Effective Licence Position — purchased, used, available, required, variance, exposure — is maintained as the data changes, not assembled the week the letter arrives. Package licence metrics are analysed alongside the named user position, because SAP will look at both.
SAP licensing is difficult because the licence you assign and the access you grant are two separate things that nobody reconciles. The system will not reconcile them for you, and the publisher has no reason to.
Read the roles. Measure the usage. Compare what each user holds against what each user needs. The gap in that comparison is your negotiating position, and it exists whether or not you have measured it.
Book a demo, or read more about CerteroX SAM.
Other posts covering the same ground.
An Oracle Unlimited Licence Agreement is only unlimited within its clauses. What certification actually asks of you, where toxic consumption creeps in, and why the measurement work has to start at the beginning of the term rather than the last six months.
Microsoft's August 2025 Product Terms changes: Extended Term standardised across programmes, Exchange and Skype for Business Server Subscription Editions, the Exchange and Windows 10 ESU programmes, and the Dynamics 365 F&O enforcement dates.
Renew, rescope or exit — an Oracle ULA gives you three routes and a narrow window to choose between them. The questions to settle first, and a six-point health check to see how ready you actually are.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.