A retailer running discovery across stores and cloud opened a renewal and found the CMDB-driven line had climbed almost a third since the last cycle, with nobody having signed off on a single purchase. Discovery had simply done its job: new tills, new cloud resources, new relationships, all dutifully counted as managed entities and billed. When the team actually reconciled the records, a meaningful share were stale, duplicated or pointing at decommissioned kit. The cost had grown not because the estate grew that much, but because the meter ran unchecked and the contract had no cap. That is the CMDB cost-control problem in one sentence.
Why does CI-based pricing inflate over time?
Because the unit that drives the bill, the configuration item or managed entity, multiplies automatically as discovery runs. Every device, virtual machine, cloud resource and relationship can become a billable unit, and a healthy discovery practice generates them constantly. The result is that a CI-priced contract drifts upward between renewals with no buying decision behind the increase. The growth is real, but a large part of it is records you do not need to be paying to manage. The wider mechanics sit in our buyer guide to ITAM and discovery costs inside ITSM contracts.
Book a license optimization review →What actually counts as a billable CI?
This is the question that decides the bill, and it is usually under-examined. Vendors differ on what counts: every discovered CI, only certain classes, managed entities, or discovery subscription units. The same physical estate can produce very different counts depending on the definition. So the first move is to pin the definition in the contract, because an unfixed definition lets the count creep without any change to the published rate. The way CI counts quietly drive cost is covered in detail in how CMDB CI counts drive hidden ITSM cost.
How do you cap CI-based pricing at renewal?
| Step | What it removes | The lever |
|---|---|---|
| Reconcile billed vs managed | Stale, duplicate and decommissioned records | Bill only the CIs you actively manage |
| Fix the unit definition | Ambiguity that lets the count creep | Written definition of a billable CI in the contract |
| Move to a banded model | Open-ended per-unit growth | Price bands with known thresholds, not pure per-CI |
| Cap the annual increase | Compounding drift between renewals | Capped uplift on the CI line specifically |
| Set a re-baseline right | Paying for a one-time discovery spike | Right to re-baseline after estate cleanup |
Should you pay per CI or buy a band?
For a growing estate, a banded or capped model usually beats pure per-unit pricing, because it makes cost predictable and removes the vendor's incentive to encourage broad discovery. Per-unit pricing rewards the vendor every time your discovery footprint expands, which is not an interest aligned with yours. A band with known thresholds lets you plan, and a cap stops the line compounding. Confirm the band thresholds against your real growth rate rather than the vendor's, because a band set too low is just per-unit pricing with extra steps.
- Clean before you count. Remove stale and duplicate CIs so the baseline reflects reality.
- Reconcile to managed, not discovered. Pay for what you actively manage, not everything the scanner finds.
- Fix the definition. Write the billable-unit definition into the contract.
- Choose the model deliberately. Band or cap for a growing estate; per-unit only if growth is flat.
- Cap the uplift. Stop the line from compounding between cycles.
Our gated ITSM License Optimization Field Guide includes the CI reconciliation worksheet and the banded-pricing model that keep CMDB cost predictable.
How much does CMDB cost control return?
It varies by how clean your CMDB is and how the contract counts, so confirm against your own order form. The reliable point from more than 500 ITSM engagements, where we average a 30% reduction, is that the savings on CI-priced lines come from two moves stacked together: cleaning the record set so you stop paying for ghosts, and changing the model so growth is capped rather than open-ended. A discount on an uncapped per-CI line is undone by the next discovery run.
What to do next
Reconcile your billed CI count against actively managed CIs, clean the stale records, and decide on a banded or capped model before the renewal. We run the reconciliation and the renewal through our license optimization service on fixed fee or gainshare.
Frequently asked questions
- Why does CI-based pricing inflate?
- Because CI and managed-entity counts grow automatically as discovery runs. New devices, cloud resources and relationships add billable units, so the contract drifts upward between renewals without any buying decision.
- How do you cap it?
- Reconcile billed units to actively managed CIs, strip stale and duplicate records, fix the billable-unit definition in the contract, and move to a banded or capped model so growth is predictable.
- Per CI or a band?
- For a growing estate a banded or capped model usually wins, because it makes cost predictable and removes the incentive to over-discover. Confirm the band thresholds against your real growth rate.
Cap the CMDB meter.
We clean the record set, reconcile billed CIs to managed reality, and move you to a capped model that holds. Fixed fee or gainshare.
Book a license optimization review →