5 Revenue Checks Every Usage-Based CFO Should Run
Most usage-based companies recognize revenue at the invoiced amount. A customer consumes 10,000 tokens at $0.01 each. The invoice says $100. The finance team recognizes $100. The numbers match, and the close moves on.
That shortcut works under one specific condition: the invoiced amount must correspond directly to the value delivered to the customer. Pure pay-as-you-go at a flat per-unit rate, billed in arrears, meets that condition cleanly.
AI products have pushed pricing past that simplicity. Tokens, credits, committed spend, declining-rate tiers, hybrid bundles. Each structure creates a gap between what the customer is invoiced and what the company should recognize as revenue. The invoice says one number. The recognition rules say another. Most finance teams have never documented why they treat the two as identical.
The assumption most teams never documented
Revenue recognition at the invoiced amount is not a default. Under ASC 606, it is a specific shortcut available only when the invoiced amount corresponds directly to the value the customer received. When the rate is flat, the billing is in arrears, and nothing else is bundled in, the shortcut holds.
The problem is that most companies adopted this approach during a billing system implementation and never wrote down the reasoning. No memo supports it. When pricing evolves, the conditions quietly stop being met, but the system keeps recognizing at the invoiced amount.
A quick diagnostic
The following table helps identify whether the shortcut still applies to your pricing model. If any row is unchecked, one or more of the five checks below applies.
Condition | Still true? |
Flat rate per unit, no volume discounts or declining tiers | |
Billed in arrears for actual consumption only | |
No prepaid credits, token packs, or committed minimums | |
No bundled services (implementation, support, platform access) alongside usage | |
Per-unit rate does not change based on cumulative volume | |
No outcome-based or success-based pricing (pay-per-resolution, pay-per-result) |
If every condition holds, invoiced equals recognized. If any condition is broken, the gap between the two numbers is where errors accumulate, in both directions.
One clarification worth noting early: losing the shortcut does not automatically mean estimating a full year of consumption upfront. Whether the invoiced amount is a valid measure of progress is one question. Whether variable consideration can be allocated to a specific period in a series is a different question with a different answer. Practitioners often collapse them, which leads to either over-engineering the estimate or skipping the analysis entirely.
Five checks to run against your pricing model
Each check below covers one pricing structure where invoiced revenue and recognized revenue diverge. For each: what the gap is, how to identify it, and how to close it.
Check 1: Tiered and declining rates
The gap. When the per-unit rate drops as volume increases, the invoiced amount at the start of the period overstates what the customer should be charged once total volume is known. A customer invoiced at $0.10 per token in January may owe a blended rate of $0.06 once March volume is counted. The error runs toward over-recognition, not under-billing. Most coverage of usage-based pricing focuses only on revenue that goes uncaptured. Tiered pricing creates the opposite problem: revenue recognized before it is fully earned.
How to identify it. Compare the invoiced per-unit rate against the blended rate the customer should pay given actual cumulative volume for the period. Focus on high-growth accounts most likely to cross tier boundaries.
How to close it. Billing logic should re-rate dynamically as consumption accumulates. Revenue recognition follows the blended rate, not the initial tier, with a true-up at period end.
Check 2: Prepaid credit blocks
The gap. Cash arrives at purchase. Revenue is recognized at consumption. The deferred revenue balance should track the remaining credit pool. When credit drawdown and usage metering run in separate systems, the two drift apart. Credits get consumed without corresponding recognition, or recognition runs ahead of actual drawdown.
A further gap opens when credits are sold at a discount. A customer pays $900 for $1,000 of credits. That $100 discount may need to be treated as a separate component, allocated and recognized over the redemption pattern.
How to identify it. Compare the credit drawdown ledger against actual metered usage for prepaid accounts. Flag any account where consumed credits do not tie to usage events, or where the deferred revenue balance does not match the remaining credit pool.
How to close it. Credit drawdown and usage metering must reconcile automatically. Every usage event should decrement the credit balance and trigger the corresponding recognition simultaneously.
Check 3: Committed spend with usage overage
The gap. A customer commits to $120K annually on a 12-month term. Usage above the commitment bills at an overage rate. Two questions determine recognition. First: is the committed floor fixed consideration recognized ratably over the term, or variable consideration with a minimum? Second: does unused commitment expire or roll forward?
The committed portion and the overage portion may require different recognition patterns. Most systems apply one pattern to both.
How to identify it. For each committed-spend contract, check whether the recognition schedule separates the floor from the overage. Check how unused commitment at period end is treated.
How to close it. Separate the committed component from the variable component. Recognize the floor ratably over the term. Recognize overage as consumed. Document the treatment for unused commitment, including whether rollover creates a separate obligation.
Check 4: Bundled platform + metered usage
The gap. The customer pays a platform fee plus a usage rate. Professional services, onboarding, or support may be bundled in. The total contract price must be allocated across each distinct component based on standalone selling price. If the entire invoiced amount flows against a single usage line, the other components are either over-recognized or never accounted for separately.
The equation "tokens × rate = recognized revenue" breaks the moment anything else is sold alongside the metered product.
How to identify it. Review contracts where usage is sold alongside implementation, support, or platform access. Check whether the total price has been allocated across components or whether all revenue flows against a single line.
How to close it. Identify each distinct component. Estimate standalone selling prices. Allocate the transaction price. Recognize each component on its own pattern. Revenue recognition for the usage component follows consumption. Recognition for implementation or onboarding follows delivery.
Check 5: Contract modifications that change the economics
The gap. A customer renegotiates pricing tiers, adjusts committed minimums, or adds products mid-period. The modification changes what the customer owes and how revenue should be recognized going forward. But the recognition schedule in the ERP often reflects the original terms, not the current ones. Sales updates the CRM. Billing may or may not update. Recognition rarely updates until close, or until the auditor finds the discrepancy.
How to identify it. Pull every contract modified in the last two quarters. Compare the current terms against the recognition schedule. Flag any account where the two do not match.
How to close it. Require that every modification flows through a single workflow that updates CRM, billing, and recognition together. The accounting conclusion should be documented at modification, not reconstructed during close.
Two additional pricing structures fall outside these five checks but still break the shortcut. Outcome-based pricing (pay-per-resolution, pay-per-result) makes variable consideration estimation unavoidable, since the amount earned depends on a result the company cannot control. Resold inference raises a separate question: whether to report revenue gross or net. That determination is covered in a companion piece on gross vs. net revenue for AI companies.
The close problem most teams overlook
Metering data does not always arrive in real time. When a usage event occurs in one period but is not processed until the next, the period-end revenue number is an estimate. Most teams treat it as a known amount.
Closing this gap requires a documented estimation method and a regular lookback check. Compare prior-period accruals against actual rated amounts once the data arrives. If the variance is consistently material, the estimation method needs revision. Maintaining reporting accuracy on this accrual protects the credibility of the close.
What a CFO can start doing now
This week (hand to your controller, ~2-3 days of work):
Run the diagnostic table above. Identify which checks apply to your pricing model.
Run the applicable checks on your top 10-20 accounts. Size the gap.
The 90-day plan:
Days 1-30: Identify and size. Run the applicable checks across the full book. Output: a one-page estimate of the gap between invoiced and recognized revenue, per check. Gate: if the gap is under ~0.5% of the audit materiality threshold, re-run annually. If over, the rest of this plan is funded.
Days 31-60: Install controls. Add change-control on contract modifications. Add monthly usage-to-billing sampling and credit drawdown reconciliation to the close checklist. Name a single owner for the invoiced-to-recognized reconciliation.
Days 61-90: Decide the structural question. Manual checks degrade as contract volume grows. Automated reconciliation improves. Compare the cost of maintaining manual checks against a platform that runs them continuously. Maximor builds and holds that single reconciled model, layering on top of the ERP a company already has.
The tenth close should be more accurate than the first. Board-ready reporting starts with clean recognition inputs.
Talk to the Maximor team
Book a call with the Maximor team to see how the platform closes the gap between invoiced and recognized revenue for usage-based, consumption, and AI pricing models.
Frequently asked questions
What is the as-invoiced practical expedient and when does it apply?
Under ASC 606, companies can recognize revenue equal to the invoiced amount when that amount corresponds directly to the value delivered to the customer. Pure pay-as-you-go pricing at a flat per-unit rate, billed in arrears, qualifies. Contracts with declining tiers, prepaid credits, committed minimums, or bundled services generally do not qualify.
What pricing structures break the invoiced-equals-recognized assumption?
Five structures commonly break it: tiered or declining rates (where the per-unit price depends on cumulative volume), prepaid credit blocks (where cash arrives before consumption), committed spend with overage (where floor and variable components require separate treatment), bundled platform plus usage (where allocation across components is required), and mid-period contract modifications (where terms change but recognition does not update).
Can tiered pricing cause over-recognition, not just under-billing?
Yes. When per-unit rates decline as volume increases, invoicing at the initial tier rate overstates revenue for the period. The correct recognized amount is the blended rate across all tiers given actual cumulative volume. The error direction is over-recognition, which is the more dangerous direction for audit and compliance purposes.
How should prepaid credit revenue be recognized?
Prepaid credits create a contract liability (deferred revenue) at the point of sale. Revenue recognizes as credits are consumed against actual usage. If credits are expected to expire unused, the unused portion is recognized proportionally to the pattern of credits actually redeemed, supported by historical redemption data. Credits sold at a discount may require separate allocation and recognition.
What should a finance team do when a contract is modified mid-period?
Each modification should be evaluated for its impact on performance obligations, transaction price, and recognition timing at the time of modification, not during close. The accounting conclusion should be documented at signature and flow through to billing and recognition in a single workflow.
How can companies close the recognition-to-invoice gap without replacing their ERP?
The fix requires a reconciliation layer that connects metering data, billing logic, contract terms, and revenue schedules into one traceable model, layered on top of the existing ERP. Platforms that learn a company's recognition logic from its existing work close the gap without rip-and-replace implementations.
Sources (internal reference, not for publication)
The following sources support the claims and frameworks in this article. Provided for the Maximor editorial team's verification.
As-invoiced practical expedient (the structural hook)
ASC 606-10-55-18 and 55-18A: the right-to-invoice expedient; available when the invoiced amount corresponds directly to the value transferred to the customer.
BillingPlatform, "ASC 606 Practical Expedients: What They Allow, What They Don't, and Where They Get Misapplied" (April 2026): confirms the expedient does not apply to tiered consumption pricing where the invoice amount doesn't track period-level value delivered. https://billingplatform.com/blog/asc-606-practical-expedients
Solvimon, "ASC 606 for Usage-Based and AI-Native Businesses" (June 2026): "The expedient stops being available the moment your rate stops corresponding directly to value. Declining-rate tiers, retroactive volume discounts, prepaid credits at a discount, minimum commitments with overage." https://www.solvimon.com/blog/asc-606-for-usage-based-and-ai-businesses
Check 1: Tiered pricing and over-recognition
ASC 606-10-32-5 through 32-9: variable consideration estimation (expected value or most likely amount) and the constraint.
BillingPlatform, "Revenue Recognition for Consumption-Based and AI-Priced Products" (April 2026): "It's not available when the invoiced amount doesn't reflect period value, which can happen with tiered pricing structures where per-unit rates change with volume." https://billingplatform.com/blog/revenue-recognition-for-ai-priced-products
LedgerUp, "Usage-Based Revenue Recognition" (June 2026): "Commitments, tiers, or retroactive pricing: estimate the variable consideration using expected value or most-likely-amount, then apply the constraint." https://www.ledgerup.ai/usage-based-revenue-recognition
Check 2: Prepaid credits, breakage, and material rights
ASC 606-10-55-46 through 55-48: breakage accounting (proportional recognition or remote-likelihood deferral).
ASC 606-10-55-42: material rights from discounted future purchases (discounted credit blocks may require separate allocation).
Aprio, "Revenue Recognition for AI Companies: ASC 606, Tokens, & Tax" (July 2026): "Selling a million compute units generates a liability; running the inference that burns those units generates revenue." https://www.aprio.com/insights-events/revenue-recognition-for-ai-companies-asc-606-tokens-tax-ins-article-tech/
Solvimon guide (June 2026): covers breakage, escheatment exclusion, and material right treatment for discounted credit blocks.
Check 3: Committed spend with overage
ASC 606-10-32-5: determining whether a minimum commitment is fixed or variable consideration.
Ridgeway Financial Services, "Revenue Recognition for AI Products" (January 2026): "The fixed commitment often behaves like a subscription-like stand-ready service recognized over time. Overages generally follow usage." https://www.ridgewayfs.com/ai-revenue-recognition/
Check 4: Bundled platform + usage (SSP allocation)
ASC 606-10-32-28 through 32-30: allocation of transaction price based on standalone selling prices.
Zuora, "SaaS Accounting Standards: Operationalizing ASC 606" (June 2026): "If you discount a bundle, you must allocate that discount proportionally across all performance obligations based on their Standalone Selling Price." https://www.zuora.com/guides/saas-accounting-standard/
Check 5: Contract modifications
ASC 606-10-25-10 through 25-13: modification accounting (separate contract, prospective treatment, or cumulative catch-up).
BillingPlatform, "Revenue Recognition for Usage-Based Billing Contracts": "Most usage-based contract amendments are modifications of existing contracts because the ongoing service is continuous and not distinct from prior periods."
Metering lag and close accruals
BillingPlatform, "Revenue Recognition for Usage-Based Billing Contracts": "Usage events may not reach your billing system in real time. When there's a delay between consumption and reporting, you have usage that occurred in one period but hasn't been processed yet."
Finlens, "Usage-Based Revenue Recognition" (June 2026): "The right to invoice practical expedient under ASC 606-10-55-18 simplifies most pure consumption models, but breaks the moment billing rates stop reflecting delivered value." https://www.finlens.app/blogs/usage-based-revenue-recognition
