The Anatomy of a Microsoft Licensing Audit
A Microsoft licensing audit is a structured commercial process designed to identify gaps between the software deployed in your environment and the licences you hold — your Effective Licensing Position (ELP). Understanding exactly how the process works, at each stage, is the foundation of effective audit defense. Organisations that treat the audit as an administrative inconvenience and respond cooperatively without independent analysis consistently pay more than organisations that engage the process strategically.
The process is not random. Microsoft has a well-defined methodology, uses specific inventory tools, applies documented licence counting rules, and follows a predictable commercial sequence. Every stage has decision points that affect your eventual liability. This article maps each stage and identifies the leverage available to you at each point.
The Standard Audit Timeline
Inventory Tools and What They Capture
The specific inventory tool used during the audit materially affects what is captured, and therefore your apparent exposure. Understanding which tool is being used — and its known limitations — is essential for preparing your ELP response.
| Tool | Primary Coverage | Known Limitations | Defense Consideration |
|---|---|---|---|
| SCCM / MECM | Windows endpoints and servers joined to domain | Misses non-domain-joined devices, BYOD, Linux/macOS | Validate agent deployment rate — ungoverned devices may have unlicensed installs not captured |
| Microsoft MAP Toolkit | Network-based scanning of Windows environments | Captures application presence, not active use; may count installed-but-uninstalled software | Challenge any software showing as installed that has been removed — request removal evidence provision |
| PowerShell Audit Scripts | Targeted product queries (Office, SQL, Windows Server) | Script quality varies by auditor; may not apply virtualisation rules correctly | Request a copy of all scripts before execution; review for virtualisation rule compliance |
| Third-party SAM (Flexera/Snow) | Normalised application recognition across complex estates | Application recognition database may misclassify editions (SQL Standard counted as Enterprise) | Review normalisation rules; challenge edition misclassifications with installation media and activation key evidence |
| Azure Usage Reports | Azure subscription consumption | Doesn't automatically apply AHB credits, Reserved Instance discounts, or MACC commitments correctly | Generate your own Azure MACC and AHB credit documentation before ELP submission |
Understanding the ELP: How Microsoft Calculates Your Gap
The Effective Licensing Position is the mathematical core of the audit. It is calculated as: Licences Required (from deployment data) minus Licences Held (from entitlement records) = ELP Gap. A negative gap is your exposure; a positive gap (over-licensing) is waste you may wish to address in your next EA renewal.
The complexity lies entirely in how "Licences Required" is calculated. Microsoft applies specific counting rules that differ significantly between product families and licence types. The most commonly misapplied rules in practice are:
SQL Server virtualisation counting. SQL Server Enterprise on a virtualised host can be licensed per-VM or per-physical-host (covering all VMs). The per-host licence requires SA and covers all current and future VMs — auditors frequently count per-VM even where per-host is the correct and more economical calculation. The SQL Server virtualisation licensing rules article covers this in detail.
Windows Server CAL stacking vs. device/user. Windows Server CALs may be device-assigned or user-assigned, and the choice significantly affects total count. Auditors sometimes default to the higher-count methodology. If your organisation uses device CALs, this should be explicitly documented and challenged if auditors apply user methodology.
SA benefit exemptions not applied. Software Assurance entitlements including step-up rights, licence mobility, and disaster recovery passive secondary instances reduce the gross licence requirement. Auditors frequently apply gross deployment counts without SA benefit offsets, inflating the apparent gap. See the Software Assurance guide for the full benefit exemption catalogue.
Test/development environment exemptions. Licences used exclusively in test or development environments may qualify for reduced-cost or no-cost licensing under specific SA and MSDN entitlements. These are frequently omitted from ELP calculations, creating false positive gaps for development infrastructure.
Settlement Mechanics: How the Commercial Resolution Works
Once a validated ELP gap is agreed, the commercial resolution is negotiated. Microsoft has a strong preference for licence purchases as settlement — this generates revenue and increases EA commitment for future periods. However, settlement through a forward-looking EA amendment is commercially equivalent from a compliance standpoint and materially better for the organisation financially.
Key settlement principles: First, all settlement pricing should reference EA pricing, not list pricing. Microsoft's MSRP for enterprise products is effectively a penalty rate — no enterprise customer pays list price, and audit settlement should not create that precedent. Second, where the gap involves products that are being migrated or decommissioned, a time-limited EA commitment (covering the remaining migration period) is commercially more appropriate than a full three-year commitment. Third, audit settlement should be documented separately from any EA renewal discussion. Bundling audit resolution into a renewal package allows Microsoft to obscure the actual cost of the settlement through renewal pricing adjustments.
For further context on the negotiation framework applicable during audit settlement, see the EA negotiation tactics guide — many of the same leverage principles apply in audit settlement discussions. The negotiation during a Microsoft audit guide covers audit-specific tactics in more detail.
A formal audit and a true-up review use different legal frameworks. The true-up is a self-certification process under your EA; you report it, you are responsible for accuracy. A formal audit inverts the burden: Microsoft must prove your non-compliance. Understanding which process you are in — and not allowing Microsoft to conduct an informal audit disguised as a true-up review — is a fundamental audit defense principle. See the true-up explainer and compliance guide for the formal distinction.