Why ILMT miscategorizes installs and how to correct it.

ILMT does not always know what it is looking at. Misread bundles, wrong part numbers, and unassigned components quietly inflate your PVU count. Here is why it happens and how to fix it before an audit reads it as fact.

The IBM License Metric Tool is treated as the authority on what you have deployed, but it is a signature matching engine, and signatures are imperfect. It regularly identifies the wrong product, counts a bundled component as a standalone license, or leaves a discovered install unassigned. Each mistake pushes your measured position above what you actually owe.

Why the tool gets it wrong

Shared signatures. Many IBM products share files and libraries. A component that ships inside a larger entitlement can match the signature of the standalone product and be counted twice.

Bundled engines. A Db2 engine bundled inside Cognos or another product is licensed under the parent, but ILMT may detect it as a separate Db2 deployment and add its full PVU to the count.

Wrong part number assignment. ILMT maps installs to catalog part numbers. When the mapping is wrong or missing, the install is sized against the wrong metric or sits in an unassigned bucket the auditor reads as unlicensed.

Version drift. New releases and fix packs can change how a product is detected, leaving older categorizations stale.

The correction workflow

• Export the raw discovery and list every detected component against the host it sits on.
• Separate genuine standalone installs from bundled components that belong to a parent entitlement.
• Reassign each component to the correct part number so it is sized under the right metric.
• Bundle or suppress components that are not separately licensable, with a written rationale for each change.
• Regenerate the report and confirm the corrected PVU count reconciles to real deployments.

Document every change

Corrections are only as strong as the evidence behind them. For each reassignment, record what the component is, why it was miscategorized, and the entitlement it actually falls under. When the auditor questions a correction, that written trail is what holds the lower number in place. An undocumented correction looks like manipulation; a documented one is simply accurate accounting.

Done before the export leaves your network, this work moves the position quietly. Done after IBM has the raw data, the same corrections become a dispute you argue under deadline.