IBM software audits remain among the most complex audits in the enterprise software market. Between PVU-based licensing, sub-capacity rules that require strict ILMT compliance, virtualization treatment that interacts unpredictably with VMware and AIX, and Passport Advantage records that rarely match deployed reality, an IBM audit can produce claims in the seven figures from a customer that believed itself compliant. This article walks through the audit triggers, the metric mechanics, and the defence strategy.
IBM software audits are dispatched by IBM Audit Services or by a third-party auditor (Deloitte, KPMG, EY are the rotating roster) on a roughly 3–5 year cadence per customer. The triggers are predictable: a Passport Advantage renewal cycle, a hardware refresh that touched a virtualization platform, a material reduction in support spend, or an M&A event that brought new entitlements into scope. Less commonly, a deal that fell through can produce an audit motion within 12–18 months.
In our experience across 340+ engagements, the customers with the highest audit exposure are those running IBM software on VMware or AIX virtualization, those who have lapsed on ILMT reporting for any period inside the 24-month look-back window, and those with material M&A or divestiture activity that hasn't been formally tied off in Passport Advantage records. For those estates, structured IBM software license audit defense begins before the audit letter — validating ILMT history and PVU mapping while the data is still yours to correct.
IBM's processor-value-unit (PVU) metric assigns a per-core multiplier that varies by processor type. The deployed PVU calculation is then compared against entitlements. The first source of compliance gap is processor-type misalignment — IBM's PVU table updates and the customer's deployed processors don't always match what the entitlements assumed.
Sub-capacity licensing — paying only for the cores allocated to the IBM workload, rather than the full hardware — requires continuous IBM License Metric Tool (ILMT) reporting. Any gap in ILMT history during the audit look-back window collapses sub-capacity entitlement to full-capacity, multiplying the deployed PVU count by a material factor. ILMT compliance is the single most common audit-claim driver.
IBM Authorised Sub-Processor (IASP) rules, IFL (Integrated Facility for Linux) on z/OS, and AIX-specific virtualization treatment each carry their own sub-capacity mechanics with their own evidence requirements. The audit team will request specific documentation for each; missing documentation collapses to full-capacity.
The first 30 days set the tone. Independent audit defence, buyer-side.
The first 30 days of an IBM audit are disproportionately important. The audit scope is set, the data request is structured, the evidence approach is negotiated, and the timeline cadence is established — and these decisions shape the eventual claim. Common first-30-day mistakes are accepting an over-broad data request, agreeing to direct ILMT access for the auditor, and conceding scope on infrastructure that should be out of scope under the audit clause.
The defensive first-30-days script: acknowledge the notice in writing, request the audit clause reference and scope definition, push back on any out-of-clause requests, establish a single point of contact, and engage independent counsel before the data exchange begins. The audit team will press for speed; the defence is process discipline.
Full audit defence playbook including IBM-specific tactics.
Independent, buyer-side IBM audit defence. Former IBM auditors on staff. 68% average claim reduction.
Weekly compliance intelligence for IT leaders.