Hosters new to a SPLA audit often expect it to work like a point in time inventory: count what is deployed now, compare it to what was reported, and settle the difference. SPLA does not work that way. Because the Services Provider License Agreement is a pay as you consume program reported every month, an audit examines compliance for each monthly cycle, not just the current one. The standard window is a 36 month lookback, which means three full years of monthly reports are reopened and tested.
This article explains how the lookback works, why a monthly program produces a monthly audit, what an auditor reconciles in each cycle, and why disciplined reporting is the only defense that holds across three years of history. The mechanics are specific to hosters and differ entirely from how an end customer Microsoft audit is conducted, so it is worth getting them precise.
Why SPLA is audited month by month
SPLA is a monthly consumption program. Each month a hoster applies the Services Provider Use Rights, counts usage, and reports either Subscriber Access Licenses or processor or core based counts depending on the products. Because the obligation renews every month, compliance is a property of every month, not of a single snapshot. A month where reporting was accurate is compliant. A month where usage exceeded what was reported is a gap, regardless of what happened before or after.
SPLA compliance is not a position you hold. It is something you demonstrate, separately, for every month in the window.
What the 36 month window actually covers
The lookback reaches back across the prior monthly cycles, commonly 36 of them. The auditor does not average across the period or accept a single reconciliation for the whole window. Each month stands on its own. That has a hard consequence: a single month with under reported usage is its own finding, and 36 months means up to 36 separate opportunities for a gap to surface. A hoster that grew quickly, onboarded customers between reports, or changed product editions mid period will often find that the exposure is concentrated in specific months rather than spread evenly.
| Dimension | How the lookback treats it |
|---|---|
| Time window | Each monthly cycle across roughly 36 months |
| Unit of compliance | The individual month, not the average |
| What is tested | Reported counts against actual usage that month |
| Where gaps cluster | Growth, onboarding, and edition changes |
What the auditor reconciles in each cycle
A SPLA audit is conducted by a Big Four firm acting as an independent third party under the audit clause of the Microsoft Business and Services Agreement. The firm has broad authority to request deployment records, server configuration data, customer contracts, and usage logs. For each month it reconciles what you reported against what your environment shows you actually consumed. That means matching reported Subscriber Access Licenses to the users who actually had access, matching processor and core counts to the hardware that ran the products, and confirming that the product editions reported match the editions deployed.
The evidence that survives this reconciliation is granular. Sealed daily authentication counts, customer mapping for each reported block, and product version mapping for each deployment are what let you show, month by month, that the report was right. Without that evidence, the auditor builds its own count from the data it gathers, and that count becomes the basis of the finding.
How a gap becomes a number
When a month shows usage above what was reported, two components follow. The first is back fees, charged at the price file rate for the under reported usage in that month. Back fees are not negotiable. The second is a penalty uplift, which can range from 25 to 125 percent depending on the severity, duration, and nature of the under reporting. Unlike the back fees, the uplift is negotiable, and that is where much of the defensible value sits.
For each month in the lookback, back fees at the price file rate are fixed and not negotiable. The penalty uplift, from 25 to 125 percent, is negotiable. Multiplied across 36 months, small monthly gaps can compound into a large number, which is why the defense begins with reconstructing each month accurately.
Why reporting discipline is the defense
Because every month is tested, the structural defense is reporting discipline maintained continuously. That means submitting monthly Subscriber Access License reports on time for every month, sealing daily authentication counts so the numbers cannot be questioned later, mapping each reported block to the customer it served, mapping product versions to what was deployed, and documenting multi tenant boundaries so shared infrastructure is accounted for correctly. A hoster that has done this can walk an auditor through three years of history and close most months immediately. A hoster that has not is left reconstructing the past under pressure.
There is also only a short window to correct a reporting mistake before it hardens into an audit finding. Acting early, with the right evidence assembled, is what keeps an exposure that spans 36 months from becoming an exposure you cannot defend. The SPLA Audit Defense Guide sets out the full reporting discipline and the month by month reconstruction in detail.
This is the work we do for hosters facing the lookback. We sit between you and Microsoft and its appointed Big Four auditor, we rebuild each month from your own evidence, and we negotiate the uplift down where the facts support it. We reduce your exposure or we reimburse our service fee.
Facing a SPLA audit lookback
Before the auditor reopens three years of monthly reports, let a buyer side team reconstruct each cycle from your own evidence. The SPLA Audit Defense Guide shows how, and our team can run it with you.