What Is a Microsoft SPLA Audit?
A Microsoft SPLA audit is a formal compliance review in which Microsoft verifies that a service provider is correctly reporting and paying for the Microsoft software it hosts under the Service Provider Licence Agreement (SPLA). It is Microsoft's enforcement mechanism for its hosting channel — and for unprepared providers, it is one of the most financially dangerous events in enterprise software licensing.
SPLA allows cloud service providers, managed service providers (MSPs), hosting companies, SaaS vendors, and outsourcers to rent Microsoft software on a monthly, pay-as-you-go basis to deliver hosted services to their customers. In return, providers must report their peak usage of every Microsoft product every month to their SPLA reseller and pay the corresponding fees. An SPLA audit checks whether those monthly reports accurately reflect reality.
Microsoft appoints a third-party auditor — almost always one of the Big Four accounting firms (EY, PwC, KPMG, or Deloitte). The auditor handles data collection and technical analysis. Microsoft's compliance team then reviews the findings and manages the commercial settlement. Audits typically occur on a three-year cycle, though providers with reporting anomalies, unusually low usage figures, or late submissions may be audited more frequently.
"We have defended dozens of SPLA audits across four continents. In every case, Microsoft's initial compliance claim was significantly higher than the final negotiated settlement — typically by 40–70%. The draft report is a starting position, not a verdict."
Microsoft sometimes begins with an SPLA Self-Assessment, inviting you to review your own compliance and certify the results. Self-assessments are less invasive and, critically, they often avoid the 25% penalty surcharge that a formal audit imposes. Always respond cooperatively — a self-assessment is your best chance to identify and correct issues before they become a full audit.
The SPLA Audit Process — Six Phases
Microsoft's SPLA audit follows a structured, multi-phase process. Understanding each phase removes uncertainty and helps you prepare the right response at the right time.
Notification and Initiation (Week 0)
You receive an official audit notice from Microsoft's Licence Compliance team identifying the legal entity, SPLA agreement number, audit period, and appointed auditor. You have 30 days to begin cooperating — this is a contractual obligation from your SPLA agreement. Immediately inform leadership, legal, IT, and finance. Designate a single point of contact for all auditor communications.
Kick-Off Meeting and NDA (Weeks 1–2)
The auditor schedules an introductory meeting to present the audit plan, timeline, data requirements, and scope. Request an NDA between your company and the auditor to protect sensitive commercial data. Take detailed notes on scope boundaries — knowing what is in and out of scope prevents accidental oversharing that widens the audit.
Data Collection (Weeks 3–8)
The most labour-intensive phase. The auditor requests hardware/VM inventories, software inventories, Active Directory exports, usage logs, customer contracts, monthly SPLA reports, and deployment change records. You may be asked to run auditor-provided scripts on your servers. This phase is iterative — expect follow-up clarification requests.
Analysis and Draft Report (Weeks 8–12)
The auditor analyses the data and produces a draft audit report with an Effective Licence Position (ELP) for each product and month. This report highlights shortfalls where calculated usage exceeds reported usage. No financial amounts are included — the auditor identifies the licence delta, not the cost.
Review and Defence (Weeks 12–16)
Your most critical window. Examine every line item, verify formulae, challenge wrong assumptions, and provide additional evidence. The draft report is negotiable — auditors expect pushback and frequently revise their findings when presented with compelling evidence. Submit your challenges in writing to create a formal paper trail.
Final Report and Commercial Negotiation (Weeks 16–24+)
The auditor issues a final report to Microsoft, concluding the technical phase. Microsoft's compliance team then calculates the financial settlement, applies penalties, and enters direct commercial negotiation with you. This phase determines your actual out-of-pocket cost — and is where independent advisory support delivers the most value.
Common Risks and Financial Exposures
SPLA audits consistently expose the same categories of compliance failure. Knowing these patterns helps providers focus their pre-audit preparation on the areas with the highest financial risk.
SAL Under-Reporting
50–80% of all SPLA audit findings. Users with access — not just active users — need SALs.
Server/VM Sprawl
Untracked VMs with Microsoft software create liability for every month they existed.
Licensing Model Errors
Processor vs SAL confusion, missing Windows Server cores, and multiplexed access mistakes.
Missing Documentation
Auditors default to worst-case assumptions. No proof of VM creation date = counted from day one.
The SAL Trap — Access vs Usage
Under SPLA, a Subscriber Access Licence (SAL) is required for every user or device authorised to access a Microsoft service — not just those actively using it. The distinction is critical: if 500 users are in an Active Directory group with access to a Windows Server deployment, all 500 need SALs even if only 50 log in regularly. Auditors will cross-reference your Active Directory exports with your monthly SPLA reports. If AD shows more users with access than you reported, the shortfall is counted for every month of the audit period.
| Product | Monthly Shortfall | SPLA Price/Unit/Month | Audit Period | Sub-Total | + 25% Penalty |
|---|---|---|---|---|---|
| Windows Server SAL | 120 users | $4.20 | 36 months | $18,144 | $22,680 |
| SQL Server Enterprise | 8 cores | $570 | 36 months | $164,160 | $205,200 |
| RDS SAL | 200 users | $4.50 | 36 months | $32,400 | $40,500 |
| Exchange Server SAL | 150 users | $4.20 | 36 months | $22,680 | $28,350 |
| Total | $237,384 | $296,730 |
In this example, a mid-sized hosting provider faces nearly $300,000 in audit liability from just four products. Larger providers with hundreds of servers and thousands of users routinely see initial claims in the $1M–$5M range.
How the 125% Penalty Is Calculated
The default financial consequence under SPLA is: shortfall quantity × SPLA list price × months of shortfall × 125%. The 25% surcharge applies on top of full back-payment at list price. Self-assessments often avoid this surcharge — which is one reason to respond proactively to Microsoft's self-assessment invitations rather than waiting for a formal audit notice.
Full Penalty + Audit Costs
If the audit finds you more than 5% out of compliance, Microsoft can require you to reimburse audit costs — the fees paid to the Big Four firm. For complex audits, these fees reach $50,000–$100,000+.
Back-Payment + Possible Waiver
Shortfalls below 5% are treated more leniently. Microsoft often waives the 25% surcharge and audit cost reimbursement for cooperative providers with minor findings.
No Penalty Surcharge
Completing a self-assessment typically avoids the 25% penalty entirely. You pay only for the identified shortfall at list price — no surcharge, no audit cost reimbursement.
Proactive Defence — Before the Audit Arrives
The best SPLA audit outcome is the one you prepared for before the audit notice arrived. These measures form the foundation of a strong defence position and can reduce your financial exposure by 50% or more before the auditor ever contacts you.
Proactive compliance is not merely a risk management exercise — it is a commercial strategy. Service providers who maintain audit-ready compliance can demonstrate clean operations during Microsoft partner reviews, negotiate better SPLA terms from a position of strength, and avoid the operational disruption that an unexpected audit creates. The cost of ongoing compliance monitoring is typically 5–10% of what a reactive audit settlement costs.
The single most impactful action you can take is establishing a monthly reconciliation process between your SPLA reports and actual deployed usage. This sounds straightforward, but in practice, the gap between reported and actual usage accumulates silently. A server provisioned in January without being added to the March SPLA report creates a three-month shortfall. If that oversight persists for 36 months, the compounding effect transforms a minor administrative miss into a six-figure liability. Monthly reconciliation breaks this compounding cycle.
🎯 Pre-Audit Readiness Checklist
- Archive monthly SPLA reports: Save every report and corresponding reseller invoice for at least 36 months in a centralised, backed-up repository.
- Quarterly self-audits: Reconcile one or two products each quarter against actual usage. This catches drift before it compounds into a 36-month liability.
- Annual mock audits: Engage a third party to run a full simulated SPLA audit — AD exports, VM inventories, ELP construction — on your terms, with no penalties.
- Active Directory hygiene: Promptly disable departed user accounts. Remove users from access groups they no longer need. Eliminate generic shared accounts.
- VM lifecycle documentation: Record creation dates, installed software, decommission dates, and associated customers for every VM. Without this, auditors assume every VM existed since day one.
- Customer BYOL attestations: For customers bringing their own licences, maintain signed attestation letters and Licence Mobility verification forms, updated annually.
During the Audit — Data Collection and Draft Report
The data collection phase is your opportunity to shape the audit's evidence base. Approach it carefully: verify scope before sharing any data, inspect outputs for anomalies before submission, retain timestamped copies of everything, and never alter or fabricate data. Oversharing accidentally widens the audit — one provider we advised mistakenly included their internal development environment, and the auditor counted it as SPLA usage.
A common mistake during data collection is treating the auditor as a neutral party. While Big Four auditors are professional and methodical, they are retained and paid by Microsoft, and their engagement is scoped to identify compliance shortfalls — not to find areas where you overpaid. This does not mean they are adversarial, but it does mean that every piece of data you provide will be interpreted through the lens of identifying under-reporting. Provide accurate, complete data for in-scope environments, but do not volunteer information about out-of-scope systems, future plans, or internal discussions about licensing concerns.
The auditor will typically request data in multiple rounds. The initial request covers the broad environment — server inventories, AD exports, and SPLA reports. Follow-up requests drill into specific areas where the initial data suggested potential shortfalls. Each round is an opportunity to provide context that prevents misinterpretation, but also a potential trap if your responses are inconsistent with previous submissions. Maintain a log of every data submission with dates, contents, and the specific auditor request it addresses.
Once the auditor has your data, they construct an Effective Licence Position (ELP) — a month-by-month spreadsheet comparing calculated usage against reported usage for every Microsoft product. Their methodology defaults to worst-case assumptions on every ambiguity: unidentified SQL Server edition becomes Enterprise, user account with potential access counts as requiring a SAL, and VMs with no creation date are counted from the start of the audit period.
"Active Directory is the battlefield. Auditors treat AD as the authoritative source for user access. If 500 users are in an AD group that grants access to an RDS deployment, the auditor counts all 500 as requiring SALs — even if only 50 ever logged in. Your AD group membership policies are, in practice, your licensing declarations."
Challenging the Draft Report — Your Most Critical Window
The draft audit report is not a verdict — it is the start of a conversation. Auditors expect pushback, and initial SPLA audit reports frequently contain errors, overestimates, and unfounded assumptions. Your response to the draft report is the single most impactful activity in the entire audit process.
Verify Every Calculation
Open the ELP spreadsheet and check every formula. Auditors build complex Excel models, and errors in formulae, lookups, or date ranges are more common than you might expect. One transposition error in a VLOOKUP can inflate a product's shortfall across every month.
Challenge Wrong Assumptions
Identify every line item where the auditor assumed worst-case due to missing information and provide the missing evidence: VM creation dates, proof of SQL Server Standard (not Enterprise), evidence of service accounts or disabled accounts that should not count as SAL users.
Verify Scope Boundaries
Confirm the auditor did not accidentally include environments, servers, or customers outside the agreed audit scope. Present documented arguments for removal of anything that should not have been included.
Document Over-Reporting
While the report will not credit over-reporting against shortfalls, documenting areas where you overpaid is valuable ammunition for the negotiation phase. It demonstrates good faith and provides a factual basis for requesting penalty waivers.
Submit Written Challenges with Evidence
Always submit responses in writing and request they be attached to the final report. A formal paper trail showing you contested specific findings with evidence strengthens your position in the subsequent commercial negotiation with Microsoft.
European Hosting Provider: $2.8M Claim Reduced to $680K
Situation: A European managed services provider with 400+ hosted customers received a formal SPLA audit notice covering a 36-month period. The auditor's draft report identified widespread SAL under-reporting, unreported SQL Server cores on development VMs, and missing end-customer declarations.
What happened: Redress Compliance challenged the auditor's Active Directory methodology (which counted disabled and service accounts as licensable users), demonstrated that 12 VMs were test environments not serving customers, and provided BYOL attestations for three enterprise clients.
North American MSP: Draft Report Reduced by $1.4M
Situation: A large North American managed services provider received a draft SPLA audit report claiming $2.1M in shortfalls across Windows Server, SQL Server, RDS, and Exchange.
What happened: Our team systematically challenged the report: 280 "users" were identified as service or disabled accounts (-$340K); 18 VMs were proven to have been created within the last 12 months rather than the assumed 36 months (-$520K); and SQL Server Standard editions were misidentified as Enterprise on 6 servers (-$540K).
Settlement Negotiation with Microsoft
Once the auditor issues a final report, the technical phase ends and the commercial negotiation begins. You now deal directly with Microsoft's compliance team — a fundamentally different conversation from the data-driven audit process. Microsoft's default calculation is full back-payment at SPLA list price for every month, plus the 25% penalty surcharge. If the shortfall exceeds 5%, they may also seek audit cost reimbursement. This is the maximum — and it is almost always negotiable.
The negotiation phase is where independent advisory support delivers the most measurable value. Microsoft's compliance team negotiates SPLA settlements daily — they are experienced, well-resourced, and they understand exactly how much leverage they hold. Most service providers, by contrast, face an SPLA audit once every three years and lack the institutional knowledge to negotiate effectively. The information asymmetry is enormous, and it consistently works in Microsoft's favour when providers negotiate alone.
A critical principle to understand: Microsoft values recurring revenue over one-time penalty collections. A service provider that continues buying SPLA licences, consumes Azure services, and maintains a strong commercial relationship is worth far more to Microsoft than the penalty from a single audit. This economic reality is your primary negotiation lever — and it is the reason Microsoft's compliance team has significant discretion to reduce settlements for partners who frame the conversation in terms of future value rather than past shortfalls.
| Negotiation Lever | How It Works | Typical Outcome |
|---|---|---|
| Future commitments | Offer increased Azure consumption, new 3-year SPLA with higher minimums, or CSP transition | 20–40% reduction in back-payment |
| Penalty waiver | Request 25% surcharge removal citing full cooperation and inadvertent under-reporting | 25% surcharge fully or partially waived |
| Audit forbearance | Request 2–3 year re-audit protection period | Commonly granted for cooperative partners |
| Payment plans | Negotiate 6–24 month instalments instead of lump sum | Generally accommodated |
| Release of liability | Ensure settlement includes full release for the audited period | Prevents re-opening same period |
| Confidentiality | Include mutual NDA on audit results and settlement terms | Standard in most settlements |
After the Audit — Building Lasting Compliance
The settlement cheque has cleared. Now the real work begins — ensuring you never face another painful audit outcome. The operational improvements you implement post-audit are your most valuable investment.
🎯 Post-Audit Compliance Programme
- Fix reporting processes: Implement automated tools that extract actual user counts from Active Directory on the last business day of each month and cross-reference them with your SPLA report.
- Deploy SAM tooling: Continuously monitor your environment for new Microsoft installations, changes in user access groups, and VM creation/deletion events.
- Train technical teams: Every technician who provisions hosted services must understand that spinning up a VM is a licensing event, not just an operational task.
- Schedule annual mock audits: Make the simulated audit a permanent fixture — it costs a fraction of an official settlement and provides early warning of compliance drift.
- Maintain advisor relationships: The SPLA landscape evolves constantly — pricing changes, CSP programme updates, virtualisation rule changes. Independent advisors ensure your practices keep pace.
10-Point SPLA Compliance Governance Checklist
Archive Every Monthly Report
Save SPLA usage reports and invoices for at least 36 months in a centralised, backed-up repository accessible to your compliance team.
Maintain a Real-Time Server/VM Inventory
List every physical and virtual machine including CPU core counts, installed Microsoft software, creation dates, and associated customers.
Reconcile Active Directory Monthly
Count total users in every AD group with access to a Microsoft service and ensure corresponding SALs are reported. Remove disabled and departed accounts promptly.
Conduct Quarterly Spot-Checks
Compare actual usage against reported usage for one or two products each quarter. Correct discrepancies immediately.
Run Annual Mock Audits
Engage a licensing expert to simulate the full SPLA audit process including AD extraction, ELP construction, and finding documentation.
Track VM Lifecycles
Record deployment dates, decommission dates, and software changes. Use change management tickets as evidence to bound the audit period for each VM.
Maintain Customer BYOL Documentation
Keep signed attestation letters and Licence Mobility verification forms for any customer bringing their own Microsoft licences, updated annually.
Report End-Customer Names
Ensure all customers spending over $1,000/month in Microsoft services are properly declared in your SPLA reporting.
Train All Technical Staff
Every technician, administrator, and engineer who touches hosted infrastructure should understand that provisioning actions are licensing events.
Designate an Audit Response Team
Pre-assign roles (compliance lead, legal, IT, finance) and maintain an audit response plan so you can mobilise within days of receiving an audit notice.