Microsoft SPLA Audit: What Hosting Providers and ISVs Need to Know

How a SPLA Audit Begins

Microsoft does not conduct SPLA compliance audits directly. The process is outsourced to one of the Big Four accounting firms — KPMG, EY, PwC, or Deloitte — who operate as independent auditors under contractual authority granted by the SPLA agreement. When Microsoft decides to audit a licensee, it formally appoints one of these firms, which then issues a notification letter to the SPLA licensee.

The notification letter marks day zero. From this point you have 30 days to formally acknowledge the audit and begin the data collection process. The letter typically specifies the audit scope (which SPLA products and which reporting periods are under review), the types of data requested, and the contact details for the auditing team. Failing to respond within 30 days does not pause the audit — it accelerates it and signals non-cooperation, which affects the auditor's posture throughout the engagement.

SPLA agreements permit Microsoft to audit licensees up to two years after the expiration or termination of the agreement. For agreements that are still active, the lookback covers up to three years of monthly reporting history. This means an audit notification received in April 2026 can examine every monthly report submitted since April 2023 — across potentially dozens of product lines and thousands of deployed instances.

What Triggers a SPLA Audit

Microsoft does not publish its SPLA audit selection criteria, but after more than 50 SPLA engagements we have observed consistent patterns that precede audit notifications. Unusually low monthly reporting amounts relative to a licensee's known hosting footprint are the most common trigger. Microsoft compares reported SPLA consumption against reseller revenue data, Azure marketplace activity, and any signals from its field team about the scale of a provider's hosted environment. A significant gap between what is reported and what the available signals suggest is deployable generates audit interest.

Customer complaints or terminated relationships also create audit exposure. When a hosting customer transitions away from a provider and the transition surfaces licensing gaps — for example, when the new provider discovers the previous host had not been reporting all required licenses — Microsoft may be notified. Rapid growth in a licensee's customer base without proportional growth in SPLA reporting is another common trigger. And since October 2025, any evidence of SPLA licenses being reported for workloads hosted on Listed Provider infrastructure is a direct trigger for enforcement action.

The SPLA Audit Process Step by Step

Understanding each phase of the SPLA audit process allows hosting providers and ISVs to respond strategically rather than reactively.

Step 1: Notification and Scope Definition (Days 1–30)

The auditor issues the notification letter and requests an initial meeting to discuss scope, data requirements, and timeline. Your objective in this phase is to acknowledge the audit without making any admissions, clarify the scope and contractual basis for data requests, and begin your own internal exposure assessment in parallel. The 30-day window is tight but sufficient if you engage immediately.

Step 2: Data Collection and Submission (Days 30–90)

The auditor requests a defined set of data that typically includes monthly SPLA reports submitted to your reseller for the audit period, server inventory exports (including hypervisor host configurations, core counts, and VM-to-host mapping), customer contracts and service descriptions for hosted services, Active Directory user counts or application user exports for SAL-licensed products, and — since October 2025 — cloud provider invoices and deployment logs confirming infrastructure location.

Auditors frequently request broader access than the SPLA contract requires. It is a contractual right to provide only the data the agreement specifies. Providing additional data — such as financial records, customer billing data, or internal product roadmaps — opens exposure that the audit scope does not require and that may generate findings beyond the original scope.

Step 3: Auditor Analysis and Preliminary Findings (Days 90–150)

The auditing firm reviews the submitted data, cross-references reported licenses against deployment evidence, and constructs a preliminary findings report. This report identifies every discrepancy between what was reported and what the evidence suggests should have been reported, calculates the back-licensing cost for each discrepancy across the full audit period, and applies a preliminary penalty uplift recommendation.

The preliminary findings represent the auditor's maximum defensible position, not a final settlement. Every figure in the preliminary report is a starting point for negotiation, not an invoice. Providers who accept preliminary findings without challenge consistently overpay.

Step 4: Response and Negotiation (Days 150–210)

You have the right to respond to preliminary findings with factual corrections, alternative interpretations of the contract language, and technical evidence that modifies the auditor's conclusions. This is where the financial outcome of the audit is primarily determined. Findings based on ambiguous deployment data, edge-case product eligibility questions, or interpretations of the SAL counting rules are almost always negotiable.

At the same time as you respond to the auditor's findings, independent engagement with Microsoft's licensing compliance team — separately from the auditing firm — creates a channel for commercial resolution. Microsoft has discretion to waive or reduce penalty uplifts, structure settlement payments, and shape the remediation requirements in ways the auditor does not control. This commercial dimension of the audit is invisible to licensees who deal only with the auditing firm.

