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. 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.
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.
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. 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.
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.
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.
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, but 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 (min 8 per processor, 16 per server) | All physical cores must be licensed on 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 server; no SAL option for Enterprise edition |
| Remote Desktop Services | 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 |
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). 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. 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 x monthly rate) may be cheaper than 200 SALs. Conversely, if a 32-core server serves only 10 users, SALs are dramatically cheaper. Calculate both options for each deployment and choose the most economical model.
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. 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.
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, that user counts include all accessing individuals (not just active subscribers), and that all Microsoft products in use are reported. 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 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.
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 or automated 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. 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.
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.
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.
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. Reductions of 40 to 70% from initial audit claims are achievable with systematic, evidence-based defence.
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. Having independent advisory during the audit process consistently produces better financial outcomes than negotiating directly with Microsoft's audit teams.
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.
Service providers should calculate the Standard versus Datacenter break-even for every host server. 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 to 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.
SQL Server Enterprise under SPLA can only be licensed per core. There is no SAL option. Every physical core on the server running SQL Server Enterprise must be licensed (minimum 4 cores per processor). Enterprise is required for features such as Always On Availability Groups (with more than two replicas), compression, partitioning, and in-memory OLTP. Using Enterprise features on a Standard-licensed instance is one of the most common, and most expensive, SPLA audit findings.
SQL Server Standard can be licensed per core (all physical cores on the server) or by SAL (each user or device accessing the database). The choice depends on the user-to-core ratio. For databases serving many users on modest hardware, per-core is typically cheaper. For databases serving few users on large servers, SALs are cheaper. Evaluate both options for every SQL Server Standard deployment.
SQL Server features are stratified by edition. Using an Enterprise-only feature (even once, even in testing) on a Standard-licensed instance creates a compliance gap requiring Enterprise licensing for all cores on that server. Common triggers include Always On Availability Groups beyond the Standard limit, online index operations, table partitioning, and resource governor. Monitor feature usage continuously to prevent inadvertent Enterprise feature activation.
If a middleware layer, application server, or connection pooler sits between end users and SQL Server, every end user accessing data through that layer still requires a SAL (or the database must be licensed per core). The intermediary software does not reduce the licence requirement. This multiplexing rule is one of the most misunderstood aspects of Microsoft licensing and a frequent audit finding in SaaS and application hosting scenarios.
SQL Server passive failover instances (servers that receive data but do not serve active queries) still require licensing under SPLA. While volume licensing provides limited free passive failover rights, SPLA does not include the same provisions. Every SQL Server instance, active or passive, must be licensed. Service providers implementing high-availability configurations should factor passive instance licensing into their cost models.
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.
| 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 |
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.
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.
Many service providers use both programmes. SPLA covers the on-premise hosting infrastructure (Windows Server, SQL Server, RDS on the provider's servers), while CSP covers Microsoft cloud services resold to the same customers (Microsoft 365 for productivity, Azure for burst capacity). The hybrid model requires careful licence management to ensure each product is covered under the correct programme with no gaps or overlaps.
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 to 35% cost reductions for service providers without reducing service capability.
Calculate the Standard versus 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 to 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. 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.
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.
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.
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 to 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.
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 versus CSP decisions. Complete vendor independence. No Microsoft partnerships, no resale commissions, no conflicts of interest.
Microsoft SPLA Audit Defence Service →An Enterprise Agreement (EA) licences Microsoft software for use by the purchasing organisation's own employees. It is an internal-use programme. SPLA licences Microsoft software for use by external third-party customers of the service provider. If you host Windows Server, SQL Server, Exchange, or other Microsoft products for customers who are not your employees, you need SPLA. If you deploy the same products for your own staff, you need an EA (or CSP/MCA). Many organisations need both: an EA for internal use and an SPLA for hosting services delivered to customers.
Each month, the service provider submits a usage report to their authorised SPLA reseller. The report details every Microsoft product deployed, the quantity of licences consumed (measured in physical cores for per-core products, or in users/devices for SAL products), and the total for each product category. The reseller invoices the service provider based on the reported quantities at the agreed SPLA price list rates. Accurate monthly reporting is the single most critical SPLA compliance requirement. Under-reporting is the primary source of audit findings and financial exposure.
It depends on virtualisation density. Standard allows two Windows Server VMs per licence set per host; additional VMs require stacking additional Standard licence sets. Datacenter provides unlimited VM rights per host. The break-even is typically four to six VMs per host. Above that, Datacenter is cheaper. For high-density virtualisation hosts (10+ VMs), Datacenter can cost 50 to 70% less than the equivalent Standard stacking. Calculate the break-even for every host and choose the most cost-effective edition for each.
Not for on-premise hosting. If you host Microsoft server software (Windows Server, SQL Server, RDS, Exchange Server, SharePoint) on your own infrastructure for external customers, you need SPLA. CSP is designed for reselling Microsoft cloud services (Microsoft 365, Azure, Dynamics 365) or providing certain subscription-based on-premise licences. Many service providers use both: SPLA for on-premise hosting infrastructure and CSP for cloud service resale. The two programmes are complementary, not interchangeable.
Microsoft initiates SPLA audits through formal notification, typically appointing a third-party audit firm. The auditor requests server inventories, hardware specifications, VM configurations, customer information, and historical SPLA reporting data. The actual environment is compared against reported usage to identify discrepancies. Common findings include unreported servers, under-reported core counts, under-counted SAL users, and SQL Server edition mismatches. Reductions of 40 to 70% from initial findings are achievable with evidence-based defence.
Under-reporting creates non-compliance that is discoverable during audits. When Microsoft identifies under-reported usage, the service provider must purchase additional licences to cover the shortfall, potentially pay back-dated fees for the period of under-reporting (which can span the entire three-year SPLA term), and may face additional penalties or contract renegotiation requirements. The financial exposure from sustained under-reporting over a multi-year SPLA term can reach millions of dollars. Accurate monthly reporting is both a compliance obligation and a financial protection.
If your staff access SPLA-licensed software as part of delivering services to external customers (for example, administrators connecting to customer servers via RDS, or support engineers accessing customer SQL Server databases), those connections may require SAL coverage under SPLA. However, SPLA cannot be used to licence software for your own internal business operations. Your internal email, file sharing, and business applications require separate volume licensing (EA, CSP, MCA). The distinction between delivering services to customers and internal use must be clearly documented and maintained.
Redress Compliance delivers independent SPLA licensing advisory for service providers, hosters, and MSPs. Compliance assessments, audit defence, cost optimisation, and strategic guidance on SPLA versus CSP decisions. Complete vendor independence.