The buyer takeaway first. SPLA is Microsoft's monthly licensing program for providers that deliver Microsoft software to external customers, and it is built around a single discipline, report what you consume each month at the price file rate. Understanding how the program works is the foundation of defending an audit, because every audit is just a test of whether your monthly reporting matched your monthly use.
What SPLA is for
The Services Provider License Agreement exists for hosters, managed service providers, and outsourcers that run Microsoft workloads on behalf of other organizations. Ordinary volume licensing assumes you license for your own use. SPLA assumes you are licensing on behalf of customers who come and go, scale up and down, and consume by the month. The program is therefore consumption based and continuous rather than a fixed purchase.
Pay as you consume
The defining feature is that you pay for what you used, each month, at that month's price file rate. There is no upfront block of entitlement to draw down. Each reporting cycle you measure consumption, apply the use rights, and submit a report. Because the model is monthly, compliance is a monthly obligation, and an audit verifies every month in scope across the 36 month lookback rather than a single point in time.
SAL and processor, the two counting bases
SPLA products are licensed on one of two bases, and choosing and applying the right one is where much of the accuracy lives:
- Subscriber Access License, or SAL, is counted per user or per device with access to the licensed product in the month. It suits user facing workloads.
- Processor or core based licensing counts the physical capacity that runs the workload. It suits high density or infrastructure workloads.
Applying the wrong basis drives error in both directions. Under reporting is compliance risk that surfaces in an audit. Over reporting quietly wastes margin every month. Right reporting protects both your compliance and your economics.
The SPUR, the rule book you report against
The Services Provider Use Rights, the SPUR, is the document that tells you how each product may be used and counted under SPLA. It changes over time, so the version that governs a given month is the version in force that month. A correct report is a report that applies the right SPUR rules to the right products for the right period. This is why product version mapping matters so much in an audit, because the rules attach to versions.
| Step | What happens | Why it matters in an audit |
|---|---|---|
| Measure | Capture active users, devices, or processor capacity for the month | This is the raw consumption the auditor will test |
| Apply the SPUR | Map each product to its use rights and counting basis | Correct application separates licensable use from raw capacity |
| Report | Submit the monthly SAL or processor counts on time | A filed, on time report is the strongest evidence you have |
| Retain | Seal the supporting counts and customer mapping | Sealed records turn assertions into defensible facts |
Where exposure builds quietly
Most SPLA exposure is not deliberate. It accumulates from small, repeated reporting gaps, a customer onboarded but not added to the count, a product version updated without updating the use rights applied, a disaster recovery instance counted as active, a multi tenant boundary that was never documented. Across 36 months these small gaps compound into the number an auditor presents. The program rewards discipline and punishes drift.
Why the program design is the defense
Because compliance is monthly, the structural defense is reporting discipline practised every month, not assembled in a crisis. Monthly SAL reports filed on time, sealed daily authentication counts, customer mapping for each reported block, product version mapping, and documented multi tenant boundaries are the evidence that lets you reconstruct any month under challenge. Where that discipline exists, an audit is a confirmation. Where it is thin, an audit is a reconstruction against the clock.
Your next step
If you run Microsoft workloads under SPLA, the full guide turns this overview into a working defense, with the reporting evidence that holds and the way back fees and the negotiable uplift are set. Read it before an audit notice ever arrives.
If an auditor is already asking questions, our SPLA audit defense team challenges the counting before back fees are set.