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.
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.

