ServiceNow can charge for data held in custom tables and for CMDB scale beyond an included allotment, and on a platform that has grown for three years that charge can add 5 to 15 percent to a renewal that the original order form never mentioned. The mechanism is not hidden in bad faith, but it is easy to miss, because the cost does not appear when you sign. It appears later, as the platform fills with the custom applications, integrations, and configuration-item data that successful ServiceNow adoption produces. The buyers who avoid the surprise are the ones who define the included capacity and fix the overage rate at signing, while they still hold bargaining power.
This guide explains how the custom-table and CMDB charges work, the thresholds that trigger them, and the contract language that caps the exposure. It is one of the most consequential items in our ServiceNow contract red flags list, and it sits underneath the per-product pricing in the ServiceNow licensing guide.
What a custom table charge is
A custom table is any table you create outside the standard ServiceNow data model, which is how almost every meaningful custom application stores its data. ServiceNow includes a baseline allotment of custom-table capacity in a subscription, and usage beyond that baseline can be charged, either per table, per row, or as a data-volume tier depending on how the agreement is written. The charge exists because custom data consumes platform resources, and ServiceNow prices the platform partly on the scale of what runs on it.
The trap is that custom-table growth tracks adoption success. The more value a team builds on the platform, the more custom data it creates, so the buyers who get the most from ServiceNow are exactly the ones most exposed to the charge. A custom application that solves a real problem and spreads across the organization is a win operationally and a cost event contractually, unless the included capacity was defined to accommodate it.
What a CMDB charge is
The Configuration Management Database, the CMDB, stores configuration items representing the assets, services, and dependencies the platform manages. CMDB scale is a natural cost driver because a mature CMDB in a large enterprise holds millions of configuration items, and ServiceNow can meter CMDB scale beyond an included allotment, particularly where ITOM Discovery and Service Mapping populate the database automatically. The more completely you map your estate, the larger the CMDB, and the closer you come to any metered threshold.
CMDB cost interacts with the ITOM products that feed it, so a buyer expanding Discovery should model the CMDB scale that expansion produces, not just the ITOM license. This is a place where two ServiceNow lines compound, and where the optimization work our ServiceNow optimization team does often finds duplicate or stale configuration items inflating the count without adding value.
Success is the trigger. Custom-table and CMDB charges scale with exactly the adoption ServiceNow encourages. The platform is sold on extensibility and complete service mapping, and both produce the data that the charge meters. Define included capacity generously at signing, because the alternative is paying a premium later for having used the platform the way it was sold to you.
The thresholds that trigger charges
The table summarizes how each charge is typically structured and what triggers it. The exact thresholds vary by contract, which is the point: because they are negotiable and often left undefined, they are where a buyer should insist on specificity.
| Charge | What it meters | Common trigger | Contract fix |
|---|---|---|---|
| Custom table | Tables or rows beyond baseline | Custom app growth, integrations | Define included tables and rows; fix overage rate |
| CMDB scale | Configuration items beyond allotment | Discovery, Service Mapping expansion | Set included CI count; require notice before overage |
| Data volume | Total stored data tier | Long retention, attachments, logs | Set retention policy; agree archive treatment |
| Table-based app | Custom apps as licensed entities | App publication to production | Clarify which apps count; cap app-based charges |
How to manage the exposure operationally
Beyond the contract, the charge responds to data hygiene. A CMDB full of duplicate, orphaned, or stale configuration items is paying to store noise, and a regular reconciliation that retires dead items keeps the count honest. Custom tables accumulate the same way, with abandoned applications and test data lingering in production, so a periodic review of what is actually used, the same discipline as right-sizing seats, applies to data as much as to licenses.
Retention policy is the other operational lever. Data kept forever costs more than data archived on a schedule, and many buyers retain everything by default because no one set a policy. Defining retention, archiving what compliance does not require live, and removing test and duplicate data are housekeeping tasks that directly reduce the metered volume, and they are worth running before a renewal where the data count sets the baseline.
How to cap it in the contract
The decisive move is at signing. Define the included custom-table capacity and CMDB allotment explicitly and generously, sized for the growth you actually expect over the term, not for day-one usage. Fix the overage rate for the full term so growth is priced at a known number rather than at renewal-time market rate. Require written notice before any overage is billed, so the first you hear of it is not the invoice. And tie all of this to the uplift cap and the rest of the protections in our contract red flags list, because a data charge governed by an uncapped renewal is two compounding problems at once.
A worked example
Picture a buyer three years into a ServiceNow deployment that began as a tidy ITSM rollout. Two custom applications proved popular and spread, each adding tables and rows; an ITOM Discovery expansion populated the CMDB with several million configuration items as it mapped the full estate; and retention was never set, so every closed record, attachment, and log accumulated. None of this was a mistake. Each step delivered value. But the renewal quote arrives carrying a data-related charge of roughly 8 percent of the subscription that the original order form never mentioned, because the included capacity was defined for day-one usage rather than for three years of successful growth.
The buyer who defined generous included capacity and a fixed overage rate at signing faces none of this, because the growth was anticipated and priced. The buyer who left it undefined faces a renewal-time negotiation from the weakest possible position, with the platform already embedded and the data already accumulated. The difference between the two buyers is not how they used the platform, which was identical, but whether they priced the consequence of using it well before they signed.
Custom tables versus raw storage
Buyers sometimes conflate custom-table charges with simple storage cost, and the distinction matters for how you respond. Raw data volume, the gigabytes a table consumes, is one cost vector, addressable through retention and archiving. The custom-table and table-based-application charge is a different vector tied to the platform's licensing of custom data structures and the applications built on them, addressable mainly through the contract definition of included capacity. A retention policy that trims storage does little against a charge that meters the number of custom tables or table-based applications, so the response has to match the charge's actual basis.
Reading your own agreement is therefore the first step, because contracts differ in whether they meter tables, rows, configuration items, raw volume, or applications, and each basis has a different fix. A buyer who assumes the charge is storage and runs an archiving project may find the metered figure barely moves, because the meter was counting tables, not bytes. Match the remedy to the meter, and confirm the meter by reading the contract rather than assuming, because the wrong remedy spends effort without recovering cost.
Common mistakes
The recurring mistakes are leaving included capacity undefined at signing, ignoring CMDB hygiene so duplicate and stale configuration items inflate the count, retaining all data forever because no policy was set, and discovering the whole exposure only at renewal when bargaining power is lowest. Each compounds the others. The buyers who avoid the surprise define capacity generously and the overage rate firmly at signing, keep the CMDB and custom tables clean as a standing discipline, set a real retention policy, and review the data position before every renewal so the number is never a surprise the vendor reveals.
Monitoring the data position
The data charge rewards monitoring the way any variable cost does, because it drifts upward quietly between renewals and only becomes visible when the bill arrives. Track the custom-table count, the configuration-item count, and the stored data volume against the contractual allotments on a regular cadence, and alert when any of them crosses a threshold that approaches the included capacity. A single new custom application or an expanded Discovery run can move the numbers materially in one quarter, and catching that movement early gives you time to clean up or to negotiate before the meter sets a renewal baseline.
Monitoring also produces the evidence that makes a renewal negotiation winnable. A buyer who can show that a large share of the configuration items are stale or duplicated, or that the custom-table growth came from a handful of applications that can be consolidated, negotiates the data terms from a position of fact rather than accepting the vendor's count as given. The same data hygiene that reduces the metered figure operationally also arms the commercial conversation, which is why the monitoring belongs to the same standing review that governs the rest of the ServiceNow relationship rather than being a task that surfaces only when an invoice surprises someone.
The single principle that governs the data charge is that it should never be a surprise, because every part of it is foreseeable at signing. Custom-table growth, CMDB scale, and data accumulation are the predictable results of using the platform well, so a contract that defines generous included capacity, fixes the overage rate, requires notice before billing, and sits under a capped renewal removes the surprise entirely. The buyers who get caught are the ones who priced only their first day on the platform; the buyers who do not are the ones who priced the platform they intended to build. Treat the data terms as a core part of the ServiceNow deal, not a technical footnote, and the charge becomes a known cost rather than a renewal ambush.
Price the data exposure as part of the whole deal, not as an afterthought, because ServiceNow discounts the relationship and the data terms are part of the relationship. Benchmark the result against the bands in our discount benchmarks, and where the platform is already at scale, bring in the optimization review that finds the stale data inflating the count. Our ServiceNow advisory and software licensing advisory teams define the capacity, fix the rate, and negotiate the data terms alongside the rest of the agreement so the charge never becomes a renewal surprise.