A SPLA report is a claim. It states how much Microsoft software a hoster made available to external customers in a given month, expressed in SAL or processor counts. Like any claim, it is only worth what stands behind it. The records that stand behind it are the license verification forms and supporting evidence that let anyone, including an auditor, trace a reported number back to the deployment that generated it. When those records are complete and current, the report defends itself. When they are thin or missing, the report is just a figure the auditor is free to challenge, and the burden of proving it sits entirely with the hoster.
This article explains what these verification records contain, why their condition decides how a 36 month lookback goes, and how to maintain them so each month stays provable. It is part of the hoster compliance operations cluster and supports the SPLA Audit Defense Guide, which covers the full audit and the reporting discipline that defends it.
Why the records decide the audit, not the report
A Big Four firm conducts a SPLA audit under the audit clause in the agreement, with broad authority to request deployment records, server configuration data, customer contracts, and usage logs. Compliance is verified for every monthly reporting cycle across the 36 month lookback, so the auditor is not testing one number. It is testing thirty six of them, and for each it wants to see the evidence that the reported figure matched reality. The report tells the auditor what you said. The verification records tell the auditor whether it was true. It is the records, not the report, that determine whether a month holds.
A report without records is an assertion. A report with records is a defense.
The asymmetry is unforgiving. Back fees at the price file rate for under reported months are not negotiable, so any month you cannot defend with evidence is a month you may simply owe. The penalty uplift, ranging from 25 to 125 percent, is negotiable, and the strength of your records is one of the main levers that moves it down. A hoster with clean, complete verification forms across the lookback argues from evidence. A hoster without them argues from memory, and memory does not survive an audit.
What a complete verification record contains
A verification record for a reporting cycle is the bundle that lets the monthly figure be reproduced from source. For each month it should hold the following.
- The submitted report itself, with the SAL or processor counts as declared and the date it was submitted.
- Sealed daily authentication counts that underpin the SAL figures, captured at the time and preserved unaltered.
- Customer mapping that ties each reported block to the external customers served, so the count reconciles to actual usage.
- Product version mapping, linking each reported product to the edition and version deployed and the SPUR rule applied.
- Multi tenant isolation evidence, showing how customer environments are separated where shared infrastructure is used.
The standard to aim for is reproducibility. Someone outside your team should be able to take the records for any month and arrive at the same reported number without asking you a question. If reproducing the figure needs your explanation, the record is incomplete, and an auditor will treat the gap as their opening, not yours.
How verification records decay
Records rarely fail all at once. They decay quietly, one missed step at a time, until a lookback that everyone assumed was clean turns out to have holes. The common failure modes are predictable.
| Failure mode | How it happens | Audit consequence |
|---|---|---|
| Authentication counts not sealed | Counts are pulled ad hoc and not preserved unaltered | SAL figures cannot be traced to source and are open to challenge |
| Customer mapping drifts | New customers are onboarded but never added to the mapping | Reported blocks cannot be reconciled to actual usage |
| Version mapping stale | An edition upgrade changes the SPUR rule but the mapping is not updated | The wrong rule appears to have been applied, inflating findings |
| Records held by one person | Evidence lives in an individual's files, not a controlled store | A departure leaves months of the lookback undefendable |
Each of these is a maintenance failure rather than a reporting failure. The number may even have been correct when submitted, but if the evidence that proves it has decayed, the correctness no longer counts. The audit tests the records, and records that were not maintained do not pass.
Maintaining the records so they hold
Keeping verification forms audit ready is a maintenance routine, run with the same monthly cadence as the reporting itself. Four practices keep the records sound.
Maintained this way, the verification forms turn the lookback from a liability into a defense. Every month is provable because the proof was created and preserved when the month closed, and the audit becomes a confirmation rather than an excavation.
The buyer side view
Verification records are the quiet foundation of every SPLA defense, and they are entirely within a hoster's control. We help hosters build the verification routine, seal the right evidence each month, and keep the mappings current so a 36 month lookback reconciles without drama. Our guarantee stands behind the work: we reduce your exposure or we reimburse our service fee, and with gainshare you pay only from verified savings or avoided penalty, with no risk to you. To see how the records fit the wider audit and the reporting discipline that defends it, download the guide below.
If you would rather not face that alone, we take over the process through our Microsoft audit defense engagement.