You just closed the biggest deal in your company's short history: a $120,000 annual commit, plus $0.10 for every API call over the included allowance. Your billing system is already metering away, and the obvious bookkeeping seems to be "recognize revenue when they use it." That instinct is right for exactly half of this contract — and wrong enough on the other half to hand your auditor a year-end adjustment.
Usage-based pricing is now the default way SaaS companies charge, not the exotic exception: more than 59% of SaaS businesses had a usage-based structure in place in 2025, up from roughly 40% two years earlier. Most of those deals are not pure pay-as-you-go. They are hybrids — a committed baseline that buys a discount, with metered overage on top. Under ASC 606, that single signature splits into two revenue streams with opposite timing rules. The baseline is fixed consideration and gets spread over the contract term whether the customer uses a single API call or not. The overage is variable consideration and waits for the meter. This guide explains why, with the journal entries that implement it.
One Contract, Two Revenue Treatments
Start with the structure, because everything else follows from it. A committed-baseline-plus-overage deal has three moving parts:
- A committed minimum. The customer pays $120,000 for the year no matter what. In exchange they get platform access plus an included allowance — say, 1 million API calls a month — at an effective rate well below list.
- An overage meter. Usage above the allowance bills at the overage rate, typically monthly in arrears. In our example, $0.10 per call.
- One signature, one term. Usually twelve months, often invoiced upfront or quarterly even though the service drips out over the year.
ASC 606 runs this contract through its five-step model — identify the contract, identify the performance obligations, determine the transaction price, allocate it, recognize revenue as obligations are satisfied — and reaches a split verdict. The committed $120,000 is a fixed transaction price for a service delivered continuously over twelve months, so it is recognized over time, normally straight-line at $10,000 a month. The overage is variable consideration: its amount depends on future usage, so it is recognized as the usage occurs, or estimated upfront only if you can clear a deliberately high bar called the constraint. Same customer, same invoice, two clocks.
The practical consequence is immediate. In a slow month where the customer burns only 400,000 calls, you still recognize the full $10,000 of baseline revenue — the customer bought a year of access, and January's twelfth of it is delivered. In a spike month at 1.5 million calls, you recognize $10,000 plus 500,000 overage calls at $0.10, or $50,000 in usage revenue. The baseline never dips with usage, and the overage never gets smoothed into months where nothing happened.
Why the Baseline Gets Straight-Lined
The accounting logic for the baseline is the calmer half of the story. Your performance obligation is not "1 million API calls" — it is standing ready to serve the customer all month, a series of distinct daily or monthly service periods that ASC 606 treats as satisfied over time. The right measure of progress is time elapsed, and the simplest faithful pattern is straight-line: one twelfth of the commit each month.
Every large usage-based vendor lands in the same place on this half. Datadog's 10-K states that for a committed contractual amount apportioned ratably, revenue is recognized ratably over the subscription term starting when the platform is made available. Alkami, which sells transaction-based banking software on monthly minimums, puts it even more plainly: minimum transaction fees are recognized on a straight-line basis, while fees for transactions above the minimum are recognized in the month the transactions are processed. Minimums are for the passage of time; overages are for the meter.
There is one famous dissenter worth knowing about, because your auditor will. Snowflake recognizes revenue as customers consume compute, storage, and transfer — even under multi-year capacity commitments — on the argument that consumption, not time, is when value transfers. That position is disclosed prominently and defended with company-specific facts. Unless you are prepared to write that memo and defend it under audit, straight-line the baseline. It is the treatment auditors expect from an early-stage SaaS company, and deviations need a written position, not a shrug.
Why Overages Wait for the Meter
Overages are variable consideration, and ASC 606 treats variable consideration with suspicion. You may include it in the transaction price only to the extent it is probable that no significant reversal will occur when the uncertainty resolves — the constraint. For usage that has already happened and been metered, there is no uncertainty left, so recognizing overage revenue in the month of usage always clears the bar. That is why "recognize it when they use it" is the default most SaaS companies choose, and the one auditors challenge least.
The alternative is estimating the year's total overage upfront and recognizing it ratably alongside the baseline. New Relic does exactly this: it projects usage above the commitment from historical data plus forward-looking factors, constrains the estimate to what it expects to be entitled to, and recognizes that amount over the term. This is compliant, and it produces smoother revenue — but notice what it demands. You need enough history to project credibly, a documented estimation method, a constraint analysis, and a true-up process when actuals diverge. For a startup with six months of metering data and one big customer whose usage doubles every quarter, that file does not exist yet. Recognize overages as incurred until your history earns you the right to estimate.
One more piece of the standard quietly supports the simple approach. Because your subscription is a series of distinct monthly service periods, usage fees that relate to a specific month can be allocated entirely to that month under the variable-consideration allocation exception. In plain terms: you do not need to forecast the year to book January correctly. January's meter reading belongs to January, full stop.
The last timing trap is confusing invoicing with recognition. If you invoice the $120,000 commit upfront in January, January's revenue is still $10,000 — the other $110,000 sits in deferred revenue. Conversely, overage usage delivered in January but not invoiced until February's billing run is still January revenue; at month-end you accrue it as unbilled or accrued revenue. Cash and invoices are billing events. The passage of time and the meter are revenue events. Your close checklist has to keep the two apart.
The Journal Entries, With Real Numbers
Here is the example deal on the books. Acme signs January 5: $120,000 annual commit, 1 million included calls a month, $0.10 per overage call. January usage comes in at 1,021,000 calls — 21,000 over the allowance, or $2,100. February is quiet at 800,000 calls, so no overage at all.
2026-01-05 * "Invoice Acme annual platform commit"
Assets:Receivable:Acme 120000.00 USD
Liabilities:Deferred-Revenue:Acme -120000.00 USD
2026-01-31 * "January: release 1/12 of commit"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USD
2026-01-31 * "January overage: 21000 calls over allowance at 0.10"
Assets:Receivable:Acme 2100.00 USD
Income:Usage-Revenue -2100.00 USD
2026-02-28 * "February: release 1/12 of commit, usage under allowance"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USDRead the story the ledger tells. January recognizes $12,100 on $120,000 invoiced — the $110,000 difference is deferred revenue, a liability for service still owed, not profit. February recognizes a flat $10,000 despite usage dropping by a fifth, because the baseline pays for access, not calls. And the overage entry only exists in months the meter exceeds the allowance. If your revenue account does not show exactly this shape — flat baseline plus spiky usage — something upstream is miswired.
Note the separate income accounts. Splitting subscription baseline from usage revenue is not cosmetic: it is what lets you report net revenue retention, usage attach rate, and commit coverage from the general ledger instead of a spreadsheet. Set up both accounts on day one of the contract, not during your first audit.
Four Mistakes That Invite an Auditor Adjustment
Booking the commit as revenue on signing. The $120,000 invoice feels like a sale, and sales teams will tell you it closed in January. But you have delivered one month of a twelve-month service. Everything beyond January's $10,000 is deferred revenue. Companies that book the full commit upfront do not just misstate one month — they borrow eleven months of future revenue and pay it back as an embarrassing restatement.
Smoothing lumpy overages across quiet months. Averaging a spike month's $50,000 overage into the surrounding quarters looks tidy and is wrong unless you estimated the total upfront, documented the constraint analysis, and true it up. Without that file, each month's meter reading stays in its own month. Auditors test this by comparing recognized usage revenue to metered usage by period; a smoothed line against a spiky meter is the fastest way to fail the test.
Letting the invoice calendar drive recognition. Annual-upfront billing tempts teams to recognize on invoice dates. Quarterly true-up invoices tempt them to recognize overages only when billed. Both directions break the rule: baseline follows the calendar of service, overage follows the calendar of usage, and neither follows the calendar of invoicing. The month-end accrual for metered-but-unbilled usage is the entry most young finance teams are missing — close the books a few days after month-end specifically so the meter has settled.
Forgetting the unused commit. If Acme ends the year 2 million calls under its total allowance and the contract says use-it-or-lose-it, that shortfall is not automatically bonus revenue in December. Unused prepaid amounts — breakage — are recognized only under a disciplined policy: in proportion to usage as rights are exercised, or when the likelihood of exercise becomes remote. Write the policy before December, apply it consistently, and disclose it. Discovering breakage during the audit is how a clean opinion gets delayed.
Your Month-End Close Checklist for Commit-Plus-Overage
Turn the rules above into a repeatable close. Every month, in this order:
- Pull the meter export and tie it to the rating engine. Rated usage by customer should reconcile to the billing system's invoice inputs to the call. Investigate gaps before booking anything — a metering outage is a revenue completeness problem, not an IT ticket.
- Release the baseline. One twelfth of each active commit out of deferred revenue and into subscription revenue. A deferred-revenue waterfall that rolls opening balance plus new invoices minus releases to the closing balance is the control auditors ask for first; review it in Fava filtered to your deferred-revenue accounts and the shape errors jump out.
- Book overages from the meter, then accrue the unbilled tail. Invoiced overage debits receivables; usage metered after the last billing run debits accrued revenue. Both credit usage revenue in the usage month.
- True up any estimates. If you estimate overages ratably, compare year-to-date recognized against year-to-date metered and book the catch-up. If you recognize as incurred, this step is a five-minute reasonableness check instead — one more reason startups should start there.
- Review the commit coverage. For each customer, compare cumulative usage value against cumulative baseline released. A customer burning far above its commit is an expansion conversation; one far below it is a renewal risk and possibly a future breakage entry. Either way, finance should spot it before sales does.
Start with this month's meter export: reconcile it to what your ledger recognized, split by baseline and usage, and confirm the two clocks are running independently. If they are, your commit-plus-overage bookkeeping is already ahead of most companies your size — and your next audit just got shorter.
