ILMT in IBM Audits: Why It Matters and How to Use It for Compliance

ILMT in IBM Audits

Introduction
IBM’s License Metric Tool (ILMT) is central to any IBM software audit. This tool determines whether you can license IBM software at sub-capacity (only for the portion of server capacity you actually use) or if IBM will charge for the full capacity of the hardware.

In other words, ILMT can be the difference between paying for eight virtual cores versus an entire 32-core server.

For organizations running IBM software on virtualized infrastructure, ILMT is not just another software asset management tool – it’s a critical compliance requirement.

In an IBM audit, ILMT often becomes the focal point. Proper use of ILMT can defend your compliance position and significantly reduce potential findings.

On the other hand, failing to deploy or maintain ILMT gives IBM the upper hand in assuming worst-case licensing consumption. For a comprehensive overview, read our ultimate guide, “IBM Software Audit: Process, Triggers, ILMT Compliance, and Negotiation Strategies.”

This guide dives into ILMT’s role in IBM audits, the compliance rules you must follow, common pitfalls to avoid, and strategies to leverage ILMT data to protect your organization.

What is ILMT and Why It Matters in Audits

ILMT (IBM License Metric Tool) is IBM’s mandated software for monitoring license usage in virtualized environments. It automatically tracks where IBM software is installed and how many processor cores (Processor Value Units, or PVUs) are being used.

The reason it matters so much is simple: IBM allows sub-capacity licensing only if ILMT is in place. Sub-capacity means you only need to license the portion of a server’s capacity that an IBM product actually uses (for example, a single virtual machine), instead of the entire physical server. This can dramatically reduce your license needs if you qualify.

Without ILMT, IBM’s default assumption in an audit is that full-capacity licensing applies. That means if ILMT isn’t deployed and correctly reporting, IBM will treat every installed IBM product as if it’s using all available cores of the host hardware. This often leads to vastly higher license requirements (and costs).

In essence, ILMT is both a compliance tool and your primary audit defense mechanism: it provides the data to prove you’ve been consuming only what you’ve licensed. Failing to use ILMT is considered non-compliance with IBM’s terms, providing auditors with an opportunity to calculate your obligations in the most punitive manner possible.

Read how to prepare, Preparing for an IBM Audit: A Complete Readiness Guide.

IBM’s ILMT Compliance Rules

IBM has strict rules for ILMT usage to maintain eligibility for sub-capacity licensing. First and foremost, ILMT must be installed and running on all servers that host IBM software under sub-capacity terms.

You typically have a grace period (e.g., 90 days from deploying an IBM product in a virtualized environment) to get ILMT up and running. Still, it’s expected to continue. The tool should be configured to scan and collect usage data on a regular basis.

Quarterly reporting is mandatory.

IBM requires that you generate an ILMT audit snapshot at least once every quarter. These ILMT reports show your peak PVU usage for each IBM product on each server or VM. Simply having ILMT running isn’t enough; you need to produce the reports on schedule. Equally important, you must archive these reports for at least two years.

In an audit, IBM will request historical ILMT data (they want to verify that you were compliant over time, not just at the time of the audit). If you cannot produce the last 2+ years of quarterly ILMT reports, it’s considered a breach of IBM’s sub-capacity requirements.

Another key rule is keeping ILMT up to date. IBM updates the ILMT tool and its catalog (which includes product identifiers and PVU values for new processors) periodically. Using an outdated ILMT version or failing to update the PVU tables can be viewed as non-compliance. You’re expected to apply ILMT updates so that the tool accurately reflects IBM’s current hardware classifications and recognizes all IBM products.

Essentially, IBM’s ILMT compliance rules boil down to deploying it everywhere it’s needed, running it continuously, creating and saving quarterly ILMT reports, and maintaining the tool properly.

Missing any of these can expose you to significant audit risk – IBM may revoke your sub-capacity rights and retroactively charge you at full capacity for periods where ILMT compliance was lacking.

How ILMT Data is Used in IBM Audits

During an IBM audit, one of the first things auditors request is your ILMT data output. Typically, you’ll be asked to provide the latest ILMT report or snapshot (and often several historical reports).

This data is effectively the cornerstone of IBM’s audit calculations for any sub-capacity eligible software. The ILMT reports list the peak usage of each IBM product (in PVUs or other metrics) on each server or cluster, which IBM then reconciles against your purchased entitlements.

