Microsoft SPLA & Service-Provider Licensing

The Microsoft Services Provider License Agreement (SPLA) lets a service provider license Microsoft products on a monthly, pay-as-you-go basis and use them to deliver hosted or managed services to its own customers. Unlike volume licensing programs such as the Enterprise Agreement, SPLA is not a purchase of perpetual licenses. It is a usage-reporting program: you report what you used last month, you pay for that usage, and the rights expire when you stop reporting. That single structural difference drives almost every compliance question a hosting business will face. This pillar guide explains the program end to end and links to the deeper cluster articles in our complete Microsoft licensing guide.

SPLA exists because Microsoft's standard licensing terms generally prohibit using volume or OEM licenses to deliver commercial software services to third parties. If your business model is "customers pay us to run software for them," you are almost certainly in SPLA territory rather than Enterprise Agreement territory. Getting that distinction right early — and reporting against it honestly each month — is the difference between a predictable cost line and a six- or seven-figure audit finding.

What SPLA is, and who needs it

SPLA is a three-year agreement between a service provider and Microsoft, signed and administered through an authorised SPLA reseller (often called an aggregator or distributor). Under it, the provider may install Microsoft software on infrastructure it controls and offer access to that software as a service to unaffiliated end customers. The provider reports usage monthly and is billed monthly. There is no upfront license purchase and no minimum commitment in the way an Enterprise Agreement has a committed quantity.

You need SPLA if you are hosting Microsoft workloads on behalf of customers for commercial gain: a managed hosting company running Windows Server and SQL Server estates for clients, an ISV delivering its application as a SaaS product on top of Microsoft components, a managed service provider operating Remote Desktop Services environments, or an IaaS provider renting virtual machines with Windows. You generally do not need SPLA for purely internal use of software you have licensed perpetually, or for serving software to your own employees.

The boundary that catches providers out is the definition of who counts as a third party. Affiliates, group companies, and outsourced IT for a single parent organisation are treated differently from genuine multi-tenant hosting, and the test turns on ownership and control rather than on how the contract is worded. Misclassifying an internal workload as an external service, or vice versa, is one of the most common and expensive SPLA mistakes.

How the program works: agreement, reseller, reporting

Three parties sit in the SPLA relationship. Microsoft owns the program and publishes the rules. The SPLA reseller holds the commercial relationship, processes monthly reports, and invoices the provider. The provider deploys the software, tracks usage, and submits a monthly usage report by the agreed deadline — typically within the first few days of the following month.

Reporting is the heart of the program and the heart of the risk. Each month the provider must report the peak or qualifying usage of every licensed product, even where that figure is zero. "Zero usage" reports are themselves a compliance signal: a long run of zeros on a product Microsoft believes is deployed will attract scrutiny. Under-reporting creates back-billing and penalty exposure; over-reporting quietly inflates your cost base. Neither is corrected automatically, which is why reconciliation discipline matters more in SPLA than in almost any other Microsoft program.

Because there is no perpetual license, you cannot stockpile rights in a good month to cover a bad one. Each month stands alone. When the three-year agreement ends, you either renew or you stop — and if you stop, you must stop using the software, because nothing you reported confers a lasting right to run it.

The two license models: SAL and per-core

Most SPLA products are licensed one of two ways. The Subscriber Access License (SAL) is a per-user (or per-device) model: you count the unique users or devices that have access to the product during the month and report that number. The per-core model — used for Windows Server and SQL Server — licenses the physical hardware running the software, counting the physical cores in each processor and applying minimums per processor and per server.

Choosing the wrong model, or mixing them incorrectly, is a frequent source of error. Windows Server and SQL Server in particular have detailed per-core rules that interact with virtualisation density and with whether the hardware is shared or dedicated. The deep mechanics live in our cluster articles on Windows Server SPLA licensing and SQL Server SPLA licensing.

The SPUR: your rulebook every month

