When a hoster receives a SPLA verification, the paperwork can look administrative: a set of forms, a data request, a deadline. It is not administrative. A SPLA verification is the mechanism by which Microsoft, through a Big Four firm acting under the MBSA audit clause, tests whether your monthly reporting across a 36 month lookback matches what you actually deployed and delivered. Every form is a question, and every answer is evidence. This article explains what the main forms and requests in a SPLA verification actually ask for, what the auditor reads into your responses, and how to answer from a defended position rather than improvising under deadline.
For the full defensive method, read the SPLA audit defense guide. Here we walk the forms one by one.
What a SPLA verification is testing
SPLA is pay as you consume, and compliance is verified for every monthly reporting cycle, not just the current position. The verification reconciles three things: what you reported each month, what you actually deployed, and what the use rights permitted. The forms exist to gather the evidence for that reconciliation. A Big Four firm conducts the work as an independent third party with broad authority to request deployment records, server configuration data, customer contracts, and usage logs. The forms are the structured front end of that authority, and what you put on them frames everything that follows.
Every form in a verification is a question about your reporting. The answer is not a number, it is a number plus the evidence that defends it.
The reporting history request
The first request is almost always your SPLA reporting history. The auditor wants the monthly SAL or processor counts you submitted across the lookback, product by product. This appears to be a simple retrieval, but it sets the baseline against which everything else is measured. Gaps in the history, months filed late, or counts that jump without explanation all become questions. The defended response is a complete, consistent reporting history with the interpretation behind each month available if asked. If your history has gaps, the time to address them is before you submit it, not after the auditor notices.
The deployment and configuration request
Next comes the request for deployment and server configuration data. The auditor wants to see what was actually installed and running: which products, which versions, on which hardware, with how many cores or processors. This is matched against your reported counts. Two issues surface most often here. The first is decommissioned or idle infrastructure that still appears in scans but consumed nothing. The second is product versions that differ from what was reported. Both can inflate the auditor's reconstruction if your records do not explain them. The defended response pairs the configuration data with mapping that shows which deployments were live, which were retired, and which version each one ran.
The customer and contract request
The verification also asks for customer contracts and the mapping between customers and reported consumption. This is where attribution is tested. Every reported SAL block should tie to a named external customer with a contract and a usage record. The auditor uses this to confirm that consumption was correctly attributed and that customer owned licenses were not mistakenly reported under SPLA or, worse, left uncounted. A clean customer mapping turns this from an investigation into a confirmation. A weak one invites the auditor to attribute ambiguous consumption in the direction that grows the count.
| Request | What it gathers | What the auditor reads into it |
|---|---|---|
| Reporting history | Monthly SAL or processor counts | Consistency, gaps, unexplained jumps |
| Deployment and config | Installed products, versions, cores | Reported versus actual deployment |
| Customer and contract | Customer mapping and agreements | Whether consumption is correctly attributed |
| Authentication and usage | Access counts and usage logs | Whether counts are contemporaneous and real |
The authentication and usage request
The final core request covers authentication counts and usage logs, the raw access data that underpins SAL reporting. The auditor uses this to test whether your reported access numbers reflect real use. The critical point is that contemporaneous evidence, sealed daily counts captured at the time, carries far more weight than figures reconstructed later. Raw authentication data without context tends to over count, because it includes service accounts, internal administrators, test identities, and other access that never consumed a licensed product. The defended response presents the raw data alongside the exclusions, so the auditor sees the same adjustments you applied when reporting.
How answers compound
The forms are not independent. The reporting history sets the baseline, the deployment data tests it against reality, the customer mapping attributes it, and the authentication data underpins it. An inconsistency in one request becomes a thread the auditor pulls through the others. This is why answering form by form, in isolation and under deadline, is risky. A number you give on the authentication form has to agree with the customer mapping, which has to agree with the reporting history. Reconciling these against each other before you submit anything is the whole game.
When a genuine shortfall emerges from the reconciliation, the commercial outcome splits in two. Back fees at the price file rate are not negotiable. The penalty uplift, which ranges from 25 to 125 percent depending on severity, duration, and nature of the under reporting, is negotiable, and a hoster who answered the forms from a reconciled position with demonstrable reporting discipline is far better placed to argue it down.
Answering from a defended position
The right way to handle a SPLA verification is to treat the forms as the visible part of a reconciliation you have already done. Before responding, rebuild your own view of the monthly base across the lookback, map every reported block to a customer and a version, identify and exclude the access that never consumed anything, and document the isolation on shared infrastructure. Then the forms become a place to present a position you can defend, rather than a place to discover problems in real time in front of the auditor.
- Reconcile your own monthly base before you answer any form
- Pair every reported count with the customer, version, and usage evidence that supports it
- Document exclusions so raw data does not over count against you
- Keep the answers across forms consistent, because the auditor reads them together
Where this leaves you
SPLA verification forms are not paperwork, they are structured questions about your reporting, and the auditor reads more into your answers than the forms suggest. Reconcile your own position first, answer each form with the evidence that defends the number, and keep the answers consistent across the whole request. Do that and the verification confirms your reporting rather than rebuilding it against you.
A buyer side advisor reconciles the monthly base, prepares the form responses, and sits between you and the auditor so the verification proceeds from your evidence. If a SPLA verification is open or expected, book a strategy call and we will assess your reporting and prepare your responses before you submit them.
If an auditor is already asking questions, our SPLA audit defense service manages the Big Four auditor on your behalf.