SPLA Audit Defense for ISVs

Many ISVs treat Microsoft licensing as a background cost of running their platform. The audit treats it as the main event. If your product runs SQL Server, Windows Server, or other Microsoft technology to deliver a service to external customers, you are almost certainly a SPLA reporter, and a SPLA reporter is audited against every month of the last three years.

Why ISVs are a distinct audit profile

SPLA is Microsoft's monthly licensing program for hosters, managed service providers, and outsourcers that deliver Microsoft software to external customers. ISVs sit inside that population, but with a twist. Most pure hosters know they are hosters. Many ISVs think of themselves as software companies first and only discover the depth of their SPLA exposure when the audit letter lands. The product was built by engineers optimizing for performance and cost, not by a licensing team optimizing for a defensible monthly report.

That gap is exactly what a Big Four auditor is engaged to find. The audit runs under the MBSA audit clause, conducted by an independent third party with broad authority to request deployment records, server configuration data, customer contracts, and usage logs. For an ISV, the difficult questions are rarely about the headline product. They are about the supporting estate: the reporting databases, the embedded SQL Server instances, the multi tenant back end, and the test and staging environments that quietly run production grade Microsoft software.

The four places ISV exposure hides

Across the ISV audits we have defended, the same structural issues recur. None of them are exotic. All of them are reconstructable if you start before the auditor does.

• Embedded SQL Server that was sized for throughput, then counted by core in a way the original architecture never anticipated
• Multi tenant back ends where one shared instance serves many customers, and the boundary between tenants is not documented in a way an auditor will accept
• Non production environments running full Microsoft software that were assumed to be free and were never reported
• Customer mapping that cannot tie each reported SAL block, or each processor licence, to the customers actually served that month

SAL or processor, and why the choice matters

Hosters apply the SPUR, the Services Provider Use Rights, and report either Subscriber Access License counts or processor and core counts each month. ISVs frequently have a mix. A management console might be best reported on a per user basis, while a high density multi tenant database is better licensed by core. Misapplying the model drives both under reporting, which is a compliance problem, and over reporting, which simply wastes margin month after month. Part of the defense is showing that the model you chose was applied consistently and correctly, not retrofitted to look clean after the letter arrived.

A worked view of where an ISV settlement is built

The figures below are indicative and illustrate the structure of a SPLA exposure, not a quote for any engagement.

Component	Status	Where the ISV defense sits
Back fees at the price file rate	Not negotiable	Reduce the underlying monthly count through accurate reconstruction and correct SPUR application
Penalty uplift, 25 to 125 percent	Negotiable	Evidence of reporting discipline, prompt correction, and good faith
Non production environments	Often disputed	Document which environments served external customers and which did not
Multi tenant boundary	Often disputed	Produce architecture records that show isolation per tenant

The non negotiable back fee is anchored to the count. So the single most valuable thing an ISV can do is get the count right before the auditor sets it, because every reduction in the underlying number reduces the fixed fee and shrinks the base the uplift is applied to.

The buyer side defense, step by step

An ISV defense is a reconstruction project run under controlled disclosure. The sequence matters.

1. Map the real estateInventory every place Microsoft software runs, including embedded instances, reporting layers, and non production systems, before you respond to any data request.
2. Reconstruct month by monthBuild your own monthly position across the 36 month window so you know the number before the auditor proposes one.
3. Document the architectureProduce clear records of multi tenant isolation, customer mapping, and version mapping, the evidence that turns an assumption into a defended fact.
4. Separate fixed from negotiableSplit the non negotiable back fee from the negotiable uplift, and build the argument for the lowest defensible uplift.
5. Control the channelRoute all auditor communication through one owner so nothing leaves the building except through a single, considered point.

What good looks like for an ISV

A good outcome is not a clean bill of health that ignores reality. It is a settlement built on your reconstructed numbers rather than the auditor's opening estimate, with the uplift argued down and your architecture documented so the next reporting cycle starts from a defensible base. For ISVs that plan to keep embedding Microsoft software, the audit can become the moment you finally put reporting discipline in place, which is the structural defense that protects every future month.

The next step

If you are an ISV and a SPLA audit has started, or you suspect your reporting has drifted from your architecture, the move is to reconstruct your position with independent help before the first working session. Our SPLA audit defense guide sets out the full sequence, and the related articles below cover the opening hours and the settlement endgame. Book a strategy call and we will tell you where the real exposure sits and how to defend it.

Related reading

If the timeline is already running, our SPLA audit defense team challenges the counting before back fees are set.