IBM software license audits are among the most technically complex in enterprise software — particularly for organisations using PVU-licensed products in virtualised environments. ILMT compliance status is the single biggest determinant of your IBM audit exposure. This guide explains what IBM examines and how to defend your position.
← Back to Software Audit Defense PlaybookIBM conducts software licence audits through its Licence Compliance team, targeting organisations that use IBM middleware, database software, and infrastructure products. IBM's licence audit activity has remained consistently elevated as the company transitions customers from perpetual licences to subscription models. For broader context on software audit defence, see our Software Audit Defense Playbook and What Triggers a Software License Audit.
IBM audits are technically distinctive because of the central role of ILMT (IBM Licence Metric Tool) — a free tool IBM provides that organisations must use to report subcapacity PVU usage. Failure to properly deploy and maintain ILMT eliminates subcapacity rights and can increase IBM licence fees by 2–5x for virtualised environments. ILMT compliance status is the first thing IBM's audit team assesses.
IBM licenses its software products using several different metrics. The most common for enterprise software include:
| Metric | Description | Common Products | Virtualisation Impact |
|---|---|---|---|
| PVU (Processor Value Unit) | Per processor core, weighted by chip type | WebSphere, MQ, DB2, Rational | Subcapacity available with ILMT |
| RVU (Resource Value Unit) | Based on specific resource volumes (users, data) | Sterling, Cognos, SPSS | Metric-dependent |
| Authorised User | Named individual user | Many IBM products | Less virtualisation risk |
| Virtual Processor Core | Per vCPU in cloud/virtual environments | IBM Cloud Pak products | Must be accurately reported |
| Install | Per software installation | Various | Deployment-count based |
PVU-licensed products represent the highest audit risk because they require precise measurement of physical and virtual processor deployments — and because IBM's subcapacity licensing model (which significantly reduces costs in virtualised environments) is only available to organisations using ILMT correctly.
IBM's PVU licensing model works as follows:
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
Consider a server with 4 physical processors (32 cores total) running IBM WebSphere on 4 virtual machines, each assigned 4 vCPUs. Under full capacity, you licence all 32 physical cores × PVU rate. Under subcapacity (with ILMT), you licence only the 16 vCPUs actually assigned × PVU rate — a 50% saving. In practice, subcapacity savings are often much larger, particularly where IBM software runs on a small number of VMs within a large physical cluster. ILMT non-compliance converting subcapacity to full-capacity frequently generates the majority of IBM audit findings.
IBM's subcapacity use rights (permitting PVU subcapacity licensing rather than full-capacity) are conditioned on meeting specific ILMT deployment and reporting requirements. IBM's ILMT requirements include:
IBM's newer Cloud Pak products licensed on Virtual Processor Core (VPC) metric use a different compliance model from traditional PVU products. While ILMT is still relevant for reporting, Cloud Pak licensing is based on declared VPC counts rather than ILMT measurement. Organisations that mix legacy PVU products with Cloud Pak products need to maintain separate compliance processes for each metric type.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
ILMT is deployed on production servers but not on development, test, failover, or disaster recovery environments where IBM software is also installed. IBM's audit scope includes all environments, not just production. Any server where IBM software is installed and ILMT is not reporting creates a full-capacity exposure for that server.
IBM software running on VMware is compliant for subcapacity only if all hosts in a vSphere cluster where the VM could migrate are licensed. If vMotion can move an IBM workload to a host that is not covered in ILMT's scope, IBM treats the entire cluster as full-capacity. This is a frequent finding in VMware environments where IBM software is deployed on a subset of cluster members.
IBM regularly updates the ILMT software catalogue to include new products and updated PVU values. Organisations that haven't updated their ILMT catalogue in 6+ months risk having newly deployed IBM products not correctly catalogued — meaning those products won't appear in ILMT reports, creating undocumented exposure.
IBM's subcapacity rights require continuous ILMT compliance throughout the reporting period. If quarterly ILMT reports are missing for specific periods, IBM treats those periods as full-capacity — even if the underlying deployment was compliant. Reconstructing historical ILMT reports after the fact is generally not accepted by IBM auditors.
ILMT must be correctly configured to communicate with your hypervisor management layer (vCenter for VMware, System Center for Hyper-V, HMC for IBM Power) to accurately map virtual machines to physical hosts. Misconfigured hypervisor connections result in ILMT reporting incorrect PVU counts — typically either under-reporting (creating compliance gaps) or over-reporting (leading to over-purchasing).
IBM licence audits typically follow a 5-stage process:
Received an IBM licence audit notification?
IBM's audit selection is driven by commercial and technical signals similar to other vendors:
The most impactful thing you can do before an IBM audit is conduct a comprehensive ILMT compliance review. Identify any gaps in server coverage, hypervisor configuration issues, missing quarterly reports, and outdated software catalogues. Remediating ILMT gaps before IBM's audit dramatically reduces full-capacity exposure.
Ensure your ILMT system has complete quarterly snapshot history for the audit period (typically 2–3 years). If snapshots are missing, investigate whether the data can be reconstructed from other sources or whether you can demonstrate compliance through alternative documentation. Missing snapshots default to full-capacity in IBM's calculations.
Gather all IBM Proof of Entitlement (PoE) certificates, Passport Advantage order history, and licence agreements. IBM's ELP analysis requires exact entitlement documentation — gaps in your PoE records may cause IBM to undercount your entitlements, increasing the assessed gap.
IBM's full-cluster rule for VMware (that all hosts where a VM could migrate must be licenced) can be contested where VM mobility is restricted through hard affinity rules, DRS configurations, or network segmentation. Document any technical restrictions that limit IBM software VMs to specific hosts within a cluster.
IBM's audit will typically request data covering a 2–3 year period. Systems decommissioned during that period that previously ran IBM software may still appear in IBM's entitlement calculations. Document all decommissioning dates with verifiable evidence to reduce the exposure period for any compliance gaps.
IBM's ELP calculations apply PVU values from the IBM processor value unit reference table. Verify that IBM has applied the correct PVU value for your specific processor model — IBM CPU PVU values vary by chip type and generation, and errors in IBM's favour are not uncommon. Even small per-core PVU miscalculations multiply across large server estates.
IBM's standard audit scope covers 2–3 years. Many IPLA agreements contain provisions limiting IBM's ability to audit beyond a specific look-back period. Review your contract language carefully — if your agreement limits retrospective claims, assert this clearly in your response to IBM's audit scope proposal.
IBM's commercial strategy prioritises migration to IBM Cloud Paks, SaaS products, and Red Hat-based architectures. If you have a credible roadmap for migrating legacy IBM middleware (WebSphere, MQ, DB2) to cloud-native alternatives — whether IBM or non-IBM — use this as leverage to negotiate audit settlements that include future commercial commitments rather than cash penalties.
IBM actively promotes migration to Red Hat OpenShift and IBM Cloud Paks as part of audit settlements. For organisations with genuine IBM modernisation roadmaps, structuring the settlement as a Cloud Pak subscription commitment (replacing legacy perpetual licences) can convert an audit liability into a planned transition with commercial incentives.
IBM licence audit defence requires specialist expertise in ILMT, PVU calculation methodology, IPLA contract interpretation, and IBM commercial strategy. General IT lawyers or procurement teams rarely have sufficient IBM-specific knowledge to defend an IBM audit effectively. See Software Audit Defense Playbook for how to select the right adviser.
ILMT compliance assessment, PVU calculation review, and commercial settlement negotiation — specialist IBM audit defence firms can dramatically reduce your exposure.