IBM’s auditors will compare ILMT’s measured usage to your license entitlements if ILMT shows that at peak, you were using 1,000 PVUs of WebSphere, but you only own 700 PVUs; that 300 PVU shortfall becomes a compliance finding with a price tag.

Conversely, if ILMT data shows usage within your entitlements, it serves as a strong defense, proving you were properly licensed (at least for the products ILMT covers).

The accuracy of ILMT data is therefore critical. Incorrect ILMT configurations or mappings can lead to inflated findings. For example, if ILMT misidentifies a product or counts a server twice due to an agent error, it might report more PVUs than you actually used.

If you haven’t caught and corrected that ahead of time, IBM will likely use the raw ILMT output at face value, potentially overstating your usage.

It’s important to realize that ILMT data can be a double-edged sword. Good data can save you, but bad data can hurt you. IBM will scrutinize whether ILMT was deployed everywhere it should be. If ILMT didn’t monitor some servers, the auditors might assume that those servers were running IBM software at full capacity with no oversight.

They will also check the timestamps of reports – gaps in reporting (e.g, missing a quarter) raise red flags.

Essentially, IBM leverages ILMT as an audit tool: any deviation from the expected ILMT compliance practice is used to question your license compliance. As the audited party, you should also use ILMT as your tool – ensure the data is accurate and complete, so you can confidently defend against any claims.

It’s wise to do your own reconciliation before IBM does: check your ILMT figures against what you know you’ve purchased, so there are no surprises.

For more indicators, read Common Compliance Risks in IBM Audits (and How to Avoid Them).

Common ILMT Audit Pitfalls

Even organizations that have implemented ILMT can encounter pitfalls that undermine their compliance position.

Here are some common ILMT audit pitfalls and how they can hurt you:

• Not covering all relevant servers: A frequent mistake is failing to deploy ILMT agents on every virtualized server or partition where IBM software is running. If certain VM hosts or clusters aren’t monitored, any IBM software there isn’t being tracked. In an audit, IBM can declare those unmonitored servers out of sub-capacity compliance and calculate licensing at full capacity. For you, that means a huge unexpected license gap simply because a server was left outside ILMT’s scope. Always ensure ILMT covers all environments where it’s required – including dev/test or DR servers if they contain IBM products (unless your contract explicitly exempts them).
• Missing historical reports: It’s not enough to install ILMT; you have to regularly generate and save the reports. Many companies get caught off guard by an audit because they don’t have the last several quarters of ILMT data readily available. If you can’t produce a report from, say, two quarters ago, IBM might assume during that period you were non-compliant. The auditors can choose to retroactively assess full-capacity licensing for that timeframe. Missing reports effectively forfeit the sub-capacity protections for the gap period. The pitfall here is often procedural – perhaps someone forgot to archive a report or ILMT wasn’t running for a time. The compliance impact is severe relative to such a simple oversight.
• Outdated ILMT version or PVU table: Using an outdated version of ILMT or failing to update its PVU classification tables is another common issue. An old ILMT may not recognize a new processor model or a new IBM product, resulting in inaccurate calculations. If your ILMT hasn’t been updated, IBM may claim you weren’t following their requirements (since staying on current versions is part of compliance). More practically, an outdated PVU table might undercount your usage on newer hardware – and if IBM recalculates with the correct PVU values, you could suddenly be over your entitlement. Always keep ILMT patched to the latest version and update its catalogs when IBM releases new ones.
• Misconfiguration and product mapping errors: ILMT requires proper setup and sometimes manual configuration (for instance, bundling or excluding certain products, or confirming software components). If ILMT isn’t tuned right, it might either miss some installations or count things incorrectly. A common example is misidentified software: ILMT might report an “unknown” product or misclassify a component, which can result in that usage not being tied to a license you own. IBM’s audit team will not generously interpret unknown entries in your favor – they may assume it’s something licensable that you didn’t account for. Similarly, if ILMT hasn’t been configured to merge duplicate entries (maybe the same server reported twice due to a hostname change), you might get double-counted. These pitfalls underscore the need to routinely audit your own ILMT data for accuracy and consistency. Make sure all your IBM products are properly recognized and mapped to the correct licenses in the tool.

