Microsoft SPLA Licensing Guide

You are registered. Your guide is ready. Read the full 2026 edition of the Microsoft SPLA Licensing Guide below.

Prepared by Atonement Licensing · buyer-side advisory · last reviewed June 2026. Figures are list-level or clearly labelled indicative ranges. The 2,000-core, 5,000-subscriber hosting estate used below is a representative benchmark scenario for illustration, not a quote.

Executive summary

The Microsoft Services Provider License Agreement is a licence-by-usage model billed every month, and service providers overpay because the report drifts away from the deployment it is supposed to describe. SPLA licenses Microsoft software for hosted software and services delivered to third parties, reported and paid monthly through a reseller against the Services Provider Use Rights (SPUR). There is no fixed entitlement to true up against, so the monthly report is the entire control surface. The gap between a habitual report and a reconciled, right-metric one is typically 15 to 25 percent of SPLA spend, and it hides in the metric choice, the retired workloads still being reported, and the reseller margin nobody has tested.

On a representative 2,000-core, 5,000-subscriber hosting estate, a provider reporting from habit, peak numbers carried forward, products on the convenient metric rather than the cheaper one, models near $3.6M per year. The same estate, reconciled to live deployment each cycle and licensed on the right metric per product, models near $2.8M per year, an annual difference of roughly $0.8M on the same infrastructure (indicative). The decision in front of a provider is which products report by subscriber and which by core, how tightly the report tracks deployment, and how the reseller relationship is priced.

This guide covers the full SPLA picture for hosters and service providers: how monthly usage reporting works, the choice between SAL and core-based metrics, the SPUR rules that quietly create exposure, how Microsoft audits SPLA and how to defend it, how to govern reporting and benchmark the reseller, and when SPLA is the wrong vehicle altogether. It is written for buyers, by advisors who represent service providers on the buyer side only.

How SPLA monthly reporting works

SPLA is structurally different from a perpetual purchase or an Enterprise Agreement. You report what you deployed each month and pay for it, with no upfront purchase, no fixed entitlement, and no ownership of the licences. Reporting runs through an authorised Microsoft SPLA reseller, and what you must report is defined by the SPUR in force for the month in question. Because there is nothing to true up against, accuracy depends entirely on your own deployment tracking, and the report is the only number Microsoft ever sees.

The most common overpayment is reporting steady peak numbers when real usage varies, or carrying retired and decommissioned workloads in the monthly figure long after they stop earning revenue. The mirror image, under-reporting, is the audit exposure. Both come from the same root cause: the report drifting away from the deployment, because no one owns the reconciliation between them.

Action. Appoint a named owner for the monthly SPLA report and require that every cycle is reconciled to live deployment before it is submitted to the reseller.

SAL versus core-based metrics

Many SPLA products can be licensed either by Subscriber Access Licence (SAL), one per user with access to the hosted service, or by a core-based metric counted on the host running the workload. The right choice is a density question. A high subscriber-to-core ratio favours core-based licensing, because you pay for the hardware rather than the large user population; a low ratio favours SAL, because you pay for the handful of users rather than a fully licensed host. Choosing the wrong metric is not a one-off error, it is a recurring monthly overpayment that compounds for as long as the product runs.

Model both metrics against your real deployment density before you settle a product's reporting basis, and revisit it as density changes. The metric that was cheapest at launch is frequently not the cheapest at scale, and architecture changes, consolidation, multi-tenancy, moving to denser hosts, can flip the answer without anyone re-running the maths. The bar chart below shows where SPLA overpayment concentrates, expressed as indicative reduction ranges against a habitual report.

Action. Build a per-product density model, pick SAL or core on the maths, and add a metric review to the cadence whenever you re-platform or consolidate hosts.

The SPUR rules that catch providers out

The SPUR contains rules that quietly create exposure if they are misread. Licence Mobility, the line between shared and dedicated hardware, the treatment of your own internal administrative use under a SPLA, and how Windows Server and SQL Server are counted in multi-tenant hosting all change what you must report. Get one of them wrong and the result is either a steady overpayment or a back-dated audit claim, sometimes both on different products at once.

The rule that catches the most providers is using SPLA licences for internal use, the provider's own staff and administrative systems, which SPLA does not cover, or mixing SPLA with other licensing programmes on the same hardware in ways the SPUR does not permit. Map each workload to the correct programme, draw clean boundaries between SPLA and non-SPLA hardware, and document why each one sits where it does.

Action. Produce a workload-to-programme map that names the SPUR rule behind each placement, and review it whenever you add a host or onboard a customer who brings their own licences.

In SPLA there is no entitlement to true up against. The monthly report is the whole contract, and whoever owns the report owns the cost.

How Microsoft audits SPLA

