A reconciliation that lives only in a spreadsheet is a guess. A reconciliation backed by sourced, dated, and traceable evidence is a defense. The difference decides how a Microsoft audit ends.
Most end customers who build an Effective License Position stop at the answer. They produce a number, see that it looks comfortable, and move on. Then a formal audit arrives, the auditor asks where each figure came from, and the comfortable number falls apart because nobody can show the working. The reconciliation was never wrong. It was simply never documented well enough to defend. This article is about closing that gap: how to record a reconciliation so that every line can be traced to a source, every assumption can be explained, and the whole position holds up when an auditor pushes on it.
If you have not yet built the reconciliation itself, start with reconciling deployment to entitlement, which covers how the two sides are compared. This piece assumes you have a position and now need to make it auditable.
Why documentation is the real defense
In an audit, the burden of proof sits with you. Microsoft and its appointed auditor do not have to disprove your entitlement. You have to evidence it. A deployment you cannot explain is counted as in use. An entitlement you cannot produce paperwork for is treated as if it does not exist. The reconciliation number itself carries no weight unless you can show how it was reached. That is why documentation, not the calculation, is what separates a position that survives from one that collapses under the first round of questions.
Good documentation also changes the tone of the engagement. When you can answer every provenance question on the spot, the auditor learns quickly that the position is built on records rather than estimates. That alone narrows the areas they probe and shortens the audit, because guesswork invites scrutiny and sourced evidence closes it down.
The four layers every reconciliation needs
Think of a defensible reconciliation as four layers stacked under the headline position. Each one answers a question the auditor will ask.
Layer one, the source records
These are the raw inputs: the inventory exports, the cloud usage reports from Azure and Microsoft 365, the volume licensing statements, the subscription records, and the agreement documents. Source records are kept as captured, unedited, with the date and the system they came from. When an auditor asks why a server count is what it is, the source record is the answer, not a recollection.
Layer two, the transformations
Raw data rarely maps straight onto a license count. Servers are grouped, cores are counted, virtualization is resolved, duplicate records are removed. Each of these steps is a transformation, and each one needs to be written down: what rule was applied, why, and what it changed. A transformation you cannot explain is a transformation the auditor will reverse in their favor.
Layer three, the assumptions
Every reconciliation rests on judgment calls. Which edition applies. Whether a prior entitlement still carries. How a licensing rule reads for a particular deployment. These assumptions are legitimate, but only if they are stated openly and reasoned. An assumption recorded with its rationale is a position you can defend. An assumption buried silently in a formula is a finding waiting to happen.
Layer four, the position
The position is the net result, product by product, that sits on top of the three layers below. It is the part everyone looks at, and the only part that means anything once the layers beneath it are sound. Documenting the position means tying each net figure back to the source, transformation, and assumption that produced it, so the chain is unbroken from raw record to final number.
A documentation record that holds up
In practice the layers come together as a record per product line. Here is the shape of one entry, kept deliberately simple so it can be repeated across the estate.
| Element | What it captures |
|---|---|
| Product and edition | The exact product, edition, and version being counted |
| Deployment figure | The count, plus the source export and its capture date |
| Entitlement figure | The count, plus the agreement or subscription reference behind it |
| Counting rule applied | The licensing rule used and why it fits this deployment |
| Assumptions | Any judgment made, stated with its reasoning |
| Net position | Surplus, short, or balanced, traceable to the rows above |
Indicative structure. The exact fields depend on your products, agreements, and the way your estate is organized.
A record like this turns a reconciliation into something an auditor can walk through line by line and find nothing to dispute, because every figure announces where it came from before the question is even asked.
Dating and sealing the evidence
Timing matters as much as content. A Microsoft estate moves constantly, and a reconciliation describes a moment. Without a clear date, an auditor can argue that your evidence describes a different point in time than the one under review. Every source export should carry its capture date, and the reconciliation as a whole should state the date it represents. Where possible, evidence is sealed at capture so it cannot be quietly revised later, which is exactly the discipline that makes daily counts credible in the hoster world and entitlement records credible here.
The same principle protects you over time. An audit can reach back, and a position you documented and dated a year ago is far stronger than one reconstructed from memory once the demand arrives. Documentation is most valuable when it is built before you need it.
Common documentation failures
Most reconciliations that fail in audit fail for a small set of repeatable reasons, all of them avoidable.
- Numbers with no source, where the figure is right but its origin cannot be shown
- Silent transformations, where data was grouped or cleaned without any record of the rule
- Unstated assumptions, where a judgment call looks like a fact until the auditor tests it
- Undated evidence, where the reconciliation cannot be tied to the period under review
- Overlooked entitlement left out, which quietly overstates your own exposure
Each of these is a documentation problem, not a calculation problem. The position was probably correct. It simply could not be proven, and in an audit an unprovable position is treated as no position at all.
Why a tool export is not documentation
A software asset management tool will produce a clean internal Effective License Position, and it is tempting to treat that export as the documentation. It is not. The tool applies its own counting logic, which you may not be able to see or explain, and Microsoft uses its own methodology and its own data from Azure, Microsoft 365, and management tooling, so its calculation can differ. When the two diverge, Microsoft's calculation governs, and a tool export gives you nothing to argue back with because you cannot show the working behind it. Documentation you control and understand is what lets you compare the two positions line by line and defend the difference.
The next step
A documented reconciliation is the asset that decides whether your Effective License Position is a defense or a liability. The full method, including the record templates and the evidence standards an auditor respects, is in our pillar, the Effective License Position Guide. To go deeper into the surrounding mechanics, read reconciling deployment to entitlement and ELP for SQL Server estates, where documentation discipline matters most. When the position is yours to defend, the worst time to build the evidence is after the demand lands. Talk to us before that, while there is still time to do it properly.
When the numbers start to look serious, we take over the process through our Microsoft audit defense engagement.
Make your reconciliation defensible before the auditor asks.
Book a strategy call and we will pressure test your documentation the way a Microsoft auditor will, then show you where it needs to hold.
Book a Strategy Call