Being aware of these common ILMT pitfalls allows you to address them proactively. Regular internal audits of ILMT, thorough agent deployment, and disciplined report archiving go a long way in preventing nasty surprises when IBM’s audit letter arrives.

ILMT vs SCRT: Distributed vs Mainframe

IBM environments come in two flavors: distributed (think Windows, Linux, UNIX servers) and mainframe (IBM z Systems). ILMT is the tool for distributed environments, but IBM’s mainframe licensing uses a different mechanism called SCRT (Sub-Capacity Reporting Tool).

It’s important not to confuse the two, especially in audits – each serves a specific domain, and you need both if your organization runs IBM software on both types of systems.

To clarify the differences and roles of ILMT and SCRT, here’s a quick comparison:

In summary, ILMT and SCRT are parallel tools for two different worlds. They are not interchangeable. If you only use IBM Passport Advantage software on distributed servers, ILMT is your key to compliance.

If you also have IBM mainframe software, you must follow SCRT reporting for that environment.

Neglecting either one where it’s required will lead to compliance issues. IBM auditors for distributed products will expect ILMT data, whereas IBM’s mainframe team will insist on SCRT reports. Make sure your software asset management strategy covers both, as applicable, so you’re not blindsided in an audit.

Case Example – ILMT Missing Reports

Consider a cautionary example that illustrates the importance of ILMT. An enterprise had several IBM WebSphere instances running on virtual servers and assumed everything was fine because ILMT was installed.

However, they neglected to archive their quarterly ILMT reports; they only had the most recent data. When IBM launched an audit, they asked for ILMT reports from the past two years. The company was unable to produce reports for multiple past quarters, essentially leaving no proof that it complied during those periods.

IBM’s response was to assume full-capacity licensing for the periods with missing ILMT data. In practice, this meant IBM calculated WebSphere PVU usage as if each server were using all its cores for the entire time where records were absent.

The result was a shock: the company’s calculated license exposure was roughly three times higher than its actual needs, simply because it lacked historical ILMT evidence. IBM billed them for that difference, an expense that could have been avoided.

The lesson from this scenario is clear – always generate and save your ILMT quarterly reports.

Treat those reports as critical compliance documents. In an audit, they are your only proof of historical sub-capacity usage. Without them, you have no defense against IBM defaulting to full-capacity charges.

Checklist – ILMT Audit Readiness

To avoid unpleasant surprises in an IBM audit, use the following ILMT audit readiness checklist to ensure your organization stays compliant and prepared:

☐ ILMT deployed on all required servers: Verify every server or VM with sub-capacity eligible IBM software has the ILMT agent installed and reporting. No eligible environment should be left unmonitored.

☐ Quarterly ILMT reports generated and archived: Schedule ILMT to produce audit snapshots every quarter. Archive each report (in a safe repository outside the ILMT server) for at least two years. This provides an audit trail that IBM can review.

☐ PVU tables and ILMT version updated: Keep ILMT’s PVU taxonomy and software catalog up to date by applying IBM’s updates. Also, upgrade the ILMT software itself to the latest version. This ensures that new processors and products are correctly recognized and accounted for.

☐ Reports validated against entitlements: After each quarterly report, compare the usage data with your license entitlements. Reconcile any discrepancies proactively. If ILMT shows more usage than you have purchased, investigate and address it before IBM does.

☐ Document any exceptions or manual adjustments: If any servers are exempt (per contract) from ILMT or any manual calculations are used (for example, in rare cases where ILMT doesn’t support an environment), document those clearly. You should have a record explaining any IBM software installations not tracked by ILMT.

☐ Governance process in place: Establish cross-functional oversight for ILMT. Have IT operations, asset management, and procurement/legal review ILMT reports together every quarter. A governance process ensures the data is trustworthy and signed off, and it readies you to present unified, verified information to IBM during an audit.

By following this checklist, you can be confident that your ILMT implementation will withstand audit scrutiny and that you are fully leveraging the tool to maintain compliance.

FAQs — ILMT in IBM Audits

Q: Does ILMT prevent IBM from auditing?
No. Having ILMT in place doesn’t stop IBM from exercising its audit rights. What ILMT does is reduce your risk and exposure during an audit. When ILMT is properly deployed and maintained, it demonstrates that you’re managing your IBM licenses diligently. This can discourage IBM from digging too hard for issues, but it absolutely does not eliminate IBM’s ability to audit your environment.

