How do I recognize revenue for usage-based/consumption pricing?

If the contractual right to bill corresponds directly to the value the customer received that period, ASC 606's right-to-invoice practical expedient lets an entity recognize revenue in the exact amount it has the right to bill for that period — no separate estimate of total contract value is required, as long as usage-based billing genuinely tracks value delivered.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the revenue recognition guide.

Governing guidance	ASC 606-10-55-18, the "right to invoice" practical expedient for measuring progress
When it applies	The billed amount must correspond directly with the value transferred to the customer that period
What it removes	The need to estimate variable consideration for the full contract upfront
What it can't do	Accelerate revenue ahead of actual value transferred — it caps recognition at what's been earned
Related concept	Usage-based fees are often a series of distinct, substantially similar performance obligations

The expedient that makes this tractable

Estimating variable consideration for an entire contract upfront — the standard ASC 606 approach for most variable pricing — is genuinely hard for usage-based SaaS, since nobody knows a customer's total consumption at signing. RevenueHub's treatment of input vs. output methods explains the alternative directly: in order for an entity to use the right-to-invoice expedient, the entity's contractual right to bill must correspond directly with the value transferred, and where that holds, the entity may elect to recognize revenue in the amount it has the right to invoice — no upfront estimate required.

What makes billing 'correspond directly' to value

The expedient is common, per RevenueHub, in arrangements where the customer is invoiced a fixed amount per unit delivered or hour of service rendered — a fixed per-API-call, per-seat-active-day, or per-GB-processed rate is the canonical case. The test isn't whether usage is variable; it's whether the price-per-unit genuinely reflects the value of that unit to the customer, consistently, not a price that happens to correlate loosely with usage for other reasons.

Why this is usually also a series

Usage-based access to a platform typically also satisfies ASC 606's series provision: a distinct good or service — access for a given day, or a given processed unit — that's substantially the same as every other instance and transferred with the same pattern over time. RevenueHub's series-provision article frames both required tests together: the goods/services must be substantially the same, and transferred with the same pattern to the customer. Treating the whole usage-based arrangement as one performance obligation, satisfied incrementally, is what lets the right-to-invoice expedient apply cleanly period by period instead of unit by unit.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Field mapping

Right-to-invoice expedient: what it requires and what it doesn't

Requirement	Applies here
Right to bill matches value transferred	Required — the core test
Estimate total contract consideration upfront	Not required when the expedient applies
Recognize ahead of actual usage	Not permitted — caps at value actually transferred

Frequently Asked Questions

No — it applies only where the billed amount genuinely corresponds directly to value transferred that period. A usage-based fee with minimum commitments, tiered discounts that don't track value, or true-up clauses may not qualify without further analysis.

If the contract genuinely bills nothing for a zero-usage period, revenue recognized for that period is zero too — the expedient ties recognition to actual billed value, not to a smoothed average.

Yes, and it's common — the flat fee is typically recognized on the stand-ready/straight-line pattern, while the usage-based overage portion can separately use the right-to-invoice expedient if it meets the test on its own.

Sources

Topic

Revenue Recognition

Revenue recognition determines when — not just how much — revenue hits the books. Under ASC 606 (US GAAP) and its international counterpart IFRS 15, revenue is recorded as a company satisfies its perf…

How-to

How do you calculate a contract's transaction price under ASC 606?

Transaction price is the consideration a company expects in exchange for goods or services. Start with the stated contract price, add variable consideration using the expected-value or most-likely-amount method, constrained to amounts unlikely to reverse, adjust for any significant financing component, then subtract noncash consideration and amounts payable to the customer.

Comparison

ASC 606 vs IFRS 15: what's the difference?

ASC 606 and IFRS 15 share the same five-step revenue recognition model and were developed jointly by the FASB and IFRS Foundation. They differ in details: ASC 606 applies a stricter US GAAP collectibility threshold, includes explicit licensing implementation guidance, and requires more granular interim disclosures for public companies than IFRS 15 does.

How-to

How do I recognize revenue for a multi-year SaaS contract billed annually?

Recognize revenue ratably over the full subscription period the customer is entitled to access, not on the annual billing schedule. A SaaS subscription is typically a stand-ready obligation under ASC 606 — revenue follows the pattern of ongoing access, which spreads evenly across the term regardless of when cash is actually invoiced or collected.