SPLA agreements carry audit rights, and Microsoft exercises them with service providers routinely. Because there is no fixed entitlement, an audit does not compare a deployment to a purchase, it reconstructs what you should have reported from deployment evidence and compares it to what you actually reported. Gaps become claims, and because the report is monthly, those claims are frequently back-dated across multiple prior reporting periods, which is what makes them large.

The defence is the same data that controls cost: a defensible, monthly record tying deployment to the report. A provider who reconciles deployment to report every cycle walks into an audit with the answer already prepared and the SPUR version it was reported against on file. A provider who reports from habit reconstructs all of it under deadline, on Microsoft's terms, using Microsoft's interpretation of the rules. The audit response itself runs in three phases.

Action. Keep the monthly reconciliation and the SPUR version you reported against on file, so an audit is a document handover rather than a reconstruction project.

Govern reporting and benchmark the reseller

SPLA cost control is a monthly discipline, not an annual event. Assign ownership of the report, reconcile it to deployment every cycle, retire workloads from the report the month they stop running, and keep the SPUR version you reported against for each period. That cadence simultaneously minimises spend and builds the audit record, so the same work pays twice, once as cost control and once as defence.

SPLA is also transacted through a reseller whose margin and terms are negotiable, and providers routinely carry the same reseller relationship for years without ever testing it. Benchmark the reseller the way you would any channel: the margin on the licences, the reporting support, and the terms. The licences are Microsoft's and identical wherever you buy them, so the reseller competes on price and service alone, which is exactly the kind of relationship that benefits from periodic market testing.

Action. Stand up a recurring SPLA governance review on this cadence and give it a permanent owner, so reporting accuracy does not depend on memory.

SPLA versus CSP-hoster and the licensing-route decision

SPLA is not the only route to licence Microsoft software for a hosted service, and it is not always the cheapest. For some providers, the CSP Hoster route, or bringing customer-owned licences under Licence Mobility where eligible, fits a particular workload better than SPLA's pay-monthly model. The point is not to migrate wholesale, it is to make the route a deliberate decision per workload rather than a default that was set once and never revisited.

The buyers who hold the strongest positions price the route the same way they price the metric: against real deployment, per workload, with the alternatives kept genuinely costed. A dense, stable, multi-tenant workload behaves very differently under SPLA than a thin, variable one, and a customer who brings eligible licences changes the maths again. Keeping the alternatives credible and costed also strengthens every reseller conversation, because a provider who can move a workload to a different route is negotiating from options rather than inertia.

Action. Classify each major hosted workload by the route that actually fits it, SPLA, CSP-hoster, or customer-brought licences, and cost the alternatives before defaulting the next one to SPLA.

Key takeaways

• SPLA pays monthly for what you deploy, with no fixed entitlement, so the report is the entire control and needs a named owner.
• Choose SAL versus core per product by deployment density, and re-test the choice whenever the architecture changes.
• Get the SPUR rules right: internal use, shared versus dedicated, multi-tenant counting, programme mixing, and Licence Mobility.
• Expect audits, and defend them with a monthly deployment-to-report reconciliation kept against the SPUR version you reported.
• Govern reporting every cycle, re-test the metric quarterly, and benchmark the reseller annually.
• Treat CSP-hoster and customer-brought licences as deliberate per-workload routes, not a default.
• The monthly reconciliation is both the cost control and the audit defence; the work pays twice.

Frequently asked questions

What is a Microsoft SPLA?

The Services Provider License Agreement lets service providers license Microsoft software to deliver hosted software and services to third parties, reported and paid monthly through an authorised reseller against the Services Provider Use Rights (SPUR). There is no upfront purchase and no ownership; you report what you deploy each month.

How is SPLA different from an EA?

SPLA is pay-as-you-go monthly with no ownership and no fixed entitlement; an Enterprise Agreement is a committed purchase trued up annually. With SPLA you report what you deploy each month, so accuracy depends entirely on your own tracking, and the monthly report is the only number Microsoft sees.

Should we license by SAL or by core?

It depends on density. A high subscriber-to-core ratio favours core-based licensing; a low ratio favours SAL. Model both against real deployment density per product, pick the cheaper, and revisit the choice as density and architecture change rather than leaving it set at launch.

What causes most SPLA audit claims?

Using SPLA for internal administrative use, mixing SPLA with other programmes on the same hardware, and mis-counting cores in multi-tenant hosting. Map each workload to the correct programme, keep clean hardware boundaries, and document the basis against the specific SPUR rule.

How do we control SPLA cost?

Reconcile the monthly report to live deployment every cycle, retire workloads promptly, license each product on the right metric, and benchmark the reseller relationship periodically. The monthly cadence is also your audit defence, because it builds the record an audit would otherwise force you to reconstruct.

Prefer to start with the overview? See the Microsoft SPLA licensing guide, or read how our Microsoft licensing experts support service providers. Related research: the Microsoft Enterprise Agreement Guide covers the committed-purchase model, and the Vendor Audit Defence Handbook covers audit defence across vendors.