SAP Annual System Measurement: Step-by-Step Guide

The SAP annual system measurement process is one of the most commercially significant recurring activities in any enterprise SAP environment — yet it receives a fraction of the governance and preparation that it warrants. Most organisations treat it as a technical task delegated to a BASIS administrator with a reminder in the calendar. SAP treats it as a commercial data-collection event. Understanding the complete SAP system measurement guide is the starting point; this sub-guide covers the operational mechanics.

Step 1: Access and Configure the SAP Licence Audit Workbench

The SAP Licence Audit Workbench (transaction SLAW or accessible via the SAP Solution Manager) is the central management hub for the measurement process. Before any measurement is run, the workbench must be correctly configured for the current measurement cycle.

Configuration tasks at this stage include: verifying that all systems to be included in the measurement are correctly registered and connected, confirming that the measurement period dates are set correctly (typically the current calendar year), and checking that the system landscape definition reflects any additions, decommissions, or migrations that have occurred since the previous measurement cycle.

A common error at this stage is failing to remove decommissioned systems from the landscape definition. Systems that have been shut down but not removed from the workbench registration will generate measurement errors or, in some configurations, incomplete measurement data that SAP may flag during audit review.

Step 2: Complete Pre-Measurement User Data Preparation

Before executing USMM on any production system, the user data preparation activities described in the full SAP system measurement guide should be complete. The critical actions are: locking all user accounts inactive for 90+ days, reviewing and correcting user type classifications for accounts flagged as Professional due to broad authorisation profiles, removing or locking former contractor and project user IDs, and verifying cross-system deduplication configuration.

Document all changes made during this preparation phase with timestamps and business justification. This documentation is not bureaucratic overhead — it is the defence record that explains why your measurement shows lower user counts than a prior period and that pre-empts SAP auditors characterising legitimate housekeeping as measurement manipulation.

Step 3: Execute USMM on Each System in Scope

With the workbench configured and user data prepared, USMM is executed on each system in the measurement scope. In most enterprise landscapes this means executing measurement on the production system, the quality assurance system, and the development system separately. Each execution generates a system-level measurement file that is subsequently consolidated in the workbench.

When executing USMM, note the execution timestamp — this becomes the point-in-time reference for the measurement. If the measurement is to be legally defensible, the execution should occur during a period of stable, representative business activity. Avoid executing during quarter-end close, major system rollout activity, or other periods when user populations are atypically large.

For organisations with complex multi-system landscapes, USMM executions should be coordinated to occur within a narrow time window — ideally the same day or within 48 hours — to ensure that the measurement captures a consistent point in time across all systems. A measurement where the production system is measured in January and a satellite system is measured three weeks later does not represent a coherent snapshot and may create inconsistencies in the consolidated SLAW report.

Step 4: Consolidate Measurement Data in the Workbench

Once individual system measurements are complete, the workbench consolidation process aggregates the results and applies the deduplication logic that identifies the same user across multiple systems. The consolidation step is technically complex and requires careful oversight.

The deduplication process matches users across systems based on configured identity attributes — typically a combination of employee number, personnel number, or system user ID mapping. In organisations that have grown through acquisition or that have migrated between SAP versions, these identity attributes may not be consistently populated across systems. A user who appears in production ECC as user ID "JSMITH001" and in an acquired subsidiary's system as "JS.001" may not be deduplicated correctly, generating two apparent licence requirements where one employee exists.

Review the consolidation output specifically for: users that appear in multiple systems without deduplication, unusually high counts in any single system that may indicate configuration errors, and engine activations that appear in unexpected systems. The workbench provides detailed output logs that support this review.

Step 5: Review the SLAW Report Before Submission

The SLAW (System Licence Audit Workbench) report is generated from the consolidated measurement data and represents the formal output that is submitted to SAP or retained as the self-declaration record. Before this report leaves your organisation, it must be reviewed in detail.

The review should examine: named user counts by licence type compared to the prior year's measurement (unexplained increases above 5% warrant investigation), engine activation flags compared to your contracted entitlement, and the landscape configuration section to verify that all systems are correctly represented. For detailed guidance on what the SLAW contains and how to read it, see our guide on what the SAP SLAW report reveals about your licence position.

