Managed service providers occupy the most exposed position in the SPLA program, and most do not realize it until an audit letter lands. The reason is structural. A pure hoster sells infrastructure and the consumption is relatively easy to attribute. A managed service provider wraps Microsoft software inside a delivered service, often mixes it with customer owned licenses, and frequently runs part of the estate on infrastructure it does not control. Each of those layers creates an attribution question, and in a SPLA audit every unanswered attribution question tends to resolve in the direction that grows the count.
This article explains why managed service providers face heightened SPLA risk, what a Big Four auditor tests in an MSP estate, and how a buyer side defense reconstructs the monthly position so the audit reconciles to your evidence. For the full method, read the SPLA audit defense guide.
Why an MSP carries more SPLA risk
SPLA is Microsoft's monthly licensing program for providers that deliver Microsoft software to external customers. It is pay as you consume, and compliance is verified for every monthly reporting cycle across a 36 month lookback, not just the current position. For a managed service provider, the difficulty is that the delivered service often hides the underlying licensing. A customer buys a managed application or a hosted desktop, and somewhere inside that service is a Windows Server instance, a SQL Server database, or a set of access licenses that must be reported through the SPUR and counted each month.
Three features of the MSP model raise the stakes. First, blended estates, where some software is provided under SPLA and some belongs to the customer, make it easy to report the wrong base. Second, subcontracted infrastructure, where the MSP runs workloads on a third party platform, raises questions about who is the licensed provider. Third, bundled commercial pricing hides the per unit licensing, so the people selling the service rarely see the reporting consequence of what they sold.
In an MSP estate, the licensing risk is buried inside the service. The audit pulls it back into the open, and you want to be the one who put it there first.
What the auditor tests in an MSP estate
A Big Four firm conducts the audit under the MBSA audit clause as an independent third party with broad authority to request deployment records, server configuration data, customer contracts, and usage logs. In an MSP estate the auditor is testing whether the monthly SAL or processor counts you reported can be tied to real customers, real products, and a defensible boundary between your SPLA estate and everything around it.
- Whether every reported SAL block maps to a named external customer with a contract and a usage record
- Whether customer owned licenses were correctly excluded rather than reported under SPLA or, worse, left uncounted on both sides
- Whether workloads on subcontracted infrastructure were licensed by the right party under the right program
- Whether the product and version reported each month matches what was actually delivered
Where the answers are clean, the auditor reconciles to your records. Where they are not, the auditor reconstructs them, and an MSP estate offers more places for that reconstruction to inflate the count than a simple hosting estate does.
The blended estate problem
The single most expensive MSP issue is the blended estate. A managed service provider commonly runs some software the customer owns under their own agreement and some it provides under SPLA. The boundary between the two is a commercial and licensing fact that has to be documented, because the auditor cannot infer it. When the boundary is unclear, the auditor tends to treat ambiguous consumption as SPLA reportable, which means you are counted for software the customer should have licensed, or you are exposed for consumption you genuinely provided but never reported.
The defense is a customer by customer ledger that records, for each engagement, which products are customer owned, which are provided under SPLA, and the contractual basis for each. This is the same discipline as customer mapping in a pure hosting estate, extended to capture the ownership boundary. Built monthly, it is straightforward. Reconstructed under audit across 36 months of changing engagements, it is one of the hardest things to recover.
Subcontracted and shared infrastructure
Many managed service providers do not own all the infrastructure they deliver from. They may run workloads on a hyperscale platform or on a partner's data center. SPLA licensing rules about who may be the provider and where the software may run are precise, and getting them wrong creates exposure on both sides of the relationship. The auditor will ask where each workload physically ran and under whose license it was provided. If your records cannot answer cleanly, the consumption can be counted against you even where another party should have carried it.
Documented multi tenant isolation and clear infrastructure mapping are the answer. You need to be able to show, for every month, where each customer's workload ran and that the licensing followed the workload correctly. For the deeper treatment of isolation evidence, the guidance on boundary documentation applies directly to MSP estates.
A worked reconciliation
Consider an indicative example. A managed service provider reports 400 SAL each month for a hosted productivity service. The auditor's opening reconstruction, working from raw authentication data without customer mapping, counts 520 unique identities and proposes that the additional 120 were under reported. The figures below are indicative and shown only to illustrate the mechanic.
| Line | Auditor opening | Defended position |
|---|---|---|
| Reported SAL per month | 400 | 400 |
| Identities in raw data | 520 | 520 |
| Internal admin and service accounts | Counted | Excluded, 60 |
| Customer owned licenses | Counted | Excluded, 45 |
| Genuine under report | 120 | 15 |
The defended position does not deny the gap. It resolves the gap with evidence: service accounts that never consumed the product, identities the customer licensed under their own agreement, and a small genuine under report that is corrected and reported honestly. The difference between a 120 finding and a 15 finding is the documentation, and the documentation is the work.
Back fees, uplift, and the MSP
When a genuine shortfall is confirmed, the commercial outcome splits into two parts. Back fees at the price file rate for the under reported consumption are not negotiable. The penalty uplift, which ranges from 25 to 125 percent depending on the severity, duration, and nature of the under reporting, is negotiable. For a managed service provider, the uplift argument turns heavily on demonstrating reporting discipline and good faith. An MSP that can show a maintained compliance register, monthly reports filed on time, and a documented method for handling blended estates is in a far stronger position to argue the uplift down than one whose records have to be rebuilt under pressure.
Where this leaves you
A managed service provider can defend a SPLA audit well, but only if the boundaries that the MSP model blurs are made explicit before the auditor arrives. Map every reported SAL to an external customer, record which licenses are customer owned, document where each workload runs and under whose license, and reconcile the monthly base to that evidence. Do that and the audit becomes a comparison against your records rather than a reconstruction from the auditor's assumptions.
A buyer side advisor builds and defends that position with you. We reconstruct the monthly SAL base, separate customer owned from provided software, document the infrastructure and isolation, and split the non negotiable back fee from the negotiable uplift before the auditor sets the number. If a SPLA audit is open or expected, book a strategy call and we will assess your MSP estate and plan the defense.
If this is live on your desk right now, our SPLA audit defense service manages the Big Four auditor on your behalf.