The USMM transaction, short for User System Measurement, is the SAP-delivered tool that runs the licence measurement at the system level. It collects user counts by classification, engine consumption metrics, and configuration data, and produces the measurement file that goes to LAW for consolidation across the landscape. The transaction is straightforward in structure and consequential in its outputs. The configuration choices that the buyer makes inside the USMM dialog determine the measurement result, and several of those choices are not obvious from the SAP-provided guidance. Our USMM and LAW advisory engagements walk buyer-side teams through the configuration. This article sets out the field-by-field tour.
The system tab
The system tab carries the basic identification: system ID, instance number, licence-key information, customer number, and installation number. Most of the fields are read-only and populated from the system itself. The two consequential fields are the measurement type (annual measurement, periodic measurement, special measurement) and the measurement date.
The measurement type matters because it interacts with the SAP measurement schedule. The annual measurement is what SAP’s standard contract requires; the periodic measurement runs additional cycles between annual runs, often for buyer-side validation; the special measurement is used in defined circumstances including merger integration and large-scale reorganisation. The choice should match the buyer’s purpose for the run; a buyer-side dry run should use the periodic type to avoid touching the official annual cycle. The ECC topic page covers the contractual measurement framework.
The user tab
The user tab is where the named-user classification is consolidated. The tab shows the total count of users by classification, with the classifications drawn from the SU01 user master data plus the classification assignment carried in the licence field. The summary view aggregates; the detail view enumerates each user with the assigned classification.
What the user counts include
The user counts include all users with a status that the measurement treats as active. SAP’s default treats locked-out users, expired users, and certain technical users as active for measurement purposes; the buyer-side configuration should override the default where the user state genuinely indicates non-active. The override mechanics include the user-status filter, the lock-status filter, and the validity-date filter; each is configurable inside the USMM dialog. The common measurement errors piece covers the recurring mistakes in user counting.
The classification consolidation
Within the user tab the classification is consolidated. Users with the same classification are aggregated into a single count. Users without a classification are counted in a default category, which is typically the highest-cost category in the contract. The buyer-side preparation here is to ensure that every user has an explicit classification before the measurement runs; users with no classification represent over-counting risk in the result. The classification rules piece covers the assignment framework.
The engine tab
The engine tab carries the consumption metrics for the licensed engines. The engines include payroll (master records, payroll-run counts), business warehouse (data volume in compressed and uncompressed form), process integration (message counts), and dozens of others depending on the system scope. The relevant engines for a given system are the ones licensed under the contract; the USMM tool collects metrics for all engines present and the buyer should map them to the licensed scope.
The recurring observation across our reviews is that the engine tab over-collects against the contract scope. Engines that were used in test scenarios, engines that were deactivated but not uninstalled, and engines that exist in the system but are not used in production all produce non-zero counts in the USMM output. The buyer-side configuration should exclude those engines from the measurement scope, with the exclusion documented in the measurement notes.
The landscape consideration
USMM runs at the system level. A landscape with multiple systems requires USMM to run on each system, with the outputs consolidated through LAW. The output of an individual USMM run is therefore not the buyer’s full entitlement position; it is the partial position at a single system. Treating an individual USMM output as the entitlement position is a recurring error and is the reason LAW exists.
USMM produces a system-level snapshot. LAW produces the landscape position. The two are different artefacts and serve different purposes. A measurement programme that conflates them produces inconsistent results across systems and an indefensible final position at the LAW level.
The variant management
USMM supports variants: pre-configured combinations of measurement parameters that can be saved and re-applied across runs. Variants are useful for the buyer-side because they document the configuration applied at each measurement run and permit re-running with the same configuration in subsequent cycles. The recurring observation here is that buyer-side teams do not use variants and instead reconfigure the parameters at each run, with the inevitable inconsistency across runs and the loss of the audit trail.
The recommended discipline is to define a variant per measurement purpose (annual measurement, periodic measurement, special measurement) and to apply the relevant variant at each run. The variant should be reviewed and re-approved at the start of each measurement cycle to confirm it remains current; configuration changes between cycles should be applied through variant update rather than through ad-hoc parameter changes at run time. The USMM and LAW measurement checklist covers the variant-management framework.
The output and the upload
The USMM output is a file in SAP’s defined measurement format. The file goes to LAW for consolidation; LAW then sends the consolidated position to SAP through the licence administration portal. The buyer should retain the USMM output file at each run with the corresponding configuration variant. The file represents the documentary basis for the measurement and any subsequent challenge to the SAP result depends on having the file.
The upload to SAP carries an implicit acceptance of the measurement result. Once the buyer sends the consolidated position to SAP through the portal, the position is treated as the buyer’s declared entitlement consumption for the period. The buyer-side validation should therefore occur before the upload, not after; a USMM result that contains over-counts should be corrected at the USMM level and re-run before consolidation, not uploaded with the intent to challenge the result post-hoc. The media company case file documents an over-counted measurement that the buyer challenged successfully but at considerable effort.
The pre-run validation
The buyer-side preparation before each USMM run should include: a review of the user master data against the classification rules, with corrections applied to mis-classified users; a review of the engine activation status, with deactivation of engines that are not in licensed scope; a review of the configuration variant against the standard for the measurement type; and a documented confirmation by the buyer-side responsible person that the configuration matches the intent. The four-step pre-run validation takes time but reduces the post-run correction effort substantially. The USMM run preparation piece covers the validation in more detail.
— 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.
What to do next
Begin with a dry run on the periodic measurement type, with the buyer-side configuration applied, and compare the result against the SAP-default configuration. The two will diverge; the divergence shows the magnitude of the configuration effect on the measurement result. Use the divergence to inform the configuration applied to the annual measurement when it falls due. The discipline converts USMM from a black-box process into a defensible buyer-side process, and the same discipline applies to LAW at the landscape level.