Microsoft publishes the Services Provider Use Rights document (the SPUR, now folded into the broader Product Terms framework) and updates it regularly. The SPUR defines, product by product, what each license permits, how it is counted, and what restrictions apply. A provider's use rights are governed by the version of the SPUR in force during the month being reported — not by the version that existed when the agreement was signed.

This is structurally important. Microsoft can and does change product use rights between SPUR releases: a product may move models, gain or lose hosting rights, or change how it is counted. A SPLA report is only defensible if it was prepared against the SPUR version that applied to that reporting month. Keeping an archive of the SPUR releases you reported against is one of the cheapest forms of audit insurance available to a hosting business.

Shared vs dedicated hardware

Whether your hosting hardware is shared across multiple customers or dedicated to one customer changes which licensing paths are open to you. Dedicated hardware unlocks options — including some customer bring-your-own-license scenarios — that shared, multi-tenant hardware does not. For Windows Server and SQL Server especially, the shared-versus-dedicated distinction can change both the model and the cost materially. We cover the full decision in shared vs dedicated hardware in Microsoft hosting.

The practical takeaway is that hardware architecture and licensing strategy cannot be designed independently. A platform team that consolidates customers onto shared clusters for efficiency can inadvertently close off the cheapest licensing path; a team that isolates customers onto dedicated hosts for licensing reasons can erode the margin those licenses were meant to protect. The two decisions belong on the same table.

SPLA vs BYOL and CSP-hosting

SPLA is not the only way to license Microsoft software in a hosted environment. Customers may, in defined circumstances, bring their own licenses (BYOL) with License Mobility through Software Assurance, and the Cloud Solution Provider (CSP) program offers another path for some workloads. Each option allocates cost and compliance responsibility differently: under SPLA the provider holds the licensing risk; under BYOL the customer does. We compare the three in detail in SPLA vs BYOL licensing and, specifically for infrastructure providers, in Microsoft licensing for IaaS providers.

For most multi-tenant hosting businesses, SPLA remains the default because it requires no action from the end customer and scales cleanly with usage. BYOL becomes attractive where a large customer already owns Software Assurance and wants to extract value from it, and where the workload can run on hardware dedicated to that customer. The right answer is usually a portfolio: SPLA for the general estate, BYOL for the handful of customers where it genuinely pays.

Products commonly licensed under SPLA

The SPLA catalogue spans most of Microsoft's server and infrastructure stack. The products that generate the most reporting volume — and the most audit findings — are Windows Server (per-core), SQL Server (per-core or SAL), Remote Desktop Services (SAL), and SharePoint (SAL). RDS and SharePoint together are a frequent source of access-counting errors, which we address in SharePoint & RDS SPLA licensing.

Microsoft has, over time, removed or restricted certain products from SPLA — most notably moving much of the productivity stack toward Microsoft 365 and CSP rather than SPLA. Providers should never assume a product is still available under SPLA on the same terms as in prior years; the SPUR is the authority, and it changes. Building your service catalogue around products with stable hosting rights reduces the chance of a forced re-platforming when terms shift.

Audit exposure and how to manage it

SPLA is among the most actively audited Microsoft programs precisely because it relies on self-reported usage with no perpetual license to anchor it. A SPLA audit typically reconciles your monthly reports against deployment evidence: hypervisor inventories, Active Directory user counts, RDS connection data, and SQL Server deployment scans. Discrepancies are billed retroactively, often across multiple years, and can carry penalty multipliers.

The defensible posture is built before any audit letter arrives. It rests on three habits: reporting peak usage honestly each month against the correct SPUR version, retaining the evidence that supports each report, and reconciling deployment to reporting on a regular internal cadence so that drift is caught early. Providers who run this discipline turn an audit into a confirmation exercise; those who do not turn it into a negotiation over how large the back-bill will be. Our dedicated guide to Microsoft SPLA audit defence covers the process step by step, and our Microsoft audit defense service supports providers through live audits.

A buyer-side compliance checklist