Any anomalies identified during this review should be investigated and resolved before submission. Once the SLAW report is submitted to SAP, the data it contains becomes the foundation for SAP's licence position analysis. Correcting errors after submission is technically possible but commercially complicated — SAP is unlikely to accept corrections that reduce reported licence usage without scrutiny.

Step 6: Choose Your Submission Timing Strategically

The annual measurement obligation does not specify the exact date within the calendar year by which the measurement must be submitted — only that it must be submitted once per year. This flexibility has significant strategic implications. The optimal SAP system measurement timing is covered in a dedicated guide, but the principle is clear: submit during a period of stable, representative business activity, after data preparation is complete, and not during peak seasonal or project phases.

For most enterprises, the optimal window is mid-year — typically Q2 or Q3 — after the year-end close period has settled and before Q4 budget-cycle activity begins. This window typically captures a stable operational user population that accurately represents the steady-state licence requirement.

Step 7: Prepare and Submit the Measurement Package

The formal submission to SAP consists of the SLAW report file plus any supporting documentation required under your specific ELA terms. The submission process is typically handled through SAP's secure document exchange portal or, in older contracts, via encrypted email to the SAP licence management team.

Before submitting, compile the supporting documentation described in the guide on what to include in your measurement report. This documentation contextualises your SLAW data and significantly reduces the likelihood of SAP requesting follow-up clarification that could extend the measurement review period.

Retain a complete copy of the submission package — including the SLAW report, all supporting documentation, and the submission confirmation — in your SAP licence management records. In the event of a future audit, the ability to produce a consistent set of annual measurements demonstrates programme maturity and reduces the audit surface area SAP can legitimately explore.

Step 8: Post-Submission Monitoring

After submission, SAP will review the measurement data and typically respond within 4–8 weeks with its licence position analysis. This analysis will either confirm that the customer is within its contracted entitlement (no shortfall) or identify apparent licence shortfalls that SAP will seek to monetise.

If SAP's response identifies a shortfall, do not treat it as final. SAP's initial shortfall analysis is a commercial opening position, not an irrefutable audit finding. Many shortfall claims contain classification errors, deduplication failures, or incorrect entitlement references. An independent review of any SAP shortfall claim, before engaging commercially, is the most effective way to identify which elements of the claim have merit and which can be challenged. Our SAP audit defence service provides exactly this analysis — buyer-side, with no SAP affiliation.

Common Mistakes at Each Step — and How to Avoid Them

Step 1 (Workbench): Failing to remove decommissioned systems. Consequence: measurement errors that raise SAP questions during review. Fix: audit the landscape registration list before each measurement cycle.

Step 2 (Preparation): Rushing data preparation or skipping it entirely. Consequence: inflated user counts that become the baseline for future shortfall calculations. Fix: schedule preparation activities 4–6 weeks before the planned measurement window.

Step 3 (USMM execution): Executing USMM during a peak business period. Consequence: temporarily elevated user populations inflating the measurement. Fix: schedule execution during stable mid-quarter periods.

Step 4 (Consolidation): Accepting the deduplication output without review. Consequence: double-counted users generating apparent shortfalls that could have been resolved before submission. Fix: review consolidation output logs specifically for multi-system duplicates.

Step 5 (SLAW review): Treating the review as a confirmation step rather than an investigative one. Consequence: errors in the SLAW report become the submitted record. Fix: compare current SLAW against prior year and investigate all unexplained increases before submitting.

Step 6 (Timing): Submitting at the default earliest convenience. Consequence: measurement may capture an atypical usage period. Fix: apply the strategic timing analysis in the dedicated timing guide.

Step 7 (Submission): Submitting without supporting documentation. Consequence: SAP requests follow-up information, extending the review window. Fix: compile the full documentation package before submitting.

Step 8 (Post-submission): Treating SAP's shortfall analysis as final. Consequence: paying for licences that may not legitimately be owed. Fix: commission independent review of any SAP shortfall claim before engaging commercially.