RevRec recipes / Hybrid pricing contract
One invoice pays for platform access, a one-time setup, an included pool of usage, and overage billed later. These four elements are each earned differently and must be recognized separately to stay compliant. Here's how Chargebee RevRec handles it.
The problem
One contract can deliver for several promises that are each earned in a different way: some by the passage of time, some on delivery, some only as the customer consumes them. When a single contract bundles all of these, three things get hard.
What gets hard
run at once. Time-based, point-in-time, and usage-based revenue all live inside one deal and have to be recognized on their own bases, not straight-lined together.
. Fees billed upfront are earned slowly, while usage consumed early may be billed late, so revenue leads billing on some parts and lags it on others.
. The same contract carries a deferred liability on the prepaid fees and an unbilled asset on the consumed-but-uninvoiced usage at the same time.
The five steps below untangle one such contract, assigning each promise its own recognition method and reconciling billing to revenue across the year.
The example
Meridian Systems signs a one-year agreement with Cadence AI, an AI agent platform. Meridian pays a fixed platform fee of $180,000, a one-time implementation fee of $40,000, and receives 12 million included AI actions. Usage beyond the pool is billed monthly at $0.02 per action. Every number on this page comes from the order form below.
| Line Item | Description | Amount | Billing |
|---|---|---|---|
| Platform fee | Platform access, includes 12M AI actions | $180,000 | Annual, advance |
| Implementation | One-time onboarding & setup | $40,000 | At signing |
| Fixed fees | $220,000 |
The platform fee includes 12,000,000 AI actions, usable at any time during the 12-month term. Included actions do not carry over past 31 December 2027.
AI actions consumed beyond the included 12,000,000 are billed at $0.02 per action, invoiced monthly in arrears for the prior month's overage.
This Order Form is non-cancellable for the full 12-month term.
One usage assumption drives the recognition schedule: Meridian's consumption ramps up through the year, exhausting the 12 million included actions by the end of September. From October onward it runs into overage.
A contract exists for accounting purposes when both sides have enforceable rights and obligations. Here they clearly do: the term is 12 months, non-cancellable, and the $220,000 in fixed fees is payable regardless of usage. So the contract is in scope from day one.
The overage being contingent on usage does not push it out of scope. A contract can hold both a fixed amount that is enforceable now and a variable amount settled later as consumption happens. Naming that split at the outset is what keeps the later steps honest.
| Contract term | One term, 12 months |
| Fixed fees enforceable at signature | $220,000 |
| Variable component | Overage, recognized as consumed |
The four obligations:
The right to use the platform throughout the 12-month term. The customer has access whether they use one action or a million, so it is earned as time passes, independent of usage levels.
A one-time onboarding with its own standalone value, delivered early in the term. It is earned when the work is delivered, not spread across the year.
The 12 million actions inside the platform fee, worth $120,000 of it. It is carved out as its own obligation because it is a revenue-bearing metric: the pool is an annual grant usable anytime, so consumption can be lumpy and exhaust before year-end. Left straight-lined, revenue would keep accruing on actions already consumed.
Actions beyond the included pool, priced at $0.02 each. It is earned action by action as usage crosses the allowance, and has no fixed amount, so it is treated as variable consideration.
What separates the included pool from the access it sits inside is whether the metric is revenue-bearing. Exceeding the pool triggers a charge, so the actions carry revenue and are recognized as consumed. A limit with no per-unit charge, such as a cap on seats or logins, is just part of the access right and stays ratable.
In this recipe we chose an annual pool that can be used anytime, which is the more complex case for revenue recognition. If the allowance had instead reset each month and expired unused, the included usage would flip to ratable recognition. When an allowance cannot be carried forward or drawn down early, spreading it evenly over the period lands on the same revenue as tracking each action, so there is no reason to track usage. That would leave three obligations instead of four. The annual pool is what puts the included usage on a usage basis.
The transaction price is the consideration the vendor expects to be entitled to. The platform fee and implementation add to $220,000, owed regardless of usage, so that fixed amount is what allocation works with. Overage is variable consideration at $0.02 per action. Chargebee RevRec recognizes it as consumed rather than forecasting it at signing, so it carries no fixed figure here and appears in Step 5 as usage happens.
| Platform fee | $180,000 |
| Implementation | $40,000 |
| Fixed transaction price | $220,000 |
| Overage | Variable, recognized as consumed |
Breakage applies when an entitlement is expected to expire unused, such as a use-it-or-lose-it allowance. You estimate the unused portion and recognize it over the term. If customers can consume the full allowance and incur overage, breakage doesn't apply.
ASC 606 allocates the transaction price across the distinct obligations by their standalone selling prices. Platform access, the included pool, and implementation each carry a fixed amount; their SSPs are used to divide the $220,000 in proportion. Overage sits outside this allocation: it is recognized at its contractual rate ($0.02 per action) as consumed.
| A | B | C | D | E | |
| 1 | Obligation | Recognition method | Standalone Selling Price (SSP) | SSP share | Allocated revenue |
|---|---|---|---|---|---|
| 2 | Platform access | Ratable | $66,000 | 27.3% | $60,000 |
| 3 | Included usage pool | Usage | $132,000 | 54.5% | $120,000 |
| 4 | Implementation | Point in time | $44,000 | 18.2% | $40,000 |
| 5 | Total | $242,000 | 100% | $220,000 |
Swipe the table sideways to see every column →
This allocation fixes the two rates Step 5 runs on: access at $60,000 ÷ 12 = $5,000 a month, and the pool at $120,000 ÷ 12 million = $0.01 per included action.
Step 2 identified each obligation's recognition method and Step 4 set its amounts. Step 5 runs those against the calendar, and the monthly mix shifts as one method hands off to the next. Open a beacon on any colored band below for how that obligation is recognized over the year.
When the timing of invoicing differs from the timing of revenue recognition, a single rollforward must track two opposite GL positions. The fixed fees are billed upfront but earned slowly, so the unearned portion is deferred revenue, a liability that drains as the year goes. Overage is earned as consumed but invoiced a month later, so the earned-but-unbilled portion is unbilled revenue, an asset that grows in Q4. The table below shows both.
| A | B | C | D | E | F | G | H | |
| 1 | Period | Fixed billed | Overage billed | Fixed revenue | Overage revenue | Total recognized | Deferred revenue | Unbilled revenue |
|---|---|---|---|---|---|---|---|---|
| 2 | Q1 (Jan–Mar) | 220,000 | 0 | 79,000 | 0 | 79,000 | 141,000 | 0 |
| 3 | Q2 (Apr–Jun) | 0 | 0 | 49,000 | 0 | 49,000 | 92,000 | 0 |
| 4 | Q3 (Jul–Sep) | 0 | 0 | 77,000 | 0 | 77,000 | 15,000 | 0 |
| 5 | Q4 (Oct–Dec) | 0 | 116,000 | 15,000 | 180,000 | 195,000 | 0 | 64,000 |
| 6 | Full year | 220,000 | 116,000 | 220,000 | 180,000 | 400,000 | 0 | 64,000 |
Disclaimer This page is not accounting advice.
Hybrid pricing contracts (platform fees, one-time setup, included pools, overage billed later) mix recognition methods that pull revenue and billing apart and break spreadsheets. Chargebee RevRec recognizes each obligation separately, keeps deferred and unbilled revenue reconciled, stays ASC 606 and IFRS 15 compliant, and shows its work on every number.
