WebSphere Application Server sits near the top of every IBM audit risk list. It is widely deployed, it is licensed by Processor Value Unit, and it runs on exactly the kind of virtualized infrastructure where sub-capacity rules are easy to fall out of. When an audit lands, WebSphere is usually the line item with the most exposure, because a denied sub-capacity claim on it does not add a little to the bill. It multiplies it.
How WebSphere is licensed.
WebSphere is a PVU product. The charge is the PVU per core value for your processor multiplied by the cores allocated to the software. Under sub-capacity, you license only the virtual cores running WebSphere rather than every physical core on the host. The size of that benefit is the whole argument. Take a WebSphere instance using four of a host's thirty two cores. At roughly 70 PVU per Intel core, that is 480 PVU under sub-capacity and 3,840 PVU at full-capacity, an eight fold swing on a single instance. Multiply across a production estate and a lookback and the difference is the audit.
Why the sub-capacity claim gets denied.
IBM denies sub-capacity on WebSphere when it concludes the eligibility conditions were not met. The recurring failure points are:
- An approved tool such as ILMT, Flexera One ITAM or HCL BigFix Inventory was not deployed within 90 days of first eligible WebSphere deployment.
- The tool did not run continuously, leaving scan gaps across the disputed period.
- Quarterly sub-capacity reports were not generated and retained for two years.
- ILMT miscategorized a WebSphere install, for example confusing an edition or counting a bundled component, and the count was never manually corrected.
Notice that none of these is about the capacity you actually ran. They are about whether the record proves it. That distinction is the buyer side opening.
Cells, clusters and bundled components.
WebSphere topology adds its own traps. A cell can span many nodes, and the deployment manager, nodes and application servers all have to be accounted for correctly. Bundled entitlements such as the database that ships with some WebSphere offerings are limited to a defined scope, and using them beyond that scope creates a separate finding. An accurate WebSphere reconciliation maps every node and every bundled component to its entitlement rather than accepting IBM's roll up.
A WebSphere finding is rarely about real over deployment. It is about whether the tooling record proves the virtual core count. The buyer side response is to meet the denial with continuous scan history, retained quarterly reports, deployment dates and corrected classifications. In a representative manufacturing matter spanning WebSphere and Db2, a methodology challenge backed by clean ILMT evidence cut the claim by 71 percent.
The buyer side defense.
Defending WebSphere under audit starts with containing the data request, then running an independent PVU and sub-capacity calculation for every WebSphere instance before IBM finishes theirs. The denial is challenged point by point with the tooling evidence, miscategorized installs are corrected, and any genuine gap is confined to the exact window rather than spread across the lookback. The corrected position and a sub-capacity reinstatement plan are written into the settlement so the same exposure does not return at the next audit.