Modern Pricing & UBB
February 26, 2026 hybrid

Committed Spend + Variable Overage: The CFO-Friendly UBP Architecture

Usage-based pricing is a product manager's dream and a CFO's nightmare. The value alignment is perfect. The revenue predictability is terrible. CFOs don't hate usage-based pricing because they don't understand it — they hate it because they've been burned by the quarterly call where engineering optimized its way to a 30% spend reduction and nobody told Finance until the invoice came in.

The committed spend + variable overage model is the architecture that solves this. It gives CFOs what they need (a predictable floor) and gives your growth team what they need (upside leverage when customers grow). Understanding its mechanics is not optional for anyone selling to enterprises in 2026.

The Basic Structure

The contract has three components:

  1. The annual commit — A minimum spend the customer agrees to, regardless of actual consumption. Usually paid upfront or in quarterly installments. This is your revenue floor.
  2. The credit allocation — The commit translates into a credits balance that the customer draws down as they use the product. The exchange rate (dollars to credits) is set at signing and often includes a volume discount vs. pay-as-you-go rates.
  3. The overage rate — If the customer exceeds their credit allocation, additional consumption is billed at an agreed overage rate — typically at or slightly above the commit exchange rate. No cliff pricing, no surprise renegotiations, just metered expansion.

Stripe's billing documentation describes this as a "prepaid credits" model with metered overage — a common pattern they've codified because enough of their customers run it that it needed first-class support in the platform.

Setting the Floor: The Art of the Commit

The commit amount is the most important negotiation variable in the deal. Set it too high and you've sold the customer a commitment they can't hit — expect a painful renewal conversation. Set it too low and you've left revenue on the table, because they'll comfortably underspend all year and have no incentive to expand.

The right starting point is a consumption forecast, not a gut feeling. Before the deal closes, build a usage model with your customer's technical team: how many API calls are they expecting? What data volumes? What workload patterns? Then apply a 70-80% confidence factor — commit to what you're confident they'll hit, not the optimistic scenario. This gives you a floor that's achievable, creates room for upside, and doesn't set the customer up to feel like they overpaid.

Best practice from the Orb blog: anchor the commit to the customer's current run-rate consumption, discounted 10-15% for the annual commit discount. This gives the customer a meaningful discount in exchange for the commitment while ensuring the commit amount maps to real, demonstrated usage — not projected growth.

Why Rollover Credits Actually Matter

Hard expiry on annual credits is a trust tax. Customers who don't fully consume their credits in year one feel like they lost money. This is true even when the math is fine — they got a discount on the commit, the vendor delivered the service, everyone should be square. But human psychology doesn't work that way. Unused credits feel like waste, and waste generates churn intent.

The solution is rollover with a capped balance. Unused credits at year-end roll into year two, up to some maximum (often 10-25% of the annual commit). This gives customers the feeling of continuity without creating an unbounded liability on your balance sheet. Customers who bank some credits in a slow quarter feel like they're ahead, not behind. That feeling is worth more than the marginal accounting complexity.

How the major vendors handle it: AWS credits expire hard. Anthropic's enterprise credits roll quarterly. Google Cloud committed use discounts have no credit balance — they're a rate commitment, not a balance. Orb recommends rolling unused credits with a 12-month total expiry window on the rolled balance.

True-Up Schedules and When Things Get Weird

A true-up is what happens when you reconcile actual consumption against the commit. If consumption exceeded the commit, the customer owes overage. If consumption fell short, in most contracts, the customer still owes the commit — it's a floor, not an estimate.

True-up frequency matters. Annual true-ups are cleaner for Finance on both sides but create larger exposure windows. Quarterly true-ups add billing complexity but reduce the magnitude of any reconciliation event. Monthly true-ups are operationally intensive but eliminate all reconciliation surprises.

The enterprise SaaS best practice is a quarterly invoice with an annual true-up. Quarterly invoices reflect actual consumption and maintain cash flow visibility for both parties. The annual true-up handles any structural gap between commit and actual — and is the moment when renewal conversations should kick off proactively rather than reactively.

One thing that always surprises founders: under-consumption is a churn signal, not a billing problem. If a customer is running at 60% of their commit by Q3, the right call is a customer success intervention to expand their usage, not a memo to Finance about the Q4 true-up. The billing mechanics are just the measurement. What you do with that measurement is the whole game.

Sources

← Hybrid Models · All posts