Every estate carried recoverable shelfware, and the median reclaim sat between 12 and 20 percent of annual IBM spend
Every estate reviewed carried recoverable shelfware, which makes this the rare finding with no exceptions. It hides in three places, and none of them is where a spend review normally looks.
Prepared by Redress Compliance · August 16, 2026 · IBM advisory. 25 to 35 IBM cost reviews, 2024 to 2025.
Executive summary
Every estate reviewed carried recoverable shelfware, with a median reclaim between 12 and 20 percent of annual IBM spend. A finding with no exceptions is worth treating as a starting assumption.
Cloud Pak pools held 15 to 25 percent of VPCs assigned to products the estate had already retired. The pool structure that makes Cloud Pak flexible is the same structure that lets entitlement sit against nothing.
Stale ILMT data forced full capacity billing on 20 to 40 percent of eligible cores. That is not shelfware in the usual sense. It is a discount you hold and cannot evidence, which prices identically.
ELA true ups were calculated on peaks that included short lived spikes nobody challenged, which inflates the renewal base rather than resolving at the true up.
The three places it hides
Shelfware on an IBM estate does not look like unused licences on a shelf. It looks like three specific structural conditions, none of which a conventional spend review surfaces.
| Where | What it looks like | Why a spend review misses it |
|---|---|---|
| Enterprise agreements | Bundled more than the estate deployed | The bundle is one line, so the unused part has no line of its own |
| Cloud Pak pools | VPCs tied to products already retired | The pool total looks fully consumed, because it is |
| Sub capacity gaps | Full capacity billing where ILMT data is stale | It appears as a legitimate charge rather than a recoverable one |
The sub capacity case is the one worth understanding precisely, because it is not really shelfware. You hold the entitlement and you hold the sub capacity right. What you lack is the instrumentation evidence that makes the right claimable, so you are billed at full capacity on 20 to 40 percent of eligible cores. Commercially it is identical to shelfware, in that you are paying for something you are not receiving. Operationally the fix is completely different: it is a data problem with a ninety day lead time rather than a contract problem you can negotiate.
A finding with no exceptions is a starting assumption
Across the IBM cost reviews led, every estate carried recoverable shelfware, and the median reclaim sat between 12 and 20 percent of annual IBM spend. The absence of exceptions is the useful part. Most benchmark findings describe a tendency, and the correct response is to check whether your estate is one of the cases. When a finding holds in every estate reviewed, the correct response is to assume it holds in yours and to go looking, because the base rate is high enough that the search is justified before any evidence is gathered.
The reason it is universal is structural rather than a matter of discipline. IBM entitlement is held in pools and bundles rather than against products, so the connection between what you pay for and what you run is indirect by design. A Cloud Pak pool with VPCs assigned to a retired product still shows as fully consumed, because the pool total is unchanged; only the mapping underneath it has gone stale. An ELA that bundled more than the estate deployed presents as a single line item, so the unused portion never appears as a distinct number anyone could question. Neither condition is visible from a spend report, which is why spend reports do not find them.
The sub capacity gap deserves its own treatment because it is misclassified by almost everyone. Full capacity billing on 20 to 40 percent of eligible cores looks like a legitimate charge, and technically it is. You hold the sub capacity right; you simply cannot evidence it because the ILMT data is stale. The commercial effect is identical to shelfware, and the remedy is not. This one cannot be negotiated, argued, or reclaimed retrospectively in most cases. It has to be fixed operationally, and the clean report that fixes it takes ninety days to produce.
The true up interaction is what makes early action worth more than it appears. ELA true ups calculated on peaks that included short lived spikes nobody challenged do not simply overcharge at that moment; they set the base the renewal prices from. So an unchallenged peak in year two is still being paid for in year five, through a renewal baseline nobody traced back to it. Evidence first, in all three cases, because you cannot reclaim what you cannot see. The vendor posture sits in the IBM vendor management playbook, the instrumentation detail in sub capacity and ILMT, and the wider library in the IBM practice.
- Shelfware priced against real contract terms, not list price
- Entitlement mapped to deployment product by product, not pool by pool
- One click executive reporting on spend, risk, and opportunity
The reclaim sequence
- Start with evidence, because you cannot reclaim what you cannot see. Entitlement, deployment, and the mapping between them, product by product rather than pool by pool.
- Audit Cloud Pak VPC assignment against live products, since 15 to 25 percent of pool capacity sat against products already retired and the pool total gives no hint of it.
- Fix ILMT before it is needed, because full capacity billing on 20 to 40 percent of eligible cores is a data problem with a ninety day lead time rather than a negotiation.
- Challenge true up peaks built from short lived spikes, which otherwise persist into the renewal base and are paid for years after the spike ended.
- Reconcile the ELA bundle against actual deployment, since a bundle presents as one line and the unused portion never surfaces as a number by itself.
- Assume shelfware exists before looking. Every estate reviewed carried it, which makes the search justified without prior evidence.
What the IBM cost reviews showed, 2024 to 2025
Across roughly 25 to 35 IBM cost reviews, every estate carried recoverable shelfware:
Recoverable share of annual IBM spend, found in every estate reviewed without exception.
Eligible cores billed at full capacity because stale ILMT data made a held sub capacity right unclaimable.
Cloud Pak pools held 15 to 25 percent of VPCs assigned to products the estate had already retired, and ELA true ups were calculated on peaks including short lived spikes nobody had challenged, inflating the renewal base rather than resolving at the true up.
All three conditions are invisible in a spend report, because IBM entitlement is held in pools and bundles rather than against products. The connection between what you pay for and what you run is indirect by design.
Your first five moves
- Build the entitlement to deployment mapping product by product, since pool level totals conceal every one of the three conditions.
- Audit Cloud Pak VPC assignment against products still running, expecting 15 to 25 percent to sit against retired ones.
- Tune ILMT and produce a clean report now, because it takes ninety days and full capacity billing continues throughout.
- Trace the current renewal base back to the true up peaks that set it, and challenge any built from short lived spikes.
- Reconcile the ELA bundle against actual deployment. The IBM practice runs the reclaim with you.
Frequently asked questions
How much IBM shelfware is typical?
The median reclaim sat between 12 and 20 percent of annual IBM spend, and every estate reviewed carried some. A finding with no exceptions is worth treating as a starting assumption rather than a hypothesis to test.
Where does IBM shelfware hide?
Three places: enterprise agreements that bundled more than the estate deployed, Cloud Pak pools with VPCs tied to retired products, and sub capacity gaps where missing data forces full capacity billing.
Why do spend reports miss it?
Because IBM entitlement is held in pools and bundles rather than against products. A Cloud Pak pool with stale mapping still shows as fully consumed, and a bundle presents as a single line, so the unused portion never appears as a number.
Is the sub capacity gap really shelfware?
Commercially yes, structurally no. You hold the entitlement and the sub capacity right; you cannot evidence it because ILMT data is stale, so you are billed at full capacity. The effect is identical and the remedy is completely different.
Can full capacity billing be reclaimed retrospectively?
In most cases no. It is a data problem rather than a contract problem, and the clean report that fixes it takes ninety days to produce, during which full capacity billing continues. That is why it is fixed before it is needed.
How much Cloud Pak capacity is misassigned?
Between 15 and 25 percent of VPCs sat against products the estate had already retired. The pool total gives no indication, because the total is unchanged; only the mapping underneath it has gone stale.
Why do true up peaks matter beyond the true up?
Because they set the base the renewal prices from. An unchallenged spike in year two is still being paid for in year five through a renewal baseline nobody traced back to it, which makes challenging it worth far more than the immediate charge.
What is the first move?
Evidence. You cannot reclaim what you cannot see, and all three conditions require a product level mapping of entitlement against deployment rather than the pool level view that hides them.
Should we assume our estate has shelfware?
Yes. Every estate reviewed carried recoverable shelfware, so the base rate justifies the search before any evidence specific to your estate is gathered. Treating it as a hypothesis wastes the time the search would have taken.
Is this a negotiation or an operations exercise?
Both, and they separate cleanly. The ELA bundle reconciliation and the true up peak challenge are commercial. The Cloud Pak remapping and the ILMT fix are operational, and the second of those runs on a ninety day clock you cannot compress.
