Credits-Based Billing
How Prepaid Credits, Drawdown, and Revenue Recognition Work
Credits-based billing is becoming the default pricing model for AI products: customers prepay for token credits or agent credits, and usage burns the balance down. This guide covers the full mechanics (grants, drawdown, expiry, refills), how credits compare to pure usage and subscriptions, and the part most guides skip: the deferred revenue accounting behind every credit pack.
Credits-Based Billing Definition
Credits-based billing is a pricing model where customers prepay for a bundle of credits and consumption draws the balance down. Each metered unit of usage (tokens, API calls, agent runs) burns credits at a defined rate, blending the upfront commitment of a subscription with the flexibility of usage-based pricing.
Also written credit-based billing; the drawdown itself is often called credit burndown.
Why credits are taking over AI pricing
Token packs, per-agent credits, monthly credit allowances: the pattern shows up everywhere in AI because it solves four problems at once.
Cash lands upfront
A credit pack is prepaid. The company collects the full amount at purchase instead of metering usage for a month and hoping the invoice gets paid, which shortens the cash cycle dramatically for capital-hungry AI companies.
Committed spend without a subscription
Buying a pack of token credits or agent credits is a commitment, but a flexible one: the customer commits dollars, not a fixed monthly plan, and consumes at whatever pace their workloads actually run.
Price abstraction over shifting model costs
Underlying inference costs change constantly as models, providers, and context windows evolve. Pricing in credits (1 credit = X tokens or Y agent runs) lets a company reprice the rate card inside the credit without touching the headline price.
A gentler on-ramp than pure usage
Pure pay-as-you-go creates bill anxiety. Prepaid usage credits cap the downside for the buyer (spend what you loaded, no surprise invoice) while preserving usage-based upside for the seller through refills and overage.
Credits sit on top of the same metering foundation as usage-based billing: the model only works if every consumed unit is captured by a reliable usage metering pipeline.
How the mechanics work: from purchase to burndown
Six moving parts, and every one of them is a place where the balance the customer sees can drift from the usage the meter recorded.
Purchase
The customer buys a credit pack, either self-serve (card payment, cash in immediately) or on contract (an invoice creates a receivable). Either way, the dollars arrive before the usage does.
Credit grant
The purchase creates a grant: a credit balance on the account with a size, a start date, and usually an expiry date. Enterprise deals often layer multiple grants (an annual pool plus promotional or trial credits) with different terms.
Drawdown against metered usage
As the product meters usage (tokens, API calls, agent runs, minutes), each unit burns credits at the rate card's conversion rate. This credit burndown is the live link between the metering pipeline and the balance, and it has to tie exactly.
Rate cards inside the credit
The conversion rate is its own pricing layer: 1 credit might equal 1,000 tokens on one model and 200 on another, with premium features burning at a multiplier. Rate card changes mid-grant are where drawdown math most often silently diverges from what was sold.
Expiry and rollover
Grants typically expire (12 months is common). Some plans roll unused credits into the next period, often capped. Expiry and rollover rules decide what happens to the unconsumed balance, which makes them revenue recognition inputs, not just product settings.
Auto-refill, top-ups, and overage
When the balance runs low, auto-refill buys the next pack automatically, or the customer tops up manually. If usage continues past a zero balance, it either hard-stops the product or spills into overage billed in arrears at a per-unit rate.
Credits vs. pure usage-based vs. subscription
Credits are not a third unrelated model. They are usage-based consumption with subscription-style cash timing, and they inherit the accounting complexity of both.
| Dimension | Credits-based | Pure usage-based | Subscription |
|---|---|---|---|
| What the customer pays for | A prepaid bundle of credits, consumed by usage over time. | Actual metered usage, billed in arrears each period. | A fixed fee for a period of access, regardless of usage. |
| Cash timing | Upfront, at pack purchase. | After consumption, when the invoice is paid. | Start of each period (or annually upfront). |
| Revenue recognition | Deferred at purchase, recognized as credits are consumed, with a breakage estimate for expected expiry. | Recognized as usage occurs, often via the right-to-invoice expedient. | Recognized ratably over the service period. |
| Bill predictability for the buyer | High: spend is capped at the loaded balance until a refill. | Low: the invoice moves with every workload spike. | Highest: the same number every period. |
| Repricing flexibility for the seller | High: adjust the credit conversion rate without changing the headline price. | Medium: per-unit price changes are visible immediately. | Low: plan changes are public and churn-risky. |
| Reconciliation burden | Highest: grants, drawdown, balances, expiry, and deferred revenue all have to tie. | High: metered usage must tie to rated invoices. | Low: fixed amounts on a fixed schedule. |
Revenue recognition for prepaid credits: a worked example
This is the part most credits guides skip, and the part your auditors will not.
A credit purchase is not revenue. Under ASC 606 and IFRS 15, the customer has paid before the service was delivered, so the full amount is deferred revenue, a contract liability on the balance sheet. Revenue is then recognized as the credits are consumed, because consumption is when the performance obligation is actually satisfied. Suppose a customer buys a $60,000 credit pack and burns 20% of it in the first month.
| Event | Journal entry | Why |
|---|---|---|
| Customer buys a $60,000 credit pack | Dr Cash (or Accounts Receivable) $60,000 Cr Deferred Revenue $60,000 | No revenue yet. The full amount is a contract liability: an obligation to deliver the service the credits represent. |
| Month 1: customer consumes 20% of the credits | Dr Deferred Revenue $12,000 Cr Revenue $12,000 | Recognition follows consumption. Each period, the recognized amount is the consumed share of the pack, driven by metered, corrected usage. |
| Each following month, as consumption continues | Dr Deferred Revenue (consumed share) Cr Revenue (consumed share) | The deferred revenue balance should always equal the dollar value of unconsumed, unexpired credits. If it does not, something upstream is broken. |
Breakage: credits that expire unused
Some credits will never be consumed. If historical data supports a reliable estimate (say, 8% of credits typically expire), the expected breakage is recognized as revenue proportionally as customers consume the rest, not held until expiry. If no reliable estimate exists, breakage waits until redemption becomes remote. Either way, estimating breakage is a variable-consideration style judgment that auditors test: they will ask for the historical consumption data behind the percentage and evidence that the estimate is updated each period.
The two wrong ways to do this
Recognizing on purchase books revenue for a service not yet delivered: it overstates current-period revenue, understates the liability, and unwinds badly under audit. Recognizing on invoice is the same error with a delay; the invoice date has nothing to do with when credits are consumed.
The only defensible pattern is recognition on consumption, driven by corrected metered usage, which is the same discipline covered in our usage-based revenue recognition guide and in the revenue recognition docs.
Where credits-based billing breaks operationally
Selling credits is easy. Reconciling them is the hard part, and it is the subledger's job.
Credit balances live in a spreadsheet
The billing system knows what was sold and the product knows what was used, but the balance connecting them is a tab someone updates by hand. The moment volume or grant complexity grows, the spreadsheet is wrong and nobody knows by how much.
Drawdown does not tie to metered usage
The balance is decremented by an approximation (or a stale rate card) instead of the corrected usage the meter actually recorded. Late-arriving and corrected usage events make this worse: the burndown was computed before the usage data was final.
Negative balances nobody notices
Usage keeps flowing after the balance hits zero and nothing stops it or bills it. That consumption is free service delivered, unbilled revenue leaking in real time until someone reconciles the account.
Expiry that is never enforced
Grants have expiry dates on paper, but expired credits stay spendable in the product. That breaks the breakage estimate, overstates the customer's entitlement, and quietly rewrites the economics of every pack sold.
Deferred revenue does not tie to unconsumed credits
The single scariest one at audit time: the contract liability on the balance sheet should equal the dollar value of outstanding credits, and when drawdown, grants, and the GL are maintained in three disconnected systems, it rarely does.
How LedgerUp reconciles credits
LedgerUp is a revenue subledger built for exactly this: it reconciles credit grants, corrected usage, and per-account balances continuously, ties deferred revenue to unconsumed credits, and produces journal-ready entries. The LedgerUp Engine API exposes grant totals, corrected usage totals, and balances per account, so the number finance closes on is the number the product displays.
Related Guides
Credits-Based Billing FAQ
What is credits-based billing?
Credits-based billing (also written credit-based billing) is a pricing model where customers prepay for a bundle of credits and consumption draws the balance down. Each metered unit of usage, such as tokens, API calls, or agent runs, burns credits at a defined conversion rate. It blends the upfront commitment of a subscription with the flexibility of usage-based pricing, which is why it has become the default model for AI products.
How is credits-based billing different from usage-based billing?
In pure usage-based billing, the customer pays in arrears for what they actually consumed each period, so the invoice varies and the vendor carries the receivable. In credits-based billing, the customer pays upfront for prepaid usage credits and then consumes against that balance. The metering is identical underneath; what changes is cash timing (upfront vs. in arrears), bill predictability (capped at the balance vs. open-ended), and revenue recognition (deferred and recognized on consumption vs. recognized as billed).
How do you recognize revenue on prepaid credits?
A credit purchase is deferred revenue, a contract liability under ASC 606 and IFRS 15, because the customer paid before the service was delivered. Revenue is recognized as credits are consumed: each period you recognize the dollar value of the credits actually burned, releasing that amount from deferred revenue. If credits are expected to expire unused, the anticipated breakage is recognized in proportion to the pattern of consumption, based on a supportable estimate.
What happens when credits expire unused (breakage)?
Unused, expired credits are called breakage. If a company can reliably estimate breakage, it recognizes the expected breakage amount as revenue proportionally as customers consume their credits, rather than waiting for expiry. If it cannot make a reliable estimate, it waits until the likelihood of redemption becomes remote (typically at expiry). The breakage estimate is a variable-consideration style judgment that auditors test: it must be supported by historical consumption data and updated each period.
Should credits expire?
Expiry is a commercial and accounting tradeoff. Expiring credits create urgency to consume, protect the vendor from carrying an open-ended obligation, and generate breakage revenue. But aggressive expiry feels punitive, invites churn conversations, and in some jurisdictions runs into gift card style consumer protections. A common middle ground for B2B is 12-month expiry aligned to the contract term, with rollover for customers who renew.
How do AI companies price with credits?
The usual pattern is a credit pack or monthly credit allowance, a rate card that converts credits into product units (1 credit = X tokens on a given model, Y agent runs, or Z minutes), burn multipliers for premium models or features, and auto-refill when the balance runs low. Credits give AI companies cash upfront and committed spend, and the conversion layer lets them reprice as underlying model costs shift without changing the headline price of a pack.
How do you reconcile credit balances?
Reconciling credits means proving that grants minus drawdown equals the balance, for every account, using corrected metered usage rather than an approximation. In practice that is a periodic tie-out: total credits granted, minus credits burned per the usage meter at the contractual rate card, minus expired credits, should equal the outstanding balance, and the dollar value of that balance should equal deferred revenue on the books. This is a subledger job: it requires account-level detail that a billing engine and a GL, on their own, do not maintain together.
What are the journal entries for a credit pack?
At purchase of a $60,000 pack: debit Cash (or Accounts Receivable if invoiced) $60,000, credit Deferred Revenue $60,000. In a month where the customer consumes 20% of the credits: debit Deferred Revenue $12,000, credit Revenue $12,000. Repeat as consumption continues, so that deferred revenue always equals the value of unconsumed credits. Estimated breakage is recognized proportionally alongside consumption, and any remaining balance is released when the credits expire.
Can you combine credits with a subscription fee?
Yes, and hybrid plans are increasingly common: a platform subscription fee (recognized ratably) plus a credit allowance or purchasable credit packs (deferred and recognized on consumption). Under ASC 606 the two are typically distinct performance obligations, so the transaction price is allocated between them and each follows its own recognition pattern. The operational catch is that one invoice now feeds two different recognition schedules, which is exactly the kind of split a revenue subledger exists to keep straight.
How does LedgerUp handle credits-based billing?
LedgerUp is an AI revenue subledger: it reconciles credit grants, corrected metered usage, and per-account balances continuously, catches negative balances and unenforced expiry before they become leakage, ties deferred revenue to unconsumed credits, and produces journal-ready ASC 606 / IFRS 15 entries. The LedgerUp Engine API exposes grant totals, corrected usage totals, and balances per account, so finance and product are always looking at the same number.