An SAP licence-type inventory is the foundational document of every compliance programme. It is the single record that answers the questions an audit will ask before the audit begins: what licences does the organisation hold, against which entities, with which engine metrics, at which classification, and against which actual usage. Most buyer organisations cannot produce that document on demand. The contract is filed in procurement, the USMM lives in basis, the user list lives in SAM, the engine readings live nowhere centralised. The inventory is the artefact that consolidates these into one buyer-side source of truth, and building it is the first work of any serious compliance programme.
What the inventory actually is
The licence-type inventory is not the contract. It is the structured extraction of every chargeable position from the contract, mapped against the operational reality. For a typical mid-sized SAP estate it contains four registers. The named-user register lists every classifiable user-type sold in the master agreement, with the contracted quantity, the current measured quantity, the variance, and the contracted unit price. The engine register lists every engine-metric line item, with the metric definition, the contracted base, the current measured throughput, and the carve-outs that apply. The indirect and digital-access register lists the contractual position on integration-driven exposure. And the entitlement register records the legal entities that may use the licences and the territorial restrictions that apply.
The four registers together are the buyer’s view of the licence position. The audit is the SAP team’s view of the same position. The settlement, when an audit comes, is the negotiation between those two views. Without a buyer-side inventory, that negotiation has only one position in the room.
Why most estates do not have one
Three structural reasons. The first is that SAP contracts are stratified across years and amendments — a master signed in 2009, an amendment in 2014, an addendum in 2018, a RISE order form in 2022 — and the consolidated entitlement is nowhere on paper. The second is that the user, engine, and integration data live in different systems and different functions, and no one’s job description includes consolidating them. The third is that the discipline of maintaining the inventory requires periodic measurement against transaction-history data, which most SAM tools do not do natively. The inventory is achievable but not automatic. The work is real.
How to build the named-user register
The named-user register starts with the contract. Every classifiable named-user type sold across the contract stack is listed, with the order-form quantities, the unit prices, and the consolidated total. Professional, Functional, Limited Professional, Developer, ESS, Self-Service, Platform User — every type appears once, even if zero are contracted, because the absence of a category is part of the position. Against each type the current USMM-measured population is listed, validated against transaction history. The variance — positive or negative — is the live exposure or the live surplus.
Most estates discover at this point that the headline shortage in one category is offset by a surplus in another. The contractual right to reclassify within the named-user bucket structure is the lever that addresses this, and it is described in the named-user buckets explainer. The inventory makes the reclassification possible because it surfaces the surpluses.
The transaction-history validation pass
A user classified as Professional in the USMM may have no Professional-grade transaction activity over a rolling twelve-month window. That user is a reclassification candidate. The validation pass — usually pulled from ST03N and SCC4 logs — is the work that converts the USMM output from an SAP-facing extract into a buyer-side defensible position. The methodology is detailed in our USMM and LAW topic page.
How to build the engine register
The engine register is the harder of the two foundational registers because engine metrics are heterogeneous: orders, line items, GB consumed, payslips processed, full-time-equivalent employees, e-document volumes, and so on. Each metric has a definition in the contract, a measurement source in the system, and a set of carve-outs that should be applied. The register lists every engine metric sold, the contractual base, the current measurement, and the variance.
The crucial discipline is the carve-out documentation. Engine metrics frequently include carve-outs for internal traffic, for test systems, for inter-company transactions, for batch processing, and for non-production environments. The carve-outs are often the difference between a defensible position and an over-stated finding. They should be written down once, in the inventory, and applied every measurement cycle.
The indirect and digital-access register
The third register is the integration-driven exposure. For pre-2018 contracts the position is indirect access; for post-2018 contracts the position is Digital Access measured in documents. Most estates carry a mixed position because the pre-2018 indirect-use position does not auto-convert. The register lists every non-SAP application that touches SAP data, the user population of that application, the document volumes flowing across the integration, and the contractual classification of each chargeable event.
The register is the artefact that determines whether the integration topology has been documented before the audit. Documenting it after the audit notification is possible but more expensive. The Digital Access Pricing Decoded white paper covers the conversion economics.
The entitlement register
The fourth register records the legal entities authorised to use the licences and the territorial restrictions on use. Corporate transactions — acquisitions, divestitures, joint ventures — routinely fall outside the entitlement scope, and the gap surfaces only in audit. The entitlement register surfaces it in advance. The register lists every legal entity, the territory of permitted use, the affiliate definition that applies, and the change-of-control provisions in the master.
How often to refresh the inventory
The inventory should be refreshed annually as a discipline, and immediately on any of five triggers: a corporate transaction (acquisition, divestiture, JV), a major integration build, an SAP product addition (a new module, a RISE conversion, a SuccessFactors expansion), a renewal cycle inside twelve months, and an audit notification. Outside those triggers, an annual refresh is sufficient.
The refresh discipline is what converts the inventory from a one-off project deliverable into a live operational tool. Most organisations build the inventory once, congratulate themselves on the work, and leave it to drift for three years. The drift is what an audit finds.
What an audit looks like with the inventory in place
An audit conducted against a current, validated, well-documented buyer-side inventory follows a different trajectory from the typical pattern. The opening claim, when it lands, is read against the inventory, the variances are identified inside ten business days, the position paper goes back to SAP inside six weeks rather than ten, and the settlement closes inside ten to twelve weeks rather than sixteen to twenty. Across our engagements where the buyer-side inventory existed before the notification, the average reduction from opening claim to settlement is higher than the headline sixty-eight per cent. The inventory does not change SAP’s opening position. It changes the speed and the leverage of the buyer’s response.
The compliance programme that produces and maintains the inventory is described in our SAP licence compliance assessment service, and the broader compliance methodology is in the license compliance pillar. The global pharmaceutical compliance baseline case file walks through one inventory build in detail.
The licence-type inventory is the single most useful artefact in an SAP compliance programme. Most estates do not have one, and they pay for the absence in every settlement.
If the inventory does not exist today, the most useful single project of the next quarter is to build it. The work is structured, finite, and lasts. We document the methodology in the audit defence pillar and in the supporting white papers.
What the inventory costs to build
Across the engagements we have led, a complete licence-type inventory for a mid-sized SAP estate — one master agreement, one to three live instances, an integration topology of fifteen to forty non-SAP applications — takes six to ten weeks of buyer-side analyst time, supported by an independent advisor and the basis team. The work is not glamorous. The cost, against the audit settlements it prevents and the renewal leverage it produces, is one of the highest-return projects in the SAP estate. Across our $180M+ in client savings, more than half traces to estates that built the inventory before the audit landed.
The inventory is a deliverable, not a tool purchase. The SAM tools available in the market all produce useful subsets of the inventory; none produces the consolidated, contractually-tied artefact that an audit response requires. The tool is an input. The inventory is the deliverable. The discipline is to treat them in that order.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.