Unearned Revenue Recognition in Subscription and Prepaid Models

Unearned revenue recognition is a settled accounting problem for flat subscriptions and an unsettled one for everything else. That distinction, not any ambiguity in the standard itself, is the subject of this piece: where the rule holds, where it strains, and why the systems recording consumption, not the accounting policy on file, now decide whether a company's revenue numbers hold up.

Deferred revenue and liability classification

Revenue recognition under ASC 606 runs on a simple premise: a company earns revenue when it satisfies a performance obligation, not when a customer's payment clears. A prepayment is a liability, not income the moment it lands in the bank, because the company still owes the customer something it has not yet delivered. It sits on the balance sheet as deferred revenue until the obligation underneath it gets fulfilled.

The five-step model that governs this process identifies the contract, identifies the performance obligations within it, determines the transaction price, allocates that price across the obligations, and recognizes revenue as each obligation is satisfied. Every dollar a company collects has to pass through this sequence before it can move from deferred revenue to recognized revenue. For a single, uniform promise, like continuous access to a piece of software, that sequence resolves cleanly. The complications in this piece all trace back to what happens when a contract stops looking like that.

How flat subscriptions satisfy the recognition rule

When the price is flat, monthly or annual, that's the case ASC 606 handles best. There's one performance obligation, delivery happens evenly over time, the price is fixed, and the schedule for releasing deferred revenue into recognized revenue is set the day the contract is signed. Monthly plans recognize revenue day by day across the billing period, and annual prepayments record the full amount as a liability on day one, then release it evenly across twelve months. The accounting simply tracks the service as it's delivered. No one has to estimate anything or revisit a judgment call later.

That means every entry traces back to a contract term, and the path from cash receipt to recognized revenue is a straight line an auditor can follow without friction. It also means the finance function built around this model, the ERP configuration, the close process, the audit checklist, all got built around one quiet assumption: that revenue schedules are fixed in advance and don't need to change once set. That assumption served SaaS finance well for a long time. But it also set up nearly everyone for trouble the moment pricing stopped being flat.

Bundled obligations and mid-term modifications

A contract that bundles more than one deliverable produces the first crack in the accounting logic. Software access, white-glove onboarding, and premium analytics, say, each count as a separate performance obligation, and each gets its own allocation and its own recognition timing: onboarding recognized when a milestone is hit, analytics recognized ratably, access recognized ratably across the term. Allocating the price across those obligations needs a standalone selling price for each piece, and when you can't observe that price directly in the market, the company has to estimate it, which invites the kind of judgment call auditors tend to scrutinize.

Mid-term changes make this worse. A seat upgrade, a downgrade, a plan swap partway through a term can create what amounts to a new contract, or require the company to reallocate the remaining price prospectively, which in turn forces a catch-up calculation against whatever deferred balance is already sitting on the books. If a finance team is handling a few dozen contracts, none of this breaks. It breaks a finance team handling a few hundred, especially once those contracts carry different start dates, different bundles, and different mid-term changes, because a spreadsheet can't hold that much variation without losing its audit trail. This is the first place where subscription accounting starts to demand the kind of per-contract judgment that usage-based pricing will demand at a much larger scale.

How prepaid credit models restructure the liability

Prepaid credit models don't just add a wrinkle to revenue recognition. At the moment a customer buys a block of credits, no one, not the company and not the customer, knows when those credits will be used, how fast, or whether they'll be used at all, which changes what the liability actually represents. The full payment still gets recorded as a liability up front. But as the customer draws down the credit balance, that liability converts into recognized revenue on a schedule set by the customer's behavior, not by the calendar the contract was signed against.

Tracking that conversion requires something closer to a ledger than a schedule: a system that knows each customer's remaining balance in real time, converts every drawdown event into recognized revenue the moment it happens, and can state the deferred balance accurately at any point someone asks for it. The underlying rule hasn't changed. ASC 606 still recognizes revenue as obligations are satisfied. The definition of "satisfied" has changed to mean "consumed," and consumption happens on the customer's clock.

Unused credits raise a separate question. If a customer buys a credit block and never spends it, the liability has to convert to revenue at some point, or it doesn't, and the answer depends on contract terms, expiration policy, and an estimate of breakage, the portion of credits the company expects will never get used. Breakage can only convert to revenue once it's probable that a significant reversal won't happen later, so the company has to keep re-running that probability estimate as actual usage patterns come in, confirming or contradicting it.

Where usage-based and consumption pricing fracture ASC 606 compliance

Usage-based pricing runs on what ASC 606 calls variable consideration, and the standard's mechanism for handling it, estimation, constraint analysis, and re-measurement at every close, works fine in principle. The trouble is that each of those steps has to happen separately for every contract with a variable component, and the work scales directly with the number of such contracts a company has on its books. A handful of consumption-based contracts can be re-estimated by hand each quarter. Thousands of them turn into a compounding operational load: fresh probability weights, revised constraint analysis, and catch-up calculations, all repeating at every close, for every contract.

