SAP Audit Preparation Toolkit: 10 Steps to Control the Audit Before It Controls You

Understanding the SAP Audit Trigger

SAP does not audit customers at random. Licence audits are initiated in response to specific commercial, technical, or contractual triggers. Understanding these triggers helps you anticipate audit risk and begin preparation before the audit notice arrives. SAP's Licence Audit & Compliance (LAC) team initiates audits for five primary reasons: major system events (new implementations, significant version upgrades, S/4HANA migration discussions), organisational changes (M&A activity, company spinoffs, significant workforce expansion), contract renewals or negotiations (renewal discussions create leverage for audit-based settlement), third-party integrations (Salesforce, Workday, or cloud platform deployments that expand system scope), and telemetry triggers (SAP's telemetry systems flag unusual activity patterns, module usage expansion, or performance-related scaling requests).

The Extended Maintenance Program (EMP) extension for EHP 0-5 systems ended December 31, 2025. Organisations still running ECC 6.0 with EHP 5 or lower are now under heightened audit scrutiny. SAP uses audit risk as commercial leverage to push customers toward S/4HANA migration timelines. If your organisation is running EHP 5 or earlier, audit risk has materially increased as of Q1 2026.

Step 1: Assemble Your Audit Response Team

Before any response to SAP's audit, establish a single point of contact and cross-functional team with clear roles. The team typically includes SAP Basis administrator (system access, LAW reports, user management data), Procurement or Vendor Manager (contract retrieval, licence certificate validation, purchase order history), IT Finance or Budget Owner (internal cost analysis, budget impact modelling), Legal or Compliance Officer (contract interpretation, dispute escalation authority), and if budget permits, External Specialist (independent methodology analysis, settlement benchmarking).

Designate a single point of contact (typically procurement or legal) for all SAP communications. This prevents ad-hoc communications that can inadvertently concede positions, create timeline complications, or trigger internal conflicts. Brief the team explicitly: nothing goes to SAP's audit team without review and approval from the designated contact. Create a communications log from day one documenting every email, phone call, meeting note, and data submission to SAP. This log becomes crucial during settlement negotiations because it demonstrates your diligence and creates a record of SAP's methodological evolution as they refine their claims.

Step 2: Run USMM and LAW Before SAP Does

SAP will run Licence Administration Workbench (LAW) and User Measurement System (USMM) during their audit. Running these tools yourself gives you 4-6 weeks to understand and address the findings before SAP uses them against you. USMM captures named user counts per system at a point-in-time. LAW consolidates across your entire landscape and identifies duplicate user accounts across systems. Neither tool validates licence type accuracy or checks historical entitlement coverage, but both form the foundation of SAP's methodology.

Run LAW immediately. Export the full output including user lists, duplicate accounts, system mapping, and client transactions. Don't wait for SAP to run it during their audit—by then the findings are established and difficult to challenge. Your own LAW run gives you opportunity to identify and address obvious errors (deactivate test accounts, consolidate duplicate user records, correct data quality issues) before SAP's measurement.

Step 3: Retrieve All Historical Contracts and Entitlements

SAP's audit team works from the most recent licence agreement. They do not proactively retrieve older agreements. This is critical: the oldest SAP licence agreements often contain the most valuable entitlements. Compile: master SAP licence agreement (the original binding document from your initial SAP procurement), all order forms and addenda (every purchase order that modified licence counts or modules), conversion credit agreements (especially from migrations or technology transitions), and all maintenance schedules and support agreements (these sometimes contain implicit licence rights).

Assign each document to the products and users it covers. Create a timeline showing how licence entitlements have evolved. Note any gaps or ambiguities. This is crucial: one European manufacturing company discovered that a 2009 master agreement contained engine licences that remained valid and offset 70 percent of a claimed $2.3 million shortfall. They had simply forgotten about the 2009 agreement when they renewed in 2019. Retrieving historical agreements recovered $1.6 million in offset coverage.

Step 4: Map and Validate Indirect Access Exposure

SAP routinely overcounts indirect access exposure by 60-80 percent. Map every third-party system that connects to SAP. For each interface: identify what data it reads or writes, estimate the document volume it creates annually, and classify that activity under the Digital Access Adoption Program (DAAP) framework. The critical distinction: SAP's audit team measures interface activity (API calls, service requests, lookup operations). You must reframe this as document counts (purchase orders created, invoices posted, goods receipts recorded). API calls for lookups and validation do not create licensing exposure under most contracts; only the creation of new documents does.

This step is essential. In the food manufacturer case study detailed earlier, 1.2 million API calls generated 180,000 unique documents. SAP's methodology multiplied the exposure by 6.7 times by counting API calls instead of document counts. Your own analysis, completed before SAP's audit, establishes the correct baseline and prevents the methodology error from being embedded in their findings.

