A controller is closing the quarter on a consumption-based pricing model. An auditor is running the same numbers through revenue recognition testing. Either way, someone asks a simple question: what was this customer entitled to on this date, and why were they charged what they were charged?
Three systems answer that question, and they don't agree. The contracts system, usually the CRM, says one thing, the billing system or ERP says another, and the product itself, the system enforcing access in real time, has its own answer. That last one usually wins by default, because it's the system the customer is using right now.
That's not a training gap or a process problem, but rather an architecture problem, and it shows up almost every time a company moves from simple subscription pricing to a consumption-based pricing model.
How consumption-based pricing models end up broken
No one decides to turn the product into the system of record for revenue. It happens gradually, and every step looks like a small, sensible call at the time, the kind finance never hears about until much later.
It starts simple: paid customers get access, free customers don't, and that's easy enough that nobody thinks twice. Then sales asks for a trial tier, and engineering builds trial logic straight into the product because that's the fastest way to ship it. A customer negotiates a one-time extension, and engineering adds an exception path rather than looping in a contracts process. Sales starts selling consumption add-ons, and engineering adds metering, thresholds, shutoff behavior, and a top-up flow, because that's where the logic naturally lands when you're the one building the feature. The company expands into a region with different overage rules, so another config flag goes in. A partner shows up with its own commercial terms, and another flag follows that.
Each of these is a defensible decision on its own, and nobody in finance signs off on any of them because nobody in finance is in the room. Six months later, the product codebase is the only system that knows what customers are entitled to, and RevOps usually finds out the hard way, when a customer disputes a charge and the contracts system, the billing system, and the product each tell a different story. That disagreement, not fraud or carelessness, is where revenue leakage comes from. The systems stopped agreeing with each other, and the product kept enforcing its own version anyway.
For companies running a hybrid pricing model, subscription plus consumption, commits with overage, prepaid drawdown, this compounds fast. Every new motion adds another layer of commercial logic that has to live somewhere. If it lands in the product, finance loses the ability to answer a basic entitlement question without opening an engineering ticket.
The two kinds of logic getting tangled together
The fix starts with separating two things that get treated as one problem but really aren't the same thing.
Capability logic is what a customer is conceptually allowed to do: did they buy the ingest capability, the analytics module, the premium support tier? This is the kind of thing finance and sales already track in the contract. It's stable, and it only changes on upgrade, downgrade, or renewal, so it should live wherever the contract lives.
Balance logic is whether they can do it right now: do they have tokens left this month, are they inside their contract window, is a trial still active, has a prepaid balance hit zero? This changes constantly, sometimes by the second, which is exactly why it tends to get buried in the product. Someone has to evaluate it in real time, and the product is the thing running in real time.
Most product runtimes handle both, and that's the mistake. Once capability and balance logic both live in the product, the product ends up knowing about renewal schedules, monthly resets, trial windows, contract dates, overage policies, grace periods, and every customer-specific exception. None of that is a product decision. It's a commercial decision, and finance and RevOps should own it instead of finding out about it after the fact, when the numbers don't reconcile.
The architecture behind an auditable consumption-based pricing model
Companies that get consumption billing right split commercial decision-making from product enforcement into four layers.
Layer 1: Governed commercial definition. The product catalog lives in the CRM, in Salesforce for most companies, not in code. Products, capabilities, pricing structures, and the motions a customer moves through (trial to paid, prepaid to overage, self-serve to enterprise) are all defined there. That's what makes the commercial model auditable: finance can see the entire structure without pulling in an engineer, and anyone designing a new pricing motion starts there instead of in a sprint planning meeting.
Layer 2: Runtime commercial services. A commercial service layer sits between the CRM and the product and answers the real-time questions: what is this customer entitled to, what's their remaining balance, what rule applies now that they've crossed a threshold. This is where usage metering and rating happens, turning raw consumption into commercial state that can answer an auditor's question directly instead of routing it through engineering.
Layer 3: Product runtime. The product does what it's always been best at: delivering the experience and enforcing access when told to. It stops reasoning through commercial rules and just receives a signal, capability on or capability off, and acts on it. That's a clarification of scope. Product still owns the experience. The commercial layer owns the decision.
Layer 4: Event synchronization. When something changes upstream, a balance hits zero, a trial expires, a renewal processes, the commercial layer emits an event and the product updates its state. That means finance can change a grace period policy or add a new overage rule through credit and consumption management without waiting on a product release, and it keeps the CRM, the product, and eventually the ERP telling the same story.
What this looks like in practice
Take a common scenario: a customer buys a prepaid block of tokens and consumes them over time. When the balance nears zero, something needs to happen: prompt a top-up, apply overage pricing, or restrict access until the account is replenished.
In the tangled version of this, the product tracks the balance, decides when the threshold is crossed, applies whatever rule that specific customer negotiated (some get immediate shutoff, some have a grace period, partner-sourced customers route differently), and manages reactivation after top-up. Every new exception is a code change, and finance finds out about each one only when the numbers stop matching.
In the separated version, the product just tracks raw consumption and sends it upstream. The commercial layer computes the balance, checks which rules apply to this customer, and decides what should happen. It emits an event, ingest capability off, when the threshold is crossed, and another, ingest capability on, when a top-up clears. The product doesn't need to know why. Neither does anyone reconciling the books at quarter end, because the commercial layer already has the answer.
ASC 606 raises the stakes here. If the product is the de facto source of truth for what was delivered and when, and it disagrees with the contracts system, that's a revenue recognition problem, not just an engineering annoyance. Centralizing commercial state in Salesforce and passing clean, structured data into NetSuite is how that gap closes for good, something we've covered in more depth in our post on when usage-based billing outgrows NetSuite.
The question worth asking this quarter
If your team can't answer "what was this customer entitled to on this date" without pulling in an engineer, or finance, product, and contracts each give a different answer, commercial logic has ended up in the wrong system. The longer it stays there, the more it costs to untangle.
Ask your team this quarter how many commercial rules are hardcoded into the product right now, and what it would take to move them upstream, where finance and RevOps can see and audit them directly.
If you're not sure where to start, talk to our team. We do this by pairing usage metering and rating with credit and consumption management directly inside Salesforce, so the commercial layer sits where this kind of drift used to happen, not bolted onto the product afterward. Most conversations make it clear within the first call whether a setup is heading somewhere expensive.
Frequently asked questions
What causes revenue leakage in a consumption-based pricing model?
Revenue leakage in a consumption-based pricing model usually comes from architecture, not fraud. When the contracts system, the billing system, and the product each track entitlements separately, they stop agreeing. The product keeps enforcing its own version, and the mismatch shows up as charges finance cannot reconcile or defend at quarter close.
What is the difference between capability logic and balance logic?
Capability logic is what a customer is allowed to do, like which module or tier they bought, and it changes only on upgrade, downgrade, or renewal. Balance logic is whether they can do it right now, like tokens left or an active trial, and it changes constantly. That is why balance logic belongs in a commercial layer, not the product.
How do you make a consumption-based pricing model auditable?
Separate commercial decisions from product enforcement across four layers: a governed commercial definition in the CRM, runtime commercial services that answer entitlement and balance questions, a product runtime that only enforces access, and event synchronization that keeps the CRM, the product, and the ERP telling the same story. Finance can then audit entitlements without opening an engineering ticket.