This sits under our buyer guide to ITAM and discovery costs inside ITSM contracts. The CI count is the quietest cost driver in the category: nobody negotiates it at signing because it looks like a technical metric, and by the time it shows up as a charge the discovery engine has already set the number for you.
Why does the CI count grow without anyone touching it?
Discovery tools exist to find things and record them as configuration items, and they are thorough. Every server, every virtual machine, every cloud instance, every piece of network kit and, depending on configuration, every relationship between them, becomes a CI. Cloud autoscaling spins instances up and down, and a naive discovery pattern records each as a new CI without retiring the old one. The result is a count that climbs through normal operation, with no procurement decision behind it. When the licensed metric is pegged to that count, your entitlement requirement climbs with it.
Which CIs are actually inflating the count?
Before you negotiate the rate, find out what is in the number. In nearly every estate we reconcile, a meaningful share of the CI count is not billable in any honest reading of the contract. The table shows the usual suspects.
| CI category | Why it inflates the count | Buyer-side position |
|---|---|---|
| Duplicate CIs | Multiple discovery sources create the same asset more than once | De-duplicate before any count; exclude duplicates by definition |
| Stale CIs | Retired or decommissioned assets never removed | Set a staleness rule that retires CIs after a defined idle period |
| Ephemeral cloud CIs | Autoscaled instances recorded but not reaped | Exclude short-lived instances or count by steady-state, not peak |
| Relationship records | Dependency mappings counted as items | Confirm relationships are not chargeable CIs |
| Non-billable classes | CI classes outside the licensed scope | Define chargeable classes narrowly, in writing |
The platform-specific mechanics of how this is licensed are in ServiceNow CMDB and CI-based licensing, the hidden cost driver. The principle holds across vendors: the count you are charged on should be the reconciled count of in-scope, in-use CIs, not the raw output of the discovery engine.
Book a license optimization review.
We reconcile the CMDB, strip the non-billable CIs, and bound the chargeable count in the contract. Fixed fee or gainshare.
Book a license optimization review →What are the steps to control CI-driven cost?
- Reconcile before you count. Run a CMDB cleanup that removes duplicates, retires stale CIs and reaps ephemeral cloud instances, so the baseline is the real estate rather than the discovery engine's raw output.
- Define the chargeable CI classes in writing. Name the classes that count toward the licensed metric and exclude the rest. A vague "configuration items" definition lets the vendor count whatever discovery produces.
- Fix the unit rate and the count points. Lock the per-CI rate for the term and specify that the count is measured at agreed points, not continuously, so a mid-term discovery sweep cannot reset your baseline.
- Cap the growth. Negotiate a banded or capped CI allowance so normal estate drift does not trigger an unbudgeted true-up.
- Make cleanup a standing process. Fund ongoing reconciliation so creation and removal stay in balance, rather than letting the count drift one way until renewal.
Steps one and five are the ones buyers skip, and they are the ones that matter most, because an inflated CMDB is a cost you carry every year until someone cleans it. Folding CMDB reconciliation into a standing license optimization program is how you stop re-fighting this at every renewal; the program design is in how to build an ITSM license optimization program.
Our gated ITSM License Optimization Field Guide includes the CMDB reconciliation checklist and the CI-class scoping worksheet behind this method.
What will the vendor argue?
The vendor will argue that the CI count reflects the value the platform manages, so a growing count is a growing service. That is true for in-use, in-scope CIs and false for duplicates, stale records and ephemeral instances, which deliver no managed value but still bill. The counter is to separate the two: agree that value-bearing CIs are fair to charge for, then reconcile the count so only those remain. Across our ITSM engagements the firm averages a 30% reduction, and on CMDB-licensed platforms a large part of that comes from reconciling the count before negotiating the rate, rather than accepting the discovery engine's number as the baseline.
Frequently asked questions
- Why do CI counts affect ITSM cost?
- Because several platforms tie discovery, service mapping and some entitlements to the CMDB CI count, and discovery grows that count automatically, so the cost grows automatically unless the contract bounds it.
- How do I stop CI counts inflating my bill?
- Reconcile out duplicates, stale and ephemeral CIs before any count, define chargeable classes in writing, fix the unit rate, and measure the count at agreed points rather than continuously.
- Are all configuration items chargeable?
- It varies by platform and contract. The definition of a billable CI is negotiable, so narrow the chargeable classes and exclude duplicates, retired assets and relationship records.
What to do next
Reconcile the CMDB before you negotiate anything, then bound the chargeable classes and fix the rate in the contract. When you want the cleanup and the scoping run as one engagement, it goes through our license optimization service on fixed fee or gainshare.
Charge for value, not noise.
We reconcile the CMDB and bound the count before the vendor sets it for you.
Book a license optimization review →