THE QUESTION
Two companies can meter the exact same customer activity, the same API calls, the same GPU hours, the same tokens processed, and recognize revenue on entirely different schedules. One recognizes a dollar the moment a customer’s usage crosses the meter. Another recognizes that same dollar over a year, in equal monthly slices, regardless of when the customer actually uses the product.
Usage-based pricing looks like it should explain the revenue pattern, since the whole model is built around metering what gets consumed. In practice it doesn’t explain much at all. It’s just a billing mechanic, and the real drivers sit underneath it, in what the contract actually promises, whether any part of the price is fixed, and whether that promise amounts to one thing or several things bundled together.
The General Rule
Start with what the contract promises before looking at how it’s priced, namely the performance obligation, and whether it’s one promise or several. From there, two questions tend to settle it.
First, is the promise one distinct thing, or a bundle of several? If it’s a bundle, the transaction price has to be allocated across the pieces using standalone selling price.
Second, does the price include a fixed floor, such as a minimum commitment, or is it entirely tied to usage? A floor gets recognized on its own pattern, while a fee tied to a specific period’s usage is typically recognized as that usage occurs.
HOW IT USUALLY GOES
Four contract patterns cover most consumption pricing in technology and AI. The same company often runs more than one at once, across different products or customer tiers.
Pure usage, no floor.
The customer pays only for what they consume, per API call, per token, per GPU hour, with no subscription and no minimum. This is usually a single performance obligation, a series of substantially identical daily or monthly services. Because the fee in a given period relates specifically to that period’s usage, it is typically recognized as the usage occurs, with no need to estimate the full contract’s usage in advance.
Usage with a minimum.
The customer commits to a minimum spend or minimum volume that resets every billing period and pays overage at metered rates above it. The minimum is fixed consideration. It is recognized on its own pattern, often ratably or as the committed volume is used, while anything above it is variable consideration recognized as it is incurred. Whether and when unused minimums get recognized before the contract ends is its own judgment call.
Subscription plus usage.
A platform fee or seat license is sold alongside included usage credits or compute, priced and billed together. The question becomes whether the subscription and the usage are one performance obligation or two distinct ones. Two distinct obligations means allocating the transaction price between them using standalone selling price, straightforward when usage is sold separately at an observable rate and much harder when it is not.
Tiered or declining rates.
The per unit price drops as volume grows within a period, common where scale economics get passed through to large customers. Because a later tier can retroactively change the effective rate on units already delivered, the period’s revenue has to reflect the expected blended rate for the full period, not simply the rate invoiced to date.
Two mechanisms can land on the same monthly number without actually being interchangeable. The invoicing practical expedient lets an entity recognize revenue at the amount it has a right to invoice, but only when that amount corresponds directly with the value delivered that period, while the variable consideration allocation exception works on a different logic entirely, allocating a variable fee to the period it relates to without requiring that the invoice track value dollar for dollar. Pure usage with no floor typically supports either path, since the fee is invoiced as consumed and relates specifically to that period’s usage. A guaranteed minimum breaks the invoicing shortcut, because the fixed floor follows its own recognition pattern regardless of what gets billed, leaving the allocation exception to govern the overage alone. Tiered pricing breaks both, because a later tier can retroactively change the value of units already invoiced, which is exactly what each mechanism’s own test is designed to catch.
| Pure usage | Usage + minimum | Subscription + usage | Tiered rates | |
|---|---|---|---|---|
| Performance obligation | Single, a series | Single, fixed floor | Potentially two obligations | Single, typically |
| Fixed or variable | Fully variable | Mixed | Mixed | Variable, tier dependent |
| Key judgment | Timing follows usage | Resets each period; floor’s pattern | Allocating price via SSP | Estimating the blended rate |
| Recognition support | Either path works | Allocation exception, overage only | Usage portion may qualify for either | Neither; has to be estimated |
Figure 1. The four consumption pricing patterns, the obligations they typically create, and the recognition mechanism each one supports.
The invoice looks the same in all four cases, a usage-based line item. The revenue pattern is decided long before the invoice is cut, in whether the contract sets a floor and whether it bundles usage with something else.
THE DECIDING FACTOR
How the contract prices and packages what it promises.
Here, the key question is how the promise relates to the meter. That means asking whether the customer is buying access, a committed amount of capacity, or a series of usage events, and whether the contract treats those as one thing or several. That relationship is set in product and pricing design. A minimum commitment, included usage, or tiered rate may look like a billing choice, but it can change what is fixed, what is variable, and how the transaction price is allocated. The invoice comes later. By then, the commercial architecture has already determined the revenue recognition.
The pricing architecture should make clear what the customer is buying and how each part of the price relates to it. A clean meter makes the accounting easier, but a bundled promise leaves the accounting to untangle it.
WHERE WE COME IN
While the patterns above cover the common structures in this sector, in practice the answer depends on the specific commitments, true-up mechanics, and pricing tiers in each contract.
We perform that detailed analysis, and we advise on pricing and contract structures that achieve the optimal revenue recognition outcome, documented well enough to survive an audit, a diligence process, and the scrutiny of a registration statement. As a firm with no audit practice, we can give you a view rather than a question.
Start a conversation at https://uniqus.com/contact-us/
GOING DEEPER
Issue 01 of By Design, Follow the Contracts, covers the related question of gross versus net presentation when an AI model is sold through a cloud partner. Available at uniqus.com/insights.
Technical references. ASC 606-10-25-14(b) and 25-15 on a series of distinct goods or services with the same pattern of transfer, 606-10-32-40 on allocating variable consideration entirely to a distinct period, 606-10-55-18 on the invoicing practical expedient for measuring progress, and 606-10-32-28 through 32-29 on allocating the transaction price using standalone selling price. IFRS 15 applies substantively identical guidance.
ABOUT BY DESIGN
By Design is a Uniqus series on the accounting decisions companies make before they know they are making them. Each issue takes one topic, sets out how the analysis usually runs, and names the single upstream choice that decides the outcome.
