SPLA is unlike most licensing programs in one decisive way. It does not measure where you stand today. It measures where you stood in every single month, because the program is pay as you consume and compliance is verified for each monthly reporting cycle, not just the current position. When a Big Four firm conducts a SPLA audit under the audit clause in your agreement, it looks back across a 36 month lookback and tests each of those months in turn. That single fact changes everything about how a hoster should approach compliance. It is not something you prepare for when the notice lands. It is something you operate, month after month, so that when the notice does land every cycle in the window is already defensible.
This article sets out what SPLA compliance looks like as an ongoing operation rather than a periodic clean up, the records that operation produces, and why reporting discipline is the structural defense for a hoster. It is part of the hoster compliance operations cluster and pairs with the SPLA Audit Defense Guide, which sets out the full mechanics of a SPLA audit.
Why SPLA is an operation, not an event
Under SPLA, a hoster applies the Services Provider Use Rights, the SPUR, and reports either SAL counts or processor counts each month for the Microsoft software it makes available to external customers. That monthly report is the unit the auditor examines. Misapplying the SPUR drives error in two directions. Under reporting is a compliance risk that surfaces as back fees and penalty uplift in an audit. Over reporting is quieter but just as costly, because it hands away margin month after month for licensing you never needed. Both come from the same root cause, which is a reporting process that is not operated with discipline.
A SPLA audit does not ask what you report now. It asks what you reported every month, and whether you can prove it.
The commercial stakes follow from the structure. In an audit, back fees calculated at the price file rate for under reported months are not negotiable. They are simply owed. The penalty uplift, which ranges from 25 to 125 percent depending on severity, duration, and the nature of the under reporting, is negotiable, and the quality of your monthly operation is what moves it. A hoster that can show clean, timely, well evidenced reports across the lookback negotiates the uplift from a position of strength. A hoster reconstructing its history under audit pressure does not.
What the operation produces every month
A compliant SPLA operation is defined by the evidence it generates as a matter of routine. These are the records an auditor will ask for, and the time to create them is the month they describe, not years later.
- The monthly SAL or processor report, submitted on time for every reporting cycle, with nothing skipped or estimated after the fact.
- Sealed daily authentication counts that support the SAL figures, captured and preserved so the report can be traced back to source.
- Customer mapping that ties each reported block to the external customers it serves, so usage and reporting reconcile.
- Product version mapping, so each reported product matches the edition and version actually deployed under the correct SPUR rule.
- Documented multi tenant isolation, showing where customer environments are separated and how that separation is maintained.
The discipline that matters most is timeliness. There is only a short window to correct a reporting mistake, so a number that was wrong when submitted and never fixed becomes a permanent feature of the lookback. An operation that catches and corrects within the window keeps the history clean. One that does not carries every error forward into the audit.
A simple monthly reconciliation view
The core of the operation is a monthly reconciliation that confirms what was deployed, what it should have generated in reported units, and what was actually reported. The figures below are indicative and meant only to show the shape of the check.
| Step | Source | What it confirms |
|---|---|---|
| Deployed services | Provisioning and configuration records | Which Microsoft products were available to customers that month |
| Required units | SPUR applied to the deployment | The SAL or processor count the deployment actually requires |
| Reported units | The submitted monthly report | What was declared to Microsoft for that cycle |
| Variance | Required against reported | Any under or over reporting, caught while it can still be corrected |
Run every month, this reconciliation keeps the variance near zero and the evidence current. Run never, it leaves a 36 month history that nobody can vouch for, which is exactly what an auditor is hoping to find.
Building the operation
Standing up a durable SPLA operation is a matter of ownership and rhythm, not technology alone. Four steps make it hold.
Done this way, compliance stops being a source of audit risk and becomes the structural defense it is meant to be. The reports are clean because they were operated, not assembled, and the lookback holds because every month in it was defended when it happened.
The buyer side view
A disciplined SPLA operation is the cheapest defense a hoster has, because it protects both compliance and margin at the same time. We help hosters stand up the monthly operation, get the SPUR applied correctly, and build the evidence that makes a 36 month lookback defensible before any auditor asks for it. 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 the full mechanics of a SPLA audit and the reporting discipline that defends it, download the guide below.
If you would rather not face that alone, we defend the full 36 month lookback through our SPLA audit defense work.