You shipped a metered API product. Customers load up $500 in credits, burn through them over six weeks calling your endpoint, and you get paid upfront. Simple, right? Then your accountant asks: "How much revenue did you actually earn in March?"
If your answer is "$500, because that's what hit the bank account," you have a problem — and it's not a small one. Usage-based and consumption pricing have become the default for API products, AI tooling, and infrastructure startups, but the accounting rules for recognizing that revenue haven't gotten any simpler just because the billing model got more flexible. Get it wrong and you're not just filing taxes incorrectly — you're misreading your own runway, misleading investors, and setting up a painful restatement down the road.
Here's what actually governs this, and how to build your books so the numbers are right the first time.
Why "Cash In" Doesn't Mean "Revenue Earned"
Under US GAAP, revenue recognition is governed by ASC 606, a five-step framework:
- Identify the contract with a customer
- Identify the performance obligations in the contract
- Determine the transaction price
- Allocate the transaction price to the performance obligations
- Recognize revenue when (or as) each performance obligation is satisfied
For a flat-rate annual subscription, this is easy — revenue trickles out evenly over 12 months regardless of when the invoice was paid. For usage-based billing, step 5 is where things get genuinely tricky: you recognize revenue as the customer consumes the service, not when they pay you.
That single sentence is the root of almost every usage-based accounting mistake. A customer who prepays $500 for API credits hasn't given you $500 of revenue — they've given you $500 of cash and a liability. You owe them either the service or the money back. Only as they burn through calls, storage, or compute do you get to move that liability into recognized revenue.
The Stand-Ready Obligation, Explained Simply
Accountants have a term for what you're actually selling in a usage-based model: a stand-ready obligation. You're not just promising to process API calls — you're promising to be available to process them on demand, whenever the customer wants, up to whatever volume they need.
This matters because it can split your revenue into two conceptually different pieces:
- Access component — the value of simply being available (sometimes recognized straight-line over the contract period)
- Consumption component — the value delivered per unit of actual usage (recognized as usage occurs)
Most pure pay-per-call products (no base fee, no minimum commitment) collapse this into just the consumption component — which is good news, because it's the simpler case to account for.
Variable Consideration: Why You Can't Just Wait and See
Because the eventual invoice amount depends on usage nobody can predict at contract signing, ASC 606 treats usage-based fees as variable consideration. In theory, that means you're supposed to estimate the transaction price up front, using either:
- The expected value method — a probability-weighted average of possible outcomes, or
- The most likely amount method — your single best guess
And critically, you can only include an estimate in your recognized revenue to the extent that a significant reversal won't occur later once actual usage is known. That "constraint" exists specifically to stop companies from booking optimistic revenue early and having to walk it back later — a pattern regulators have flagged repeatedly in software audits.
For an indie developer running lean, building probability-weighted usage forecasts every month is overkill. Fortunately, there's a shortcut.
The Practical Expedient Almost Every API Business Should Use
ASC 606 includes a "right to invoice" practical expedient: if the amount you're entitled to bill in a given period corresponds directly to the value you delivered in that period, you can skip the estimation exercise entirely and just recognize revenue as usage occurs, at the amount you have the right to invoice.
This is the standard pattern for pure per-call, per-token, or per-transaction pricing: if you charge $0.001 per API call with no volume discounts or minimum commitments, the amount you can invoice for a given day's calls is the value delivered that day. No estimation needed — you recognize revenue as calls happen, full stop.
Where the expedient breaks down is tiered or cumulative-volume pricing, where the per-unit rate in period two depends on how much the customer used in period one (think: "first 100K calls at $0.002, everything above that at $0.001"). There, the invoiced amount in any single period doesn't cleanly correspond to that period's value, and you may need proper estimation instead. If your pricing has volume tiers, this is worth a conversation with an accountant before you assume the shortcut applies.
A Concrete Walkthrough
Say your API product has a $200/month base fee that includes 200,000 calls, with overages billed at $0.001/call at the same effective rate as the included calls:
- Base + included usage: because the overage rate matches the effective included rate, the entire fee — base plus overages — typically qualifies for the invoice practical expedient. You recognize $200 evenly as the 200,000 included calls are consumed, plus $0.001 per overage call as it happens.
- Prepaid credit packs: a customer buys $1,000 in credits in January. You debit cash, credit deferred revenue for $1,000. As they burn credits in February at $0.002/call, you debit deferred revenue and credit recognized revenue call by call. If $300 of credits are unused by month-end, $300 stays a liability on your balance sheet — not revenue, no matter how good March looks.
- Unbilled usage at month-end: your billing cycle runs the 1st to the 1st, but a customer's December usage isn't invoiced until January 2nd. That gap still needs a journal entry: debit unbilled receivables (an asset), credit revenue, for the value of calls made in December but not yet billed. When the invoice actually goes out, you reclassify from unbilled receivables to standard accounts receivable — the revenue was already booked.
Cash-Basis Taxes vs. Accrual-Basis Books
Here's where a lot of solo founders get tangled: your tax return and your revenue recognition don't have to run on the same basis, and often shouldn't. Most small businesses can file taxes on a cash basis — income is taxable when received, expenses deductible when paid — regardless of what ASC 606 says about when revenue is "earned." A single-member LLC selling API credits can legitimately pay tax on the $1,000 prepayment in the year it lands in the bank, even while its internal books show only $700 as recognized revenue and $300 sitting in deferred revenue.
The trap is treating these two views as interchangeable and only keeping one set of numbers. If you only track cash-basis totals, you'll have no defensible answer when a potential acquirer, investor, or lender asks for GAAP-basis revenue during diligence — and by then it's too late to reconstruct months of usage history. Keep both views in your ledger from the start: a cash flow you can hand to your tax preparer, and an accrual view with deferred revenue and unbilled receivables tracked explicitly, so either question can be answered from the same source of truth instead of a spreadsheet built under deadline pressure.
The Mistakes That Actually Bite
Talking to teams who've been through this, the failures cluster around a handful of repeatable patterns:
- Metering drift. If your usage-tracking pipeline undercounts or overcounts calls relative to what you actually bill, your revenue ledger and your billing system silently diverge — and nobody notices until reconciliation, which for a bootstrapped team might be "whenever the accountant asks why the numbers don't match."
- Mid-cycle plan changes with no proration logic. A customer upgrades tiers on day 15 of a 30-day cycle. If your system doesn't split that period's usage and pricing correctly, you'll either over- or under-recognize revenue for that customer that month.
- No separation between billing logic and revenue recognition logic. It's tempting to treat "what we invoiced" as "what we earned." For flat subscriptions those numbers converge quickly. For usage-based pricing, they frequently don't — especially with prepaid credits or annual minimums.
- Treating disputes and credits as an afterthought. If a customer disputes an overage charge and you issue a credit, that credit needs to flow back through your revenue ledger, not just your billing system, or you'll overstate revenue for a period you've since reversed.
Building This Into Your Books From Day One
None of this requires enterprise accounting software when you're small. What it requires is treating your usage events as a real accounting artifact, not just a billing input:
- Keep an auditable log of usage events (timestamp, quantity, rate applied) separate from your invoicing system — you'll need it to reconstruct revenue by period, and to defend the numbers if you're ever audited or raising a round.
- Track deferred revenue and unbilled receivables as explicit ledger accounts, not implicit assumptions. If a customer has prepaid and hasn't used it all, that balance needs to be visible on your books, not buried in a billing dashboard nobody but sales looks at.
- Reconcile your billing system against your revenue ledger on a schedule — monthly at minimum — so metering drift gets caught in weeks, not quarters.
This is exactly the kind of structure that plain-text, version-controlled accounting is good at. When your chart of accounts lives in a Git-tracked ledger rather than a black-box SaaS dashboard, "show me deferred revenue as of March 1st" and "show me every usage-based revenue entry for this customer since signup" are just queries against a file you can actually read — not a support ticket to your billing vendor.
Keep Your Usage-Based Revenue Honest
Usage-based pricing is genuinely better for customers and often better for growth — but it pushes real accounting complexity onto founders who'd rather be shipping product. Beancount.io gives you plain-text, double-entry accounting that makes deferred revenue, unbilled receivables, and usage-based recognition transparent and auditable instead of hidden inside someone else's SaaS. Get started for free and keep your books as precise as your metering pipeline.