A Microsoft SPLA audit reconciles your self-reported monthly usage against the evidence of what you actually deployed — and because SPLA has no perpetual license to anchor it, that reconciliation is unusually unforgiving. Discrepancies are billed retroactively, often across several years, and can carry penalty multipliers. The defensible position is built long before an audit letter arrives, through the reporting discipline described in our Microsoft SPLA licensing guide. This guide explains how a SPLA audit works and how to be ready for one.
SPLA is among the most actively audited Microsoft programs precisely because it trusts the provider to report honestly each month with no purchased license to verify against. That structural trust is also a structural exposure: when the only record of entitlement is the report you filed, the report had better be right and the evidence behind it had better still exist.
How a SPLA audit unfolds
An audit typically opens with a notice and a request for deployment data, then reconciles that data against your filed monthly reports. The auditors gather hypervisor inventories to test Windows Server and SQL Server core counts, Active Directory and connection-broker data to test RDS and SharePoint SAL counts, and SQL Server deployment scans to test edition and metric choices. Each reported month is tested against the Product Terms in force for that month — not today's rules — which is why retaining the historical Product Terms versions you reported against matters so much.
| Audit area | What is tested | Evidence that defends you |
|---|---|---|
| Windows Server / SQL Server | Physical core counts per host, edition, density | Dated hypervisor inventory tied to reports |
| RDS / SharePoint | Unique SAL access counts | Reconciled access lists, de-provisioning logs |
| BYOL exclusions | Workloads excluded as customer-licensed | License Mobility verification, SA proof, dedication |
| Use rights | Each month vs the rules then in force | Archived Product Terms by reporting month |
Where findings come from
The largest findings usually trace to a handful of recurring causes: SQL Server cores under-counted on shared clusters, Windows hosts added without being licensed, RDS or SharePoint access that accreted idle users, and BYOL exclusions that cannot be substantiated because the customer's Software Assurance proof was never collected. These map directly onto the product mechanics in SQL Server SPLA licensing and the model choice in SPLA vs BYOL licensing, and onto the hardware eligibility rules in shared vs dedicated hardware.
The version-of-record defence: the strongest audit posture is one where you can hand the auditor, for any month, both the report you filed and the Product Terms version it was prepared against, plus the deployment evidence that supports it. Providers who can do this turn the audit into a confirmation exercise. Providers who cannot are negotiating the size of a back-bill from a position of incomplete facts — and the absence of evidence is rarely resolved in the provider's favour.
Building the defensible position
Audit readiness is not a project you start when the letter arrives; it is a monthly habit. Three controls carry most of the weight: report peak qualifying usage honestly each month against the correct Product Terms version, retain the evidence that supports each report, and reconcile deployment to reporting on a regular internal cadence so drift is caught in the month it happens rather than years later. The cost of catching a discrepancy monthly is a few hours of analyst time; the cost of catching the same discrepancy in an audit is the back-bill, the penalties, and the lost negotiating leverage of being wrong on the facts. For dynamic estates this discipline has to be instrumented rather than manual, as we explain for Microsoft licensing for IaaS providers.
If you are already in an audit
When an audit is live, the priorities are to control the scope and timeline, to validate the auditor's methodology rather than accept their reconciliation at face value, and to ensure your own evidence is assembled before responding. Many initial audit findings rest on assumptions — that a host runs a workload it does not, that access equals usage, that a cluster is fully exposed when a workload is pinned — that disciplined evidence can rebut. Our advisors represent providers through live SPLA audits as part of Microsoft audit defense, and the underlying reporting framework is set out in the SPLA licensing guide.
How to respond when the audit notice arrives
The first response to an audit notice is not to send data; it is to understand and bound the scope. Confirm which entities, which products, and which time period the audit covers, and agree a realistic timeline rather than accepting the first one proposed. Providers who rush data out under time pressure routinely hand over more than the scope requires and create findings that need never have surfaced.
The second step is to assemble your own picture before engaging with the auditor's. Pull your filed reports, the Product Terms versions they were prepared against, and the deployment evidence, and run your own reconciliation. Knowing where your real exposure sits — and where the auditor is likely to be wrong — lets you steer the conversation rather than react to it.
The third step is to test the auditor's methodology rather than accept it. Many initial findings rest on assumptions: that a host runs a workload it does not, that access equals usage, that a whole cluster is exposed when a workload is pinned, or that today's rules applied to a historical month. Each of these can be rebutted with evidence, and each rebuttal reduces the settlement.
What a defensible evidence pack contains
A provider who can produce, for any reported month, the filed report, the Product Terms version in force, a dated hypervisor inventory, the SAL access reconciliations, and the substantiation for any BYOL exclusions has effectively pre-empted the audit. The reconciliation becomes a confirmation of numbers the provider already stands behind. Building this pack is not extra work invented for the audit; it is the natural output of the monthly reporting discipline done properly. The providers who suffer in audits are not those with complex estates — they are those who reported diligently but kept no evidence, and so cannot prove that the diligent reports were correct.