Back to blog
Revenue Recognition for Usage-Based Billing: When Credits Become Revenue
Insights

Revenue Recognition for Usage-Based Billing: When Credits Become Revenue

BBen Foster
Ben Foster
|

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.

ModelWhat is being soldWhen revenue is recognized
EntitlementAccess and availabilityOver time (ratable)
CommitmentMinimum usageOn consumption
Pre-funded top-upsPrepaid usageOn 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.