Updated September 10, 2026 (originally published in 2019)
IBM ILMT (IBM License Metric Tool) is the tool IBM requires you to run if you want to license eligible IBM software by what you actually use in a virtualized environment (sub-capacity) instead of paying for the full capacity of every server it could touch. If ILMT isn’t installed, scoped, and reporting correctly, IBM can license your environment at full capacity — retroactively.
See exactly what IBM’s ILMT terms require →
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.
Missing reporting evidence can put your eligibility for subcapacity licensing at risk. If the applicable requirements are not met, the affected software may need to be licensed against the full activated physical capacity of the server, rather than the eligible virtual capacity available to it.
Quick answer: IBM ILMT compliance requires more than installing the tool. For eligible subcapacity deployments, you need an eligible environment, correctly configured ILMT or an approved alternative, complete measurement, accurate software classification and the required reporting history. IBM requires audit snapshots at least quarterly, retained for at least two years. Gaps can put subcapacity eligibility at risk and expose the affected software to full-capacity licensing.
What Is PVU Licensing?
Processor Value Units (PVUs) are one of the metrics used to license IBM software. The PVU requirement depends on the processor technology and the number of cores that must be licensed. ILMT also supports other metrics, including Virtual Processor Core (VPC).
Full-capacity licensing generally counts the activated physical processor cores on the relevant server. Eligible subcapacity licensing can use a lower virtual capacity, subject to IBM’s counting rules. It is not a measure of average CPU utilization.
Your reporting needs to substantiate the capacity available to the software over the relevant period. IBM’s subcapacity licensing requirements explain the eligible products, technologies and approved tools.
What could full-capacity exposure look like? Consider an eligible deployment with four virtual cores allocated to IBM software on a server with 32 activated physical cores. If the software must instead be licensed at full capacity, the count could move from four to 32 cores—eight times the license quantity, assuming the same PVU-per-core factor. This is an illustration, not an estimate of your bill. The applicable counting rules, environment, existing entitlements and pricing determine the exposure. See IBM’s explanation of full-capacity and subcapacity licensing.
Not sure your ILMT reporting would hold up today?
Talk to an ILMT expert about your current setup, reporting history and concerns. We’ll discuss what needs a closer look and whether MD360 can help.
Why ILMT Compliance Is Not Optional Once You Have Sub-Capacity Licensing
Subcapacity licensing can reduce the capacity you need to license, but eligibility depends on meeting IBM’s requirements. Those include the relevant products and technologies, approved tooling and reporting evidence.
The commercial risk is a change in the licensing basis: software you licensed at subcapacity may need to be licensed at full capacity if the requirements are not met. IBM explains the reporting and configuration obligations in its licensing tools guide.
An audit is a difficult time to discover that reports are missing or the measured environment is incomplete. Checking the position earlier gives you time to understand the gaps and address them.
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, reviewed and retained. Generate audit snapshots at least quarterly and retain them for at least two years. Before generating a snapshot, check that software and capacity data are complete, imports have succeeded and software classification reflects your licensing documents. Scheduling scans or seeing a current dashboard is not the same as reviewing and retaining the required evidence. Follow IBM’s guidance on preparing and retaining ILMT audit reports.
- Correct topology, not just correct software. ILMT must accurately reflect the virtualization environment underneath the software: hosts, clusters, and how workloads move between them. Incomplete or incorrect virtualization data can distort the reported capacity, even when the tool is running.
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.
Correct software bundling is part of the reporting work
ILMT discovers software components and assigns them to products, but those assignments need to match your licensing documents. A component may be separately licensable or included with another product as a bundled or supporting program, subject to the permitted use. The tool’s initial assignment is not a substitute for checking those rights.
Review the product and metric assignments, correct them where necessary, and confirm the classifications before generating your audit snapshot. Incorrect bundling can overstate or understate the license requirement. It does not mean every classification error automatically removes all subcapacity eligibility. IBM explains how to review and confirm software classifications.
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, and move workloads. If nobody keeps the virtualization data current, reports can overstate or understate the licensing position, and the discrepancy may remain unnoticed until the data is reviewed.
- 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.
Take ILMT maintenance and reporting off your team’s plate
Keeping ILMT installed is only the beginning. MetrixData 360’s ILMT as a Service helps you manage ongoing maintenance and reporting, address compliance gaps, and reduce the burden on your internal team.
See what’s included and how we help you stay prepared for an IBM audit.
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. Without correction, that missing coverage could put the affected deployments’ subcapacity eligibility at risk.
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
Installing ILMT is one step. Maintaining the measurements, classifications, and retained reports is an ongoing responsibility. A current installation does not, by itself, substantiate earlier reporting periods.
A deployment that has not been reviewed since year one has an unverified current position. The next step is to check the environment and evidence, rather than assume either compliance or noncompliance.
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, that means validating ILMT’s scope against actual deployment data, checking the virtualization data and reviewing the available reporting history. Where evidence is missing, investigate what reliable historical data remains and what can be substantiated. Correcting the current deployment does not automatically resolve an earlier gap. Assign ongoing ownership so the next reporting period does not depend on institutional memory.
At MetrixData 360, we start with your existing ILMT setup and records. We compare the reports with your deployments, entitlements and IBM’s requirements, then explain which gaps need investigation, correction or a licensing decision. Our ILMT as a Service support includes recurring reporting and review, with agreed responsibilities for following up on changes and unresolved issues.
Frequently Asked Questions
What is IBM ILMT? IBM License Metric Tool identifies IBM software and measures license metric consumption. For eligible subcapacity deployments, it helps produce evidence of the capacity available to the software and the associated license requirement.
Is ILMT mandatory? IBM requires approved tooling for subcapacity reporting. ILMT is IBM’s standard tool, and specified approved alternatives are also permitted. Your environment must meet the applicable eligibility, measurement and reporting requirements.
What happens if ILMT quarterly reports are missing? Missing reports can put your subcapacity position at risk. Check which periods are affected, what underlying data exists and whether the available evidence supports the applicable requirements. Do not assume that generating a current report resolves historical gaps.
Can I use an alternative to ILMT? Yes. IBM accepts approved alternatives such as BigFix Inventory, provided they are installed and actively tracking sub-capacity eligible products within 90 days of deployment, with the same quarterly reporting and two-year retention requirements as ILMT.
Who is responsible for ILMT compliance after installation? IBM holds the licensee responsible, not the installer. In most of the gaps we find, ILMT was installed correctly and nobody was assigned to own it afterward — the tool kept running, but nobody reviewed the reports or updated the scope as the environment changed.
Check Your Own Exposure
Answer these honestly, without pulling a single file first:
- Do you know whether the required quarterly ILMT snapshots for the past two years—or since your deployment began, if more recent—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?
- Have your product and bundle assignments been checked against your entitlements and permitted use, or are you relying on the tool’s initial classifications?
- If IBM issued an audit letter this week, do you know how many quarters of history you could actually produce?
If any answer is uncertain, your ILMT position deserves a closer look. Uncertainty does not prove noncompliance, but it is a reason to check the evidence before relying on it.
Need help checking your ILMT position?
MetrixData 360 reviews your existing ILMT setup, reporting evidence and software bundling against your deployments and license entitlements. Explore our IBM ILMT services to see how we help identify gaps and decide what needs attention.
Unsure whether your ILMT setup and records support your subcapacity position? Talk to an ILMT expert about what you have today and the next step. You do not need a complete technical inventory to start the conversation.
