Revenue Recognition Timing for Prepaid Credit Sales
Prepaid credit sales look like the simplest accounting problem in software: a customer wires $10,000, the company books $10,000, done. Under ASC 606 and IFRS 15, that intuition is wrong, and wrong in a way that has landed real companies in real trouble with the SEC. Revenue recognition for prepaid credits depends on when and how customers actually consume what they bought, not on when the cash lands. That distinction, and the mess that follows when finance teams miss it, is what this piece works through.
When a customer prepays $10,000 for credits, the cash hits the bank that same day, but none of it becomes revenue on day one. It sits on the balance sheet as a deferred revenue liability until the company delivers what it promised, which in practice means until the customer burns through the credits. Deferred revenue isn't income waiting in a lobby somewhere; it's a liability, an obligation owed in the form of future service. The income statement is supposed to track delivery, not cash collection, and blurring the two is exactly the pattern examiners are trained to catch.
I've sat across from an auditor who pulled a spreadsheet apart line by line because a client had recognized a chunk of prepaid revenue the week the wire cleared, not the week the credits got used. It took three weeks to unwind. The recognition policy can't be something you write once and file away; it has to live inside the contract template from day one, because by the time an examiner asks the question, it's too late to build the answer.
How the five-step ASC 606 model applies to a prepaid credit sale, step by step
ASC 606 is the U.S. GAAP standard; IFRS 15 is its international twin. They share the same five-step skeleton but split on a few technical points, one being the collectibility threshold: ASC 606 sets it around 75 to 80%, IFRS 15 at 50%. That gap rarely changes the outcome for prepaid credit deals, but know which standard governs before running the rest of the model.
Identifying the contract sounds like a formality until you hit terms allowing refunds or letting credits lapse without penalty. Those clauses decide whether a contract even exists in the accounting sense, and they resurface later when we get to breakage.
The real judgment call sits in step two: identifying the performance obligation. Is the company promising continuous access, a stand-ready obligation recognized over time no matter how much gets used? Or a specific quantity of units, recognized only as those units get consumed? Most prepaid credit setups fall into the second bucket, and contract language decides this, not the sales team's mental model of what the product does.
Determining the transaction price starts simple (the total amount prepaid), then gets messy the moment breakage estimates and variable usage show up. We'll get to that.
Allocating the price is trivial with one performance obligation. It gets genuinely hard with hybrid plans bundling seat access and credit burn, since each piece needs its own logic and its own math.
Step five is the operating principle underneath everything else here: recognize revenue as credits are consumed. Most of what follows in this piece is an elaboration of that single sentence.
KPMG's December 2025 Software and SaaS Revenue Handbook notes that shifting business models keep generating new judgment calls around performance obligations and price allocation. The five steps are settled law at this point, but their application to token-based and usage-based AI pricing is not, and companies building those products are laying the road as they drive on it.
Mapping credit consumption to the moment of recognition in practice
Easy to say, hard to build: revenue gets recognized as credits are consumed, not when they're purchased. The hard part is defining "consumed" precisely enough that a finance system can act on it without someone checking every entry by hand.
An API call that draws down a token balance triggers recognition the instant that request processes, not when the invoice goes out weeks later. A batch job triggers recognition on completion. Credits with rollover provisions just sit as deferred revenue until used or expired; rollover doesn't accelerate anything, it stretches out how long the liability stays on the books.
None of this works without usage data accurate to somewhere close to real time. If billing can't tell finance exactly how many credits a customer burned in a given window, the revenue number for that period is a guess wearing a suit. Usage events in AI products fire fast, thousands of times a second in some deployments, and a system that batches or approximates that data introduces small timing errors that compound quietly and show up three weeks later as a reconciliation headache nobody budgeted time for.
Accurate recognition needs an event log that's complete, timestamped, and attributed correctly to the customer and plan, not stitched together after the fact from partial records. Miss that infrastructure, and finance teams end up hand-reconciling billing discrepancies instead of pulling numbers from a ledger they trust. Call it what it actually is: a metering gap, not a finance gap.
Breakage: recognizing revenue from credits that will never be used
Breakage is the slice of prepaid credits a customer buys and never redeems (the ones that expire on the shelf or get abandoned mid-contract). Sounds like a footnote, but it isn't. For some subscription and credit businesses breakage is a meaningful share of total revenue, and getting the timing wrong on it is a real misstatement, not a rounding error.
Unredeemed credits represent an obligation the company will never fulfill. That means revenue sits behind them, already earned in effect, since the service never has to be delivered. ASC 606 is specific about when that revenue can actually hit the books, though.
If a company can reasonably estimate what share of credits will go unused, it recognizes breakage proportionally, as customers redeem the credits they do use, rather than all at once at expiration. That's the proportional method: for every dollar of credits actually consumed, the company books a proportional slice of the breakage expected across that cohort. When it can't estimate reliably, recognition waits until redemption becomes remote, and that shows up later as a lump instead of a smooth line.
"Reasonably estimable" is not a low bar. It demands historical cohort data, a track record of what percentage of each cohort typically goes unredeemed, and that estimate has to hold up at every reporting date, not just the day the contract was signed.
Luckin Coffee's FY2025 SEC filing lays this out cleanly for prepaid coupons: revenue stays deferred until redemption, with estimated breakage recognized in proportion to the pattern of rights customers actually exercise. Worth reading if you want to see the proportional method applied in a real filing instead of a textbook example.
The cautionary tale runs the other direction. Cambium Networks restated financials for FY2022, FY2023, and interim 2024 periods after its Audit Committee found the variable consideration models hadn't kept pace with information available at each reporting date. An estimate that was reasonable once and never got updated stops being reasonable, and auditors eventually notice. A company that can't track which credits get consumed, by which customers, in which cohorts, has no shot at building the dataset the proportional method demands.
How committed minimums and overages change the recognition calculation
Most AI API contracts aren't pure prepaid deals. They're a committed minimum, say $50,000 a year, plus usage-based overage once the customer blows through the floor. Two different accounting events, one contract.
The committed minimum is fixed consideration, recognized ratably as service gets delivered, regardless of actual consumption. The overage is variable consideration under ASC 606-10-32-5 through 32-16, meaning it gets estimated, constrained, and recognized only as usage actually happens.
The constraint is the part people skip. A company can only fold variable amounts into the transaction price if it's probable that a significant revenue reversal won't happen later, and there's no recognizing overage on a hopeful guess about what a customer might use next quarter.
Which method applies depends on what the company actually promised. Continuous platform access is a stand-ready obligation, measured with a time-based method, recognized ratably. A specific number of successful outcomes calls for an output method, recognized as each outcome lands. Deloitte's June 2026 Technology Spotlight on agentic AI pricing flags this as the central judgment call in outcome-based AI arrangements, and that's no overstatement; misclassify it and the whole recognition schedule for the contract drifts off course.
Hybrid seat-plus-credit plans stack the difficulty further. Seat revenue goes ratably, credit revenue goes as consumed, and the two streams need separate tracking and separate allocation. Most legacy billing systems were never built to handle a committed minimum and variable overage together, let alone alongside a seat fee. That gap is exactly where spreadsheets quietly crawl back into finance teams that thought they'd automated past them.
What expiring credits, refunds, and plan migrations do to deferred revenue balances
Credits with expiration dates sit as deferred revenue until the clock runs out. If breakage has been recognized proportionally the whole way through, whatever estimate remains gets booked at expiration. When it hasn't, the entire remaining balance waits for redemption to become remote before it moves anywhere near the income statement.
Refund provisions complicate things further. A customer who can demand money back for unused credits changes how the transaction price gets calculated at the outset, and that refund right needs its own liability, separate from deferred revenue. Blend the two together and the balance sheet understates the real obligation, quietly and without anyone noticing until someone goes looking.
Plan migrations are their own animal. A customer who upgrades or downgrades mid-period leaves behind unused credits that need consistent treatment, either carried forward as deferred revenue under the new plan or recognized if the old obligation is genuinely gone. Under ASC 606 that migration might be a contract modification, or it might be an entirely new contract, and which one applies hinges on whether the new plan adds distinct goods or services priced at standalone selling price. Different paths produce different timing, and this isn't a technicality; it changes the actual numbers on the page.
Practically, the billing and revenue system has to re-run the deferred revenue balance and breakage estimate at the moment of modification, not once at signing and never again. Every adjustment needs a paper trail: what triggered it, when, how the estimate moved. Auditors ask for that trail, and "we're pretty sure" does not survive the follow-up question.
Why metering accuracy is a revenue recognition control, not just a product feature
Because recognition ties directly to consumption, the income statement is only as good as the usage data underneath it. Metering isn't a backend detail. It's a revenue recognition control, and it deserves the same scrutiny as any other internal control over financial reporting, no less.
The metering stack has three jobs it cannot fail at: complete event capture, with no gaps from network hiccups or traffic spikes; accurate timestamping, because an event processed after period close but which actually happened before it creates a prior-period adjustment nobody wants to walk an auditor through; and correct customer and plan attribution, so each event draws down the right balance instead of someone else's.
AI products push all three toward the breaking point. Consumption events fire at volumes older billing architectures were never built for, and a metering layer that batches or approximates rather than capturing events live introduces a consistent bias, not noise that averages out, but the same error showing up at every close. Weak metering turns month-end into a manual slog, finance stops trusting the deferred revenue figure, and breakage estimates can't get built because the cohort data underneath them has holes in it.
Auditors know this. When they evaluate revenue recognition under ASC 606, the reliability of the usage data pipeline is part of how they judge the company's whole estimation process, which makes metering an audit committee question now, not just an engineering one.
Flexprice's infrastructure is built around exactly this gap: sub-50ms P99 latency on event ingestion, over 10 billion API requests processed monthly, real-time credit balance tracking. The throughput number isn't the point. What matters is that the usage record finance needs is accurate the moment consumption happens, instead of something reconstructed during close from three logs that don't quite agree with each other.
How to structure a revenue recognition policy for prepaid credits that holds up under audit
A written policy needs four things nailed down: the performance obligation for each contract type (whether stand-ready access, unit delivery, or some blend); the breakage estimation method, proportional or remote, along with the actual historical data backing it; how contract modifications get classified when plans change; and how each distinct structure (pay-as-you-go, committed minimum plus overage, hybrid seat and credit) gets accounted for on its own terms instead of forced into one template.
Estimation models have to run on information available at each reporting date, not the information available when the ink dried on the contract. Cambium Networks is the object lesson here, worth keeping taped to the wall of whatever team builds this policy.
Cohort data is non-negotiable: at minimum, a rolling history of issuance, consumption, and expiration broken out by segment, detailed enough to actually support whatever breakage rate the policy claims. A rate without a dataset behind it is a guess with a decimal point attached.
Public companies carry a disclosure obligation too, on the transaction price allocated to remaining performance obligations and when they expect to recognize it. Deferred revenue balances and breakage estimates both feed that disclosure, so the internal numbers and the external filing have to tie out exactly, not approximately.
None of this scales by hand. A prepaid credit recognition policy has to be enforced by the billing system itself, generating audit-ready logs and flagging drift the moment actual consumption departs from what the estimates predicted. Building that in-house (event ingestion, real-time balance tracking, deferred revenue logic) takes months of engineering and then demands upkeep every time pricing changes, which for most AI companies is often. Infrastructure like Flexprice handles that layer directly, so finance closes the books on data that was already correct rather than data someone had to go rebuild by hand at 11pm before a board meeting.
The companies that get this right treat revenue recognition as ongoing maintenance, not a quarterly checkbox. Estimation models get revisited every period, metering data gets validated continuously, and new pricing structures get tested against the recognition logic before launch, not after finance discovers, three weeks into close, that nobody ever accounted for the new plan at all.
