An IBM audit letter arrives. The team pulls the ILMT reports to prove sub-capacity licensing held up all along and finds two quarters missing from last year. Nobody remembers why. Someone installed the tool. Someone was supposed to check it.
Under IBM’s own terms, a missing report is not a paperwork problem. It decides whether you pay for the capacity you actually used, or for the full capacity of every server the software could touch.
What Is PVU Licensing?
Processor Value Units (PVU) are IBM’s licensing metric for the products ILMT tracks. They set the number of licenses you need by the type and number of processor cores available to the software, not by a simple per-user or per-device count.
- Under Full Capacity licensing, you license every processor core the software could touch, whether it uses them or not.
- Under Sub-Capacity licensing, you license only the cores you actually assign to the software within its virtual machine, not the physical server’s total capacity. Sub-Capacity almost always costs less, which is exactly why organizations want it. It’s also why IBM grants it only in exchange for proof, via ILMT, of what you actually deployed and consumed.
Not sure your ILMT reporting would hold up today?
Book a meeting with our IBM ILMT team for a focused review of your current deployment, reporting history, and audit-readiness gaps.
Why ILMT Compliance Is Not Optional Once You Have Sub-Capacity Licensing
IBM’s sub-capacity model lets organizations pay for the processing capacity their IBM software actually uses in a virtualized environment, not the full capacity of every physical server it could theoretically run on. That is the entire appeal of sub-capacity terms: it usually costs less.
The tradeoff: sub-capacity pricing is conditional, not automatic. IBM only honors it when you can prove, with ILMT (IBM License Metric Tool) data, exactly what you deployed and what capacity you consumed. Fail to produce that proof, and IBM’s own Passport Advantage terms let it license the environment at full capacity instead, retroactively. That is not a penalty clause hiding in fine print. It is the baseline rule the discount rests on.
Most organizations discover this the way the one above did: at audit time, when the reports that should be there aren’t.
What IBM’s ILMT Terms Actually Require
The requirements are specific, and they are unforgiving of gaps:
- Installation inside 90 days. You must install ILMT (or an approved alternative, such as BigFix Inventory) and have it actively tracking sub-capacity eligible products within 90 days of first deployment. Late installation puts the entire pre-installation period at risk of full-capacity treatment.
- Full scope, not partial scope. You must discover and track every sub-capacity eligible product in the environment, not just the ones someone remembered to configure. IBM treats a product running outside ILMT’s scope as unmanaged.
- Quarterly reports, generated and kept. ILMT must produce a compliance report every quarter, and you must retain those reports for two years. A missed quarter is a gap IBM does not have to fill in your favor.
- Correct topology, not just correct software. ILMT must accurately reflect the virtualization environment underneath the software: hosts, clusters, and how workloads move between them. Get the topology wrong, and the report understates capacity even when the tool is technically “working.”
None of this is unusual or aggressive on IBM’s part — IBM publishes all of it in its own licensing terms. What makes it risky is that it demands continuous operational discipline, not a one-time installation.
Where ILMT Programs Actually Fail
In the IBM engagements we walk into, the tool itself is rarely the problem. The gap is almost always operational:
- Nobody owns it after installation. A team deploys ILMT to pass an initial audit or satisfy a renewal condition, then assigns nobody to review the quarterly reports it generates. The reports exist. Nobody looks at them.
- New deployments outrun the scope. A new VM cluster, a cloud migration, or an acquisition adds sub-capacity eligible software, and nobody adds it to ILMT’s scan scope. The tool keeps reporting correctly on what it knows about, and silently misses what it doesn’t.
- The topology drifts. Virtual environments change constantly: teams add hosts, reorganize clusters, move workloads. If nobody keeps ILMT’s model of that environment current, its reports can understate real consumption — and often nobody notices until IBM’s own audit team does.
- Reports are generated but not retained. The quarterly report ran, but nobody saved it anywhere a second person can find two years later — which, for audit purposes, is close to never running it at all.
What This Looks Like in a Live Engagement
MetrixData 360 currently manages an ongoing ILMT program for a large North American enterprise running IBM software across a multi-thousand-server estate. Partway through a routine reporting cycle, our team surfaced a gap the client didn’t know existed. An acquisition years earlier had brought in an entire environment, complete with its own set of virtualized servers — and nobody had ever added it to ILMT’s scan scope. On paper, the quarterly reports looked clean. In practice, a whole acquired environment was running IBM software with zero sub-capacity visibility behind it.
That is the “new deployments outrun the scope” pattern above, just with real servers behind it. Left alone, it shows up the way most ILMT gaps do: at audit time, as a demand for full-capacity licensing across an environment nobody had been tracking.
Instead, we treated it as a scope-correction problem, not a compliance failure to explain away. Our team validated the current ILMT deployment against the client’s actual environment and identified every asset running outside scope. Then we rolled out ILMT agents across the newly discovered servers. Reporting on that estate now runs on the same regular cadence as the rest of the program — specifically so the process catches the next acquisition or environment change, instead of an auditor catching it.
That is the shape of the work: find what the reports aren’t telling you, close the gap before IBM’s audit team finds it, and put a cadence in place so you catch the next gap early instead of late.
The Reframe: Installing ILMT Is Not the Same as Being Compliant
The instinct is to treat ILMT like a checkbox: install it once and move on. IBM doesn’t evaluate it that way. IBM evaluates whether the reporting history is complete, accurate, and current, going back as far as the audit reaches.
That means ILMT compliance is a standing operational commitment, not a one-time project. A program that was compliant in year one, and that nobody has reviewed since, is not a compliant program — it’s a compliant installation with an unknown number of gaps behind it.
Find out where your ILMT program actually stands. Book a meeting with MD360’s IBM ILMT team and get a clear, evidence-based read on your sub-capacity compliance.
How Organizations Close the Gap
Closing an ILMT gap is a data and governance problem before it is a negotiation problem. That is the same sequence MD360 applies across every vendor: build a defensible position before you need one.
For IBM specifically, that means validating ILMT’s scope against actual deployment data, correcting the topology model, and reconstructing or supplementing any missing reporting history. Then it means putting ongoing ownership in place, so the next quarter’s report doesn’t depend on institutional memory. Organizations that want to handle this continuously, rather than reconstruct it under audit pressure, run it as ILMT as a Service: MD360 manages IBM sub-capacity compliance for you, quarterly compliance packs and audit evidence repository included, without you needing a dedicated in-house ILMT operator.
Check Your Own Exposure
Answer these honestly, without pulling a single file first:
- Do you know, right now, whether your last four ILMT quarterly reports actually exist and are retained somewhere a second person can access?
- If a new virtualized workload went live in the last six months, are you confident it is inside ILMT’s scan scope, or are you assuming it is?
- Could someone other than the person who configured ILMT explain your current topology model and defend it to an auditor?
- If IBM issued an audit letter this week, do you know how many quarters of history you could actually produce?
If any of those produced hesitation, the gap already exists. The only open question is whether you find it before IBM’s audit team does.
