Usage-Based Billing and Revenue Recognition for AI Companies

This post is general guidance, not accounting or audit advice for your specific entity. Revenue treatment depends on the terms of your contracts.

Usage-based pricing is now the default for AI products, and for good reason: it aligns what customers pay with the value and the cost of what they consume. But it also breaks the tidy revenue recognition most founders learned from SaaS, where a $12,000 annual contract becomes $1,000 of revenue a month and everyone moves on. When a customer pays for tokens, API calls, compute minutes, or credits, the cash they send and the revenue you earn are two different things on two different schedules. Getting the gap right is the difference between a clean monthly close and a revenue number you have to restate when an investor or auditor looks closely.

This post covers how the revenue recognition standard, ASC 606, applies to consumption pricing, and the practical rules for recognizing usage revenue without overstating it.

The Core Rule: Recognize Revenue as the Customer Consumes

ASC 606 is built on a single principle: you recognize revenue when you transfer control of a good or service to the customer, in the amount you expect to be entitled to. For a consumption product, control transfers as the customer uses the service. A customer who runs ten million tokens through your API in March has received ten million tokens’ worth of value in March, and that is when the corresponding revenue is earned, regardless of when they paid or when you invoice.

This sounds obvious, but it is the opposite of the subscription instinct. With usage pricing there is no smooth monthly entitlement to spread evenly across a term. There is a meter, and revenue tracks the meter. If your billing system and your accounting system are not both reading from the same usage data, your revenue will not match reality.

Walking Consumption Pricing Through the Five Steps

ASC 606 has a five-step model, and it is worth seeing how a usage contract moves through it, because the answers differ from a subscription.

First, identify the contract. Straightforward: your terms of service or order form.

Second, identify the performance obligations, meaning the distinct promises you are making. For most AI products this is the promise to stand ready to process the customer’s requests and to deliver output on demand. If you also bundle onboarding, fine-tuning, or support, those may be separate obligations.

Third, determine the transaction price. This is where usage pricing gets interesting. The total price is variable because it depends on consumption you cannot know in advance. ASC 606 calls this variable consideration, and ordinarily you would have to estimate it. But there is a practical expedient that fits most usage models cleanly, covered below.

Fourth, allocate the price to the obligations. With a single usage-based obligation priced at a per-unit rate, allocation is simple. With bundles, you allocate based on standalone selling prices.

Fifth, recognize revenue as you satisfy each obligation, which for usage means as consumption occurs.

The Right-to-Invoice Expedient Is Your Friend

Here is the rule that makes usage revenue manageable. ASC 606 includes a practical expedient that lets you recognize revenue in the amount you have the right to invoice, when that amount corresponds directly to the value delivered to the customer to date. A per-token or per-call price billed in arrears is the textbook case: each unit consumed has a price, that price reflects the value transferred, and you have the right to invoice for it. So you can recognize revenue equal to the usage that occurred in the period, without building elaborate estimates of total contract value.

This is why pure pay-as-you-go pricing is the cleanest model to account for. Usage happens, you have the right to bill it, you recognize it. The complexity arrives when money changes hands before usage does, which is the prepaid case.

Where It Gets Hard: Prepaid Usage and Commitments

Two common structures complicate the simple picture.

The first is prepaid credits or wallets, where a customer pays up front and draws down. The cash is a deferred revenue liability when received, and you recognize revenue only as credits are consumed. Smooth monthly recognition would overstate early revenue and understate later revenue, and it ignores the real liability you owe the customer until they use what they bought.

The second is minimum commitments, where a customer commits to spend, say, $120,000 over a year with usage drawn against it. Now you have a fixed floor and variable usage on top, and you have to decide how the committed minimum is recognized if the customer under-consumes, including whether unused commitment is forfeited or rolls over. These terms drive the accounting, which is exactly why the contract language matters as much as the billing system.

Because prepaid and committed structures carry a deferred revenue liability, they deserve their own treatment, which we give in deferred revenue and prepaid credits for AI startups.

Usage Billing Needs a Real System, Not a Spreadsheet

The reason usage revenue gets mishandled is rarely that founders do not understand the standard. It is that the data lives in three disconnected places: your product emits usage events, your billing tool issues invoices, and your accounting system records revenue, and nothing reconciles them automatically. When those are stitched together by hand, the meter, the invoice, and the recognized revenue drift apart, and your close becomes an archaeology project every month.

This is the problem JustPaid was built to solve, and it is why we point AI founders to it. JustPaid is an AI-powered billing and contract-to-cash platform that connects the usage data to the money. In practice that means it meters consumption and turns it into accurate invoices automatically, so per-token, per-call, and per-credit billing does not depend on someone exporting logs into a spreadsheet. It reads the actual contract terms, including minimums, tiers, and overage rates, so committed-use deals bill correctly instead of being approximated. It runs the collections and dunning side, chasing overdue invoices so cash actually arrives, which for a usage business is its own discipline (we wrote about that pain in the money is already yours). And it surfaces the revenue metrics that matter, recognized revenue, deferred balances, and run-rate, on the consumption basis rather than the cash basis, which is exactly the distinction that keeps your top line defensible.

The point is not the tool for its own sake. It is that consumption pricing creates a data-reconciliation problem, and the clean way to recognize usage revenue is to have billing and revenue reporting reading from the same source of truth rather than reconstructing it at month-end.

Why This Matters Beyond the Close

Recognizing usage revenue correctly is not just a compliance exercise. It produces the metrics your investors actually trust. Recognized revenue, not cash collected, is what feeds a real run-rate. Mixing the two, counting a large prepaid credit purchase as revenue in the month it was sold, inflates a single month and creates a cliff the next. Anyone who has underwritten a usage-based business will normalize for this immediately, and a startup that already reports on recognized revenue looks far more credible than one that does not see the distinction.

It also connects to how you read your own margins. Usage revenue recognized in a period should be matched against the compute cost of serving that usage in the same period, which is the only way your gross margin means anything. We cover where compute belongs in accounting for AI startups.

The honest summary: if you charge for consumption, recognize for consumption. Let the meter drive revenue, lean on the right-to-invoice expedient for pay-as-you-go, and treat every dollar collected before usage as a liability until it is earned. Do that and your top line will survive any diligence.

Frequently Asked Questions

How do you recognize revenue on usage-based pricing under ASC 606? You recognize revenue as the customer consumes the service, because that is when control transfers. For pay-as-you-go pricing billed in arrears, the right-to-invoice practical expedient lets you recognize revenue equal to the amount you can bill for usage to date, without estimating total contract value.

Is prepaid usage revenue recognized when the customer pays? No. Cash collected before usage is deferred revenue, a liability, and converts to revenue only as the customer consumes what they bought. Recognizing it when paid overstates current revenue and creates a cliff later.

Can I just recognize an annual usage contract evenly each month? Not for true consumption pricing. Straight-lining ignores when usage actually happens and distorts revenue in whichever direction the customer’s usage is uneven. Recognition should follow the meter.

What is the difference between recognized revenue and collected cash for an AI startup? Collected cash is what customers have paid, including prepayments you have not earned. Recognized revenue is what you have actually delivered. Investors use recognized revenue for run-rate, so reporting on cash overstates your real recurring base.

If you want to talk through how this applies to your company, book a call.

Anelya Grant is the founder of AG Accounting (AG Grant, Inc.), an accounting firm serving tech startups and healthcare organizations. She is also co-founder of JustPaid.ai, an AI-powered billing and contract-to-cash platform for growing companies.