① Journal · IBM · Audit
IBM runs one of the more structured compliance programs in enterprise software, and on the mainframe its audits follow recognizable lines. From the buyer side the activity clusters on four measurement areas. Knowing where IBM looks, and what holds up when it does, is the difference between a routine reconciliation and a full capacity true up.
An IBM audit is a measurement dispute. It is won on data you validated first.
IBM (International Business Machines) audits the mainframe the way it licenses it: by measurement. Almost every IBM compliance question on the platform comes down to whether the data behind your reduced rate position is complete, current, and defensible. For Monthly License Charge (MLC) software, that data is the Sub-Capacity Reporting Tool output that establishes your rolling four hour average, the basis IBM bills sub-capacity against. For PVU licensed software, including Linux on IBM Z and distributed products, it is the IBM License Metric Tool (ILMT) snapshot that entitles you to pay for assigned rather than full physical capacity. For International Program License Agreement (IPLA) one time charge products, it is entitlement against the capacity where the product is deployed. And for specialty engine offload, it is whether work claimed as zIIP eligible genuinely qualifies. None of these is exotic, and all of them are checkable, which is exactly why IBM checks them.
The pattern we commonly observe is not aggression for its own sake but a methodical test of your records against your deployment. Where the records are clean the audit resolves quickly. Where they are not, the financial exposure is large, because the fallback positions all run in IBM's favor: missing or incomplete ILMT data can revert PVU products to full capacity pricing for the period in question, and an SCRT position you cannot independently defend gets reconciled on IBM's reading of the peaks. The buyers who come through an IBM audit without a surprise are the ones who validated their own SCRT and ILMT data before the notice arrived and answered every request from their own evidence rather than reconstructing it under deadline. Read this with why audits are rising again and the IBM publisher hub.
Where IBM mainframe audits cluster · what we commonly observe and the buyer defense
| Focus area | What IBM checks | Buyer defense |
|---|---|---|
| Sub-capacity SCRT | R4HA peaks and SCRT completeness for MLC software | Validate SCRT independently, retain reports, explain peaks |
| ILMT for PVU | ILMT deployed and reporting for Linux on Z and distributed | Keep ILMT current, quarterly snapshots, two years retained |
| IPLA entitlement | One time charge products against deployed capacity | Reconcile entitlement to deployment, document decommissions |
| zIIP eligibility | Whether offloaded work genuinely qualifies as zIIP eligible | Confirm eligibility per workload, keep offload evidence |
These are patterns we commonly observe across IBM mainframe audits, not statements of IBM audit policy. Your specific entitlements, license agreements, and measurement obligations govern; validate against your own SCRT and ILMT data and your contract before relying on any position.
The audit is decided by the data, and the buyer who validates that data first controls the discussion. Run your own SCRT and ILMT validation before sharing anything, reconcile it against deployment, and resolve discrepancies internally rather than discovering them in IBM's report. Data you have checked is data you can defend. Data you hand over unexamined is data IBM reads for you.
Check your own numbers before the auditor does.
For PVU licensed software the reduced rate depends on ILMT running correctly and producing quarterly snapshots, with the reports retained as evidence. A lapsed or incomplete ILMT environment is the single most expensive gap in an IBM audit because it can revert affected products to full capacity pricing for the period. Treat ILMT as continuous infrastructure, not a tool you stand up when the notice lands. See our explainer on soft capping and defined capacity.
ILMT is the gate. Keep it open continuously.
An audit expands to fill the data you volunteer. Scope it to the entitlements actually in question, answer every measurement request in writing, and avoid offering data outside that scope. Mobilize in the first days, because the early framing sets the tone for the entire process. A disciplined, documented response turns an IBM audit into a reconciliation rather than an open ended investigation. See our guide to the buyer response protocol.
Scope it tight, answer it in writing, mobilize early.
④ Where the IBM audit is won
An IBM audit tests your records against your deployment. The defense is data you validated first. Check SCRT and ILMT, keep the gate open, scope it tight.
Mobilization on an audit notice
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
Four areas: sub-capacity reporting through SCRT for MLC software on the rolling four hour average, ILMT deployment for PVU licensed software including Linux on IBM Z, IPLA one time charge entitlement against deployed capacity, and zIIP specialty engine eligibility. The common thread is measurement, whether the data behind your reduced rate position is complete and current.
For PVU licensed software, sub-capacity entitlement typically depends on running ILMT and producing quarterly snapshots. If ILMT is not deployed or reporting correctly, IBM can revert affected products to full capacity pricing for the period in question, which frequently multiplies the liability. Keeping ILMT current and retaining two years of reports is the standard defense.
Treat it as a structured process. Validate your own SCRT and ILMT data before sharing anything, answer every measurement request in writing, scope the audit to the entitlements in question, and avoid volunteering data outside that scope. A defensible sub-capacity position turns the audit into a reconciliation rather than a full capacity true up. See the audit clause you signed and forgot.
We validate your SCRT and ILMT position independently, scope the audit, and manage the response from the buyer side so the reconciliation runs on your evidence. Our audit defense service mobilizes within 48 hours of a notice and our IBM MSU optimization service reduces the measured profile the audit and the next renewal both build on.
Related: IBM publisher hub · why audits are rising again · IBM contract traps · audit defense · IBM MSU optimization
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →