What to Include in Your SAP System Measurement Report

Most enterprises submit their SAP system measurement as a single SLAW report file. That bare-minimum approach is contractually sufficient — but commercially naive. The SLAW file contains data; it does not contain context. And context is what determines whether SAP reads your measurement as a clean compliance confirmation or as an opportunity to open a shortfall conversation.

A well-constructed SAP system measurement report package contains the SLAW data file, supported by documentation that explains your methodology, contextualises your numbers, and closes off the most predictable SAP lines of inquiry before they are raised. This guide covers every component of a defensible measurement submission.

1. The Core SLAW Report File

The SLAW (System Licence Audit Workbench) report file is the mandatory deliverable in every annual measurement submission. It contains the consolidated measurement data for all systems in your landscape, including named user counts by licence type, engine activation flags, and landscape configuration details. To understand what the file contains and how SAP reads it, see our dedicated guide on what the SAP SLAW report reveals about your licence position.

Before including the SLAW file in your submission, verify that: all systems expected to be in scope are represented, user counts by licence type reconcile with your internal licence management data, and the file has been generated after all pre-measurement preparation activities are complete. A SLAW file generated from an unclean system should not be submitted — the opportunity to reduce exposure through data preparation exists only before the measurement, not after.

2. System Landscape Overview Document

The landscape overview document is a one-to-two page summary of the systems included in and excluded from the measurement, with explanations for any changes from the prior year. This document addresses the most common SAP follow-up question: "Why are these systems included and not those?" without requiring a back-and-forth exchange during which SAP has time to form its own (likely less favourable) interpretation.

The landscape overview should include: a table of all systems in scope with their system IDs, descriptions, and roles (production, QA, development), a list of any systems included in prior years' measurements that have since been decommissioned with decommission dates, any new systems added to the landscape since the previous measurement and the business context for their addition, and the deduplication methodology used for cross-system user identification.

3. User Type Classification Methodology Note

If any user type reclassifications were made before the measurement was run — which they should have been, as part of proper pre-measurement preparation — the methodology note documents what was changed, why, and on what authority. This is not a defensive document; it is a transparency document that demonstrates the measurement was conducted rigorously and in good faith.

The methodology note should identify: the number of user accounts reviewed for reclassification, the criteria applied to determine correct user type (specific reference to SAP's user type definitions is recommended), the number of accounts that were reclassified and from/to which types, the number of accounts that were locked as inactive with the criteria used for the inactivity determination, and the date on which the review was completed relative to the measurement execution date.

Organisations that conduct this review consistently year-over-year and can demonstrate a trend of improving data hygiene are in a substantially stronger position during an SAP audit defence than those that appear to perform reclassifications only in years when a shortfall is expected.

4. Year-Over-Year Variance Commentary

The year-over-year commentary is the single most impactful narrative document in the measurement package. SAP auditors compare current measurements against prior years' data; significant changes in user counts, engine activations, or landscape scope trigger follow-up. If you explain those changes in your submission, SAP has less reason to request additional information — and less opportunity to construct its own explanation.

The commentary should address: any increase in named user counts exceeding 10% in any category, with the business reason (acquisition, new system rollout, headcount growth), any decrease in named user counts exceeding 10% in any category, with the reason (divestiture, system decommission, improved data hygiene), changes in engine activations, and any measurement period changes relative to prior years. The commentary should be factual, specific, and cross-referenced to the SLAW data.

5. Contract Entitlement Confirmation

Include a document confirming the contracted entitlement that the measurement is being assessed against. This appears redundant — SAP has your contract — but it is not. Organisations that have undergone ELA amendments, acquisitions, or divestitures sometimes find that SAP's entitlement record does not match the customer's understanding of the current agreement. Including your entitlement confirmation creates a record of what you understood the measurement to be evaluated against.

If there is a known discrepancy between your entitlement records and SAP's, the measurement submission is not the place to resolve it — but it is the place to formally note the discrepancy and request clarification before SAP applies its interpretation in a shortfall calculation.

6. Engine Activation Review Notes

For any engine activations flagged in the SLAW report, include a brief note confirming whether the activation represents active business use or a historical technical artefact. Specifically document any engines that are activated in the technical layer but are not in commercial use — and note whether deactivation has been assessed or is planned.

This documentation serves two purposes: it demonstrates that your organisation actively manages its engine footprint, and it pre-empts SAP from treating every activated engine as a chargeable entitlement without giving you the opportunity to provide context. In cases where engines are flagged by SAP as shortfall items, having documented that the engine was not in active commercial use significantly strengthens the challenge position in an audit findings challenge.

7. Digital Access and Third-Party Integration Statement

Since the introduction of SAP's Digital Access model, measurements have increasingly been used to identify potential indirect access scenarios. Including a brief statement on your digital access scope — specifically, any third-party systems or custom applications that interact with SAP — prevents SAP from assuming the absence of documentation means the absence of awareness.

The statement should not volunteer information that expands your apparent exposure, but it should confirm: that you are aware of the DAAP (Digital Access Adoption Programme) framework, that your indirect access scenarios have been reviewed, and the basis on which your digital access licence requirement has been assessed. For organisations that have not yet conducted a comprehensive digital access review, engaging independent advisors before the next measurement cycle is strongly recommended. See our SAP Digital Access guide for the full framework.

8. Measurement Submission Cover Letter

A brief cover letter accompanying the measurement package provides the formal record of submission, confirms what is included, and establishes the context for SAP's review. The cover letter should be brief (one page), addressed to the appropriate SAP licence management contact, and should state: the measurement period, the list of documents included in the package, and the name and title of the responsible individual at the customer organisation.

The cover letter is also the appropriate place to note any specific matters you wish SAP to address or confirm in its response — for example, a request that SAP confirm its entitlement records match the customer's contract records before proceeding with any shortfall analysis.

The Complete SAP Measurement Report Checklist

Use this checklist to confirm your measurement package is complete before submission:

What Not to Include in Your Measurement Submission

As important as what to include is what to leave out. The measurement submission is a structured document exchange, not a general disclosure forum. Avoid including: speculative analysis of future licence requirements, references to commercial discussions or negotiations with SAP account executives, unsolicited opinion on SAP's pricing or audit methodology, or raw system access logs or transaction data that have not been interpreted and contextualised.

The submission should contain only what is factual, verified, and relevant to the current measurement period. Anything that opens interpretive space for SAP without supporting your position should be excluded.