USMM, SLAW, and LAW are SAP's three official measurement tools. USMM (User Survey Measurement Module) runs the named-user count and engine measurement on a single SAP system. SLAW (SAP for Me upload tool) is the upload mechanism that sends USMM output to SAP. LAW (License Administration Workbench) consolidates USMM output across multiple systems into a single combined measurement. Run together at audit time, these tools produce a measurement that overstates customer entitlement by 15 to 25 percent on average. The over-statement is the audit settlement starting position, not the truth. This page explains each tool, what it actually measures, and the customer-side counter-measurement methodology that produces the defensible position.
USMM: the User Survey Measurement Module
USMM is transaction USMM in SAP NetWeaver. It is the on-system measurement tool. Every productive SAP system (ECC, S/4HANA, BW, Solution Manager) runs USMM at customer request or at SAP's audit request. USMM produces two outputs: a user classification report and an engine measurement report.
The user classification report assigns each named user a licence type based on the user's activity in the system over the measurement period (default 12 months). The licence types correspond to SAP's user-type catalogue (Professional, Limited Professional, Functional, Self-Service, Developer, Test, Platform). The user-type detail is covered in SAP User Types Compared.
The engine measurement report counts consumption of engine-licensed components: HANA memory blocks, Solution Manager managed objects, Process Integration message volume, employee headcount for HR modules, document volume for industry solutions.
| USMM output | Measures | Common inflation pattern |
|---|---|---|
| User classification | Named users by licence type | Inactive users counted; users classified by maximum activity rather than typical activity |
| Engine measurement (HANA) | Memory utilisation blocks | Peak utilisation counted, not steady-state |
| Engine measurement (PI/Integration) | Message volume | All messages counted, including internal SAP-to-SAP system messages excluded from licence count |
| Engine measurement (Industry) | Document or unit volumes | Volumes from non-productive systems counted alongside productive |
| Engine measurement (HR) | Employee headcount | Total HR records counted, not active employee records |
SLAW: the SAP for Me upload tool
SLAW is the upload and reporting tool inside the SAP for Me customer portal (formerly the SAP Service Marketplace). SLAW receives the USMM output files from each SAP system in the customer estate and packages them for submission to SAP.
SLAW does not measure. It transports. The customer's measurement responsibility ends at USMM. SLAW's role is to upload USMM output and SAP's role is to interpret it.
The submission window is annual, typically aligned to the customer's SAP fiscal year. SAP customers with active support contracts are required to submit annual measurement under standard SAP licence terms. Failure to submit triggers escalation, ultimately a formal audit notice.
LAW: License Administration Workbench
LAW is transaction SLAW2 in SAP, or LAW in older systems. It is the consolidation tool. LAW takes multiple USMM outputs across multiple SAP systems and produces a combined measurement that de-duplicates users who appear in multiple systems.
The de-duplication is the most commercially important LAW function. A user with the same employee ID in ECC, BW, and Solution Manager should be counted once, not three times. LAW performs the de-duplication based on identifier matching (employee number, email, SAP user ID).
The trap: LAW de-duplication only works when the identifiers match. If a user has employee ID 12345 in ECC but employee ID E12345 in BW, LAW treats them as different users. The result is a double-count. Across a 50-system enterprise SAP estate, 8 to 18 percent of users are double-counted by LAW because of identifier inconsistencies.
| LAW de-duplication failure mode | Inflation impact | Customer fix |
|---|---|---|
| Employee ID format inconsistency across systems | 4 to 8 percent | Pre-LAW data cleansing to align IDs |
| Email address variations (corporate versus personal domains) | 2 to 5 percent | Standardise on corporate email field |
| Service accounts (RFC users) counted as named users | 3 to 7 percent | Tag service accounts in USMM before LAW |
| Former employees with active SAP accounts | 5 to 12 percent | Pre-measurement user-lock for terminated employees |
| Test and training accounts in productive systems | 2 to 6 percent | Migrate test users to non-productive systems |
Running the measurement: the 60-day window
The standard SAP measurement cycle gives the customer 60 days from SAP's measurement request to submit. The 60 days is not preparation time. It is correction time. Preparation should begin 90 to 180 days before the measurement request arrives.
The customer-side preparation calendar:
- Month 6 before measurement: identify the measurement period (typically the prior 12 months). Run a baseline USMM in test mode on the largest productive system. Identify the gross user count and the engine measurements.
- Month 4 before measurement: user cleanup. Lock terminated employees, tag service accounts, align employee identifiers across systems, archive long-inactive users.
- Month 2 before measurement: classification review. Reclassify users who are over-classified (Professional users who only run Self-Service activities; Limited Professional users who could be Functional). Document the basis for each reclassification.
- Month 0 to 2 (measurement window): run USMM, run LAW, review the combined output, prepare counter-measurement documentation, submit through SLAW.
Measurement preparation principle: the customer who prepares 6 months before measurement submits a measurement 18 to 30 percent below SAP's expected position. The customer who prepares 60 days before measurement submits at or near SAP's expected position. Preparation lead time is the highest-impact variable.
Common errors that inflate the count
Six errors recur across SAP measurement engagements:
Inactive users counted as active. Users not logged in for 90+ days but with active accounts are counted in USMM. The defensible position is to lock or archive these accounts before measurement.
Maximum activity classification. USMM classifies users by the highest licence-tier activity they performed. A user who ran a single Professional-level transaction once in the year is classified Professional, even if 99 percent of their activity is Self-Service. The customer position is to negotiate classification based on typical activity, with single-event exceptions excluded.
Service accounts classified as named users. RFC users, batch users, integration users, and system-to-system service accounts are not human users. They should be tagged as service accounts in USMM and excluded from named-user count.
Test and training accounts in productive systems. Users provisioned for testing in productive systems inflate the count. Either migrate testing to non-productive systems or tag test accounts.
Engine measurement at peak, not steady-state. HANA memory and PI message volume are routinely measured at peak. The licensable position is steady-state utilisation, with peak excluded as transient.
Industry solution measurement from non-productive systems. Industry solution measurement (Banking, Utilities, Retail-specific) often pulls from training, development, and QA systems alongside productive. Only productive system measurements are licensable.
The customer-side counter-measurement methodology
The counter-measurement is the customer's independently produced measurement that contests SAP's USMM/LAW output. It follows a four-step methodology:
Step 1: independent user inventory. Extract user master tables (USR02, USR21) from each SAP system. Filter for users with login activity in the measurement period. Cross-reference against HR active-employee tables. Exclude terminated employees, service accounts, test accounts.
Step 2: independent activity analysis. Extract transaction logs (STAD records, AUDIT_TR) for the measurement period. Classify each user by typical (median) activity pattern, not maximum activity. Apply SAP's user-type definitions strictly.
Step 3: independent engine measurement. Extract HANA utilisation logs from system monitoring (DB administration views, M_LOAD_HISTORY_HOST). Calculate steady-state at the 95th percentile excluding peaks. Compare to USMM's peak-based measurement.
Step 4: document the gap. Produce a counter-measurement report that itemises every variance between SAP's USMM/LAW output and the customer's independent measurement. Include the basis for each variance, the supporting evidence, and the alternative classification.
| Measurement element | SAP USMM output | Independent counter-measurement | Variance |
|---|---|---|---|
| Professional users | 4,200 | 2,800 | 33 percent reduction |
| Limited Professional users | 3,800 | 3,200 | 16 percent reduction |
| HANA memory blocks (peak) | 148 | 112 (95th percentile) | 24 percent reduction |
| PI message volume | 92M annual | 68M annual excluding internal SAP messages | 26 percent reduction |
| HR headcount licensed | 52,000 | 43,500 active | 16 percent reduction |
The variance is the negotiation position. SAP's licence sales team will dispute each variance. The customer's documented basis is the defence.
SAP's response to disputed measurements
SAP's standard response to a disputed measurement follows three escalation stages:
Stage 1: SAP licence audit team review. SAP's audit team reviews the customer's counter-measurement and either accepts variances or disputes them line by line. Customer-defensible variances (terminated employees, service accounts, test users) are typically accepted within 30 to 60 days.
Stage 2: SAP commercial team escalation. Disputed variances escalate to SAP's commercial sales team, who introduce commercial considerations (renewal positioning, RISE conversion, broader contract). The discussion shifts from compliance to commerce.
Stage 3: formal audit (rare). If commercial negotiation stalls, SAP can escalate to formal audit under the SAP support agreement's audit clause. Formal audit is rare for customers who engage substantively. It occurs in roughly 5 percent of measurement disputes.
The customer's position is strongest when the counter-measurement is produced before SAP's commercial team engages. A counter-measurement produced after SAP has anchored on the USMM output is harder to negotiate.
Engine measurement deep-dive
The named-user side of USMM gets most of the customer attention. The engine measurement side often produces larger settlement impact. Engine measurement covers components priced by capacity rather than by named user: HANA memory, Process Integration message volume, Solution Manager managed objects, employee headcount for HR modules, document or unit volumes for industry solutions.
Each engine has distinct measurement rules and distinct customer counter-positions:
| Engine | SAP measurement | Customer counter-measurement |
|---|---|---|
| HANA memory | Peak memory utilisation in 64GB blocks | Steady-state at 95th percentile, excluding transient peaks |
| Process Integration messages | Total message volume including internal SAP-to-SAP | External messages only, with internal traffic excluded |
| Solution Manager managed objects | All managed objects regardless of active status | Active managed objects only, with archived and deprecated excluded |
| HR headcount | Total employee master records | Active employees only, with terminated and inactive excluded |
| Industry solution units | All system instances (productive plus non-productive) | Productive systems only |
The HANA peak-versus-steady-state distinction is the most commercially significant. SAP's measurement captures a memory peak during the measurement period. If the peak hit 768 GB but typical consumption is 512 GB, SAP measures 12 blocks at 64GB each. The customer counter-measurement records steady-state at the 95th percentile, excluding peaks, and produces 8 blocks. The differential is $130,000 in annual maintenance per the standard 22 percent rate.
The annual measurement cycle versus on-demand audit
SAP distinguishes between two measurement events: the routine annual measurement (customer-initiated, SAP-required under support contract terms) and the on-demand audit (SAP-initiated, typically triggered by a specific exposure signal).
The routine annual measurement carries lower commercial pressure. SAP's audit team reviews the submission, accepts most variances, and the outcome is recorded for next year's renewal context. Aggressive customer-side measurement positions are typically accepted with limited dispute.
The on-demand audit is different. SAP initiates it when commercial intelligence (an integration project disclosure, a competitor displacement, a major M and A event) suggests the customer estate has changed materially. On-demand audits carry full commercial weight: SAP's licence sales team is involved from day one, settlement is targeted, and the audit timeline is compressed. The customer's preparation lead time is shorter, and the counter-measurement must be ready faster.
For broader audit response context, see SAP Audit Defence, the SAP Audit Rights overview, and the Audit Defence Guide. For named-user pricing detail, see SAP User Types Compared. For broader SAP commercial framework, see the SAP Licensing Complete Guide and SAP vendor intelligence. To engage on an active measurement or audit response, see Vendor Audit Defence.