An SAP audit conversation that begins and ends with the USMM file alone is the exception, not the rule. The auditor receives the file, parses the counts, and produces a follow-up list that asks for the supporting evidence: classification decisions, role mappings, dormancy exclusions, communication-user justifications, engine-metric inputs, indirect-user identification. The evidence the auditor requests in follow-up is the evidence pack. Submitting the pack alongside the USMM file shortens the audit cycle, reduces the volume of follow-up questions, and improves the negotiation position when claims emerge. This article walks through the pack contents, the assembly sequence, and the audit questions the pack must answer the first time. It is the methodology underneath our USMM and LAW advisory engagements.
What the pack is for
The evidence pack serves three functions during an audit. First, it pre-empts the follow-up questions. An auditor who can answer their own questions by reading the pack does not ask the questions, and the audit cycle compresses from months to weeks. Second, it documents the classification reasoning. Where the auditor disagrees with a classification, the pack provides the basis on which to discuss the disagreement substantively rather than to accept the auditor's reclassification by default. Third, it preserves the institutional memory. The team that assembled the measurement may not be the team that defends it at audit eighteen months later. The pack carries the reasoning forward.
Estates that operate without an evidence pack discover during audit that the classification reasoning has been lost. The accounts are classified Professional or Developer, but no one currently in the estate can explain why. The auditor's reclassification proposal becomes the only documented position, and the buyer-side defence is anchored to the auditor's view. The USMM topic page covers the wider audit-defence frame.
The seven sections of the pack
A complete pack has seven sections. Each addresses a category of audit question and each can stand alone as evidence.
Section one — measurement scope
The scope section lists the systems included in the measurement, the systems excluded with the basis for exclusion, the measurement date, and the LAW consolidation perimeter. It includes a system inventory diagram showing the production, non-production, and shadow systems with their licence status. The diagram is the auditor's mental model of the estate; the scope statement is the buyer-side definition of what the measurement covers and excludes.
Section two — user-population reconciliation
The reconciliation section maps the USMM user counts back to the underlying HR and identity-management populations. It documents the inclusion logic (active employees, contractors with named access, third-party partners with portal access), the exclusion logic (terminated employees with residual SU01 records, service accounts reclassified as Communication users, test accounts reclassified out), and the date alignment between the HR cut and the USMM cut. The reconciliation answers the audit question "do these counts reflect the real population".
Section three — classification logic
The classification section documents the rules applied to assign each licence type. For each licence type used, it includes the SAP price-list definition, the buyer-side interpretation of the definition, the role and authorisation pattern that triggers the classification, and the volume of accounts in that classification. Where the buyer-side interpretation differs from the auditor's customary view, the section anticipates and addresses the disagreement. The classification rules article covers the interpretation patterns.
Section four — dormancy and exclusion
The dormancy section documents accounts excluded from the chargeable population on the basis of inactivity. It includes the dormancy threshold (typically twelve months without a logon), the source of the last-logon data, the exclusion volume, and the post-exclusion verification that the excluded accounts are not still consuming the estate through batch jobs or background processes. The auditor's customary challenge to dormancy exclusion is that the accounts may be in use through indirect paths; the section addresses this anticipation.
Section five — engine and package metrics
The engine section documents the consumption inputs for each engine and package metric in the contract. For each metric, it includes the source of the consumption figure, the calculation logic, the measurement period, and any data-extraction queries used. Where the metric is self-declared, the section includes the self-declaration evidence. The self-declaration article covers the methodology.
Section six — indirect-access identification
The indirect-access section documents the integrations to non-SAP systems, the categorisation of each integration as human-driven or system-driven, the digital-access document estimate, and the contractual basis for the digital-access position. It addresses the auditor's customary view that any non-zero integration list creates a digital-access liability.
Section seven — methodology notes
The methodology section records the tools used (USMM, LAW, custom extracts), the personnel involved, the review and approval chain, and the version history of the measurement. It is the audit trail for the audit trail.
The pack is assembled once and maintained across cycles. Each annual measurement updates the relevant sections; the underlying framework persists. Estates that maintain the pack across cycles answer audit questions in days rather than weeks.
The assembly sequence
Assemble the pack in the order the auditor will read it. Scope first, then population, then classification, then exclusions, then engines, then indirect, then methodology. Each section assumes the prior sections; the auditor reads it as a narrative, and the narrative order matters.
The assembly itself takes between two and four weeks for a mid-size estate that has never produced a pack before, and between three and ten days for an estate maintaining the pack across cycles. The differential is the cost of doing the assembly retrospectively versus iteratively. The post-measurement cleanup article covers the iterative model.
How SAP uses the pack
SAP's auditor reads the pack alongside the USMM file. Where the pack answers a question completely, no follow-up is required. Where the pack raises a question, the auditor flags the section and asks for the underlying evidence (the source data, the SQL extract, the HR feed). Where the pack omits a section, the auditor asks for the section in full. The reading order is the auditor's reading order; the question density falls as the pack quality rises.
The pack is also the basis for the closing letter. A measurement defended successfully through the audit cycle yields a closing letter that references the pack. The reference is consequential at the next audit cycle: the prior closing letter sets the precedent against which the next audit is conducted. The media-company case file documents the pattern.
The white-paper reference
Our USMM and LAW checklist white paper sets out the full section-by-section assembly. It is the working reference for buyer-side teams building the pack for the first time.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
Where to start
Start with section one. The scope statement is the foundation, and most estates discover during the scope work that the system inventory diagram is itself out of date. The diagram is a worthwhile deliverable in its own right, and the audit-defence value is consequential.