SAP Licence Compliance Tools and Metrics: Understanding USMM, LAW, SLAW and STAR

Why SAP Compliance Measurement Tools Matter

SAP licence compliance is a contractual obligation that requires annual measurement and reporting. The contractual mechanism through which SAP customers fulfil this obligation is the annual licence measurement — a formal process using SAP's native tools that produces a documented record of licence consumption across named users and engine metrics. This record forms the basis for SAP's commercial position in any true-up, audit, or renewal negotiation.

The critical insight that most SAP customers miss is that the measurement tools SAP provides are also the tools that SAP uses when it conducts its own audit. Understanding how these tools produce their output — and where their output can legitimately be influenced through correct system configuration and user classification — is the foundation of both compliance management and audit defence.

Running USMM or LAW only when SAP asks for the data, and then submitting the output without independent review, is equivalent to asking the opposing party to write your legal statement. The measurement is accurate, but its interpretation and presentation can be the difference between a clean compliance submission and a multimillion-euro true-up claim.

USMM: User and System Measurement Management

What USMM Is

USMM (User and System Measurement Management) is the transaction code and framework within each SAP ABAP system that collects licence consumption data. Transaction USMM is the starting point for every on-premise SAP licence measurement. It runs directly within each SAP system and produces two categories of output: named-user licence counts classified by licence type, and engine and package usage metrics for software components installed and active in that system.

The USMM measurement collects data on every user account in the system. It classifies each user account into a licence type based on the user's authorisation profile — the set of roles and permissions assigned to them. Users with access to professional-grade transactions are measured as Professional users. Users with access only to limited transactional functions may be measured as Functional (Limited) users. Users with employee self-service access are measured as Productivity users.

How USMM Measures Users

The user classification logic in USMM is based on a proprietary SAP algorithm that maps authorisation objects to licence types. The algorithm is not publicly published in full, but its behaviour can be observed and, within limits, influenced through careful user role and authorisation management. Users who have been assigned roles containing high-value authorisation objects — even if they never use those functions in practice — will be measured at a higher licence type than their actual usage warrants.

This is the source of the most common and most commercially significant USMM measurement error: users classified at a higher licence type than their actual usage because of over-broad role assignments. An accounts payable clerk who has been assigned a standard AP role that happens to include a reporting authorisation object may be measured as a Professional user when a Functional user classification is commercially appropriate. Across an enterprise of thousands of users, systematic over-classification of this type creates significant unnecessary licence costs.

USMM and Engine Metrics

In addition to named-user counts, USMM collects the engine usage metrics for SAP software components installed on the measured system. The measurement scope for engines varies by component type. For processor-based engines, USMM reads the hardware configuration data. For volume-based engines, USMM may read transaction counters, record counts, or other system-level indicators. For engines where the metric is not directly readable from system data — such as employee counts or spend under management — USMM requires the administrator to input the relevant business volume manually.

This manual input requirement for certain engine metrics is a significant governance vulnerability. If the administrator responsible for running USMM does not have visibility into the current business volume figures, or does not understand which engines require external data inputs, the measurement output will be incomplete or inaccurate. Incomplete measurements are interpreted by SAP's GLAC team as evidence of inadequate compliance governance, and inaccurate measurements — even if accidental — can create compliance gaps that SAP will use as the basis for commercial claims.

LAW: License Administration Workbench

What LAW Is

The License Administration Workbench (LAW) is SAP's tool for consolidating USMM measurements from multiple SAP systems into a single, unified licence position. For organisations running more than one SAP system — which is the vast majority of enterprise SAP customers — USMM alone is insufficient because it measures each system independently and counts the same user multiple times if they have accounts on multiple systems.

LAW resolves the double-counting problem by consolidating user accounts across systems and matching users who appear in multiple SAP systems to a single licence count. A named user who accesses three SAP systems — ECC, CRM, and BW — would be counted three times if USMM results from each system were simply added together. LAW identifies that the same person (matched by user ID, email, or other identifier) appears in all three systems and counts them once in the consolidated licence position.

The Consolidation Logic and Its Limits

LAW's consolidation logic applies the "highest licence type" rule: if a user is measured as a Professional user in one system and a Functional user in another, the consolidated licence position counts them as a Professional user. This rule means that licence type optimisation must be performed at the individual system level, in each system's USMM output, before the consolidated LAW measurement is run. Optimising at the LAW level is not possible because LAW applies the highest-type rule automatically.

The practical consequence is that remediation work — correcting over-broad role assignments, removing inactive user accounts, reclassifying users whose actual usage warrants a lower licence type — must be performed in each SAP system before the annual LAW measurement is submitted. Organisations that discover classification errors after submitting the LAW result to SAP face a process of dispute and negotiation to correct the submission, which SAP does not facilitate easily.

SLAW and SLAW2: Enhanced License Administration

SLAW (SAP License Administration Workbench, standalone version) and its successor SLAW2 are enhanced versions of the LAW tool that provide additional functionality for complex multi-system landscapes. While the original LAW is typically run within SAP Solution Manager or the central SAP system, SLAW and SLAW2 can operate as standalone tools, providing greater flexibility for organisations that do not have a fully configured Solution Manager environment.

SLAW2 introduces improved consolidation algorithms, better support for indirect access measurement, and enhanced reporting capabilities that facilitate deeper analysis of the licence position before submission. The indirect access analysis features in SLAW2 can identify third-party system connections and generate a preliminary assessment of digital access document volumes — making it a useful tool for identifying indirect access exposure before an SAP audit team does so independently.

