ASC 606 Revenue Recognition for SaaS Usage Contracts

ASC 606 says a company recognizes revenue when control of a good or service passes to the customer, in the amount it expects to get paid for it. That rule was written for a world where the payment is predictable: a license fee, a flat subscription, a fixed-price contract you sign once and bill the same way for three years. Usage-based SaaS breaks that assumption in three separate places, and it breaks quietly, buried inside the accounting long before anyone notices it on a balance sheet.

Start with deferred revenue, since it trips people up fastest. A customer pays $120,000 upfront for a year of service, and that cash sits on the books as a liability until the company delivers what it promised. Under a flat subscription this is mechanical: divide by twelve, recognize monthly, done. Under a consumption contract, the amount delivered changes every month based on what the customer actually used, so the schedule has to track reality instead of a calendar. KPMG's December 2025 handbook on software and SaaS revenue recognition points out that business practices keep shifting fast enough to produce new judgment calls under ASC 606, and usage-based pricing is where most of those calls now sit. What follows walks through where, in the five-step framework, they show up.

Step 1 — Identifying the contract, and why usage agreements are harder to lock down than they look

ASC 606 sets five conditions for a valid contract: approved terms, identified rights, payment terms, commercial substance, and collectability that's probable. Each sounds like a checkbox until a usage contract tests it.

Take "approved terms" first. Plenty of API deals are click-wrap, self-serve, sign-up-and-go, priced off a rate card the customer glanced at once and never opened again. Whether that counts as mutual assent to specific terms is a real question, and no amount of wishing makes it simpler.

Collectability presents its own problem. A customer on a fixed fee gives a company something to underwrite. A customer who pays for whatever they consume gives the company a moving target, so "probable collectability" gets judged against usage that hasn't happened yet.

Then there's the gap between the day someone clicks "agree" and the day usage starts. Those two dates aren't always the same, and the difference matters, because the recognition clock and the contract clock don't have to start together. Enterprise AI deals make this worse: a master agreement with usage addendums bolted on later means every purchase order has to get classified, either as its own contract or as a modification of the master one. That single classification call ripples through every step after it.

This is a data problem before it's an accounting one. Finance needs a system that captures the contract's start date, the exact rate card version live on that date, and any minimum commitment thresholds tied to it. None of that shows up if the only record of the deal is an invoice sitting in someone's inbox.

Step 2 — Identifying performance obligations when "access" and "consumption" coexist in the same contract

Step 2 comes down to one question: is giving a customer access to a platform a separate promise from processing each unit they use on it, or is it the same promise doing double duty?

ASC 606-10-25-14 and 25-15 give a way through: series guidance. If a stream of goods or services is substantially the same and gets delivered the same way each time, the whole stream counts as one performance obligation. This provision, on its own, is what makes usage-based SaaS and AI API contracts workable at all. Without it, a company would have to account for every API call or every million tokens separately. When series guidance doesn't apply, each distinct piece needs its own treatment, and the accounting gets granular fast.

Bundling has its own traps. A setup fee that just flips on access isn't distinct from the subscription, so it gets deferred and recognized over the contract term, and configuration work that changes the software's actual code usually folds into the SaaS obligation too. Training, data migration, and implementation planning are often genuinely separate obligations, recognized as each one gets delivered.

Hybrid contracts, a seat subscription with usage overage stacked on top, create at least two obligations running on two different recognition schedules, even though they land on the same invoice line. The seat fee and the consumption fee are distinct accounting events regardless of whether the customer writes one check for both. Whatever gets decided here about how many obligations exist is what there is to allocate in Step 4. Get it wrong at Step 2, and the mistake doesn't stay put; it compounds through everything after.

Step 3 — Determining the transaction price when the customer's consumption is unknowable at contract signing

Usage fees count as variable consideration under ASC 606, since the total dollar figure depends on something that hasn't happened yet: how much the customer winds up using. Two methods exist for estimating that number, and both show up constantly in practice. The expected value method takes a probability-weighted average across possible outcomes and works well when usage could land anywhere across a wide range; the most likely amount method picks the single most probable outcome and fits better when the range is narrow or basically binary.

