Every SAP audit, after the notification letter, produces a document-request list. The list is the operational instrument of the audit: it defines what data the SAP team will see, in what form, at what cadence. Buyers who respond to the request list as if it were a final and binding inventory of what must be produced miss the point. The list is a position, not an order. It is negotiable, scope-limited, and almost always over-broad on first delivery. The work of the first response is to bring it within the boundaries the contract defines.
What the request list typically contains
A standard SAP audit document-request list contains six categories of item. The USMM and LAW outputs from each in-scope system. The contracted entitlement — the order forms, amendments, and current consolidated position. The user master listings, with role assignments and last-login data. The engine-measurement outputs for each metric in the contract. The integration topology — the questionnaire on non-SAP applications that touch SAP data. And the historical correspondence and prior settlement documents from any earlier audit cycle.
Each category has a defensible scope and a contestable scope. The defensible scope is what the audit clause clearly entitles the SAP team to receive. The contestable scope is what the SAP team has requested beyond that. The buyer-side response separates the two and produces the first against an agreed protocol while contesting the second.
The scope negotiation
The first work on the request list is the scope negotiation. The contract’s audit-rights clause defines the audit’s scope — the entities in scope, the territories, the audited period, the systems included. The request list will typically exceed at least one of those boundaries. Common over-reaches include requests for data on entities not in scope (subsidiaries outside the audited entity), requests for data on integration patterns outside the audited systems, and requests for data on periods outside the audited window.
The buyer-side response is to write back to SAP, in the scope-confirmation letter described in our audit response sequence article, confirming what is in scope and what is out. The over-reaches are addressed in that same letter. The negotiation is rarely contested by SAP because the scope is contractual; what gets disputed is the buyer’s read of the scope, and that dispute is held openly rather than absorbed into a quiet over-production.
The USMM request
The USMM request is the most consequential single item on the list. The SAP team will request the raw USMM output from each in-scope system, often in a defined format and with specific metadata fields populated. The buyer-side response is not the raw USMM. It is the validated USMM — the same data, with the transaction-history classification pass applied, the documented re-classifications recorded, and a buyer-side commentary in the cover note.
This is not a refusal to produce. It is a production with the buyer’s reading attached. The contractual basis is clear: the audit clause entitles SAP to the measurement data, not to a specific format that excludes the buyer’s commentary. The methodology is detailed in our USMM and LAW topic page.
The role-collection over-classification trap
The raw USMM, in any estate with broad role design, will over-classify users. The transaction-history pass is what closes the gap. Producing the raw USMM without the pass is the single most expensive document-production decision a buyer makes in an audit. The gap is typically fourteen to twenty-two per cent of the named-user count.
The user master request
The user master listing request is broader than it appears. The standard request asks for every user ID in the system, with role assignments and last-login timestamps. The buyer-side response should include the active-user filter (last login inside the audited window), the technical-user separation (system IDs that should not be classified as named users), and the inter-system de-duplication (users present in multiple systems but classifiable once under the contract).
The de-duplication discipline is particularly important in multi-system landscapes. A user present in ECC, BW, and CRM under three IDs is one named user under the contract. The LAW consolidation does this for SAP’s benefit; the same discipline applied buyer-side surfaces the residual single-classification opportunity.
The engine-measurement request
The engine-measurement request asks for the throughput of each engine metric in the contract. The buyer-side response should include the carve-out documentation for each metric — the internal-traffic carve-out, the non-production carve-out, the inter-company carve-out, and any contract-specific exemptions. The carve-outs are usually defined in the order form and routinely omitted from the raw measurement run.
The carve-out documentation is the work that converts an over-stated engine reading into a defensible one. The difference is, across our engagements, three to eight per cent of the engine measurement — which on most metrics is a six- or seven-figure shift. The methodology is in our engine metrics topic page.
The integration topology questionnaire
The integration topology questionnaire is the audit’s probe for indirect and digital-access exposure. It asks for every non-SAP application that touches SAP data, the integration pattern, the document volume, and the user population of the connected application. The buyer-side response should be the integration topology document maintained as part of the compliance baseline — not a re-construction under audit pressure.
If the topology document does not exist, the audit is the first time the integration architecture is being formally documented, and the documentation will be done under SAP’s questioning. That is the wrong sequencing. The right sequencing is to build the topology as a compliance deliverable, refresh it on the cadence described in our licence-type inventory article, and produce it as a finished artefact when the audit lands.
The data-exchange protocol
Once the scope is agreed and the documents are scoped, the exchange protocol governs the actual production. Three rules. Every document is produced in writing, attached to a dated cover letter, in a named file format. No document is exchanged in a screen-shared session, on a phone call, or in an unscripted meeting. And every production is logged in a buyer-side production register that records what was sent, when, to whom, and with what commentary.
The production register is the buyer-side record of the audit. It is what allows the matter to be reconstructed in dispute, what protects against later claims of unproduced material, and what closes the audit cleanly at settlement. The discipline is straightforward; the absence of the discipline is the most common cause of avoidable cost in audit defence.
The privileged categories
Three categories of material on the request list should not be produced without legal review: the historical correspondence and prior settlement documents (which may be privileged); internal compliance assessments and risk registers (which are buyer-side analysis, not audit subject matter); and counsel communications. The audit clause does not entitle SAP to privileged material. The buyer’s response is to produce what is required, to identify what is privileged, and to log the privileged items in the production register without producing the underlying text.
The document-request list is a position, not an order. The first work is the scope negotiation. The second is the buyer-side commentary on every production. Both are routine; the absence of either is the typical cause of a badly run audit.
What a good request-list response looks like
A good response is structured, written, and on the record. It begins with the scope-confirmation letter. It produces the in-scope material in named files with commentary. It contests the over-scope items in writing. It logs every production. And it closes by handing the SAP audit team a complete, navigable record of the buyer-side position. The matter that arrives at the position-paper stage with a clean production register settles faster and at a lower percentage of the opening claim than the matter that does not. The SAP audit defence service page describes how we structure the production work alongside in-house teams, and the global-manufacturer case file includes a production register from one engagement.
The production register
The production register is the buyer-side log of every document produced to SAP during the audit. The register records the document name, the date of production, the cover letter reference, the named recipients, and the buyer-side commentary attached to the production. The register is maintained by the audit owner and reviewed at the end of every week of the engagement. At settlement, the register is the artefact that closes the production work and supports the release language in the settlement agreement.
The discipline of the register is straightforward. The absence of the register is the most common cause of avoidable cost in audit defence, because it leaves the buyer without a contemporaneous record of what was produced, and SAP’s file becomes the only record of the matter.
— 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.