Step 5: Reclassify Users to Correct Licence Types

Run a detailed transaction analysis for every user in your LAW report. SAP's audit team classifies users based on aggregated role definitions and module access, not actual transaction patterns. This systematic overclassification is the largest source of overclaimed named-user exposure. Review actual user behaviour: warehouse staff doing only goods receipt (should be Limited Professional, not Professional). Time-entry clerks doing only ESS (should be no charge at all, included in M365). Accounts payable posting only invoices (should be Limited Professional). Field supervisors doing only leave approvals (should be ESS). Production planners doing only report viewing and dashboard access (should be Fiori viewer or portal user, not Professional).

User reclassification typically reduces named-user exposure by 30-50 percent. Create documentation showing actual transaction patterns per user role. This becomes your strongest negotiating tool during settlement because it is based on your data, not SAP's assumptions.

Step 6: Validate Engine and Package Licence Consumption

SAP engines and packages (PI/PO message counts, HANA memory consumption, Fiori licences, BW capacity) are measured differently from named users. Validate current consumption against entitlement levels. Key areas: PI/PO message volumes—track your actual peak and average message throughput for the measurement period. HANA capacity—if you are using HANA for development or testing (non-productive environments), different measurement rules may apply. Fiori licences—as of 2025, only 39 percent of SAP's 35,000 ECC customers have actually licensed S/4HANA; if your HANA licence was procured for ECC development, the measurement metric may have changed. Business Analytics infrastructure—BW capacity pricing changed multiple times between 2015 and 2025; your entitlement may not match current metering assumptions.

This analysis is technical and requires deep licensing knowledge, but it often uncovers 10-20 percent of additional defensible savings in engine and capacity-based claims.

Step 7: Document Your Clean Core Position

As of 2026, SAP increasingly uses S/4HANA migration discussions as an audit leverage point. Document your clean core status: current customisations that run on standard ABAP with no BTP exposure, integrations that use SAP Cloud Integration versus third-party middleware (affects digital access liability), and BTP credit consumption versus entitlements. If your S/4HANA migration is under discussion, this documentation becomes leverage: "An audit-driven settlement now supports business case assumptions for migration timing. An unfair settlement jeopardises the entire programme."

Step 8: Establish Your Commercial Position

Before engaging with SAP's audit team, calculate your own true exposure using defensible methodology. Then identify where SAP's methodology overreaches. Quantify the concessions you would accept in a settlement (forward-looking digital access licences, user reclassification, migration credits) and determine your walk-away position. A European manufacturing company walked into their SAP audit with a $9 million claim and walked out with a $1.4 million settlement because they had completed steps 1-7 and knew exactly where their defensible position was before the first call with SAP's audit team.

Step 9: Manage the Audit Execution Phase

During SAP's active audit: provide only what is contractually required, in the format you control. Never provide raw SAP system access. Export data instead and provide in structured format. Never send unreviewed email to SAP's audit team—all communications go through your single point of contact. Document every communication in your log. Challenge every methodology assumption in writing before agreeing to any measurement approach. For example: "We understand you are measuring interface call volumes. Can you confirm which contract language requires licensing based on call volumes versus document creation? We believe the operative measurement is document counts under DAAP. Please confirm your methodology before we provide access to system data."

Step 10: Plan the Settlement Negotiation

SAP's LAC team has settlement authority but operates within hierarchies. Account executives have limited authority (typically 15-20 percent reductions from opening claim). Deal desk can approve 20-25 percent reductions. VP-level can approve 30-40 percent. SVP or MD can negotiate further when commercial leverage is demonstrated. Plan your negotiation in stages. Use migration leverage: "We are evaluating S/4HANA—a fair settlement now supports the business case." Use competitive leverage: third-party maintenance (Rimini Street, Spinnaker) is a 50 percent cost reduction from SAP support and a credible alternative. Use the data from steps 1-9 to demonstrate analytical rigor and force SAP to justify every overclaimed position in their methodology.

Key Principles Across All 10 Steps

Three principles emerge across all 10 steps. First: preparation is asymmetric leverage. SAP expects most customers to begin audit response after receiving the audit notice. You begin during the contract lifecycle and maintenance period. This gives you months of preparation advantage. Second: methodology challenge must precede data submission. Once you provide data to SAP's audit team, their interpretation of that data becomes your burden to overcome in settlement negotiations. Challenge methodology in writing before providing data. Third: commercial context matters as much as technical methodology. S/4HANA migration timelines, system modernisation programmes, and licence renewal discussions create commercial leverage that pure technical analysis cannot provide. Use both.