Step 5: Settlement and Remediation Agreement

The audit concludes with a settlement agreement specifying the back-licensing fees to be paid, any penalty uplift that applies, and the remediation obligations the licensee must implement to avoid future findings. Settlements often include a structured payment arrangement, an enhanced compliance reporting requirement for the next 12 to 24 months, and in some cases an Azure consumption commitment that Microsoft uses to convert audit resolution into a cloud revenue opportunity.

The October 2025 Listed Provider Restriction

The single most significant SPLA compliance change in the program's history took effect on October 1, 2025. From that date, SPLA licensees are prohibited from deploying their SPLA licenses on the infrastructure of Listed Providers: Amazon Web Services, Google Cloud Platform, Microsoft Azure, and Alibaba Cloud.

The restriction was announced in October 2022 and a three-year transition period allowed providers to migrate workloads off Listed Provider infrastructure. That transition period ended on September 30, 2025. Providers that continued to report SPLA licenses for workloads hosted on Listed Provider infrastructure after that date are in material breach of their SPLA agreement.

The consequences are distinct from standard SPLA audit findings. While standard findings result in back-licensing and penalty uplift, Listed Provider violations are treated as material breaches of the agreement's infrastructure terms. Microsoft has reserved the right to terminate the SPLA agreement for providers found to be in material breach, which would result in immediate loss of all SPLA license rights — a business-ending outcome for hosting providers whose entire service model depends on SPLA-licensed products.

What Auditors Check for Listed Provider Compliance

Since October 2025, SPLA auditors routinely include cloud provider invoices, deployment metadata, and infrastructure configuration records in their data requests. AWS instance logs, Google Cloud project billing records, and Azure resource group deployments can all be cross-referenced against SPLA monthly reports to identify whether reported licenses were running on restricted infrastructure.

Providers whose workload transition was incomplete at the October 2025 deadline face a binary situation: either they can demonstrate the workloads were moved before the deadline, or they cannot. Providers in the latter situation should seek immediate independent legal and licensing counsel before engaging with any audit process — the exposure extends beyond financial penalty to potential agreement termination and the consequential business disruption that creates.

The Penalty Framework in Detail

SPLA penalties are calculated as a compound of three components. The first is the back-licensing cost: for every month in the audit period where a discrepancy exists, the full monthly SPLA rate applies for the gap between what was reported and what should have been reported. Because SPLA includes Software Assurance equivalent by design, there is no separate maintenance recapture — the full monthly rate covers both license and maintenance for the period.

The second component is the penalty uplift. Microsoft applies an uplift percentage on top of the back-licensing cost that reflects the severity of the non-compliance. The range is 25% to 125%. A 25% uplift is applied where the non-compliance appears inadvertent, the licensee has a strong prior compliance record, and the provider cooperates fully with the audit process and presents a credible remediation plan. A 125% uplift is applied where the non-compliance is material, persistent, involves Listed Provider infrastructure violations, or where the licensee is found to have submitted deliberately inaccurate monthly reports.

The third component is interest, which accrues on unpaid back-licensing fees at a rate specified in the SPLA agreement from the date each monthly report should have been filed. For discrepancies that extend across the full three-year lookback period, interest charges can add a meaningful additional cost to the settlement.

Proactive Compliance: Preventing Audit Findings

The most cost-effective SPLA audit strategy is one that prevents significant findings from existing. Hosting providers who conduct regular internal compliance reviews — using the same methodology Big Four auditors apply — consistently resolve discrepancies in monthly reports before they accumulate into auditable gaps. The key practices are monthly reconciliation between server deployment records and SPLA reports, a quarterly full-stack inventory review that captures new deployments and retired instances, and a documented process for customer onboarding that captures licensing requirements at the point of service provisioning.

Our Microsoft licensing advisory team provides proactive SPLA compliance reviews that apply auditor-level scrutiny to your current reporting posture. Providers who conduct a proactive review before an audit notice arrives consistently achieve materially better outcomes than those who discover gaps for the first time through the audit process itself.

For providers navigating the post-October 2025 environment, a specific Listed Provider compliance review is also essential. This review documents the workload migration timeline, confirms that all previously restricted deployments have been transitioned, and creates an evidence record that can be produced to auditors to demonstrate pre-audit compliance remediation.