SAP Operations
SAP License Measurement: USMM Basics and SLAW Workflow
A practical guide to preparing SAP user and engine measurements with USMM, reviewing results, and consolidating system data in SLAW.
What USMM measures
USMM is the User and System Measurement transaction used in an ABAP-based SAP system to collect licensing-relevant information. It measures users according to their assigned classification and collects selected system, engine, and package data that can support a contractual review.
The result is an operational data set, not an automatic determination of contractual liability. License definitions, contract terms, engines, indirect use, and local agreements determine how the collected data is interpreted. Keep the measurement date, system identity, system role, and responsible reviewer with the exported results.
For surrounding operational work, see SAP version check procedures before starting and SAP support package application when the measurement is part of a broader maintenance cycle.
Prepare the measurement
Start by defining the system scope. List production, quality, development, training, and sandbox systems that are included in the reporting request. Record each system’s SID, client, host context, business purpose, and connection path. This prevents a development system or an obsolete copy from being omitted or counted twice.
Review user master data before running the measurement. Inactive, technical, dialog, communication, service, and named business users should have an intentional classification and an accountable owner. Remove obsolete accounts through the normal security process, and document accounts that remain for interfaces, background processing, emergency access, or system administration.
Coordinate the measurement window with application owners. A user classification change made after the measurement can produce a different result, so freeze the review population for the agreed period. Keep evidence of the review, including the owner’s decision for unusual or shared technical identities.
Run USMM
Run USMM in each included ABAP system and client according to the system’s measurement procedure. Review the selection and classification settings before starting the measurement, then execute the relevant measurement steps and save the result in the system’s designated location.
After execution, inspect the result for technical errors, missing classifications, unexpected user counts, and engine or package records that need business validation. Compare the output with the previous approved measurement where one exists. Large changes should have an operational explanation such as a new interface, a system copy, a user population change, or a role redesign.
Use a controlled export and a clear file naming convention that includes the SID, client, measurement date, and revision. Restrict access because the result can contain user-related and system-related information. Preserve the original export separately from any normalized workbook or management summary.
Review user classification
User classification is one of the most important quality controls in USMM. The assigned category should reflect how the user is used in the system and the applicable licensing agreement, rather than simply matching a role name or department.
Review these populations separately:
- Named business users with interactive access
- Technical users used by interfaces or middleware
- Background users that execute scheduled processing
- Communication users used for system-to-system calls
- Service or shared identities with controlled ownership
- Locked, expired, or obsolete users retained for audit history
Use role assignments, login history, interface inventories, job ownership, and application-owner confirmation as evidence. A user can have several roles while still requiring one deliberate classification decision. Record exceptions and approvals instead of silently changing classifications to reduce a count.
Validate engines and packages
USMM can collect information about selected engines, packages, and other measurable components. The technical result requires business validation because a detected component does not by itself establish that a specific licensed metric applies.
For each reported item, identify the responsible business owner, the relevant process, the active system or client, and the source data used to confirm the result. Reconcile duplicate records created by system copies or parallel landscapes. Keep a separate explanation for development-only, test-only, inactive, or technically installed components when those distinctions matter to the review.
If the measurement concerns SAP S/4HANA or an SAP ERP landscape, involve the process owners for areas such as FI, MM, SD, PP, HCM, or EWM as applicable. Their confirmation helps connect technical records with actual business use without treating a module assignment as a license conclusion.
Consolidate results in SLAW
SLAW, the License Administration Workbench, is used to consolidate measurement results from multiple systems when the reporting process requires a central view. Import the approved results using the agreed system identifiers and measurement period, then check that each source system appears once and is associated with the correct system role.
Review the consolidated data for duplicate users, inconsistent system names, missing source results, and unexplained differences between local USMM output and the central view. Keep the original source files with the SLAW consolidation record so every aggregated figure can be traced back to a system and measurement date.
A consolidated result supports review and reporting; it does not replace contractual analysis. Separate technical totals, user classifications, engine observations, and business decisions in the working papers. This makes later questions easier to answer and prevents a technical count from being presented as a final entitlement calculation.
Handle common measurement problems
Missing or stale user classifications
Check the user master records, classification assignments, account status, and review ownership. Re-run the relevant measurement after approved changes, then retain both the change record and the new result.
Unexpected user totals
Compare the current population with the prior measurement and investigate system copies, client refreshes, dormant accounts, duplicate identities, and recently integrated systems. Confirm whether the reporting scope changed before treating the difference as a usage increase.
Incomplete source data in SLAW
Verify that the source USMM result was generated for the intended system and client, that the export is complete, and that the import used the correct system identity. Resolve the source issue first, then repeat the consolidation rather than manually adjusting the central total.
Engine or package data needs clarification
Route the item to the responsible process owner and retain the supporting technical record. Capture the business process, active users, transaction or application context, and the decision made for the reporting period.
Build an audit-ready record
An audit-ready measurement package should contain the scope list, measurement schedule, approved user-classification review, USMM exports, SLAW consolidation evidence when used, exception decisions, and sign-off by the accountable operational and business owners.
Use immutable or access-controlled storage for the original files. Keep a working copy for analysis and label every transformation. Record who ran each measurement, which client was used, when the result was generated, and which changes occurred between measurement cycles.
Review the package after system refreshes, acquisitions, major interface changes, user population changes, and contract-driven reporting events. A short recurring review is more reliable than reconstructing decisions after a reporting deadline.
Practical USMM checklist
- Define the systems, clients, measurement period, and responsible owners.
- Confirm that system copies and retired systems are handled consistently.
- Review interactive, technical, communication, service, and background users.
- Resolve missing classifications and document approved exceptions.
- Run USMM and preserve the original result.
- Validate engines, packages, and business-process ownership.
- Import approved results into SLAW when central consolidation is required.
- Reconcile totals and investigate unexplained differences.
- Store evidence, approvals, and change history together.
- Separate measured technical data from contractual interpretation.