For a service provider operating under SPLA, the recurring disciplines are straightforward to state and demanding to sustain: confirm each workload genuinely belongs in SPLA rather than BYOL or internal-use licensing; report peak qualifying usage every month, including zeros, against the in-force SPUR; archive each SPUR version and the evidence behind each report; reconcile deployment against reporting at least quarterly; and review hardware architecture and licensing model together whenever the platform changes.

Above all, treat the three-year agreement boundary as a planning horizon, not a renewal formality. A SPLA renewal is the natural moment to re-examine which workloads should stay in SPLA, which have grown large enough to justify BYOL, and whether the product mix still has stable hosting rights. For the full set of related decisions, start from our complete Microsoft licensing guide and the Microsoft vendor hub, or engage our advisors through Microsoft audit defense.

How SPLA cost behaves

SPLA cost is a function of reported usage, not a fixed commitment, which makes it behave very differently from an Enterprise Agreement. There is no committed quantity to amortise and no true-up at year end; the monthly invoice simply reflects what was reported for that month. This is a genuine advantage for businesses with variable or seasonal demand, because cost tracks revenue rather than running ahead of it. It is also a discipline, because there is no economy of scale to lean on — every reported unit is billed at the applicable rate every month it is used.

Because the program is consumption-based, the two levers that move SPLA cost are accuracy and architecture. Accuracy means reporting exactly what is used — no more, no less — so that over-reporting does not silently inflate the bill and under-reporting does not silently build audit liability. Architecture means designing the platform so that the cheapest correct licensing path is available: consolidating onto dense, efficiently-licensed hosts, choosing the right edition and metric per workload, and reserving dedicated hardware for the customers where it genuinely pays. A provider that gets both right runs SPLA as a predictable, revenue-aligned cost line. A provider that neglects either treats SPLA as a black box and usually overpays while remaining exposed.

The mistakes that become audit findings

Most SPLA audit findings trace to a short list of recurring errors, and every one of them is preventable with monthly discipline. Workloads are misclassified as internal use or as BYOL when they should have been reported under SPLA. Windows Server and SQL Server cores are under-counted on shared clusters, or hosts are added to a cluster without being licensed for the workloads that can migrate to them. Remote Desktop Services and SharePoint access counts drift as departed users and broad security groups accumulate. BYOL exclusions are taken on trust without collecting the customer's Software Assurance evidence. And reports are prepared against the wrong version of the Product Terms because the historical versions were never archived.

None of these is exotic. They are the ordinary consequences of treating SPLA reporting as a monthly clerical task rather than a controlled process. The providers who avoid them do three unglamorous things consistently: they reconcile deployment to reporting every month, they retain the evidence and the rules version behind each report, and they put licensing review into the change process for anything that touches the hosting platform. The product-specific versions of these errors are covered in the cluster guides on Windows Server, SQL Server, and SharePoint and RDS, and the audit process itself in SPLA audit defence.

Renewing or exiting a SPLA agreement

The three-year agreement boundary is the natural moment to re-examine the whole estate rather than renew on autopilot. By the time an agreement comes up for renewal, the product mix has usually shifted, some customers have grown large enough to justify BYOL, and Microsoft may have changed the hosting rights or counting rules for products in the catalogue. A renewal review that revisits which workloads belong in SPLA, which should move to BYOL, and whether the product mix still has stable hosting rights typically pays for itself in avoided over-reporting and avoided forced re-platforming.

Exiting SPLA — whether to wind down a hosting line or to move customers onto their own licensing — requires care precisely because the program confers no lasting rights. When reporting stops, the right to run the software stops with it, so any workload that continues must be re-licensed under another model before the SPLA reporting ceases, not after. Sequencing the transition so that every continuing workload has a valid license on the day SPLA reporting ends is the difference between a clean exit and an accidental compliance gap. Our advisors plan these transitions as part of Microsoft audit defense, working from the deployment-to-reporting reconciliation rather than from the contract alone.