The deployment data collection tool is the auditor's primary evidence.

In almost every IBM audit, the deployment data collection tool is the single source the auditor trusts most. Understand what it captures, why its output becomes the license position, and how a buyer side team keeps it honest.

When IBM opens an audit, the request that matters most is rarely for contracts. It is for the output of your deployment data collection tool: the IBM License Metric Tool, or an approved equivalent such as Flexera One ITAM or HCL BigFix Inventory. That export becomes the spine of the entire engagement. Whatever it says you have installed is treated as fact until you prove otherwise.

What the tool actually collects

ILMT and its peers scan every server in scope and record the IBM software components they detect, the processor value units allocated to each, and the virtualization layer underneath. The result is a measured deployment count expressed in PVU, RVU, or virtual processor cores depending on the product metric. That count is what the auditor compares against your entitlements.

The tool does three jobs at once: it discovers installs, it sizes the hardware capacity that drives PVU, and it produces the quarterly sub capacity reports that prove you are entitled to license only the virtual cores running IBM software rather than the whole physical host.

Why the output drives the license position

Sub capacity licensing depends entirely on this tool. To license only the virtual cores in use, IBM requires an approved tool deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years. Miss any one of those conditions and IBM defaults to full capacity charging across every physical core in the host. The difference is not small. A WebSphere instance using 4 of 32 host cores is 480 PVU under sub capacity and 3,840 PVU at full capacity.

Because the auditor reads the tool's export as ground truth, an error in the tool becomes an error in your bill. ILMT routinely miscategorizes installs, double counts components, and carries decommissioned machines that no longer exist. Each of those inflates the measured position.

How a buyer side team controls it

• Pull and review the export before IBM sees it, not after. The data leaving your network should be scoped and verified first.
• Reconcile every detected component against a real install. Bundled components counted as standalone products are a frequent over count.
• Confirm the capacity figures match the actual hardware allocation, not the maximum the host could theoretically reach.
• Check that quarterly reports exist, are continuous, and cover the full lookback window the auditor is claiming.

The tool is not neutral. It was built to measure consumption, and left uncorrected it measures more than you owe. Treating its output as a draft to be challenged, rather than a verdict to be accepted, is the difference between a defensible position and an inflated one.