The SPUR is the rule book for SPLA. The Services Provider Use Rights set out which products a hoster may license through SPLA, how each one is counted, and the conditions under which it may be delivered to external customers. Every monthly report a hoster files is, in effect, an interpretation of the SPUR applied to that month's deployment. When the interpretation is right, the report is both compliant and efficient. When it is wrong in one direction, you under report and build audit exposure. When it is wrong in the other, you over report and give away margin. This article explains how to read the SPUR so that neither happens.
For the wider defensive context, read the SPLA audit defense guide. Here we stay close to the document itself.
What the SPUR actually governs
The SPUR does three jobs at once, and reading it well means keeping all three in view. First, it defines eligibility: which products may be licensed under SPLA at all, since not everything Microsoft sells is available to hosters through this program. Second, it defines the counting model for each eligible product, whether that is a subscriber access license, a per processor or per core measure, or another unit. Third, it sets the use rights and conditions, including how the software may be delivered to external customers and what is and is not permitted. A report that gets eligibility right but the counting model wrong is still wrong, and the audit will find it.
The SPUR is not a price list. It is a counting rule. The number you report is an interpretation, and the auditor will test the interpretation.
The two counting models you will meet most
Most SPLA reporting comes down to two families of measure, and confusing them is one of the most common and expensive mistakes. Subscriber access licensing, or SAL, counts the users or devices that have access to the software, reported monthly. Processor or core based licensing counts the physical capacity the software runs on, regardless of how many users access it. The right model depends on the product and how it is deployed, and for some products you may choose the model that fits your deployment, which is where margin can be won or lost.
| Aspect | SAL based | Processor or core based |
|---|---|---|
| What is counted | Users or devices with access | Physical cores or processors |
| Best fit | Many servers, fewer users | Many users, fewer or denser servers |
| Reporting frequency | Monthly, by access | Monthly, by deployed capacity |
| Common error | Counting accounts that never accessed | Counting decommissioned or idle cores |
Choosing the wrong model is not a compliance failure on its own, but it almost always produces a number that is either too high or too low. A dense deployment with heavy user counts is usually cheaper on a core measure. A sparse deployment with few users across many servers is usually cheaper on SAL. The SPUR tells you which models are available for each product, and the deployment tells you which one is efficient.
Eligibility is the first gate
Before counting anything, confirm the product is eligible for SPLA at all. Some products are simply not offered through the program, and some are eligible only under specific conditions. Reporting an ineligible product under SPLA, or running a product the SPUR does not permit a hoster to deliver, creates exposure that no amount of accurate counting will cure. The eligibility question changes over time as Microsoft updates the program, which is why the SPUR has to be read in its current version for every reporting period, not once and then assumed.
Reading the use rights and conditions
The conditions attached to each product are where a careful reader earns their keep. They cover how the software may be delivered, whether it may be shared across customers, and the boundaries that must be maintained between tenants. These conditions matter enormously in an audit, because an auditor testing a multi tenant estate will ask whether the delivery met the SPUR conditions. Reading the conditions correctly, and documenting that your delivery meets them, is what turns a reported number into a defensible one.
Where misreading shows up in an audit
A SPLA audit, conducted by a Big Four firm under the MBSA audit clause across a 36 month lookback, is in large part a test of how well you read the SPUR each month. The auditor compares your reported counts against the deployment evidence and asks whether your interpretation of eligibility, counting model, and conditions holds. Under reporting from misreading the SPUR produces back fees at the price file rate, which are not negotiable, plus a penalty uplift of 25 to 125 percent, which is. Over reporting does not trigger a penalty, but it has been quietly eroding your margin for months or years, and the audit is often the first time anyone notices.
Reading the SPUR as a monthly habit
The hosters who read the SPUR well do it as a recurring discipline, not a one time exercise. Each reporting cycle, they confirm eligibility against the current SPUR, apply the right counting model to the actual deployment, check that delivery met the conditions, and record the interpretation alongside the report. That record is what lets them defend the number later and what stops a small misreading from compounding silently across the lookback. Reporting discipline of this kind is the structural defense in SPLA, and reading the SPUR correctly is its first step.
Where this leaves you
The SPUR is a counting rule, and reading it correctly is the difference between a report that is both compliant and efficient and one that drifts into under reporting or wasted margin. Confirm eligibility, choose the right counting model for the deployment, meet the conditions, and record your interpretation every month. Do that and the audit becomes a confirmation rather than a discovery.
If you want the full method for reading the SPUR, reconstructing the monthly base, and defending it under audit, download our SPLA audit defense guide and work through it against your own estate.
If the timeline is already running, our SPLA reporting discipline service puts the monthly evidence in order before an auditor ever asks.