An IBM software audit tests your deployment against your entitlement under the Passport Advantage verification clause. This guide sets out what triggers a review, the ILMT evidence IBM examines, how to control scope, and the settlement levers a buyer holds.
An IBM software audit, which IBM calls a licence review or verification, is a contractual exercise in which IBM checks that your deployed software matches the entitlements you have bought. Admodum is an independent, buyer-side software licensing advisory firm, and this page sets out how that review works and how a buyer defends its position. The right to conduct it sits in the International Passport Advantage Agreement, the framework under which most IBM volume licensing is transacted.
Two routes are common. IBM may run the review itself through its own compliance function, or it may appoint a third-party firm such as Deloitte or KPMG under a separate engagement. Either way the obligations are the same: you must cooperate, provide deployment data, and remedy any shortfall the review establishes. The review is not adversarial in form, but its commercial consequences are real, and the buyer who treats it as a routine data request rather than a negotiation usually pays more than it needs to.
This page is part of the IBM sub-capacity licensing pillar. Because almost every expensive audit finding traces back to processor-based metrics, read it alongside the PVU metric explained and ILMT deployment and the 90-day rule.
Audits are rarely random. IBM allocates verification effort where it expects to find a gap, and the signals it reads are largely visible from outside your organisation.
The defensive inference is straightforward: the conditions that trigger an audit are the same conditions a buyer should be self-auditing against in advance. The estate that maintains current ILMT reports and a clean entitlement map removes most of the signals that draw IBM's attention in the first place.
A review is, at bottom, a contest of evidence. IBM compares what is deployed against what is entitled, and the quality of your records determines whether you argue from strength or concession.
For processor-based products the decisive evidence is the ILMT report. To claim sub-capacity, you must show ILMT was installed, discovering the relevant servers, and producing the quarterly sub-capacity reports retained for at least two years. Where those reports exist and reconcile, IBM counts only the virtual cores the software can use. Where they are missing, incomplete, or contradicted by the infrastructure, IBM is entitled to assess at full capacity, counting every physical core in the server or, with unconstrained mobility, the whole cluster.
Alongside ILMT, IBM examines the Proof of Entitlement records that evidence what you bought, the Passport Advantage transaction history, and the actual deployment data gathered for the review. The buyer's task is to ensure these three views agree before IBM reconciles them, because a discrepancy IBM finds first is a discrepancy negotiated on IBM's terms.
The contractual obligation is to provide accurate deployment data, not to surrender control of how that data is gathered. The distinction is where audit defence is won or lost.
When an auditor proposes scripts or tooling, the buyer should review what they collect, run them with its own team where practical, and confirm scope in writing before anything executes. This protects data security and, just as importantly, the accuracy of the result: auditor tooling that over-discovers or misreads virtualisation boundaries produces inflated counts that then have to be argued back down. It is far cheaper to scope the collection correctly once than to dispute an inflated figure afterwards.
A single point of contact, a defined data-room, and a rule that no information leaves the organisation without internal review are the basic hygiene of a controlled review. The wider programme that institutionalises this discipline sits at Audit Defence, and the supporting-program and bundling complexities that frequently inflate a first-pass count are explained in IBM part numbers and bundling traps.
Equally important is controlling the channel through which information flows. A review should run through a single, briefed point of contact, with a rule that no figure, screenshot or export leaves the organisation without internal review, and that informal conversations between engineers and the auditor are routed back through that contact rather than answered on the spot. Auditors are skilled at gathering admissions in passing, and a well-meaning technical answer given without context can become a finding that is hard to retract. The buyer that treats the review as a managed disclosure, deliberate, reviewed and consistent, rather than an open-door cooperation exercise, both protects itself and shortens the process, because a clean, controlled data set is faster to reconcile than a contradictory one assembled from many uncoordinated sources.
An audit finding is an opening position, not a final invoice. Between the draft number and the settled number sit several legitimate levers a buyer should expect to use.
First, contest the count itself. Deployment errors, decommissioned servers still showing as live, non-production environments wrongly scoped, and supporting programs counted as if fully licensable are routine in first-pass findings. Second, net off what you already own. Double-counted entitlements, products entitled under a bundle, and unused capacity elsewhere in the estate reduce the genuine shortfall. Third, fold the remainder into a commercial conversation. IBM would generally rather convert a shortfall into forward business, a renewed or expanded agreement, than litigate a back-licensing claim, which gives a prepared buyer room to trade a clean settlement for better forward pricing.
The settlement is therefore best handled as part of the renewal, not separately from it. Timing the resolution to coincide with an IBM contract negotiation lets the buyer convert compliance pressure into commercial terms rather than simply paying a penalty. The aggregated reading sits at the IBM knowledge hub, the wider engagement at the IBM practice, and to put a senior advisor between you and the auditor, get in touch.
Yes. The IBM International Passport Advantage Agreement contains a verification, or audit, clause that gives IBM the right to verify your compliance with reasonable notice. The review is usually conducted by IBM directly or by an appointed third party such as Deloitte or KPMG, and you are contractually obliged to cooperate, supply deployment data and remedy any shortfall.
Common triggers include a missing or stale ILMT deployment, an expiring Enterprise Licence Agreement, a large hardware refresh or virtualisation change, a merger or acquisition, sharp swings in support renewals, and simply the time elapsed since the last review. IBM also runs scheduled verification cycles, so the absence of any specific trigger is not a guarantee against being selected.
IBM typically examines the current deployment position and recent history. Sub-capacity rules require ILMT reports to be retained for at least two years, so that two-year window is the practical evidentiary period for sub-capacity claims. Where ILMT evidence is absent, IBM will assess the position at full capacity for the period it cannot verify, which is materially more expensive.
The single largest risk is losing sub-capacity entitlement for want of valid ILMT evidence. Without compliant ILMT reports IBM counts every physical core in the server or cluster, not the virtual cores the software uses, which can multiply a finding several-fold. Unconstrained VMware mobility, where a workload can move across a whole cluster, is the most expensive version of this exposure.
You should control the data-gathering process rather than surrender it. Scripts and tooling proposed by an auditor should be reviewed, run by your own team where possible, and their scope confirmed in writing before anything executes. You are obliged to provide accurate deployment data, not to grant unsupervised access, and the distinction protects both data security and the accuracy of the count.
The supporting-program complexity that inflates first-pass findings.
Our white paper sets out the sub-capacity and ILMT model IBM auditors test against, with the evidence checklist a buyer needs before a review opens. A senior Admodum IBM advisor will then stand between you and the auditor. Audit moments route to the Audit Defence programme and renewal moments to the Renewal Programme; the newsletter carries vendor-policy alerts.