Metric mismatches between entitlement and deployment.
A product can be fully entitled and still fail an audit, if the metric you bought it under is not the metric it is now measured by. The gap is not over deployment, it is a conversion problem. And conversion problems are findings whenever the buyer cannot show the bridge between the two.
What a metric mismatch is
A metric mismatch arises when the basis of your entitlement differs from the basis of the deployment measurement. You hold PVU entitlements but the product has moved to VPC metering. You bought a user based licence but the install is now counted by processor. You own an older edition's metric and the deployed edition is measured differently. In each case the rights may be sufficient, but the two sides are expressed in different units, and the comparison only works once a correct conversion is applied.
Why mismatches accumulate
They are a by product of how IBM estates evolve. Products are repackaged, metrics are revised at version boundaries, and migrations such as the move of metered products to VPC under Passport Advantage v11 change the measurement basis without changing what the customer set out to license. Entitlement records, meanwhile, stay in the units they were purchased in. Years later the entitlement says one thing, the deployment is measured in another, and nobody kept the conversion that ties them together.
How the mismatch becomes a finding
An auditor measures the deployment in its current metric and compares it to entitlements in that same metric. Entitlements expressed in a different unit either get converted with a ratio that may not favour you, or are set aside as not matching, leaving the deployment looking partly unentitled. Either way the gap is scored as a finding. The exposure is manufactured by the conversion, not by any genuine shortfall in rights.
Defending the conversion
The defence is the bridge. For every product where the entitled and deployed metrics differ, you need the documented conversion: the ratio IBM itself publishes for that migration, the part number history showing the original purchase, and the mapping that carries the old entitlement into the new metric. With that bridge in hand, the deployment reconciles against rights you already hold. Without it, you are arguing from memory against an auditor's spreadsheet, and the spreadsheet wins.
Not every gap is over deployment. When entitlement and deployment sit in different metrics, the finding often lives entirely in the conversion. Keep the part number history, use IBM's own published conversion ratios, and build the bridge from old metric to new before the audit. A documented conversion turns an apparent shortfall back into entitled use.
Entitled in one metric, deployed in another?
Our PVU Reconciliation engagement rebuilds the conversion bridge between your purchased metrics and current deployment measurement, using IBM's own ratios and your part number history, so entitled use is not scored as a finding. We mobilize within 48 hours of your audit notice.
See PVU Reconciliation →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.