AI pricing makes estimation harder, because token and compute usage can swing sharply in ways historical data doesn't predict well, turning the constraint analysis, the judgment of how much variable consideration is unlikely to reverse, into a real decision rather than a formula a spreadsheet can run. The Cursor incident shows what that volatility looks like in practice: a single developer ran up a $7,225 invoice in one day after exhausting thousands of API calls and burning through the team's entire monthly AI allocation. That kind of spike produces an invoice far outside what the original variable consideration estimate assumed, which forces a retroactive re-estimation and a catch-up recognition entry after the fact. Hybrid contracts, a fixed platform fee layered with consumption-based usage, add a further wrinkle: the two components have to be split apart, each allocated its own standalone selling price, and each recognized on its own schedule, simultaneously, which multiplies the accounting work for every contract that uses the structure.

The AI pricing transition and new recognition complexity

The market has moved toward credit-based and hybrid pricing fast, and the systems finance teams rely on to account for it haven't caught up. Seventy-nine companies in the PricingSaaS 500 Index now run a credit-based pricing model, up from a much smaller share at the end of 2024. Credit ledger accounting has gone from an edge case to something close to standard practice.

Vercel charges a fixed monthly base per seat on top of metered bandwidth, serverless compute, and edge requests, with a small credit buffer covering overages, so the accounting has to combine a fixed ratable component with consumption-event recognition in the same contract. Salesforce's Agentforce runs on a per-conversation consumption model alongside seat-based access sold through add-ons, with no per-lead metering, so the consumption piece recognizes revenue at the point each interaction resolves. Intercom charges a sub-dollar fee for each resolved customer interaction on top of tiered seat-based platform fees, so the triggering event for recognition is a completed resolution, not the passage of time. GitHub Copilot switched, as of June 1, 2026, to AI Credits tied directly to token consumption, replacing its earlier Premium Request Unit structure, and the change rolled out unevenly: monthly subscribers migrated automatically that day, while annual subscribers stayed on the old request-based pricing until their plan renewed, creating different accounting treatment depending on contract type.

Each of these models produces its own deferred revenue treatment, and a company that has launched more than one product line, or migrated from one pricing archetype to another, now has to run several recognition schedules in parallel: some ratable, some triggered by discrete events, some driven by credit drawdown. AI pricing itself has cycled through seat-based, usage-based, hybrid, and outcome-based structures more than once in a short stretch of time. ASC 606 and IFRS 15 both accommodate variable consideration as a matter of principle, but the billing, ERP, and recognition infrastructure built for fixed-fee SaaS was never designed to keep applying that principle consistently while the pricing models underneath it keep changing this fast.

The billing system determines recognition defensibility, not the accounting policy

An accounting policy for variable consideration can be written correctly in every respect and still produce financials no one can defend, because the number it relies on is only as good as the usage data feeding it. If that data arrives late, arrives incomplete, or arrives inconsistent across systems, the recognized revenue figure built on top of it inherits the same flaws. The policy was never the weak link. The event record was.

For any credit-based or usage-based product, the deferred revenue balance at a given reporting date equals cash received minus the value of whatever consumption events have actually been recorded and validated by that date. An incomplete event record throws that equation off in one direction or the other: it overstates the liability and understates recognized revenue, or does the reverse, depending on which part of the pipeline dropped the data. Credit drawdown in particular demands real-time event processing, atomic updates to each customer's balance, and careful handling of race conditions when API calls arrive concurrently, because the accounting rule itself requires an accurate consumption record at every reporting date. Auditors have adjusted their expectations accordingly: they want to see the logic governing recognition at each period end directly, not a spreadsheet reconstructed after the close. The event log, the balance ledger, and the recognition schedule all have to trace back to one shared source of truth.

Companies running multiple billing codepaths for subscriptions, usage, and credits often discover at close that the three systems do not agree on the same customer's balance, requiring manual reconciliation before any recognition schedule can be trusted.

Period close for finance teams running manual or fragmented billing systems

If a finance team's billing systems can't produce a clean, event-level consumption record at period end, someone ends up doing that reconciliation by hand, which costs time and leaves the numbers exposed if an auditor pulls the thread. One SaaS operator described the problem on Reddit in plain terms: "I work at a growing SaaS startup and so far have been handling all revenue recognition in Excel. Because we are growing pretty quickly (with more products and plans), this is becoming unmanageable."

The failure patterns repeat across companies in predictable ways. Cash from a prepayment gets booked straight to revenue with no deferred revenue schedule built underneath it. Bundled contracts get collapsed onto a single recognition schedule instead of split across their separate obligations. Contracts with usage components get tracked in spreadsheets where formulas break quietly and the audit trail disappears along with them. When companies run separate billing paths for subscriptions, usage, and credits, they often find at close that the three don't agree on the same customer's balance, so nothing downstream can be trusted until someone reconciles the difference by hand.

The exposure here isn't hypothetical. A manual calculation that breaks under scrutiny is a liability on its own, separate from whatever number it was supposed to produce, and auditors are looking for a process they can trace and repeat, something other than a spreadsheet built years ago that nobody on the current team fully understands. Cash isn't revenue until the obligation behind it is satisfied, and that rule hasn't changed since ASC 606 took effect. What's changed is how hard that obligation is to pin down, and the companies still running on spreadsheets built for flat subscriptions are finding that out at exactly the moment it costs them the most.