The USMM output file is the artefact that turns the buyer’s SAP estate into the dataset against which SAP measures licence consumption. Every audit, every compliance position, and every renegotiation reference point ultimately traces back to the rows in this file. Yet most internal SAP teams treat the output as an opaque object: USMM runs, the file is produced, the file goes to SAP, and the implications are interpreted only later when the SAP-side analysis returns. That is the wrong sequence. The output file should be read by the buyer before it leaves the buyer’s perimeter, anomalies should be identified and remediated, and submission should follow the analysis rather than precede it. Across our USMM and LAW measurement advisory engagements we apply a consistent inspection method.
What the output file contains
The USMM output is a structured dataset, exported in SAP’s defined format, that captures: user counts by licence type at the system level; engine consumption metrics for measurable engines; system metadata identifying the system being measured and the measurement period; and supplementary fields that vary by SAP version. The file is not a free-form report. Every row maps to a defined schema and every field is intended to be machine-readable by SAP’s LAW consolidation layer.
The relevance of the structure is that anomalies are typically structural: a duplicated user, an unexpected licence type, an engine consumption figure outside the plausible range, a missing field that the LAW layer expects. Each anomaly type signals a different upstream problem. The USMM transaction walkthrough piece sets out the execution context inside which the output is generated.
The user counts section
The first block of the output is the user count by licence type. Each row represents a licence type configured in the system; each row carries the count of users assigned to that licence type as of the measurement run. The structure looks simple. The pitfalls are not.
What to inspect
Inspect three things on the user count rows. First, the total user count against the total user count expected from the buyer’s own user master records. A material gap signals either an SU01 inclusion problem or a measurement scope misconfiguration. Second, the distribution across licence types. A heavy concentration in the most expensive licence type often signals reactive over-classification by SAP basis teams who default to the safe-but-expensive option. Third, the special user types — reference users, technical users, communication users — should be reviewed individually. Each of these is a source of measurement noise. The common measurement errors piece documents the typical user-side errors.
The engine consumption section
The second block captures the consumption metrics for the measurable engines: Payroll, Employee Self-Service, Document Volumes, and the wider engine list as configured at the buyer’s estate. Each engine has its own metric (active employees, processed documents, transactions, etc.) and its own measurement methodology.
Anomalies in engine rows
Three anomalies recur. The first is a zero or near-zero consumption figure for an engine that the buyer is known to use materially — typically indicating a measurement script that failed to execute or a parameter set that excluded the relevant data. The second is a consumption figure dramatically higher than the buyer’s own internal estimate — typically indicating a measurement script that double-counts, includes historical data outside the measurement period, or aggregates against a denominator that does not match the contract’s definition. The third is a missing engine row for an engine the buyer is licensed for — typically a configuration error in the SAP-side engine registration. The engine metrics topic page covers the methodology for each major engine.
The system metadata section
The system metadata block identifies the system, the measurement period, the measurement parameters, and the user who executed the measurement. This block is rarely audited by buyers and is consequently a frequent source of submission errors that produce avoidable downstream complications: wrong system ID, wrong measurement period, parameter inconsistencies between sister systems that should produce consolidatable LAW outputs.
The USMM output is not a status report. It is the submission against which SAP will calculate the buyer’s licence position for the year. Reading the file before submission is the difference between negotiating from a defensible position and negotiating from a position SAP has already framed.
Cross-checking the output against SU01 and ST03
The most useful pre-submission validation is to cross-check the USMM output against the underlying SAP data: SU01 for user master records, ST03 for usage statistics, the licence-type assignment tables for the configured licence allocation. The cross-check identifies users that USMM counted but SU01 does not justify, licence types that USMM reports but the configuration does not contain, and usage patterns that contradict the assigned licence types.
The validation is mechanical and can be supported with the SAP-standard reporting transactions. The output of the validation is a remediation list: users whose assignments need correction; configuration items that need adjustment; engine measurement parameters that need re-running. The remediation should precede submission rather than follow it. The post-measurement cleanup piece covers the remediation discipline in detail.
The plausibility review
The final review is a plausibility check against the buyer’s own business reality. Does the user count match the buyer’s expectation for the workforce? Does the engine consumption match the buyer’s expectation for the volume of activity? Are there licence types reported that the buyer did not believe it had assigned? Does the system metadata identify the system the buyer intended to measure?
The plausibility check often surfaces the most material problems: a population of dormant users still counted as Professional; a measurement that captures sister-system traffic the buyer did not intend to include; a configuration error that misassigns a substantial user population. Each surfaced problem produces a remediation that reduces the measured position. Each unsurfaced problem produces a measured position that overstates the buyer’s consumption. The USMM and LAW measurement playbook white paper sets out the full plausibility framework.
Submission as the commercial event
Submission is not a clerical act. Once the file is submitted, the buyer’s capacity to amend the measured position is sharply reduced. SAP will use the file as the reference dataset for the year’s compliance position, the renewal conversation, and any audit that follows. The inspection discipline before submission is the buyer’s last opportunity to shape the dataset on which the next twelve months of commercial conversation will rest. The manufacturer USMM cleanup case file documents an estate that reduced its measured Professional user count by twenty-three per cent through pre-submission analysis.
— 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.
The follow-through
The USMM output is the single most consequential artefact in the SAP compliance cycle. Reading it well is a learned discipline; the inspection method is repeatable across measurement cycles and the remediation backlog reduces with each iteration. Buyers who treat the output as an opaque submission ship problems forward into commercial conversations they cannot easily reverse. Buyers who treat it as the input to a documented analysis ship a defensible position. The USMM run preparation piece sets out the pre-measurement discipline that determines the output quality.