Either way, a constraint sits on top of whatever number gets picked: a company can only include variable consideration that isn't probable to cause a significant revenue reversal down the road. That constraint has to be documented, revisited every reporting period, and adjusted as actual usage data rolls in. It doesn't resolve itself.

For pure pay-as-you-go deals, ASC 606 gives a practical shortcut: recognize revenue in the amount the company has the right to invoice, as long as that amount tracks directly with the value delivered. This right-to-invoice exception is the thing that makes consumption-only pricing workable. Otherwise a company would have to estimate the full contract value on day one, sight unseen.

That shortcut disappears the moment a committed minimum shows up in the contract. The minimum behaves like fixed consideration and gets recognized ratably; the overage above it is variable, estimated and constrained on its own. One contract, two recognition treatments, running side by side, never touching.

AI workloads make the estimation problem worse. Token and compute consumption can spike hard the moment a customer changes how they use a product, so historical usage patterns make a shaky foundation for an expected-value estimate at best. The estimation process has to sit with that volatility directly rather than smoothing it into something tidier than it is. Cohen and Company's 2025 review of ASC 606 compliance found that transaction price determination, variable consideration specifically, standalone selling price estimates, and discounts, is where errors cluster hardest for software and SaaS companies. That finding predates AI consumption pricing becoming the default, and the problem has only gotten worse since.

Step 4 — Allocating the transaction price across obligations, and what standalone selling price means when pricing changes constantly

Once the transaction price is locked, ASC 606 requires splitting it across performance obligations in proportion to standalone selling price: whatever the company would charge if it sold that piece by itself. When a public rate card exists and nobody's negotiated around it, this is arithmetic. It stops being arithmetic the second enterprise accounts get individually negotiated rates, bundle discounts blur what any one piece is worth, or a pricing experiment changes the public rate card mid-year.

Pricing experiments happen constantly, for what it's worth. Changes to public rate cards and packaging structures are a routine feature of the current market, and each one potentially invalidates the standalone selling price a company used to support allocations it already made before the change went live.

There's one piece of relief built into the standard, for a narrow case: when variable consideration relates entirely to a single obligation, say, usage fees tied only to API processing, ASC 606 lets a company allocate that variable amount entirely to that one obligation rather than spreading it across the whole contract. Applied correctly, this makes hybrid contracts a lot more manageable.

Mid-term changes complicate things further. If a modification adds distinct services at standalone prices, it gets treated as a new contract, accounted for going forward. If it changes existing scope at prices that aren't standalone, the company runs a cumulative catch-up adjustment through the current period instead. Downgrades and cancellations bring their own edge cases: a non-refundable prepayment with no remaining obligation lets the company recognize the rest of the deferred revenue right away, while a refundable amount forces a reversal.

At a handful of accounts, this is a spreadsheet exercise. At hundreds of accounts modifying plans in the same quarter, that same math by hand stops producing numbers anyone should trust.

Step 5 — Recognizing revenue as performance obligations are satisfied, and why "as usage occurs" is harder than it sounds

ASC 606 lets revenue get recognized either at a single point in time or over time. SaaS and API usage almost always falls into the "over time" bucket, since the customer receives and consumes the benefit the moment it's delivered.

Two approaches survive contact with that standard. One recognizes revenue in the period the consumption actually happens, matching the economic event as closely as it can, but only works if metering data is complete and sitting there at close. The other recognizes revenue ratably across the contract term, which fits minimum commitments and access fees fine but has no business getting applied to pure consumption.

In a hybrid contract, both run at once. The seat portion goes ratably, the usage portion goes as-consumed, and neither substitutes for the other. That creates a hard operational dependency: recognizing revenue in the period usage occurred needs metering data that's complete and accurate before the books close, full stop, and a delay in usage event ingestion is a revenue recognition failure waiting to surface at close, usually at the worst possible time. High data volumes paired with fragmented IT systems are a big part of why usage-based revenue recognition keeps showing up as a critical audit matter for companies going through this transition, and that exposure lands in real audit findings on real companies, every year.

