For a hoster under SPLA, the Services Provider Use Rights, known as the SPUR, decide almost everything that matters. They set out how each Microsoft product must be licensed when delivered to external customers, how it must be counted, and how it must be reported. The SPUR is updated regularly, and the version that applies is the one in force for the month being reported. Because SPLA verifies compliance for every monthly cycle across a 36 month lookback, the way you read the SPUR is not a one time decision. It is a practice that is tested in every month of the audit.
This article explains what the SPUR is, the core ideas a service provider needs to apply it correctly, where it is most often misread, and why getting it right is the foundation of SPLA compliance. The mechanics are specific to hosters. They have no direct equivalent in an end customer Microsoft audit, where the question is a point in time Effective License Position rather than a stream of monthly reports.
What the SPUR is
The SPUR is the document that translates a SPLA agreement into operating rules. It tells a service provider which licensing model applies to each product, what counts as use, and what each license actually permits when software is hosted for someone else. SPLA itself is pay as you consume: you report what you used and pay for it monthly. The SPUR is what defines used. Without it, a monthly report is just a guess at obligations that the SPUR has already specified in detail.
SPLA tells you to report what you consume. The SPUR tells you what consumption means. Confuse the two and every month is wrong in the same way.
The core ideas to apply correctly
Three ideas do most of the work. First, the licensing model: many products are licensed by Subscriber Access License, where you count the users or devices accessing the software, while others are licensed by processor or by core, where you count the hardware. Picking the wrong model misstates the whole report. Second, edition matters: Standard and Enterprise editions of the same product carry different rights and different rates, so the edition you ran has to be recorded and reported precisely. Third, the version in force: the SPUR changes over time, and the rules that apply to a given month are the rules from that month, not the latest ones.
| SPUR question | What it determines |
|---|---|
| SAL, processor, or core model | How you count and report that product |
| Standard or Enterprise edition | Which rights and which rate apply |
| Which SPUR version applies | The rules in force for the reported month |
| Eligibility under SPLA | Whether the product can be hosted at all |
Where the SPUR is misread
Misreadings cluster in a few places. Service providers apply the current SPUR to past months, when the version in force at the time was different. They count by the wrong unit, reporting users where the product requires processor or core counting. They report a workload under Standard when the features actually in use placed it in Enterprise. And they overlook eligibility, hosting a product through SPLA that the SPUR did not permit to be delivered that way. Each of these is the kind of error that becomes a standing practice, which is what makes it expensive when the lookback exposes it month after month.
A SPUR error is rarely a single line. It is a rule you applied every month. Correct the reading once and you have to correct every report that used it, which is why reading the SPUR right the first time is the cheapest control a hoster has.
Why correct SPUR application is the foundation
Everything else in SPLA compliance sits on top of an accurate SPUR reading. Monthly SAL reports are only as good as the model and edition behind them. Customer mapping and product version mapping exist to evidence the SPUR application for each deployment. The penalty uplift negotiation depends on showing the auditor that your reading was disciplined and consistent. Get the SPUR right and the rest of the pack reinforces it. Get it wrong and the same mistake undermines every report you submit.
Reading the SPUR correctly each month, and being able to show how you read it, is the structural defense against an inflated SPLA finding. For how the SPUR fits with monthly reporting discipline, the data request, and the uplift negotiation, the SPLA Audit Defense Guide sets out the full hoster playbook and is the place to start.
Not sure your SPUR reading holds up
If you are unsure whether you applied the right model, edition, or version across the lookback, the guide walks through it. Download the SPLA Audit Defense Guide for the complete hoster playbook.