The Microsoft Services Provider Licence Agreement (SPLA) is the licensing programme that enables service providers, hosters, managed service providers (MSPs), and outsourcers to licence Microsoft software on a monthly basis for delivering hosted services to external customers. Unlike Enterprise Agreements designed for internal use, SPLA is purpose-built for organisations that provide technology services to third parties — and it comes with its own pricing structures, reporting obligations, compliance requirements, and audit risks that differ fundamentally from any other Microsoft programme. SPLA compliance is among the most frequently audited areas in Microsoft licensing, with audit findings routinely reaching millions of dollars. This pillar guide provides a complete reference for understanding how SPLA works, which products are available, how licensing is measured, where the compliance risks are, and how to build a hosting practice that is both cost-effective and audit-ready.
The Services Provider Licence Agreement (SPLA) is Microsoft’s licensing programme for organisations that provide software-based services to external customers. Unlike volume licensing programmes (EA, Select, MPSA) that licence software for internal use by the purchasing organisation’s own employees, SPLA licences Microsoft software for use by third parties — customers, subscribers, and end users who are not employees of the service provider. Learn more about Microsoft licensing.
Any organisation that hosts Microsoft software or services for external customers needs SPLA licensing. This includes traditional hosting providers offering dedicated or shared Windows Server environments, managed service providers running hosted Exchange, SharePoint, or SQL Server for clients, software-as-a-service (SaaS) companies whose applications run on Microsoft infrastructure, outsourcers managing IT environments on behalf of client organisations, and independent software vendors (ISVs) who embed Microsoft technologies in their hosted solutions. The defining characteristic is that the end users are external to the organisation holding the SPLA — if only internal employees use the software, standard volume licensing (EA, CSP, MCA) is the appropriate programme.
SPLA is structured as a three-year agreement between the service provider and an authorised SPLA reseller. The service provider reports its monthly usage, and the reseller invoices accordingly. There is no upfront licence purchase — SPLA operates on a pay-as-you-go model aligned with the service provider’s revenue cycle. This monthly flexibility is the programme’s primary commercial advantage, but it also creates its primary compliance challenge: accurate monthly reporting of every Microsoft product deployed across every customer environment, every month, without exception.
Organisations offering dedicated, shared, or virtual private server environments running Windows Server, SQL Server, Remote Desktop Services, or other Microsoft server products for external customers. This includes colocation providers who manage the software stack, IaaS providers delivering virtual infrastructure, and traditional hosters offering managed Windows environments. Every Windows Server instance, SQL Server database, and RDS deployment serving external customers requires SPLA licensing.
MSPs delivering hosted productivity, collaboration, or infrastructure services to clients — such as hosted Exchange, hosted SharePoint, managed SQL Server databases, hosted desktops (VDI/RDS), or managed Active Directory services. MSPs frequently have complex SPLA requirements because they serve multiple clients with varying product mixes, user counts, and service tiers. Each client’s deployment must be accurately tracked and reported under the MSP’s SPLA.
Software companies whose applications are built on Microsoft technologies (Windows Server, SQL Server, .NET) and delivered as hosted services to customers. The SaaS company’s SPLA must cover the underlying Microsoft infrastructure: every Windows Server instance, every SQL Server database engine, and every user accessing the hosted application through Remote Desktop or web-based interfaces. ISVs embedding Microsoft components in their products need SPLA for any externally-hosted deployment.
Organisations managing IT infrastructure or business processes on behalf of external clients. If the outsourcer deploys Microsoft software to serve the client’s users (rather than the outsourcer’s own employees), SPLA is required. This is a common area of licensing confusion: outsourcers often assume the client’s existing Microsoft licences cover the outsourced environment, but unless specific licence mobility or outsourcing rights are documented, the outsourcer needs its own SPLA coverage. Learn more about independent Microsoft advisory services.
Understanding SPLA’s commercial framework is essential for managing costs and maintaining compliance. The programme has specific structural requirements that distinguish it from all other Microsoft licensing models.
SPLA is a three-year contract signed between the service provider and a Microsoft-authorised SPLA reseller (not directly with Microsoft). The reseller processes monthly orders, provides pricing, and serves as the commercial intermediary. Choosing the right SPLA reseller matters — resellers vary in their pricing, support quality, licensing expertise, and willingness to help with compliance questions. The three-year term auto-renews unless terminated by either party with 30 days’ notice before the anniversary date. Service providers should evaluate reseller options at each renewal to ensure competitive pricing.
The service provider must report its Microsoft software usage to the SPLA reseller every month. The report details which products are deployed, how many licences are consumed (by core count, by subscriber, or by other applicable metric), and the total quantities for each product. This monthly reporting obligation is non-negotiable and is the single most critical compliance requirement under SPLA. Late, inaccurate, or incomplete reporting is the most common source of SPLA audit findings. Automated reporting tools and disciplined monthly processes are essential.
SPLA pricing is monthly — the service provider pays for the licences reported each month with no upfront capital expenditure. Prices are set by Microsoft and published in the SPLA price list, though resellers may offer modest discounts. Pricing is subject to annual adjustments (typically upward). The monthly model aligns licensing costs with revenue — as customer deployments grow or shrink, SPLA costs follow. However, the per-unit monthly cost is higher than the equivalent annual cost under volume licensing, reflecting the flexibility premium.
SPLA covers a broad range of Microsoft server products, each with specific licence types that determine how usage is measured and reported. The two primary licence models are Subscriber Access Licences (SALs) and Per-Core licences. Understanding which model applies to each product — and how to count correctly — is the foundation of SPLA compliance.
| Product | Licence Type | Measurement | Key Compliance Requirement |
|---|---|---|---|
| Windows Server | Per-Core | Physical cores on host server (minimum 8 per processor, 16 per server) | All physical cores must be licensed; applies to every server running Windows |
| SQL Server Standard | Per-Core or SAL | Cores on server, or individual users/devices accessing the database | Per-Core requires all cores; SAL requires every accessing user/device |
| SQL Server Enterprise | Per-Core only | Physical cores (minimum 4 per processor) | All cores on the server; no SAL option for Enterprise edition |
| Remote Desktop Services (RDS) | SAL | Per user or per device accessing RDS | Every individual connecting via RDS must have a SAL |
| Exchange Server | SAL | Per user accessing hosted Exchange mailboxes | Every mailbox user requires an Exchange SAL |
| SharePoint Server | SAL | Per user accessing hosted SharePoint | Every user accessing SharePoint content requires a SAL |
| System Center | Per-Core | Cores on managed servers | Licence the cores on every server managed by System Center |
| Windows Server RMS, Skype for Business, etc. | SAL or Per-Core (varies) | Product-specific | Refer to SPLA product terms for each specific product |
Per-Core licensing requires the service provider to licence every physical core on every server running the Microsoft product. Windows Server and SQL Server are the most common per-core products. The minimum licence count is 16 cores per server (or 8 cores per physical processor, whichever is greater). This means a 2-processor server with 8 cores each (16 total) requires 16 core licences. A 2-processor server with 12 cores each (24 total) requires 24 core licences. Per-core licensing in SPLA is reported monthly: if the server runs that month, the cores are reported. Decommissioned servers are removed from reporting.
SALs licence external users or devices that access the Microsoft software. Unlike internal Client Access Licences (CALs) in volume licensing, SALs are specifically designed for SPLA scenarios where the users are the service provider’s customers. SALs can be assigned per user (each individual person) or per device (each accessing device), depending on the product. The critical requirement is counting every unique user or device that accesses the service during the reporting month — including administrators, support staff, and automated systems that connect to the environment.
For products like SQL Server Standard that offer both per-core and SAL options, the cost-effective choice depends on the ratio of users to cores. If a SQL Server Standard instance runs on a 16-core server and serves 200 users, the per-core model (16 cores × monthly rate) may be cheaper than 200 SALs. Conversely, if a 32-core server serves only 10 users, SALs are dramatically cheaper. Service providers should calculate both options for each deployment and choose the most economical model — and they can change models at renewal if usage patterns shift. Learn more about Microsoft SPLA audit defence guide.
Monthly reporting is the operational heartbeat of SPLA compliance. Every month, the service provider must accurately report all Microsoft product deployments across all customer environments. The report captures which products are deployed, the quantity of licences consumed (cores or SALs), and the resulting fees. Inaccurate or incomplete reporting is the most common SPLA audit finding and the primary source of compliance exposure.
Maintain a continuously updated inventory of every server, VM, and service instance running Microsoft software under SPLA. For per-core products, record the physical core count of every host. For SAL products, record the number of unique users or devices accessing each service. This inventory must cover all customer environments, all internal infrastructure used to deliver customer services (management servers, monitoring systems, backup infrastructure), and any development or test environments that serve customer-facing functions.
SPLA reporting reflects the state of the environment during each month. New server deployments, customer onboarding, server upgrades (core count increases), and new service activations must be captured in the reporting month they occur. Customer offboarding, server decommissioning, and downgrades should be reflected as reductions in the month they are completed. The most common reporting failures are delays in capturing new deployments and delays in removing decommissioned assets — the former creates audit exposure, the latter creates unnecessary cost.
Before submitting the monthly report to the SPLA reseller, reconcile the reported quantities against the actual environment. Spot-check a sample of servers and customer deployments to verify accuracy. Ensure that server core counts reflect current physical hardware (not historical configurations), that user counts include all accessing individuals (not just active subscribers), and that all Microsoft products in use are reported (including products deployed on management, monitoring, and backup infrastructure). Discrepancies between reported and actual usage are the definition of non-compliance under SPLA.
Manual SPLA reporting is error-prone, particularly for service providers with hundreds of servers and thousands of customers. Invest in automated discovery and reporting tools that scan the environment for Microsoft installations, count physical cores, enumerate RDS connections, and produce monthly reports aligned with SPLA product categories. Automation does not eliminate the need for human review, but it dramatically reduces the risk of omissions and counting errors that accumulate over months and years into material compliance gaps.
SPLA compliance failures follow predictable patterns. Understanding these patterns — and building processes to prevent them — is the most effective way to reduce audit risk and avoid the multi-million-dollar true-up demands that characterise SPLA audit outcomes.
The most financially significant SPLA compliance failure. Service providers report fewer cores than are physically present on servers running Microsoft software. This happens when servers are upgraded (additional processors or higher-core-count processors) without updating the SPLA report, when new servers are deployed without being added to reporting, or when the service provider reports virtual cores rather than physical cores. Microsoft’s audit methodology compares reported cores against actual hardware — any discrepancy generates a true-up obligation for the entire period of under-reporting. Learn more about Microsoft SPLA pricing 2026.
Service providers frequently undercount the users accessing SAL-licensed products. Common causes include counting only “active” subscribers while ignoring dormant or occasional users who still have access, excluding the service provider’s own staff (administrators, support engineers, monitoring systems) who access customer environments, failing to count users who access services through APIs, automated systems, or indirect connections, and not updating user counts when customers onboard new employees or devices.
Microsoft products deployed for infrastructure management, monitoring, backup, or internal operations are often omitted from SPLA reporting because the service provider does not consider them “customer-facing.” However, if these products support the delivery of services to external customers, they require SPLA licensing. Common omissions include SQL Server instances used for monitoring databases, Windows Server instances running backup infrastructure, System Center deployments managing customer environments, and RDS connections used by the service provider’s own staff to manage customer servers.
Months where SPLA reports are late, incomplete, or skipped entirely create compliance gaps that are immediately visible during audits. Microsoft auditors compare reported usage month-by-month against the actual environment, and any month with zero reporting or suspiciously low numbers triggers scrutiny. Reporting inconsistencies — such as a sudden drop in reported cores followed by a sudden increase — suggest that actual deployments were not being accurately captured. Consistent, accurate monthly reporting is both the best compliance practice and the best audit defence.
Service providers running virtualised environments must licence the physical cores on the host servers, not the virtual cores allocated to VMs. A host server with 32 physical cores running 10 VMs with 4 vCPUs each requires 32 core licences — not 40 (the sum of virtual cores) and not 4 (a single VM’s allocation). Additionally, Windows Server Datacenter edition (which provides unlimited virtualisation rights on the licensed host) can be more cost-effective than Standard edition when running multiple VMs per host. Choosing the wrong edition is a common and expensive mistake.
SPLA licences are exclusively for delivering services to external third-party customers. Using SPLA-licensed software for the service provider’s own internal business operations (email for internal staff, internal file sharing, internal databases) is a licence violation. Service providers need separate volume licensing (EA, CSP, MCA) for their own internal IT. Mixing internal and external use on the same infrastructure without proper licence separation is a common audit finding.
Redress Compliance provides independent Microsoft licensing advisory — fixed-fee, no vendor affiliations. Our specialists help enterprises optimize Microsoft costs, negotiate better terms, and ensure compliance.
Explore Microsoft Advisory Services →Microsoft conducts SPLA audits through its Software Asset Management (SAM) engagement programme, typically performed by third-party audit firms on Microsoft’s behalf. SPLA is one of the most frequently audited Microsoft licensing programmes because the monthly reporting model creates abundant data for comparison against actual deployments, and because compliance gaps in hosting environments tend to be both common and financially significant.
Microsoft (or its appointed auditor) sends a formal audit notification citing the audit provisions in the SPLA contract. The notification requests detailed information about the service provider’s environment: server inventories, hardware specifications, VM configurations, customer lists, user counts, and historical SPLA reporting data. The scope of data requested is often broader than contractually required — service providers should review the request against the SPLA audit clause and negotiate scope before providing data. Engage legal counsel and licensing specialists immediately upon receiving an audit notification.
The auditor analyses the provided data (and may request deployment of discovery tools) to determine the actual Microsoft software footprint. This is compared against the service provider’s historical SPLA reports to identify discrepancies. Common findings include unreported servers, under-reported core counts, under-counted SAL users, unreported SQL Server instances, and SQL Server Enterprise features used with only Standard licences. The auditor produces a preliminary findings report showing the compliance gap — typically expressed as the number of additional licences required and the corresponding financial obligation. Learn more about Microsoft SPLA to CSP migration guide.
The preliminary findings are the starting point for negotiation, not the final determination. Service providers should challenge findings with evidence: hardware retirement records proving servers were decommissioned, customer contracts proving user counts, architectural documentation proving software was not in use during specific periods, and entitlement records from other Microsoft programmes. The financial resolution typically involves purchasing licences to cover genuine shortfalls, potentially paying back-dated fees for periods of under-reporting, and committing to improved reporting processes going forward. Reductions of 40–70% from initial audit claims are achievable with systematic, evidence-based defence.
Windows Server is the most commonly licensed product under SPLA and the one most frequently miscounted. The choice between Standard and Datacenter editions has a material impact on both cost and compliance, particularly in virtualised hosting environments.
Windows Server Standard under SPLA allows up to two Windows Server virtual machines (Operating System Environments, or OSEs) per licence set covering all physical cores on the host. If the host runs more than two Windows Server VMs, additional Standard licence sets are required — one set for every two additional VMs. For a host running six Windows Server VMs, three Standard licence sets (covering all physical cores three times) are required. This stacking cost increases linearly with VM density.
Windows Server Datacenter provides unlimited virtualisation rights on the licensed physical host. Regardless of how many Windows Server VMs run on the host, a single Datacenter licence set (covering all physical cores) provides complete coverage. For hosts running more than approximately four to six VMs, Datacenter becomes more cost-effective than stacking Standard licences. The break-even point depends on the monthly price differential between Standard and Datacenter core licences, which varies by reseller and volume.
Service providers should calculate the Standard vs Datacenter break-even for every host server. The formula is straightforward: if the monthly cost of Datacenter core licences is less than the monthly cost of multiple Standard licence sets needed to cover all VMs on the host, Datacenter is more economical. In practice, the break-even is typically four to six VMs per host. Hosting environments with high VM density (10+ VMs per host) see substantial savings from Datacenter — often 50–70% less than the equivalent Standard stacking cost.
SQL Server is the second most commonly licensed SPLA product and the one most likely to generate significant audit findings. The combination of edition confusion (Standard vs Enterprise), metric choice (per-core vs SAL for Standard), and feature-based licensing traps makes SQL Server the highest-risk product in most service providers’ SPLA estates.
Microsoft’s Cloud Solution Provider (CSP) programme has emerged as an alternative channel for service providers, particularly for Microsoft 365 and Azure services. Understanding when SPLA is required versus when CSP is appropriate — and how the two programmes can coexist — is essential for optimising costs and maintaining compliance. Learn more about SPLA vs CSP for hosting providers.
| Dimension | SPLA | CSP |
|---|---|---|
| Purpose | Licence on-premise/hosted Microsoft server software | Resell Microsoft cloud services and some on-premise licences |
| Products covered | Windows Server, SQL Server, RDS, Exchange Server, SharePoint Server, System Center | Microsoft 365, Azure, Dynamics 365, some on-premise server subscriptions |
| Deployment | Service provider’s own infrastructure (physical or virtual) | Microsoft’s cloud infrastructure (Azure) or customer’s environment |
| Billing | Monthly to SPLA reseller based on reported usage | Monthly to Microsoft or CSP distributor based on subscriptions |
| Contract term | 3-year agreement | Ongoing with monthly or annual subscription terms |
| Audit exposure | High — Microsoft audits SPLA providers regularly | Lower — usage tracked automatically by Microsoft |
| Use case | Hosting on your own infrastructure | Reselling Microsoft cloud services or hybrid deployments |
SPLA only: You host Microsoft server software (Windows Server, SQL Server, Exchange, SharePoint, RDS) on your own physical or virtual infrastructure for external customers. CSP cannot replace SPLA for these on-premise hosting scenarios. If your business model is built on owning and operating infrastructure, SPLA is your primary licensing programme.
CSP only: You resell Microsoft cloud services (Microsoft 365, Azure, Dynamics 365) to customers without hosting on-premise Microsoft server software on your own infrastructure. The customer’s workloads run in Microsoft’s cloud, and you act as the billing and management intermediary.
SPLA licensing costs can be optimised significantly through systematic analysis of deployment architecture, product editions, licence metrics, and operational processes. The following strategies consistently deliver 15–35% cost reductions for service providers without reducing service capability.
Calculate the Standard vs Datacenter break-even for every physical host. Convert high-density virtualisation hosts (6+ VMs) to Datacenter licensing. Consolidate VMs onto fewer hosts where Datacenter is already licensed to maximise the unlimited virtualisation rights. This single optimisation typically delivers the largest SPLA cost reduction for hosting providers — often 20–30% of total Windows Server SPLA spend.
Audit every SQL Server instance for edition requirements. Downgrade Enterprise to Standard wherever Enterprise-only features are not genuinely required. For SQL Server Standard instances, calculate whether per-core or SAL is cheaper based on actual user counts. Consolidate SQL Server instances onto shared infrastructure (where customer isolation requirements permit) to reduce the total core count requiring licensing. Remove or stop SQL Server instances that are no longer actively serving customer workloads.
Review SPLA reports for servers that have been decommissioned but not removed from reporting, customers that have been offboarded but whose infrastructure remains in reports, and development/test environments reported as production. Every month of over-reporting is a month of unnecessary cost. Implement a monthly reconciliation process that compares reported assets against the live environment and removes anything that no longer exists or serves customers.
Fewer physical servers means fewer cores to licence. Consolidate customer workloads onto higher-density hosts with Datacenter licensing. Retire older servers with inefficient core-to-performance ratios. Modern processors deliver more compute per core, meaning the same workload can run on fewer physical cores — directly reducing per-core SPLA costs. Infrastructure consolidation should be a standing item in every service provider’s annual capacity planning cycle.
SPLA pricing is not identical across all resellers. Compare pricing from multiple authorised SPLA resellers at each three-year renewal. Larger service providers with significant monthly volumes have leverage to negotiate better per-licence rates. Additionally, evaluate whether certain workloads could be migrated from SPLA-licensed on-premise infrastructure to Azure (under CSP or direct Azure billing) where the total cost of ownership may be lower, particularly for variable or burst workloads. Learn more about licensing across Microsoft programmes EA CSP SPLA.
SPLA compliance is not a one-time exercise — it is a permanent operational discipline that must be embedded in the service provider’s infrastructure management, customer onboarding, and financial reporting processes.
Deploy tools that automatically discover Microsoft software installations across all infrastructure, count physical cores on every host, enumerate RDS connections and SAL-eligible users, and produce monthly SPLA reports aligned with product categories. Manual reporting is insufficient for service providers with more than a handful of servers. The investment in automation pays for itself through reduced compliance risk, lower audit exposure, and the elimination of over-reporting waste.
Integrate SPLA reporting into customer onboarding and offboarding workflows. When a new customer is provisioned, the associated Microsoft licensing requirements should be calculated and added to the next SPLA report automatically. When a customer is offboarded, the associated licences should be removed from reporting in the month the infrastructure is decommissioned. This lifecycle integration prevents both the under-reporting that creates audit exposure and the over-reporting that creates unnecessary cost.
Conduct quarterly reviews that replicate Microsoft’s SPLA audit methodology: compare reported usage against actual deployments, verify core counts against hardware inventories, spot-check SAL user counts against customer records, and identify any unreported products or services. Treat these reviews as audit rehearsals. Document findings, resolve discrepancies, and update reporting processes. Service providers that conduct regular internal reviews consistently achieve clean audit outcomes.
Every team member involved in infrastructure provisioning, customer onboarding, or server management must understand the SPLA reporting implications of their actions. Deploying a new server, upgrading hardware, activating a SQL Server feature, or onboarding a customer all have SPLA licensing consequences. Assign a designated “SPLA Compliance Owner” with authority to enforce reporting processes and escalate discrepancies. Without clear accountability, reporting discipline degrades over time.
SPLA licensing combines the complexity of Microsoft’s product licensing rules with the operational challenge of monthly reporting across dynamic, multi-customer environments. Independent advisory provides the licensing expertise, audit defence capability, and cost optimisation intelligence that service providers need to manage this complexity effectively.
Redress Compliance conducts comprehensive SPLA compliance assessments that replicate Microsoft’s audit methodology: full infrastructure discovery, core count verification, SAL enumeration, product inventory, and comparison against historical reporting. We identify both under-reporting (compliance exposure) and over-reporting (unnecessary cost) simultaneously, and provide a detailed remediation plan that resolves gaps before Microsoft identifies them. Our assessments typically find both significant compliance risks and significant cost savings in every SPLA environment we review. Learn more about Microsoft audits and compliance playbook.
When Microsoft initiates an SPLA audit, our team manages the entire defence process: scope negotiation, data request review, finding challenges, and commercial resolution. We challenge audit methodology, dispute inflated user counts, present evidence of decommissioned assets, and negotiate the financial resolution. Our SPLA audit defence engagements consistently achieve 40–70% reductions from Microsoft’s initial compliance claims, saving service providers hundreds of thousands to millions of dollars.
Redress Compliance has no commercial relationship with Microsoft — no partner status, no CSP resale revenue, no SPLA reseller commissions. Our recommendations on SPLA optimisation, edition selection, metric choice, and audit defence are exclusively aligned with the service provider’s interests. This independence is particularly critical during SPLA audits, where Microsoft’s audit teams are incentivised to maximise compliance findings and drive licence purchases or cloud migration.
“SPLA compliance is simultaneously the most operationally demanding and the most frequently audited area of Microsoft licensing. The monthly reporting obligation, the complexity of per-core and SAL counting across multi-customer environments, and Microsoft’s aggressive audit programme create a compliance landscape where mistakes are easy to make and expensive to resolve. Service providers that invest in automated reporting, quarterly internal reviews, and independent compliance assessments convert SPLA from a perpetual audit risk into a manageable operational cost — typically saving 15–35% in the process.”
Redress Compliance delivers independent SPLA licensing advisory for service providers, hosters, and MSPs — compliance assessments, audit defence, cost optimisation, edition and metric analysis, reporting process design, and strategic guidance on SPLA vs CSP decisions. Complete vendor independence. No Microsoft partnerships, no resale commissions, no conflicts of interest.
Book a free consultation with our licensing specialists. No obligations, no vendor ties — just independent advice tailored to your situation.
Book Your Free Consultation →