SAP SLAW Report: What It Reveals About Your Licence Position

The SAP SLAW (System Licence Audit Workbench) report is generated by the USMM measurement process and submitted to SAP as part of the annual measurement obligation. It is the primary document on which SAP bases its licence position analysis — and therefore the primary document on which audit shortfall claims are built. Understanding what it contains is the foundation of any effective defence strategy, whether you are approaching your annual measurement or responding to an audit notice.

This guide is part of the complete SAP system measurement series and covers the SLAW report in forensic detail — its structure, what each section reveals, how SAP uses it, and where the most common errors create exploitable exposure on both sides.

Key Takeaways

The SLAW report is a structured data file — not a free-text document — and its format determines what can be challenged and how.
Named user counts in the SLAW are driven by classification logic that can be reviewed and challenged before and after submission.
Engine activations in the SLAW may reflect historical technical deployments rather than active commercial use — this distinction is contestable.
SAP compares your SLAW against your contracted entitlement on file — discrepancies in SAP's entitlement record directly affect shortfall calculations.
SLAW data from prior years establishes a baseline that SAP uses to identify trends — understanding your historical SLAW profile is important before any audit.

What the SAP SLAW Report Is

The SLAW report is the output of the USMM (User and System Measurement) transaction. It is a structured XML-based data file that consolidates measurement results from all systems in the SAP landscape and packages them in the format required for submission to SAP's licence audit team. When submitted, the SLAW data is ingested into SAP's central licence management systems, where it is compared against the customer's contracted entitlement to identify apparent shortfalls.

The report is not a summary document — it contains granular data about individual user IDs, their assigned licence types, the authorisation profiles that drove the classification, and the system-level measurements for each component of the landscape. This granularity is both the SLAW's strength (it provides the detailed basis for challenging specific classifications) and its risk (it exposes information about your user population and system footprint that SAP can use in audit conversations).

Expert Perspective

"The SLAW report is the most important document in any SAP audit engagement — more important than the initial audit notice. It's the evidence base. Clients who understand what their SLAW contains before SAP does are in a fundamentally different commercial position from those who find out what it contains when SAP presents a shortfall claim."

The Structure of the SLAW Report: Section by Section

Section 1

System Landscape Header

Identifies all systems included in the measurement, their system IDs, system roles (production, development, QA), and the measurement execution date. SAP uses this section to verify that the measurement covers the correct landscape and to flag any systems that were expected but absent.

Section 2

Named User Data

The most commercially significant section. Contains the count of users by licence type for each system and in aggregate, following deduplication. User type classifications are listed with the classification basis (authorisation profile, special indicator, manual assignment). This is where shortfall claims originate — and where classification challenges are most effective.

Section 3

Engine and Package Usage Indicators

Lists all SAP engines, packages, and add-ons identified as active across the landscape. Activation is detected at the technical layer — not at the business usage layer. An engine that is technically installed and activated may appear here regardless of whether any user has interacted with it commercially.

Section 4

Indirect Access Indicators

In USMM versions 4.0 and later, this section captures indicators of third-party system integration activity and RPA usage patterns. The data is directional rather than definitive — it flags scenarios SAP may wish to investigate further, rather than providing a complete indirect access usage picture.

Section 5

Deduplication Output

Documents how users appearing in multiple systems have been consolidated into single licence requirements. The deduplication logic applied is recorded here. Errors in deduplication — which are common in organisations with complex landscapes — appear as multiple licence requirements for the same individual.

📬 SAP Licensing Intelligence

Get Independent SAP Licensing Insights

Expert analysis on SAP audits, contracts, and cost reduction — direct to your inbox. Corporate email required.

How SAP Uses the SLAW Report

When SAP receives a SLAW report, it is processed against the customer's entitlement record in SAP's global licence management system. The process is largely automated: named user counts are compared by category against contracted quantities, engine activations are checked against contracted engine entitlements, and any quantities where measured use exceeds contracted entitlement generate an apparent shortfall record.

SAP's licence management team then reviews the shortfall record and, typically within 4–8 weeks of receiving the SLAW, issues a licence position analysis letter to the customer identifying the shortfalls and proposing a commercial resolution. This letter is the formal opening of the audit or compliance review process.

Understanding the SLAW report is critical at this stage because the shortfall analysis letter will reference specific lines and quantities from the SLAW. Enterprises that have reviewed their own SLAW data before submission will immediately recognise which items in the shortfall analysis are legitimate and which reflect classification errors, deduplication failures, or entitlement record discrepancies — and can begin the challenge to SAP audit findings from a position of knowledge rather than reaction.

Challenging SLAW Classifications: Where the Leverage Is

The named user section of the SLAW is the most frequently challenged component. The SAP USMM classification engine assigns user types based on authorisation profile analysis, and that analysis is not always accurate. The most common classification errors that can be challenged include:

Broad profile over-classification: Users assigned broad authorisation profiles (typically SAP_ALL, SAP_NEW, or composite roles built for emergency access) are classified by USMM as Professional users. In many cases, these users' actual day-to-day function is lower-value — they have broad access for technical, not commercial, reasons. Reclassifying these users with a documented business justification is a standard and legitimate challenge.

Inactive account inclusion: If account locking was not performed before the measurement, inactive users appear in the SLAW as active users. In a formal audit context, a challenge based on actual inactivity — supported by login timestamps — can retroactively challenge historical shortfall claims that included dormant accounts.

Deduplication failures: Users appearing in multiple systems under different IDs, not correctly deduplicated, generate multiple licence requirements in the SLAW. Demonstrating that a set of apparent separate users are in fact the same individual — with supporting HR or identity management records — directly reduces the shortfall count.

Engine non-use: Engine activations in the SLAW reflect technical activation, not commercial use. For engines where no business user has interacted with the functionality, a challenge based on demonstrable non-use is supportable. This requires technical evidence from the system (transaction logs, usage statistics) and is most effective when assembled before the audit dialogue begins.

Entitlement Record Discrepancies: The Hidden Risk

SAP's shortfall calculation compares SLAW data against the entitlement on file in its global licence management system. If SAP's record of your entitlement is wrong — which happens more often than enterprises realise — the shortfall calculation will be wrong in SAP's favour.

Common sources of entitlement record discrepancies include: multiple ELA amendments that have not been consistently applied to the master entitlement record, acquisitions or divestitures that have partially transferred entitlement without completing the administrative update, and legacy licences purchased through multiple channels that appear in different parts of the entitlement record. Before engaging with any SAP shortfall claim, verify your contracted entitlement independently against your own contract records and request SAP's entitlement record in writing. Discrepancies discovered at this stage significantly reduce the apparent shortfall before any commercial negotiation begins.

The SLAW Report in Formal SAP Audits

When SAP escalates from a compliance review to a formal SAP audit, the SLAW report becomes a primary piece of evidence. SAP auditors will typically request the most recent SLAW submission and may request historical SLAW data to construct a trend analysis. Organisations that have maintained consistent, well-prepared annual measurements are in a substantially stronger position than those with gaps or anomalies in their measurement history.

If SAP's auditors believe the self-reported SLAW understates actual usage, they may conduct their own system access to generate an alternative measurement. Understanding your SLAW data thoroughly — and being able to defend every line of it — is the foundation of an effective response to this scenario. Independent advisors who work exclusively on the buyer side, like our team, can review your SLAW data and identify both the strengths of your current position and the lines that require additional documentation or challenge before SAP's analysis crystallises.

For the full defensive framework, see our comprehensive SAP Audit Guide.

Our Services