The difference between a true-up and a compliance finding is not the size of the gap. It is who found it.
A gap you discover yourself gets quoted at normal commercial terms in your next renewal conversation. The same gap discovered during an audit is a finding, and findings are not negotiated from the same footing. That is the entire argument for doing this work before anyone asks.
What an Audit Actually Checks
1. Deployed cores against licensed cores. Every populated socket, every physical core, measured against entitlements. This is where the 16-core per socket minimum and the 72-core per order minimum matter: they set the floor, and deployment above your entitlement is the gap. Per-core licensing means hardware changes and licence positions have to move together.
2. Edition and feature use. Whether the features actually in use are covered by the tier you licensed. Mixed estates — some hosts on one edition, some on another, after years of piecemeal purchasing — are where this gets uncomfortable.
3. Build and patch level, for perpetual holders. Perpetual entitlements cover the builds you were entitled to while support was current. Updates installed after support expired sit outside that. This is the specific exposure Broadcom's 2025 letters targeted, covered in can Broadcom disable your perpetual licence.
The Three Findings That Catch Most Estates
Core count drift. The most common by a distance, and almost never deliberate. Hardware refreshed to denser CPUs. A host added to a cluster during an incident and never removed. A lab environment that quietly became production. None of it routes through procurement, so entitlements never move.
Minimums not applied. Estates that last renewed before April 2025 were sized under the old rules. A sparsely populated socket still licenses at 16 cores; an order still floors at 72. Anyone who has not re-sized since then is working from a stale number.
Post-lapse patching. Perpetual holders whose support expired, who kept applying updates because the update path still worked. The software installing successfully is not the same thing as the entitlement covering it.
The Evidence Pack to Assemble Now
From vCenter: a host inventory export listing physical sockets and physical cores per host, grouped by cluster, with build and patch level. Include everything — labs, DR sites, dormant hosts. Anything powered on and licensed counts.
From procurement: every purchase order, entitlement certificate, renewal confirmation and support contract, including the ones from before the acquisition. Perpetual entitlements from years ago still matter, and they are usually the hardest documents to find.
The reconciliation: cluster by cluster, deployed cores against entitled cores, with the minimums applied. This is the actual deliverable. Everything else is input.
Keep it current. Re-run it whenever hardware changes and at every renewal. A reconciliation done once and left to age is how drift starts again.
If You Find a Gap
Close it during a renewal conversation, not a compliance conversation. Sizing a renewal to your true deployed footprint is an ordinary commercial transaction; it happens at list-adjacent pricing with the normal levers available, and nobody is characterising it as a breach.
Do not resolve a gap by quietly decommissioning hosts the week before an audit. Deployment history is visible in vCenter, and it converts a routine true-up into a credibility problem.
If you want the reconciliation done properly and the result turned into a correctly sized renewal quote, talk to AceMQ. We are a Broadcom partner and this is a normal part of a renewal.
FAQ
Is Broadcom auditing VMware customers?
Agreements reserve audit rights, and since 2025 entitlement boundaries have been actively enforced — including cease-and-desist letters over post-expiration patching. Know your own numbers.
What does a VMware licence audit actually check?
Deployed cores against licensed cores with the minimums applied; edition and feature use against the tier licensed; and for perpetual holders, build level against the support expiry date.
What is the most common finding?
Core count drift — hardware refreshes, hosts added during incidents, labs that became production. Almost never deliberate, and per-core licensing makes every populated socket count.
How do I gather the evidence?
vCenter host inventory with sockets, physical cores and build level; every purchase order and entitlement certificate; then reconcile the two cluster by cluster.
What if I find a gap?
Close it as a true-up in a renewal conversation. The same gap found during an audit becomes a compliance finding negotiated from a much worse position.
Does lapsed support create an audit exposure?
Yes, a specific one: perpetual entitlements cover builds you were entitled to while support was current, not updates installed after it expired.
