Many companies walk into a Microsoft audit believing their licensing position is settled because their own software asset management tool produced a clean Effective License Position. It is a costly assumption. Microsoft builds its own ELP, with its own counting methodology and its own data, and Microsoft's calculation is the one that governs the commercial outcome. Knowing how that calculation is assembled, and where it tends to overstate, is the foundation of any defense. This article explains how Microsoft constructs its ELP and why your internal number is a starting point rather than a conclusion.
For the full method on building and defending a position, read the Effective License Position guide. Here we focus on how Microsoft builds its side.
What an ELP is and who owns the number
An Effective License Position is the reconciliation of what you have deployed against what you are entitled to use. It is the central document of an audit, because the gap between deployment and entitlement is what drives any settlement. The critical point most buyers miss is that there are two ELPs in play. There is the one you or your SAM tool produce, and there is the one Microsoft produces. When they differ, Microsoft's calculation governs, because Microsoft uses its own methodology and its own data rather than accepting yours. Your number is useful for preparing, but it does not bind the outcome.
A clean SAM tool ELP can still differ from Microsoft's calculation, and Microsoft's calculation is the one that sets the bill.
The data Microsoft uses
The biggest reason the two numbers diverge is the data behind them. A SAM tool sees what it is configured to scan. Microsoft sees a great deal more, because it draws on telemetry and account data that you may not be feeding into your own tooling. In 2026 that data picture is wide and detailed.
- Azure consumption and resource telemetry, which reveals what is actually running in the cloud
- Microsoft 365 account and service data, which shows assigned and active users across the tenant
- Management and identity tooling signals, which expose servers and services your scans may miss
- Azure Arc telemetry, which can reveal unlicensed servers connected to your environment
Because Microsoft assembles the deployment side from this telemetry rather than from your scan, its view of what you are running can be both broader and different from yours. Anything your SAM tool did not see, but Microsoft's data did, becomes a line in Microsoft's ELP that was never in yours.
The counting methodology
Data is only half of it. The other half is how the data is counted, and Microsoft applies its own methodology. Two organizations can look at the same deployment and the same entitlements and produce different positions because they count edition, virtualization, and access differently. Microsoft's methodology tends to resolve ambiguity in the direction that increases the deployment count or decreases the credited entitlement. Where your tool gave you the benefit of the doubt on an edition or a virtualization scenario, Microsoft's count may not, and that difference flows straight into the gap.
| Element | Your SAM tool ELP | Microsoft's ELP |
|---|---|---|
| Deployment data | What the tool was configured to scan | Azure, Microsoft 365, and management telemetry |
| Counting method | Your interpretation of the terms | Microsoft's methodology |
| Ambiguity | Often resolved in your favor | Often resolved toward more exposure |
| Authority | Preparation only | Governs the commercial outcome |
How the ELP enters the audit
In a formal audit, the Effective License Position is produced through a third party accounting firm engaged under the MBSA audit clause, working from Microsoft's data and methodology. The report it produces is presented as the position, but it is not the final sentence. The ELP is negotiated after the report, and the contract clause that follows from it is precise: if unlicensed use is 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. That threshold and that multiplier are why the accuracy of the deployment count matters so much, and why an overstated count is expensive in two ways at once.
Why your number still matters
If Microsoft's calculation governs, why build your own at all. Because you cannot challenge a number you have not independently reconstructed. Your own ELP, built from your real entitlements and a careful read of your deployment, is the instrument you use to test Microsoft's. It shows you where Microsoft's data picked up something that is decommissioned, double counted, or licensed under an entitlement Microsoft did not credit. Without your own position, you are accepting Microsoft's on faith. With it, you can identify line by line where the two diverge and argue each difference on evidence. This is why running your own internal assessment first, before responding to a formal demand, is a recognized defensive move.
Where this leaves you
Microsoft builds its ELP from its own data and its own methodology, and that calculation governs the outcome. A clean SAM tool report is preparation, not protection. To defend your position you have to understand how Microsoft assembles its number, reconstruct your own from real entitlements, and challenge the difference before the 5 percent threshold and the 125 percent multiplier turn an overstated count into a large bill.
If you want the full method for reconstructing a defensible ELP and challenging Microsoft's calculation line by line, download our Effective License Position guide and work through it against your own estate.
When the numbers start to look serious, we model the exposure through our ELP exposure modeling work before the auditor publishes theirs.