In a SPLA audit, what you ran is only half the question. The other half is which exact edition and version you ran, because the Services Provider Use Rights price each edition differently and impose different licensing rules on each. When a hoster cannot show precisely which product version sat behind each reported deployment, the auditor is free to assume the version that produces the largest exposure. Product version mapping is the discipline that closes that gap by tying every deployment to a documented edition, and it routinely separates an accurate finding from an inflated one.
This article explains what product version mapping is, why it matters so much under the SPUR, where mapping gaps create exposure, and how a buyer side defense uses accurate mapping to bring a SPLA finding back to the true position. The mechanics are specific to hosters reporting under SPLA and have no equivalent in an end customer Microsoft audit.
What product version mapping is
Product version mapping is the record that links each deployed instance to the specific Microsoft product, edition, and version it ran, for each month it ran. It answers questions like whether a database server ran Standard or Enterprise, which release year applied, and whether a workload that looks identical on the surface was in fact a different licensable product underneath. Under SPLA the answers carry real money, because the SPUR sets out distinct rights and the price file sets out distinct rates for each.
An auditor who cannot see which edition you ran will assume the one that costs the most. Mapping is how you take that assumption away.
Why the SPUR makes version a pricing question
Hosters apply the SPUR each month to determine how a product must be licensed and reported, whether by Subscriber Access License, by processor, or by core. The same workload can fall under very different obligations depending on the edition. Enterprise editions cost more than Standard. Certain features move a deployment into a higher tier. Older and newer versions can carry different rules. When the report does not record the edition precisely, and the records do not back it up, the audit cannot confirm the lower cost option, so it defaults to the higher one.
| Mapping question | Why it changes the cost |
|---|---|
| Standard or Enterprise edition | Different SPUR rights and price file rates |
| Which version or release | Different licensing rules may apply |
| Core or processor based | Determines the counting method that month |
| Feature set actually in use | Can move a workload into a higher tier |
Where mapping gaps create exposure
Mapping gaps tend to appear in predictable places. Rapid growth and frequent server provisioning outpace the documentation, so deployments exist that were never tied to a confirmed edition. Upgrades and migrations change the version in place without updating the record. Templates and images replicate a configuration across many servers, so a single mapping error multiplies. And multi tenant environments, where shared infrastructure serves many customers, blur which edition served which workload. Each gap is a place where the auditor can apply the most expensive assumption across the 36 month lookback.
Every deployment that lacks a documented edition is priced at the auditor's assumption, not yours. Accurate product version mapping converts assumptions back into facts, and facts are almost always cheaper.
How mapping defends a SPLA finding
A buyer side defense uses product version mapping in two ways. First, it shrinks the base. By documenting the actual edition and version behind each deployment, month by month, it replaces the auditor's worst case assumptions with the true, often lower, licensable position. Because back fees at the price file rate are calculated on that base, an accurate map directly reduces the non negotiable part of the finding. Second, it strengthens the case on the penalty uplift. A hoster that can produce clean version mapping demonstrates control and good faith, which supports an argument for the uplift to sit nearer 25 percent than 125 percent.
Doing this well means reconstructing the mapping from your own evidence: deployment records, configuration data, image and template histories, and change logs. It pairs with customer mapping, which ties each reported block to the customer it served, and with documented multi tenant boundaries, so that the whole picture holds together when the auditor tests it. This is the reporting discipline that protects a hoster across the lookback, and it is far easier to maintain continuously than to reconstruct under audit pressure.
To see how version mapping fits with the monthly reporting discipline and the uplift negotiation, the SPLA Audit Defense Guide sets out the full hoster defense.
This is the detailed reconstruction work we run for hosters. We sit between you and Microsoft and its appointed Big Four auditor, we rebuild the version mapping from your own records, and we use it to bring both the base and the uplift down. We reduce your exposure or we reimburse our service fee.
Worried your SPLA mapping will not hold
If your version records are incomplete, the auditor will assume the most expensive edition. Let a buyer side team rebuild the mapping and defend the true position. Talk to us about your SPLA audit.