How to Recognize Revenue on Usage-Based AI Billing

Under ASC 606, you recognize revenue as you satisfy performance obligations, not as you collect cash. For a usage-based AI contract, the performance obligation is usually the delivery of the service on a per-unit basis, each token processed, each API call served, not a bundle of features delivered on day one. That distinction matters because revenue tracks usage, not the invoice date or the payment date, and a customer who pays a year upfront for credits they haven't used yet hasn't triggered revenue recognition for the unused portion, no matter when the cash arrived.

ASC 606 normally asks you to estimate variable consideration up front and constrain that estimate to avoid a later reversal. There's a practical expedient for exactly this situation, though: when your right to payment corresponds directly to the value delivered so far, meaning you're billing a fixed rate per token or per call, you can recognize revenue at that invoiced amount for the period instead of building a forward estimate. For a straightforward per-unit overage rate with no volume discounts that change retroactively, this expedient usually applies cleanly and saves you from modeling variable consideration you don't actually need to model.

A prepaid credit pack is a liability, not revenue, the moment the customer pays for it, because you haven't delivered anything yet. Revenue moves from that liability to the income statement as tokens are drawn down, unit by unit, which means you need usage data at the granularity of the credit pack itself, not just a monthly usage total. Breakage, the credits a customer buys but never uses, has its own rule: if you're entitled to keep unused credits and you have enough history to estimate how much typically goes unused, you can recognize that breakage in proportion to the pattern of redemptions. Without that history, or without the right to keep unused credits, you wait until the chance the customer will ever redeem them becomes remote.

For example, a customer buys a credit pack covering a full year and draws down roughly a quarter of it in the first quarter. Only the drawn-down portion moves to revenue; the rest stays a liability. A common mistake is recognizing the whole pack ratably over twelve months because the invoice covered a year, which treats a usage contract like a subscription and misstates revenue in slow-usage quarters. The fix is to keep a credit ledger per pack, updated from metered usage, and to let the revenue schedule pull from that ledger at each close instead of from the billing calendar. Only start estimating breakage once your redemption history is reliable enough to support it.

A minimum commitment, sometimes called a take-or-pay floor, is consideration you're entitled to regardless of whether the customer uses the service at all, so it behaves more like a fixed fee than a usage fee. Recognize it on a straight-line or ratable basis over the commitment period unless the contract ties it explicitly to usage. Overage above the minimum is the part that genuinely varies with consumption, and that's where the right-to-invoice expedient does its work. Keeping these two pieces of the same contract separate in your revenue schedule, rather than blending them into one usage number, is what keeps the schedule auditable.

Work through a token-metered contract in this order:

1. Identify the performance obligation as delivery of the service per unit, such as each token processed or API call served, and recognize revenue as usage occurs.
2. Record prepaid credit purchases as a liability, then move amounts into revenue as tokens are drawn down, using usage data at the credit pack level.
3. Recognize any minimum commitment ratably over the commitment period, treating it like a fixed fee unless the contract ties it to usage.
4. Apply the right-to-invoice expedient to per-unit overage billed at a fixed rate, recognizing revenue at the invoiced amount.
5. Estimate breakage only when you're entitled to unused credits and have enough redemption history, then recognize it in proportion to the redemption pattern.

Software companies typically run gross margins other sectors rarely see, often above seventy percent¹, but a usage-based AI business often runs meaningfully thinner than that once model inference cost is netted against metered revenue. Getting the revenue timing right matters here specifically because a lag between when compute cost hits the income statement and when the matching usage revenue is recognized can make a period look far more or less profitable than the underlying unit economics actually are. A clean, unit-level revenue schedule is what lets you see the real margin instead of an artifact of timing.