For organisations with complex landscapes involving multiple SAP versions, varied system architectures, and a mix of on-premise and cloud components, SLAW2's enhanced consolidation capabilities provide materially better insight than the standard LAW tool. However, SLAW2 requires proper configuration and experienced interpretation to produce useful output. Running SLAW2 without expertise in interpreting its indirect access analysis output may generate data that is technically accurate but commercially misleading.

STAR: SAP's System Topology and Reporting Framework

STAR (System Topology and Reporting) is SAP's framework for documenting the system landscape — the complete picture of which SAP systems are deployed, how they are connected, and what software is installed and active. The STAR report provides SAP's GLAC team with a landscape map that they use to cross-reference against the customer's licence entitlement and the USMM/LAW measurement output.

The STAR report is less a compliance measurement tool and more a landscape documentation tool. Its compliance relevance comes from the fact that systems appearing in the STAR landscape but not reflected in the USMM/LAW measurement — because they were overlooked or deliberately excluded — create an immediate compliance red flag. SAP's GLAC team uses STAR reports to identify systems that should have been measured and were not.

Maintaining an accurate and current STAR report, aligned with your actual SAP system landscape, is a compliance hygiene requirement. SAP landscapes that have evolved organically over many years frequently contain legacy systems, development systems, sandbox environments, and pilot systems that are technically active but not reflected in the formal measurement submission. Each of these unmeasured systems represents a compliance gap that SAP can identify through STAR report analysis.

Third-Party Compliance Tools: Supplementing SAP's Native Toolset

SAP's native measurement tools — USMM, LAW, SLAW2 — are designed to produce data for compliance reporting. They were not designed to optimise your licence position, identify cost reduction opportunities, or provide actionable intelligence for negotiation. Third-party SAP licence management tools supplement the native toolset with analytics, benchmarking, and optimisation capabilities that the native tools do not provide.

The leading third-party tools in the SAP licence management space — including VOQUZ samQ, Snow Software's SAP management module, Flexera Software License Management, and USU SAP License Management — provide capabilities such as real-time consumption monitoring against entitlement, automated licence type reclassification recommendations, role-usage analysis that identifies over-broad assignments, indirect access document counting, and scenario modelling for licence tier changes. These tools transform the annual measurement from a point-in-time snapshot into a continuous compliance intelligence process.

However, third-party tools have a significant limitation: they produce accurate data but they do not provide strategic interpretation of that data in the context of your commercial relationship with SAP. A tool that identifies 300 users who could be reclassified to a lower licence type produces a list of targets. Converting that list into a commercially optimal position — understanding which reclassifications SAP will accept without challenge, which require role changes, and how to sequence the optimisation to maximise the negotiating impact — requires human expertise that tools cannot provide.

How to Use Compliance Tools Proactively

Run USMM Quarterly, Not Annually

The contractual obligation is to submit an annual measurement, but the compliance intelligence value is highest if USMM is run quarterly. Quarterly measurements provide a trend line that shows licence consumption growing or shrinking over time, gives advance warning of approaching licence tier thresholds, and generates the documentation trail that demonstrates proactive compliance governance — which is a material factor in any audit defence.

Review and Clean User Classifications Before the Annual Submission

Schedule a pre-measurement review three months before your annual USMM submission. This review should identify inactive user accounts that should be deactivated, users classified at a higher licence type than their actual usage warrants, and role assignments that are driving unnecessary licence type upgrades. Three months is sufficient time to implement classification changes and allow the system to stabilise before the formal measurement run.

Validate Engine Metric Inputs Before Submission

For engine metrics that require manual data input, establish a validation process that cross-references the input data against the business source — HR system headcount reports for employee metrics, procurement system spend reports for spend-based metrics, and infrastructure documentation for processor metrics. The validation should be signed off by the data owner in the relevant business function, not just the IT administrator running the USMM tool.

Conduct an Independent Review Before Submitting to SAP

The annual measurement submission to SAP should be reviewed by an independent advisor before it is sent. This review should verify that the measurement is complete, that user classifications are accurate and defensible, that engine metric inputs are correct, and that the consolidated LAW output reflects your intended licence position. Corrections after submission require SAP's agreement and are commercially complex.

Common Measurement Errors and How to Avoid Them

The most frequent USMM measurement error is submitting the measurement without first deactivating inactive user accounts. SAP systems accumulate inactive accounts over time — employees who have left, contractors whose access was not revoked, and service accounts that are no longer in use. Each inactive account counts in the USMM measurement at whatever licence type its authorisation profile warrants. Running a user account audit and deactivating all inactive accounts before the measurement significantly reduces the measured licence count without changing actual compliance.

The second most common error is failing to include all SAP systems in the LAW consolidation. Development systems, quality assurance systems, and sandbox environments are sometimes excluded from the measurement on the assumption that they are "not production." SAP's licence agreement does not exclude non-production systems from licence measurement requirements unless there is an explicit contractual provision for non-production use rights. Excluding systems from LAW creates a measurement scope gap that SAP's GLAC team can identify and treat as a compliance violation.

The third common error is mismatching the measurement period to the contractual reporting date. Most SAP licence agreements specify that the annual measurement should reflect the licence position at a specific date or within a specific measurement window. Running USMM at an arbitrary point in the year and submitting the output may not satisfy the contractual measurement requirement if the measurement date does not correspond to the contractual window. Verify the measurement period requirement in your licence agreement before running the annual measurement.