An SAP audit closes on the basis of a workpaper, and the workpaper is a structured set of numbers. The numbers are the user counts, the engine measurements, the indirect-access document counts, and the chargeable surface that connects them to a commercial claim. None of the numbers should be accepted without independent validation. The validation is not adversarial in tone; it is methodical in practice. Across the matters that produced the firm’s benchmark sixty-eight per cent average claim reduction, the largest single source of reduction was not contractual interpretation but arithmetic — a finding that, line by line, did not reconcile with the buyer’s system of record. This article describes the validation techniques that recur.
The workpaper as an object
An SAP audit workpaper is, structurally, a set of joined tables. The first table is the user inventory: the SU01 list filtered by valid-from and valid-to dates, joined to the licence assignment in USMM. The second is the engine inventory: the active engines and their measured metric values from the LAW consolidation. The third is the indirect-access surface: the inbound RFC connections, the integration patterns, and (where applicable) the Digital Access document counts. The fourth is the entitlement set: the contractual quantities from the order forms and amendments.
The audit claim is the arithmetic of those four tables: measured minus entitled, multiplied by price, summed across the line items. The validation is the same arithmetic, run independently, with the buyer’s own filters applied. Where the two numbers diverge, the divergence is the negotiating surface. The methodology is covered in our USMM and LAW measurement checklist white paper.
Validation move one — the user inventory
The user-inventory line of the workpaper is the most frequent source of overstatement. The overstatement runs in three patterns. The first is inactive users: SU01 rows that have not logged in for a defined window but appear in the chargeable count. The second is technical users: system accounts, batch users, interface users that should not be counted against named-user licences. The third is duplicate users: a single human with multiple SU01 entries, often the result of name changes, merges, or system renames.
The validation runs three queries against SU01 and the SUIM history. Query one filters for last logon outside the agreed dormancy window. Query two filters for user-type IDs that match the system-user definition in the contract. Query three groups by employee identifier (where available) to detect duplicates. The three queries together typically reduce the chargeable user count by between twelve and twenty-two per cent on a first pass. The dormant user purge tactics article covers the cleanup before validation begins.
The classification sub-check
Once the count is correct, the classification is the next validation. SAP’s workpaper assigns each user to a licence type — Professional, Functional, Productivity, or Employee — based on the rules in the named-user table. The buyer-side validation re-runs the classification using the buyer’s reading of those rules. Where the readings diverge, the divergence is documented. The named user buckets article covers the classification logic.
Validation move two — the engine measurement
The engine line of the workpaper covers the metered components: payroll line items, financial document counts, HR record counts, BW data volumes, and (where applicable) the indirect-access document counts. Each engine is governed by a metric, and each metric is defined contractually. The validation question is whether SAP’s reading of the metric matches the contractual definition.
Three patterns recur. The first is the wrong measurement window: SAP’s measurement covers a twelve-month window that may include peak-load periods not contemplated in the original sizing. The second is the wrong scope of inclusion: an engine count that includes records not subject to the metric (test records, voided documents, archived records that should not be re-counted). The third is the wrong rounding: a metric that is contractually defined per ten thousand records but counted at the unit level. The methodology is in our USMM and LAW defensive prep article.
Validation move three — the indirect-access surface
The indirect-access line is the most contested portion of most workpapers. The contestation is structural: SAP’s reading of the integration surface is derived from the system traces, which capture every inbound connection regardless of whether the connection generates chargeable activity. The buyer-side reading reconstructs the integration topology from the architectural inventory, and counts only the patterns that produce chargeable activity under the contract.
The validation has three sub-moves. First, identify the inbound RFC connections from the SM59 inventory and reconcile against the documented integrations. Second, classify each integration as direct-use, employee-mediated, or third-party-platform, and apply the chargeable-surface rules. Third, calibrate the document count (where Digital Access is in scope) against the actual line-item counts in the engine, not the trace counts. The work is covered in our middleware risk article.
Validation move four — the entitlement reconciliation
The entitlement line of the workpaper is the contractual quantities the buyer has purchased. The validation is the reconciliation of those quantities against every order form, amendment, and assignment letter in the contract history. Across long-tenure SAP customers, the entitlement reconciliation typically uncovers between three and seven per cent of additional capacity that the SAP-side has not picked up — legacy purchases, conversion credits, and free-of-charge entitlements that were granted as part of prior negotiations.
The reconciliation requires the complete contract history, including pre-RISE entitlements where the customer has converted to RISE. The conversion tables are often imperfectly maintained on the SAP side, and the validation work surfaces the carry-forward entitlements that should reduce the gap. The licence compliance assessment service covers the methodology.
The discrepancy log
The validation work produces a structured discrepancy log: one row per workpaper line item, with the SAP-side value, the buyer-side value, the variance, and the contractual or technical basis for the buyer-side reading. The discrepancy log is the input to the position document. Each discrepancy is then prioritised by financial impact and by defensibility. The high-impact, high-defensibility discrepancies are taken first; the low-impact, low-defensibility discrepancies are either conceded or held in reserve for trade in the settlement architecture.
Across our matters, the discrepancy log typically contains between twenty and forty rows for a mid-size enterprise audit. The cumulative variance is the negotiating surface that produces the firm benchmark settlement. The structured presentation of the discrepancy log to SAP is itself a discipline; the position paper article covers the structure.
The workpaper is a structured set of numbers, and the validation is the same arithmetic run independently. Where the two numbers diverge, the divergence is the negotiating surface. The settlements at the benchmark are the settlements where the divergence was identified, documented, and presented.
The burden of proof question
One frequent question is whether the burden of proof for each line of the workpaper sits with SAP or with the buyer. The contractual answer varies by agreement; the practical answer is that whichever side documents the line first sets the burden on the other. If SAP’s workpaper is the only documented reading, the burden is on the buyer to challenge it. If the buyer’s validation is documented in parallel, the burden becomes shared, and each line is resolved on the documentation rather than on default presumptions. The SAP ECC topic page covers the related contractual context.
The cadence of the validation work
The validation is conducted in parallel with the SAP-side measurement, not after it. A common error is to wait for SAP’s workpaper before beginning validation; by the time the workpaper arrives, the cadence is set by SAP’s timetable and the buyer’s validation runs as a reactive check. The disciplined approach runs the validation as a proactive measurement that produces the buyer’s own workpaper before SAP’s arrives. The two workpapers are then reconciled side-by-side.
For a representative example of the technique applied at scale, see our global manufacturer case study, where structured validation reduced an opening claim by sixty-eight per cent over a four-month engagement.
The economic case for validation
Across our $180M+ in client savings, line-item validation has been the single largest source of reduction. The contractual argument and the negotiation architecture matter, but they operate on a base that the validation has already corrected. A negotiation conducted against an unvalidated workpaper trades from a position that the buyer’s own data does not support. A negotiation conducted against a validated workpaper trades from a position that the buyer can defend, contractually and arithmetically, line by line. The audit defence service page describes how the validation is integrated into the broader engagement.
— 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.