Usage-based billing changes when revenue is recognized. Credits may look identical in product UI but behave differently under ASC 606 and IFRS 15 depending on whether they represent entitlements, commitments, or prepaid usage. This matters more for AI products where usage is spiky, costs are real, and regulators scrutinize when value is actually delivered.
AI products incur real costs in real time. Flat subscriptions were not designed for this reality.
As pricing shifts toward usage, credits become the primary unit of value. Customers see tokens, API calls, or compute hours. Finance teams see a harder question:
When does cash become revenue?
Under ASC 606 and IFRS 15, the answer depends on what was promised to the customer. Different credit models can look identical in a product UI and behave very differently on the balance sheet.
This is not theoretical. It determines whether revenue is recognized today or deferred until usage occurs.
A typical AI pricing structure
An AI company sells API access to a language model.
The pricing page states:
$20 per month, includes 100 credits 1 credit = 1 model inference Credits reset monthly and do not roll over
This looks straightforward. But this single line does not tell you when revenue is earned.
That depends on whether those credits represent an entitlement, a commitment, or prepaid usage.
The entitlement model: selling availability
In an entitlement model, included credits represent capacity rather than prepaid consumption.
The promise is simple: the service will be available up to a defined level for the duration of the period.
Accounting treatment
- Performance obligation: Stand-ready obligation to provide access
- Value delivered: Ongoing availability
- Revenue recognition: Ratable over time
Even if the customer uses zero credits in a given month, the obligation has been satisfied. Revenue is earned through time, not usage.
Where auditors challenge this
Problems arise when the included credits are economically significant.
If the pricing were:
$20 per month, includes 10,000 credits
Auditors may conclude that the customer has received more than simple access. In practice, this often triggers a material right assessment.
A material right exists when a customer receives the option to purchase additional goods or services at a price they would not otherwise receive.
In usage-based pricing, this typically shows up when:
- Included credits materially exceed expected usage
- Marginal price of additional usage is meaningfully lower than standard rates
- Credits have standalone economic value beyond incidental convenience
When a material right exists, part of the subscription fee is treated as payment for future usage. That portion cannot be recognized upfront or ratably. It must be deferred and recognized only as the credits are consumed.
This is why "included usage" is not automatically benign. In AI pricing, credits often represent real, measurable cost. When that cost is bundled into a low platform fee, regulators expect companies to justify why the arrangement is still access-based rather than usage-based.
The commitment model: revenue follows usage
Consider a different structure.
The customer agrees to:
$2,000 minimum usage commitment Credits draw down as inferences occur Unused balance expires after 12 months
From an accounting standpoint, this is no longer time-based.
Accounting treatment
- Cash received: Contract liability (deferred revenue)
- Revenue recognition: As usage occurs
- Constraint: Service delivery must happen first
The consideration may be fixed, but revenue is only earned when the service is actually performed.
Breakage considerations
If historical data shows that some committed usage consistently goes unused, standards allow or require proportional breakage recognition. These estimates must be conservative, supported by data, and revisited regularly.
This attracts attention during audits.
Ad-hoc pre-funded top-ups: prepaid consumption
The third model is common in early-stage AI companies.
Customer tops up $500 of credits Credits are consumed over time No subscription, no minimum commitment
From a product perspective, this often feels like the simplest form of usage-based billing.
From an accounting perspective, it is very clear.
Accounting treatment
- Cash received: Contract liability (deferred revenue)
- Revenue recognition: On usage
- Breakage: Relevant only if credits expire and breakage can be reliably estimated
There is no stand-ready obligation here. The customer has prepaid for future service. Revenue is earned strictly as that service is delivered.
A worked example makes the mechanics concrete. A customer tops up $500 for 500 credits at $1 each. At the moment of purchase, the full $500 is a contract liability: deferred revenue, not income. If they consume 300 credits in the first month, $300 moves to recognized revenue and $200 stays deferred. If the remaining 200 credits later expire unused and breakage can be reliably estimated, that $200 is recognized as breakage revenue at expiry.
Economically, this behaves like a commitment without the obligation to spend a minimum amount.
Same credits, different revenue treatment
The unit of measure matters less than the promise behind it.
| Model | What is being sold | When revenue is recognized |
|---|---|---|
| Entitlement | Access and availability | Over time (ratable) |
| Commitment | Minimum usage | On consumption |
| Pre-funded top-ups | Prepaid usage | On consumption |
This is why pricing changes that look small to product teams often trigger concern from finance.
The accounting impact is rarely small.
Why this matters more for AI products
AI pricing exposes edge cases that older models could ignore:
- Usage is spiky and non-linear. Consumption patterns are harder to predict.
- Costs are abstracted behind credits. The economic substance is harder to assess.
- Metering must be defensible. Revenue estimates are easier to challenge.
- Regulators scrutinize when value is delivered. The traditional subscription playbook does not apply.
Standards are not opposed to usage-based pricing. They are opposed to revenue being recognized before value is delivered.
How billing infrastructure affects revenue recognition
Most billing systems treat credits as a single balance. Accounting standards do not.
Credyt models entitlements, commitments, top-ups, and promotions as distinct credit grants, each with explicit recognition behavior.
This separation allows teams to:
- Define pricing intent without accidentally changing accounting treatment
- Apply recognition logic at the grant level
- Maintain clear, auditable usage records
- Evolve pricing without unintentionally altering when revenue is earned
Credyt is not just supporting usage-based billing. It is preventing accidental accounting models from emerging as pricing evolves.
When a customer receives 1,000 promotional credits, 500 credits from a monthly entitlement, and 2,000 prepaid credits from a top-up, Credyt knows which grant is consumed first and applies the correct revenue recognition logic to each.
This matters when:
- Promotional credits should never recognize revenue (marketing expense)
- Entitlement credits recognize revenue ratably over time
- Prepaid credits recognize revenue only on consumption
Without this separation, teams either build fragile workarounds or discover revenue recognition issues during their first audit.
What breaks without proper grant tracking
Teams that treat credits as a single balance encounter problems:
Revenue leakage: Promotional credits get recognized as revenue instead of being tracked as marketing expense.
Audit failures: Auditors cannot verify that the right revenue recognition method was applied to each credit type.
Migration complexity: Changing pricing models requires rebuilding the entire credit system because grants were not modeled separately from the start.
Deferred revenue errors: Contract liabilities are calculated incorrectly because the system cannot distinguish between different grant types with different recognition rules.
The fix is not adding fields to a credits table. The fix is treating grants as first-class primitives with defined lifecycles and recognition behavior.
Closing principle
Usage-based billing does not break accounting rules.
It removes the margin for ambiguity.
In AI pricing, the difference between an entitlement, a commitment, and a top-up is not semantics. It determines whether revenue is earned or deferred.
Systems that do not make this distinction force teams to choose between pricing flexibility and accounting correctness.
Credyt was built to eliminate that tradeoff.
For the wider market, compare the best usage-based billing platforms, or learn how to implement consumption-based pricing. See Credyt's billing platform.
Frequently asked questions
How does revenue recognition work for usage-based billing?
Revenue is recognized when the service is delivered, not when cash is collected. For usage-based billing that usually means recognizing revenue as usage occurs, so prepaid credits sit as deferred revenue until they are consumed.
When are prepaid credits recognized as revenue under ASC 606?
Prepaid credits are deferred revenue at purchase and recognized as the customer consumes them. Breakage, meaning credits that expire unused, is recognized once the likelihood of redemption becomes remote.
Is there a difference between ASC 606 and IFRS 15 for usage-based billing?
The two standards align on the core principle of recognizing revenue as performance obligations are satisfied. Differences are mostly in disclosure and edge cases, not in the basic treatment of usage-based revenue.
Are usage-based credits a liability or revenue?
Until consumed, prepaid credits are a liability recorded as deferred revenue. They become recognized revenue as the customer uses them, or when they expire and breakage is recognized.
What is breakage in usage-based billing?
Breakage is the portion of prepaid or committed credits a customer never uses before they expire. When you can reliably estimate it from historical redemption patterns, you recognize breakage as revenue in proportion to actual usage; when you cannot, you wait until the likelihood of redemption is remote. The estimate has to be supported by data and revisited each period.
How are promotional credits accounted for?
Promotional credits granted for free are a marketing expense, not deferred revenue. They carry no customer payment, so consuming them recognizes no revenue. The accounting risk is treating them like paid credits, which inflates both deferred revenue and recognized revenue. Tracking promotional grants separately from paid grants keeps them out of the revenue line.