Every Microsoft audit turns on a single document, the Effective License Position, which reconciles what you have deployed against what you are entitled to use. The gap between those two figures is what drives any settlement. What buyers rarely appreciate is that the position an auditor presents is full of errors, and those errors are not random. They cluster in a handful of recurring categories, and almost all of them push the number up rather than down. This article walks through the most common ELP errors we see in Microsoft audits, why each one happens, and how a buyer side review corrects it before it becomes a bill.
For the complete method on building a defensible position from the ground up, work through the Effective License Position guide. Here we focus on the specific mistakes that recur in the auditor's draft.
Why the errors run one way
The first thing to understand is that the auditor builds the deployment side of the position from Microsoft's own telemetry and account data, drawn from Azure, Microsoft 365, and management tooling, and counts it with Microsoft's own methodology. That telemetry is broad but it is not tuned to your entitlements or your history. It captures signals and treats every signal as a live, licensable instance unless someone proves otherwise. The result is a draft that overstates deployment and understates entitlement, because the burden of correction sits with you and nothing in the auditor's process removes the noise on its own.
The draft position assumes every signal is a licensable instance. Your job is to show which ones are not.
Error one, counting decommissioned and dormant systems
The most frequent error is counting servers and instances that no longer run. Telemetry lags reality. A server that was decommissioned last quarter can still appear in management tooling or leave a trace in identity logs, and the draft position counts it as deployed. The same happens with dormant virtual machines that were spun up for a project, never licensed because they were never meant to persist, and never fully removed. Each of these becomes a line of unlicensed use in the auditor's count even though nothing is actually running. The correction is documentary: decommission records, change tickets, and infrastructure logs that show the date a system left service.
Error two, ignoring entitlements you actually hold
The mirror image of overcounting deployment is undercounting entitlement. The auditor credits the licenses it can see cleanly in your agreements, but entitlements are scattered. Licenses acquired through an acquisition, rights carried under Software Assurance, downgrade and prior version rights, and licenses sitting in a subsidiary agreement are all easy to miss. If your own records do not surface them, the draft will not credit them, and every uncredited license widens the gap. The correction is to assemble the full entitlement picture from every agreement, amendment, and acquisition before you accept the auditor's tally of what you own.
Error three, misreading virtualization rights
Virtualization is where counting methodology does the most damage. Whether you license by physical core, by virtual machine, or under a rule that lets a fully licensed host run unlimited instances changes the number dramatically. The draft position frequently applies the most expensive reading, counting each virtual instance as if it needed its own license when the host is already licensed to cover them, or counting cores in a way that ignores the minimums and maximums in the product terms. This single category can swing an exposure figure by a wide margin. The correction is to map each workload to the correct licensing rule and show the math the product terms actually require.
| Error category | What the draft does | The correction |
|---|---|---|
| Decommissioned systems | Counts stale telemetry as live | Decommission records and change logs |
| Missed entitlements | Credits only the visible licenses | Full entitlement picture across all agreements |
| Virtualization | Applies the most expensive reading | Map workloads to the correct rule |
| Edition assumptions | Assumes the higher edition | Evidence of the edition actually installed |
| Double counting | Counts the same use twice | Reconcile telemetry sources against each other |
Error four, assuming the higher edition
When telemetry cannot tell which edition is installed, the draft tends to assume the more expensive one. A standard edition counted as a premium edition, or a base product counted with an add on it does not use, inflates both the deployment and the price applied to it. Edition errors are quiet because they do not change the instance count, only the value attached to each instance, which makes them easy to overlook in a long report. The correction is installation evidence that shows the edition actually deployed.
Error five, double counting across data sources
Because Microsoft assembles its view from several telemetry sources at once, the same use can appear more than once. A user counted through Microsoft 365 account data and again through a device signal, or a server counted through both management tooling and Azure Arc telemetry, lands twice in the draft. Double counting is among the easier errors to argue once you reconcile the sources against each other, but it is invisible until someone lines the data sets up side by side and looks for the overlaps.
Why these errors are expensive twice over
An inflated ELP is not just an inflated number. It interacts with the contract clause that governs the settlement. If unlicensed use reaches 5 percent or more of total use, the customer reimburses Microsoft's verification costs and acquires the licenses at 125 percent of the current price. So an error that pushes you over the 5 percent threshold does two things at once, it triggers the cost reimbursement and it applies the higher multiplier to every license in the gap. This is why correcting the count is not a clerical exercise. Pushing the unlicensed figure back under the threshold, or reducing the size of the gap that sits above it, changes both the price and the penalty mechanics.
An error that nudges you past 5 percent costs you twice, once in reimbursed verification fees and once in the 125 percent multiplier.
How a buyer side review corrects the draft
The defense is methodical rather than dramatic. You reconstruct your own position from real entitlements and a careful read of your deployment, then you set it against the auditor's draft line by line and identify exactly where the two diverge. Each divergence falls into one of the categories above, and each is argued on evidence rather than assertion. The auditor cannot simply hold its number when you produce a decommission record, a missing entitlement, or a virtualization rule that the draft ignored. Running your own internal assessment first, before responding to a formal demand, is a recognized defensive move precisely because it gives you the independent position you need to test theirs.
Where this leaves you
The Effective License Position an auditor presents is a draft built to overstate, not a verdict. Its errors are predictable, they cluster in a few categories, and almost all of them run in Microsoft's favor. The buyers who settle well are the ones who treat the draft as a claim to be tested, reconstruct their own position, and correct each error before the 5 percent threshold and the 125 percent multiplier turn an overstated count into a large and avoidable bill.
To work through the full method for reconstructing a defensible position and challenging each error in turn, download our Effective License Position guide and run it against your own estate before the auditor sets the number for you.
If you would rather not face that alone, our ELP exposure modeling team stress tests every line the auditor will count.