Q: What happens if ILMT isn’t deployed?
If you choose not to deploy ILMT (and you’re using virtualization or any sub-capacity licensing), IBM will treat that as a compliance breach. In an audit, IBM will assume full-capacity licensing for all relevant products. Essentially, you lose the right to pay for only what you use. This often means IBM will calculate your license requirement as if every server is fully utilized, which can dramatically increase your costs. In short, not using ILMT virtually guarantees a significant compliance gap when audited.

Q: How often must ILMT reports be submitted or prepared?
IBM’s sub-capacity rules require that ILMT generate reports at least quarterly. You don’t necessarily “submit” them to IBM regularly (unless IBM specifically asks, which is usually during an audit or if you’re in an IBM compliance program). Still, you must have them available upon request. You must retain those quarterly reports for a minimum of two years. Therefore, every quarter, run the ILMT audit snapshot and store the output safely. If IBM audits you, they will likely request up to two years of history to ensure you have been continuously compliant.

Q: Can third-party tools replace ILMT for IBM compliance?
Generally, no, not by default. IBM will only recognize ILMT or an IBM-approved equivalent for sub-capacity license tracking. While there are third-party SAM tools (Flexera, Snow, etc.) that can track IBM licenses, IBM typically requires a formal agreement or certification for those to count. In most cases, unless you have a written agreement from IBM allowing an alternative, you are expected to use ILMT. Relying solely on an unapproved tool is risky; IBM’s auditor can simply disregard that data and insist on full-capacity licensing if ILMT data isn’t provided.

Q: Do non-production systems need ILMT coverage?
Yes, unless your contract explicitly says otherwise. IBM’s standard rules don’t care whether a server is production, development, or test – if it’s running an IBM product under sub-capacity terms, it should be monitored by ILMT. Some clients negotiate exceptions for certain environments (for example, disaster recovery or cold backups) in their contracts. Barring such written exceptions, assume every instance of an IBM program in a virtualized setting must be reported via ILMT. Auditors have caught companies who ignored dev/test environments, resulting in compliance findings because those were untracked.

Q: Can ILMT errors be corrected during an audit?
Technically, yes – if you discover an ILMT configuration error or missing data during the audit, you can fix it and present an updated report or explanation to IBM. However, be aware that IBM auditors tend to be skeptical of fixes made mid-audit. If, for example, ILMT initially showed 1,000 PVUs used and after you tweak it, now it shows 800 PVUs, IBM may question the change. They might investigate whether you had misconfigured ILMT (which is your responsibility) or if you’re trying to manipulate the outcome. It’s far better to have ILMT accurate before the audit starts. While you can and should correct genuine mistakes (and provide evidence for why the initial data was wrong), expect pushback from IBM. They often favor the first set of data they receive, unless you have a very solid case for the revision.

Q: Is ILMT required for all IBM products and licenses?
No, ILMT is specifically required for IBM products that are eligible for sub-capacity licensing (primarily those licensed by PVU, Virtual Processor Core, or similar metrics on distributed systems). If an IBM product is licensed by user, by install, or if you’re always licensing it at full capacity, ILMT might not apply. For example, if you run IBM software on a dedicated server without virtualization (full capacity), you don’t need ILMT for that scenario. However, many IBM software licenses in enterprise use are PVU-based and benefit from sub-capacity. For any such product, ILMT is effectively mandatory. In practice, most IBM Passport Advantage software running on modern server infrastructure will fall under ILMT’s domain. Always check IBM’s licensing terms for each product – if sub-capacity is an option, assume ILMT needs to be in place.

Q: Can ILMT data help negotiate audit findings?
Absolutely. ILMT data, when properly maintained, is one of your strongest negotiation tools in an IBM audit. If IBM’s initial findings are based on assumptions or worst-case scenarios, you can counter with concrete ILMT reports that show the real usage. For instance, if an auditor claims you owe licenses for 500 PVUs on a server but your ILMT report shows the peak was only 300 PVUs, you can push back and have them revise the claim. Clean ILMT history also shows that you’ve been diligent, which can make IBM more amenable to a settlement. It’s hard for IBM to argue against its own accepted tool’s data. In cases where you do have a shortfall, having accurate ILMT records may help in negotiating penalties down or obtaining concessions, as it demonstrates a good-faith effort. In summary, reliable ILMT data gives you the leverage to challenge inflated numbers and ensure that any audit resolution is based on facts, not fear.

