Every month a hoster files a SPLA report, two errors are possible and they pull in opposite directions. Under reporting means you reported less consumption than you actually delivered, which leaves a compliance gap that a SPLA audit will eventually price as back fees plus a penalty uplift. Over reporting means you reported more than you delivered, which is clean from a compliance view but quietly burns margin month after month. Most hosters watch only for the first kind, because it is the one that triggers a demand. The disciplined ones watch for both, because the same reporting habits that prevent one prevent the other.
Why the two errors share a root cause
SPLA is pay as you consume. Each month you apply the Services Provider Use Rights, the SPUR, to your deployment and report SAL counts or processor counts for the products you delivered to external customers. Both under reporting and over reporting come from the same place: a gap between what you actually ran and what your monthly report claims you ran. When the report understates the estate, you are exposed. When it overstates the estate, you are paying for licenses no customer consumed. The discipline that closes that gap is identical in both directions. It is an accurate, repeatable monthly reconciliation between deployment and the report you file.
Under reporting, the side an auditor cares about
Under reporting is the failure the audit is built to detect. A Big Four firm conducts the SPLA audit under the MBSA audit clause, with authority to request deployment records, server configuration data, customer contracts, and usage logs across a 36 month lookback. When the reconstructed consumption for a month exceeds what you reported, the difference is under reporting. The auditor turns it into back fees at the price file rate, which are not negotiable, and then applies a penalty uplift ranging from 25 to 125 percent depending on severity, duration, and nature.
The common drivers of under reporting are mechanical, not deceptive. A new customer estate is stood up but never added to the monthly SAL block. A product is upgraded to an edition that carries a higher SPUR obligation, but the report still counts the old edition. A SPUR update changes how a workload must be licensed, and the change is missed. Each of these is defensible when you can show it was a narrow, honest mechanical error rather than a pattern, but only documentation makes that case.
Over reporting, the side your finance team cares about
Over reporting attracts no audit attention because it never leaves you short. It simply costs money. The usual causes mirror the under reporting causes in reverse. A customer churns and the SAL count keeps reporting them for months. A test or internal environment that does not require a SPLA license is swept into the report. A processor count is filed for hardware that was decommissioned. Multi tenant boundaries are drawn too widely, so users who never touched a licensed workload are counted anyway. None of this is a compliance problem. All of it is margin you handed back without a customer attached to it.
For a hoster running on thin per seat economics, sustained over reporting can be the difference between a healthy and an unhealthy product line. It rarely shows up in a compliance review precisely because compliance reviews look for shortfalls, not surpluses. It shows up only when someone reconciles the report against the real, billable estate.
A worked illustration of the two errors
The figures below are indicative and chosen only to show the shape of each error, not to quote any real outcome. Picture a single product line reported over one month.
| Measure | Under reported | Accurate | Over reported |
|---|---|---|---|
| Actual SAL delivered | 1,000 | 1,000 | 1,000 |
| SAL reported | 820 | 1,000 | 1,180 |
| Compliance gap | 180 short | none | none |
| Margin leak | none | none | 180 paid, unbilled |
| Audit consequence | back fees plus uplift | clean | silent cost |
Indicative illustration of how each error behaves, not a quoted outcome.
The accurate column is the target. Notice that the over reported column is invisible to an audit yet expensive, while the under reported column is the only one a SPLA audit will surface. A hoster who tracks only audit risk will tolerate the over reported column indefinitely.
How to find each error before it costs you
The fix for both is one process applied with discipline. Reconcile the monthly report against the real estate each cycle, using the same authoritative sources the auditor would use, before you file rather than after a demand arrives.
- Seal a daily authentication count for each licensed product and reconcile the monthly SAL block to it
- Map every reported SAL block to a named customer, so churned or non existent customers fall out
- Map product versions and editions to the current SPUR, so edition upgrades raise the right obligation
- Document multi tenant boundaries, so users are counted only where a licensed workload was actually reachable
- Exclude environments that genuinely carry no SPLA obligation, so they never inflate the report
Run this reconciliation monthly and the under reporting gap closes because nothing in the estate is missed, while the over reporting leak closes because nothing dead or out of scope stays in the count. The SPLA program gives only a short window to correct a reporting mistake, so finding errors in the same cycle they occur matters more than finding them later.
Why this is the structural defense
When an audit arrives, the hoster with a clean monthly reconciliation is in a fundamentally different position from one reconstructing positions from memory. Clean records do two things at once. They shrink the consumption figure that drives back fees, because nothing is overstated against you. And they characterize any genuine shortfall as a narrow, inadvertent error rather than a systematic pattern, which is the single strongest argument for a penalty uplift at the low end of the 25 to 125 percent range. The same monthly habit that stops you over paying Microsoft every month also stops the auditor from pricing your gaps at the top of the band.
For more on the mechanics behind the monthly cycle, see how SPLA monthly reporting works, and for the specific mistakes that turn into findings, read common SPLA reporting errors. Both feed the same defensive posture set out in the pillar guide.
The next step
If you are not sure whether your monthly reports are accurate in both directions, a short review will tell you where the exposure and the leak sit. The SPLA Audit Defense Guide sets out the reconciliation that catches both, and a Strategy Call will pressure test your current reporting against the way a Big Four auditor will read it.
Find the gap and the leak before the audit does.
Book a Strategy Call to pressure test your monthly SPLA reporting against the way a Big Four auditor will read your 36 month lookback.
Book a Strategy CallIf an auditor is already asking questions, our SPLA reporting discipline service puts the monthly evidence in order before an auditor ever asks.