The USMM — User and System Measurement — is the technical heart of every SAP audit. It is the report that classifies every user in the SAP system by licence type, counts engine-metric consumption, and reports the system landscape. The LAW — License Administration Workbench — aggregates USMM results across multiple SAP systems in a single landscape. Together, they produce the data that SAP’s audit team uses to construct the opening claim. In ninety-one per cent of the USMM submissions we review before they are sent to SAP, the submission overstates the licence position. The overstatement is usually not deliberate. It is the result of the SAP-recommended classification methodology applied without buyer-side validation. This pillar walks through the measurement mechanics, the five most common over-classifications, the validation methodology that produces a defensible submission, and the operating routine that keeps the measurement clean year-round. It informs our USMM and LAW advisory service.
What the USMM actually measures
The USMM transaction is a system measurement report that runs in each SAP system. It produces four outputs. A user count classified by licence type (Professional, Limited Professional, Employee Self-Service, and several specialised categories). An engine measurement, with the consumption of each engine metric on the system. A system landscape report describing the technical configuration. And a metric report covering specific licence-relevant counters such as named-user records and active client populations.
The user classification is the heart of the measurement and the largest single source of audit exposure. The classification is based on the role-collection assigned to each user, with role-collections mapped to licence types through a configurable table maintained in the SAP system. The classification can also be overridden manually by the SAM team, with the override recorded and visible in the report. The methodology is well-documented in our USMM and LAW topic page.
Why role-collection classification over-counts
The role-collection method classifies a user as Professional if any of the user’s assigned role-collections is itself classified as Professional. This is a conservative approach — it over-classifies rather than under-classifies — and it produces a defensible position from SAP’s perspective. But it does not match how users actually work.
In most estates, role-collections are designed broadly. A user who occasionally needs access to a specific transaction is assigned a role-collection that includes that transaction along with many others. The user’s actual usage may be entirely within the Employee Self-Service or Limited Professional band; the assigned role-collection puts them in the Professional band. The classification reflects what the user could theoretically do, not what they actually do.
The difference matters because the cost differential between the licence bands is large. A Professional licence is typically three to five times the cost of a Limited Professional licence, and ten or more times the cost of an Employee Self-Service licence. An estate with twenty thousand users and a twenty per cent over-classification has roughly four thousand users priced three to five times higher than necessary. This is the principal source of named-user audit exposure.
The five most common over-classifications
Across our USMM reviews, five patterns account for the majority of over-classification. They are:
- Project-trial roles never deactivated: users assigned Professional-level roles for a defined project who retain the assignment after the project ends
- Inherited roles from organisational moves: users moved into a new role retaining the prior role-collection alongside the new one
- Service-account contamination: technical or service accounts classified as Professional users when they should be excluded from the named-user count
- Broad-design role-collections: role-collections that include Professional-level transactions for the rare case but are assigned to large user populations with lower actual usage
- Workflow-substitution residue: users granted temporary Professional access for a vacation cover or approval substitution that was never withdrawn
Each of these is correctable with a transaction-history review. The pattern is consistent enough that we treat the five categories as the standard checklist on every USMM validation engagement.
The validation methodology
A defensible USMM submission is the raw USMM output plus a buyer-side validation pass. The validation has four steps. First, the transaction-history pull: actual transaction execution by user, over a rolling twelve-month window, extracted from ST03N or equivalent audit logs. Second, the role-collection design review: which role-collections contain Professional-level transactions, which contain only Limited Professional or Employee Self-Service transactions, and which are mixed. Third, the reclassification pass: each user whose actual transaction history falls below the Professional threshold is reclassified, with the reclassification rationale documented. Fourth, the manual-override application: the reclassified position is applied as USMM manual overrides, with the override basis documented per user.
The output is a USMM submission that reflects the actual licence requirement of the estate rather than the theoretical role-collection assignment. The submission is defensible because every override is supported by transaction-history evidence. SAP’s audit team can challenge specific reclassifications but cannot challenge the methodology.
The transaction-history evidence
The transaction-history pull is the single most important input to the validation. Without it, the classification is opinion. With it, the classification is evidence. The pull should cover the same twelve-month window that the USMM measurement period covers, should include all users in scope, and should be extracted from a source — ST03N, SCC4, or the equivalent — that is independently verifiable.
The LAW consolidation
The LAW aggregates USMM results across multiple SAP systems in a single landscape. The aggregation is necessary because most enterprises run multiple SAP systems — production ECC, S/4HANA, BW, sandboxes, and so on — and the licensing position is at the landscape level rather than the system level. The LAW de-duplicates users across systems and produces a consolidated licence requirement.
The LAW introduces a second source of measurement error: the user-matching logic. Users with different identifiers in different systems may be matched incorrectly, creating either inflated user counts (where one person appears as multiple users) or deflated counts (where multiple people appear as one). The user-matching review is the LAW-specific validation layer and should be performed before the LAW output is submitted to SAP.
The engine measurement dimension
The USMM also produces engine-metric counts. Each engine has its own measurement methodology defined in the contract. The recurring categories of error are the same as in the named-user space: internal traffic counted against the metric, measurement periods that exceed the contractually defined window, and metrics counted at gross rather than net of contractual carve-outs. The engine measurement review parallels the named-user review and should be conducted at the same time, on the same data. See the engine metrics pillar for the engine-specific detail.
The operating routine
A clean USMM submission is not an annual heroic effort. It is the output of a year-round operating routine. The routine has three components. A quarterly classification review that catches over-classification before it accumulates. A defined process for role-collection design changes that includes a licence-impact assessment. And a manual-override register that documents every USMM override with the rationale and the supporting evidence. With the routine in place, the annual USMM submission becomes a procedural exercise rather than a fire drill, and the audit position is defensible from day one.
The USMM is the entire audit. Everything SAP’s audit team knows about the estate, they know from the USMM, the LAW consolidation, and the integration-topology questionnaire. The submission is the position. The validation work that goes into the submission is the difference between settling at thirty per cent of opening and settling at sixty per cent.
The S/4HANA FUE overlay
S/4HANA introduces an additional measurement dimension in some contract structures: the Full Use Equivalent (FUE) metric. FUE consolidates named-user counts into a single weighted metric, with different user types contributing different FUE values. The conversion from a pre-S/4HANA named-user position to an FUE position is itself a negotiated commercial event, with the contracted FUE quantity becoming the licence position for the converted estate.
The validation principle is the same as in the classical USMM environment. The user classification must be supported by transaction-history evidence. The FUE conversion ratios are contract-specific and should be reviewed for the actual usage mix on the estate. The S/4HANA migration is the natural moment to perform the classification rebuild because the migration project usually requires a comprehensive role-design review anyway, and that review can be paired with the licence-classification validation at limited additional cost. See the S/4HANA migration compliance pillar for the broader migration context.
The USMM in cloud and hybrid landscapes
The classical USMM is a transaction in an on-premise SAP system. In hybrid landscapes — where some workloads have moved to RISE or to standalone cloud products while others remain on-premise — the measurement layer becomes more fragmented. RISE-hosted SAP systems run a measurement equivalent to the USMM, with the output flowing to SAP through the RISE service rather than through a buyer-controlled extract. Cloud modules like SuccessFactors use their own metering surfaces that are separate from the USMM mechanism.
The practical implication is that a complete licence position for a hybrid estate requires a consolidated view across multiple measurement mechanisms, with different data formats and different validation surfaces. The principle is the same in each layer: the measurement must reflect actual usage rather than configured entitlement, and the buyer-side validation must be supportable with transaction evidence. The mechanics differ, and the operating routine described above must be extended to cover the cloud-module metering as well as the classical USMM. The consolidated reporting layer is usually built once during a major migration event and maintained from there.
The twenty-year view
The USMM mechanism has been the technical heart of SAP audit since the early 2000s. The transaction itself, the role-collection classification approach, and the engine-metric measurement framework have all evolved within a stable conceptual model. Across our 500+ engagements and $180M+ in client savings, the validation methodology set out in this pillar has been applied consistently and produces a defensible submission across all SAP product generations. The validation work is the difference between a settlement at thirty per cent of opening and a settlement at sixty per cent. Twenty-plus years of practice in the category confirms that the SAP-recommended classification approach over-counts in almost every environment, and that a transaction-history-supported validation is the single most consequential pre-audit investment a buyer-side team can make.
The USMM at S/4HANA conversion
The S/4HANA conversion is the most consequential single event for the USMM position in most estates. The conversion typically triggers a re-baselining of the licence position, often paired with a commercial conversion from perpetual licensing to a subscription model under RISE or a continued perpetual structure on private-cloud or on-premise. The licence position established at the conversion event sets the baseline for the post-conversion estate, and any over-classification carried into the conversion becomes the contracted licence quantity for the new structure.
The implication is operationally clear. The USMM validation work should be performed before the conversion event, not after. A well-validated pre-conversion USMM produces a smaller and more accurate contracted licence quantity in the post-conversion structure, with a corresponding reduction in subscription or perpetual fees over the contract life. A raw pre-conversion USMM produces an inflated baseline that the post-conversion contract perpetuates for the contracted term.
The pattern is well documented in the pharma S/4HANA case file, where the pre-conversion classification rebuild reduced the post-conversion contracted quantity by approximately twenty-six per cent against the position the estate would have carried without the validation work. The single largest opportunity to clean the USMM position is the period preceding a major commercial event; the conversion is usually that event.
The override register
Every manual reclassification of a USMM user belongs in the override register. The register records the user identifier, the original classification, the revised classification, the rationale (typically a transaction-history finding), the supporting evidence reference, and the date of the change. The register is the audit trail that supports the validated submission, and it is the document SAP’s audit team will request if specific reclassifications are challenged. A well-maintained override register makes the validation methodology defensible by construction; an absent or incomplete register puts the reclassification position in question even when the underlying analysis is correct.
The register also supports the inverse case. Where SAP’s audit team proposes a reclassification that the override register can show is contradicted by transaction-history evidence, the register provides the immediate buyer-side counter without requiring fresh analysis under audit pressure.
— 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.
Where to start
If you have an active audit, the first action is the validation pass on the USMM before any submission is sent to SAP. If you have an upcoming measurement cycle but no active audit, the right starting point is a dry run: a USMM execution plus validation, with the gap analysis used to inform the operating routine improvements before the actual measurement window. If you have neither, the right starting point is a baseline classification review against transaction-history evidence to establish the current position. The USMM and LAW advisory service brief covers the engagement structure, and the Fortune 500 manufacturer case file shows the validation methodology applied in a live audit defence.