Q: Is ILMT free to use, or does it cost extra?
IBM provides ILMT at no additional license cost. It’s a free tool available to IBM customers precisely because IBM wants it to be widely used for compliance. You can download and install ILMT without needing to purchase it. That said, while the software is free, there are indirect costs to consider: you need infrastructure (such as a server to run ILMT and database storage) and resources (including administration and maintenance effort) to use it effectively. IBM does offer ILMT as part of its BigFix suite, but even if you don’t use BigFix for anything else, the ILMT component doesn’t require a paid license. In short, cost should not be a barrier – the real investment is time and diligence in managing the tool.

Q: Does ILMT automatically send data to IBM?
No, ILMT does not automatically transmit your usage data to IBM. The data collected by ILMT stays within your control on your servers. IBM only sees ILMT data when you choose to share it (or are required to do so). Typically, this means providing ILMT reports during an audit, or possibly during a true-up or contract renewal if requested. By default, ILMT isn’t a “phone home” tool; it’s running for your benefit to measure usage internally. This is why IBM places the onus on customers to run and preserve the reports. You remain responsible for producing the data when needed. So, you can be assured that just installing ILMT won’t result in IBM automatically monitoring your deployment – it’s not a pipeline back to IBM. However, if you’re found without ILMT data in an audit, then you’re at IBM’s mercy regarding how your usage is calculated. It’s always better to have ILMT and control the narrative with your own data than to have IBM assume the worst.

Five Recommendations — Using ILMT in Audits

1. Treat ILMT as Mandatory – Never assume IBM will overlook the absence or improper use of ILMT. If you use any sub-capacity licensing, deploy ILMT across all those environments as a non-negotiable policy. Treat it as part of the installation checklist for any new IBM software instance on a virtual server.
2. Validate and Archive Quarterly Reports – Don’t just generate ILMT reports; actually review them and back them up. Each quarter, verify the report for accuracy (do the numbers make sense given your environment?) and then archive it in a secure location. Keep at least two years of reports. Missing data is IBM’s biggest audit weapon – don’t hand it to them.
3. Align ILMT Data with Entitlements – Regularly reconcile ILMT findings with your purchase records. Before IBM ever audits you, you should know if ILMT is reporting usage beyond what you own. If you find discrepancies (e.g., ILMT shows 100 PVUs in excess of your entitlement), investigate and resolve them proactively. This may involve purchasing additional licenses, reallocating resources, or adjusting ILMT’s configuration. It’s far better to catch and fix issues yourself than to have IBM identify and correct them.
4. Involve IT, Procurement, and Legal in ILMT Governance – ILMT shouldn’t be solely an IT operations tool running in a silo. Establish a governance team or process that includes IT (who deploys and maintains ILMT), Procurement or SAM managers (who understand entitlements and financial impact), and Legal or Contract managers (who grasp the compliance terms). This cross-functional team should periodically review ILMT reports together to ensure consistency and accuracy. They can ensure the data is accurate, the entitlements match up, and any potential compliance issues are addressed with a unified strategy. Having this oversight also means if an audit happens, your internal stakeholders are all on the same page with ILMT data and its implications.
5. Leverage ILMT Data as a Negotiation Tool – In any audit or license discussion with IBM, use your ILMT data to your advantage. Well-maintained ILMT reports are hard evidence. If an auditor’s claim seems inflated, present the ILMT report that disputes it. If IBM’s initial findings assume full capacity, counter with ILMT’s sub-capacity figures. Demonstrating a handle on your usage through ILMT can also lend credibility, which is beneficial in negotiations. IBM is less likely to impose exorbitant penalties if you can demonstrate control and provide clear proof of your actual usage. In short, let ILMT data do the talking – it can turn a potentially contentious audit into a more straightforward reconciliation based on facts.

By treating ILMT as a core part of your IBM license management strategy and following these recommendations, you’ll not only minimize compliance risks but also empower your organization to face IBM audits with confidence and leverage, rather than fear.

Read about our IBM Audit Defense Service.

Do you want to know more about our IBM Audit Defense Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit