Allocated vs Used Cores: What IBM Actually Charges
Buyers often assume IBM charges for the cores their software actually uses. IBM charges for the cores allocated to the software, regardless of how busy they are. That single distinction explains a large share of unexpected audit findings.
The distinction that drives the bill
IBM's PVU model is a capacity metric, not a utilization metric. The requirement is the per core PVU rating multiplied by the cores made available to the IBM software, not the cores it happened to consume. A lightly used server still owes PVU for every core the software can run on. Runtime utilization, average load, and idle time do not reduce the count.
What allocated means by environment
The cores that count depend on how the software is provisioned. On a physical host with no eligible virtualization, every physical core counts. Under an approved sub-capacity configuration, the count is the virtual cores allocated to the partition running the software. Crucially, on some platforms allocation is charged even when the cores sit idle. IBM on Power LPAR, for example, counts the cores allocated to the partition even when they are not actively used.
- Full-capacity: all physical cores on the host, used or not.
- Sub-capacity: virtual cores allocated to the partition, subject to the approved tool and reporting conditions.
- Allocated and idle: on platforms like Power LPAR, allocated cores count even when idle.
Why this surfaces in audits
Teams size partitions generously to leave headroom, then assume the bill follows actual usage. An auditor counts the allocation. The gap between a partition sized for peak and the entitlement bought for typical load becomes a finding. The defense is rarely to argue about utilization, which IBM does not credit, but to confirm the allocation was measured correctly and that any sub-capacity claim limiting the count to virtual cores is valid and supported by continuous reporting.
Reducing the exposure honestly
Because allocation drives the count, the legitimate levers are allocation discipline and a clean sub-capacity claim. Right sizing partitions to what the workload genuinely needs lowers the allocated core count directly. Maintaining an approved tool with continuous reporting keeps the count at virtual cores rather than the whole host. Both are defensible because they change the measured allocation, not the interpretation of it.
Utilization is not a defense, because IBM never charged on it. An audit counts allocated cores, and on platforms like Power LPAR it counts them even when idle. Defend the number by validating how allocation was measured and whether a valid sub-capacity claim limits the count, then reduce exposure by right sizing allocation rather than arguing about load.