Billing prepaid credits and AI usage: from drawdown to deferred revenue and breakage
Prepaid credits revenue recognition, step by step: usage drawdown, contract liability, and breakage under ASC 606, with a worked example of both methods.
Part of the subscription and usage billing guide.
Prepaid credits revenue recognition follows one rule: the cash is a contract liability until the customer uses the credits, and each use is revenue. Credits the customer will never use are breakage. ASC 606 recognizes breakage in proportion to usage if you can estimate it, or when further use becomes remote if you cannot. The accounting is short. The hard part is the record chain: usage event, credit drawdown, invoice, contract liability balance and breakage estimate, each held in a different system. This post walks that chain and works one hypothetical credit package through a year under both breakage methods.
Key takeaways
- A prepayment for credits is a contract liability from the date it is paid or due, whichever is earlier (ASC 606-10-45-2 and 55-46).
- Revenue follows usage. Each credit drawn down transfers service, so it moves from the contract liability to revenue.
- Breakage has two methods. Proportional, if you expect to be entitled to it and the estimate passes the variable consideration constraint. Remote, if you do not (ASC 606-10-55-48).
- The method changes timing, not the total. In our hypothetical example, the year-end total is $100,000 either way, but the Q3 contract liability is $22,500 under one method and $38,000 under the other.
- Unclaimed property can block breakage. Amounts you must remit to a government are a liability, not revenue (ASC 606-10-55-49).
- Loopfour, the deterministic finance workflow automation platform, builds the drawdown-to-ledger workflow and the monthly reconciliation between the credit ledger and the GL.
Why prepaid credits are a contract liability
A nonrefundable prepayment for credits obliges you to stand ready to deliver service later, so it is a contract liability, not revenue. ASC 606-10-55-46 says the liability is derecognized, and revenue recognized, as the goods or services are transferred (ASU 2014-09). For a credit plan, that transfer is the customer's usage.
The timing of the liability depends on payment, not on the invoice date. Under 606-10-45-2, the contract liability is recorded when the customer pays or the payment falls due, whichever is earlier. An invoice for a credit package issued on net 30 and still unpaid at month-end is not yet on the balance sheet. Many teams call the balance deferred revenue; for that definition, see what deferred revenue is.
The record chain from usage event to ledger
Every dollar of credit revenue should trace from a usage event to a GL entry through six records. If one link is missing, the contract liability cannot be proven at audit.
usage event → rated credit drawdown → credit ledger balance → invoice and payment → contract liability rollforward → breakage estimate → GL entry
| Record | Usually lives in | What it proves | Owner |
|---|---|---|---|
| Usage event (API call, token count, job run) | Product database or metering tool | The service was delivered | Engineering |
| Rated drawdown (credits per event) | Metering or billing system | How many credits each event consumed, at contract rates | Billing operations |
| Credit ledger (balance per customer, per grant) | Billing system | Credits purchased, used, expired and remaining | Billing operations |
| Invoice and payment | Billing system, then ERP | When the liability arose | AR |
| Contract liability rollforward | ERP and a reconciliation schedule | Opening balance, additions, revenue, breakage, closing balance | Revenue accounting |
| Breakage estimate | Memo and schedule | The rate used and why it passes the constraint | Controller |
Keep grants separate in the credit ledger. A customer who buys a second package before the first expires has two balances with different expiry dates. If the ledger pools them, you cannot say which credits expired. For keeping the meter itself accurate, see how to meter and reconcile usage-based billing.
How does ASC 606 treat breakage?
ASC 606 treats breakage as revenue only when you are entitled to it, and the timing depends on whether you can estimate it. Paragraph 606-10-55-48 sets two paths:
| Proportional method | Remote method | |
|---|---|---|
| When it applies | You expect to be entitled to a breakage amount | You do not expect to be entitled to breakage, or cannot estimate it reliably |
| Timing | Expected breakage recognized in proportion to the pattern of rights the customer exercises | Remaining balance recognized when the likelihood of use becomes remote, often at expiry |
| Test | The variable consideration constraint (606-10-32-11 to 32-13): a significant revenue reversal must not be probable | None beyond assessing when use is remote |
| Evidence needed | History of usage and expiry for similar customers and plans | Expiry terms or evidence the customer has stopped using the service |
Many new credit plans start on the remote method. Aprio notes that for young AI companies, "the conservative and 'remote' method often applies," because there is no usage history yet (Aprio). Deloitte's Roadmap applies the same two paths and the same link to the constraint (Deloitte 8.8).
Unclaimed property comes first. If you must remit unused amounts to a government entity, 606-10-55-49 requires a liability for those amounts, not revenue. Aprio describes whether unclaimed property laws reach prepaid AI credits as "a genuinely open question." Get a legal view before you book any breakage.
Worked example: one credit package, both methods
This example is hypothetical, and every figure is illustrative. On January 1, a customer pays your company $100,000 for 100,000 credits, nonrefundable, expiring December 31. The customer uses 20,000 credits in Q1, 24,000 in Q2, 18,000 in Q3 and 14,000 in Q4. The remaining 24,000 credits expire unused.
The proportional method
Under the proportional method, each credit used releases its own value plus a share of the expected breakage. Suppose the company's history for this plan supports an expected breakage of 20%, and the estimate passes the constraint. Expected usage is 80,000 credits, so each credit used releases $1.25 of the $100,000 ($100,000 divided by 80,000).
| Quarter | Credits used | Revenue on usage | Revenue at expiry | Total revenue | Contract liability at quarter-end |
|---|---|---|---|---|---|
| Q1 | 20,000 | $25,000 | $25,000 | $75,000 | |
| Q2 | 24,000 | $30,000 | $30,000 | $45,000 | |
| Q3 | 18,000 | $22,500 | $22,500 | $22,500 | |
| Q4 | 14,000 | $17,500 | $5,000 | $22,500 | $0 |
| Year | 76,000 | $95,000 | $5,000 | $100,000 |
Actual breakage (24%) came in above the 20% estimate, so $5,000 is left when the credits expire. In practice, you update the estimate each reporting period, and the change flows through as a catch-up adjustment. The example holds the estimate steady to keep the arithmetic visible.
The remote method
Under the remote method, each credit used releases $1, and the unused balance waits until use is remote. Here that is the expiry date.
| Quarter | Credits used | Revenue on usage | Revenue at expiry | Total revenue | Contract liability at quarter-end |
|---|---|---|---|---|---|
| Q1 | 20,000 | $20,000 | $20,000 | $80,000 | |
| Q2 | 24,000 | $24,000 | $24,000 | $56,000 | |
| Q3 | 18,000 | $18,000 | $18,000 | $38,000 | |
| Q4 | 14,000 | $14,000 | $24,000 | $38,000 | $0 |
| Year | 76,000 | $76,000 | $24,000 | $100,000 |
The two methods recognize the same $100,000, but Q4 revenue is $22,500 under one and $38,000 under the other. For a company with thousands of packages expiring on different dates, that timing difference drives monthly revenue. It is also why the method and the rate need a documented owner.
Want to see your credit ledger reconciled to the GL? Book a workflow review.
The monthly contract liability rollforward
The monthly rollforward for prepaid credits has one more line than a subscription rollforward: breakage. Using the proportional method for Q3 of the example:
| Contract liability, Q3 | Amount | Source |
|---|---|---|
| Opening balance, July 1 | $45,000 | Prior quarter's closing schedule |
| Add: credit purchases paid or due | $0 | Billing system invoices and payments |
| Less: revenue on credits used (18,000 x $1.00) | ($18,000) | Rated drawdowns from the credit ledger |
| Less: breakage recognized in proportion to usage (18,000 x $0.25) | ($4,500) | Breakage schedule at the approved rate |
| Less: breakage recognized at expiry | $0 | Credit ledger expiry records |
| Closing balance, September 30 | $22,500 | Agrees to the GL |
Then reconcile the credit ledger to the GL. At September 30, the ledger shows 38,000 unused credits, or $38,000 at the purchase rate. The GL shows $22,500. The $15,500 difference is breakage already recognized on the credits used to date: 62,000 credits used multiplied by $0.25. If the difference is anything else, a drawdown, a grant or a manual adjustment is missing.
Billing decisions that shape the accounting
A handful of contract terms decide how clean the accounting is, so finance should review them before a credit plan launches.
| Term | Why finance cares |
|---|---|
| Expiry date | Without one, the remote method can leave a liability on the books indefinitely |
| Refundability | Refundable credits are not breakage; unused amounts may be a refund liability |
| Rollover of unused credits | Extends the liability and the period over which breakage is estimated |
| Overage after credits run out | Billed in arrears as usage; revenue and a receivable, not a drawdown |
| Credits per unit of usage by product | Must match the contract rate table used to rate each event |
| Free or promotional credits | Need a separate analysis; this post covers paid credits only |
For recognition on usage plans more broadly, including overage and tiered rates, see how to recognize revenue for usage-based consumption plans.
Who approves the breakage estimate?
The controller should own and approve the breakage estimate each quarter, with revenue accounting preparing it. The estimate is a judgment that moves revenue, so it needs the same control as any other accounting estimate.
A quarterly breakage review covers four steps:
- Pull usage and expiry history by plan and customer segment from the credit ledger.
- Compute the breakage rate on expired grants only, so open grants do not distort it.
- Test the constraint. Document why a significant reversal is not probable, or stay on the remote method.
- Approve and record. The controller signs off, and the approved rate is the only rate the schedule uses until the next review.
Where Loopfour fits
Loopfour builds and runs the workflow from rated drawdowns to the GL, so the credit ledger and the contract liability agree every month. The flow:
usage events from your metering tool → drawdowns rated on contract rules → credit ledger updated per grant → invoices and payments synced from Stripe → contract liability rollforward and breakage at the approved rate → differences routed to revenue accounting in Slack → controller approves the entry → posted to NetSuite, QuickBooks or Sage Intacct
Rating, drawdown and posting run on predefined rules, so the same usage produces the same entry every time. The breakage rate is an input the controller approves, not a figure the workflow invents. We build it, run it and maintain it. More on billing is in our subscription and usage billing hub.
Frequently asked questions
How do you recognize revenue on prepaid credits?
Record the prepayment as a contract liability when it is paid or due, whichever is earlier. Recognize revenue as the customer uses credits, because each use transfers the service. Unused credits that will never be redeemed are breakage, recognized under ASC 606-10-55-48.
What is breakage revenue?
Breakage is the part of a nonrefundable prepayment that customers never use. ASC 606 recognizes it in proportion to the customer's usage if the company expects to be entitled to it, or when the chance of the customer using the rest becomes remote if it does not.
When can we use the proportional method for breakage?
Use the proportional method when you expect to be entitled to a breakage amount and the estimate passes the variable consideration constraint, meaning a significant revenue reversal is not probable. That usually requires a history of credit usage and expiry for similar customers and plans.
Are unused AI credits always revenue when they expire?
Not always. If a company must remit unused amounts to a government under unclaimed property laws, ASC 606-10-55-49 requires a liability, not revenue. Whether those laws reach prepaid AI credits is a legal question; Aprio describes it as open.
Do credits that never expire ever become revenue?
Credits with no expiry stay a contract liability until they are used or the likelihood of use becomes remote, unless the company can estimate breakage under the proportional method. Without an expiry date or reliable history, the liability can stay on the balance sheet for a long time.
Where should the credit balance live: billing system or ERP?
The per-customer credit balance usually lives in the billing or metering system, and the contract liability lives in the ERP. The two must reconcile every month, credit by credit converted to dollars, with the breakage estimate shown as a separate line.
Conclusion
Prepaid credits revenue recognition is simple in principle: liability on payment, revenue on use, breakage under one of two methods. What makes it hold up is the record chain: every drawdown rated on contract terms, every grant tracked to expiry, and a breakage rate the controller approves. Build that chain before the credit plan scales, and the year-end audit becomes a reconciliation, not a reconstruction.
Tell us the one workflow your team dreads. We will show it running. Book a demo.