The estimation work from Step 3 doesn't stop at signing. As actual usage piles up through the term, companies have to update their variable consideration estimates and adjust the constraint, applying it or releasing it as new data comes in. This recurs every reporting period, not just at year-end, and it scales with contract count: what one finance analyst knocks out in an afternoon at 50 contracts needs a full team once the company reaches a much larger scale.

Where the five steps break down operationally — the close process under usage-based contracts

Every billing event, an invoice sent, usage accrued, a contract modified, creates or releases a deferred revenue balance somewhere on the books. At low volume, keeping those balances in sync with recognition schedules by hand is tedious but doable. At scale it produces errors, and those errors compound across periods instead of resetting cleanly each month.

Three failure patterns show up more than any others. Usage data lands after the close window has already shut, forcing manual true-ups or, worse, restated entries. Contract modifications get processed in the billing system with no matching re-allocation in the revenue schedule, so the two systems end up telling different stories about the same contract. Variable consideration estimates don't get updated mid-period, which understates or overstates revenue in whichever period consumption happened to move the most.

The Cohen and Company finding on where errors cluster, variable consideration and standalone selling price, predates AI consumption pricing becoming a standard contract feature. The error surface it describes has only gotten wider since.

ARR-to-GAAP reconciliation is where a lot of this becomes visible to people outside accounting. When usage gets billed in arrears but has to be recognized in the period it actually occurred, billing timing and recognition timing pull apart, and reconciling the two takes real work every close. That effort matters, because revenue restatements are among the most damaging things a SaaS business can put out. They retroactively call into question every ARR and NRR figure the company has ever handed to investors.

Each of the five steps carries its own judgment call, its own data dependency. Close is where all five collide, on the same calendar, against the same deadline.

What compliant, automated revenue recognition requires from billing infrastructure

Traceability is the real requirement sitting underneath all five steps. Every recognition event needs a clean line back to a specific usage event, a specific version of the contract, and a specific allocation decision. An auditor asks for exactly that, and it's exactly what a spreadsheet stops producing once contract volume clears a few hundred accounts.

Real-time metering is a precondition for Step 5 working at all. If usage data isn't sitting there by the time books close, there's no way to recognize revenue in the period it actually occurred. Infrastructure that ingests usage events reliably and promptly is what makes that obligation achievable instead of aspirational.

Mapped against the five steps, here's what the system actually needs to do. Contract version management has to keep the rate card in effect at inception rather than overwriting it the moment pricing changes (Step 1). Performance obligation configuration has to represent hybrid structures, with access fees and consumption fees set up as separate obligation types carrying separate recognition rules (Step 2). Variable consideration estimation and constraint tracking need to run per contract, updated automatically as usage data comes in, with an audit trail behind every revision (Step 3). Allocation logic based on standalone selling price has to adjust automatically when a contract gets modified mid-term, and apply the single-obligation allocation rule correctly for usage fees (Step 4). And period-level recognition schedules need to run off actual metering data rather than billing cycles, generating deferred revenue journal entries without someone doing it by hand the night before close (Step 5).

Any one of these is manageable alone. All five together, at scale, with mid-term modifications and real-time metering and audit-grade traceability running at once, is a different problem entirely, one that favors purpose-built billing infrastructure over whatever a team could bolt together in-house on a deadline. Finance teams running on that kind of infrastructure close in days instead of weeks. Engineers stop getting paged for billing issues at two in the morning, because the recognition logic runs on its own instead of needing someone to babysit it every period end.

IDC has forecast AI software revenue climbing to $307 billion by 2027, up from $64 billion in 2022. Whatever you think of five-year forecasts, the direction underneath this one isn't really in question. The volume of usage-based contracts needing this kind of infrastructure is going to keep outpacing whatever a manual process can absorb, and that gap is why the accounting has to get built before the close process breaks, not after.