‍

Monetization is in the middle of an evolution, and it is putting a disproportionate amount of pressure on finance and accounting teams. SaaS companies are moving away from flat subscription pricing towards usage-based models, or blending the two, raising two hard questions for finance and accounting. First, is the model actually working? Second, and just as important: what are the actual earned revenue numbers once you strip away all the usage-based mechanisms sitting on top?

‍

That second question is the subject of this guide. Usage-based accounting is materially harder than subscription proration or ecommerce, where a single transaction is delivered and the revenue is recognized. With usage-based billing, revenue recognition timing is coupled with upstream usage and decoupled from billing timing, creating layered accrual, reversal, and true-up cycles that can run across hundreds of thousands microtransactions inside a single contract period.

‍

This guide breaks down what usage-based billing is, why it is so hard to account for correctly, and how to structure the accrual, reversal, and credit grant mechanics so your revenue numbers hold up under audit. 

‍

What Is Usage-Based Billing?

‍

Usage-based billing is a pricing model where customers pay based on their actual consumption of a product or service, rather than a fixed subscription fee. Companies track specific usage events, such as API calls, data processed, compute hours, or feature access, and then apply pricing rules to convert that usage into a billing amount.

‍

The model has moved from a niche pricing choice to a mainstream one. AI companies, in particular, have built entire pricing strategies around metered consumption, and billing infrastructure has followed. Stripe's acquisition of Metronome, positioned as Stripe's module for usage-based billing and Adyen’s acquisition of Orb is a clear signal of how central this pricing model has become to modern SaaS.

‍

For revenue accounting, though, usage-based billing does not replace subscription accounting. It is usually alongside or on top of it. A customer might pay a base subscription fee for platform access, plus a usage component layered on top and a prepaid token balance that draws down against future usage. Each of those pieces has its own performance obligation and revenue recognition treatment under ASC 606, and they interact with each other in ways that are easy to get wrong.

‍

What Makes Usage-Based Accounting Hard

‍

There are five complex use cases we’ve identified that show up across usage-based billing. Individually, each one is manageable, but multiplied across thousands of customers and millions of usage events, it becomes impossible to build reporting around. 

‍

1. Prepaid Tokens and Credit Grants

‍

Customers buy platform access plus a set number of tokens, or they receive free tokens as a standalone incentive tied to their subscription. Those tokens get drawn down over time against future usage-based invoices. 

‍

The accounting challenge is tracking the token balance accurately at the customer level, and recognizing revenue only as tokens are actually consumed, not when they are issued.

‍

2. Prepaid and Burndown

‍

This is the traditional usage-based model: a customer buys a block of prepaid commitments, sometimes structured annually, and usage draws that balance down over the contract period. 

‍

This creates a percent-complete accounting problem that potentially crosses accounting periods. If a customer has purchased 10,000 events and used 1,000, the accounting answer is that 10% of the contractual prepaid commitment should be recognized as revenue for the period. That percentage, however, is backed by potentially hundreds of thousands of individual micro-events, which makes it difficult to explain or audit without a system that can trace the aggregate number back to the underlying usage. Add in expiration, or add-on modifications mid cycle and you can see where the complexity can skyrocket. 

‍

3. Bill-in-Arrears (Overage)

‍

When a customer exceeds their committed usage, the vendor typically bills the overage the following month. That creates a three-transaction cycle: accrue estimated revenue in the month the usage occurred, reverse that estimate the following month, and record the actual final billed amount once it is known.

‍

Revenue has to be recognized in the period the usage actually happened, not the period it was billed, which means accounting has to run an ongoing accrue, reverse, and true-up cycle for every customer with overage activity. This also creates an interesting credit risk situation that the accounting team has to manage and potentially reserve for either as a revenue constraint under ASC 606 or CECL reserve under ASC 326.

‍

4. Prepaid Usage Not Yet Applied to Burndown

‍

Usage can occur before it is actually applied against a customer's prepaid balance. Some systems do not apply usage to the burndown balance until month-end or later. 

‍

Revenue recognition does not wait for that system to catch-up. Under ASC 606, revenue is recognized in the period the customer received the benefit of the service, regardless of when the burndown accounting reflects that usage.

‍

5. Promotional and Free Token Balances

‍

Free or promotional tokens require a judgment call about intent, and the two treatments produce very different financial statement outcomes.

‍

• Discount treatment: Treated as a reduction of revenue when tokens are bundled into a paid offer, for example a subscription that comes with a fixed allotment of free tokens as part of the purchase.

‍

• Marketing expense treatment: This is a marketing expense on the giver's side, offset by a liability that must be tracked as the recipient uses the tokens over time. Functionally, it behaves like a gift card written off as a marketing expense: it sits in a deferred liability balance until the customer uses it or it expires, which reverses the expense.

‍

The reality

‍

Usage-based accounting is harder than subscription proration or ecommerce accounting because revenue recognition timing is now coupled with usage data and still decoupled from billing timing. That gap is what creates layered accrual, reversal, and true-up cycles across enormous volumes of micro-transactions.

‍

Journal Entries

‍

The entries below are illustrative examples for each use case. Actual account naming and sub-ledger structure will vary by company, but the recognition logic and sequencing hold across most usage-based contracts.

‍

‍

Best Practices for Usage Based Billing

‍

• Build the three-step cycle into the close process. Model the accrue, reverse, replace cycle as a standard operating pattern for every metered contract, not a manual month-end exercise. The volume of usage events makes manual reconciliation unsustainable past a small customer base.

‍

• Treat the estimate-to-actual variance as a control, not an afterthought. The gap between accrued usage-based revenue and actual billed revenue is a leakage indicator. Track it by customer and investigate recurring variances rather than writing them off as noise.

‍

• Maintain transaction-level traceability. Every recognized dollar should be traceable to the usage events, credit grant ledger entry, or invoice that produced it. This is what auditors will ask for, and it is what makes percent-complete revenue defensible.

‍

• Classify credit grants at issuance, not at consumption. Determine upfront whether free or promotional tokens function as a discount against a paid product or as a standalone marketing giveaway. That judgment call drives materially different treatment on both the revenue and expense lines.

‍

• Don't let expiration terms fall through the cracks. Unused promotional credits and expired grants need a defined process for reversing the associated expense or liability. Left untracked, expired balances quietly overstate liabilities on the balance sheet.

‍

• Flag SSP bundling situations early. Whether credits are use-it-or-lose-it within a period or roll forward changes whether you are looking at a straightforward two-performance-obligation allocation or a running usage ledger spanning multiple periods. Confirm this at contract review, not at close.

‍

Limitations of Usage-Based Accounting

‍

Even with a well-designed accrual model, usage-based accounting has real limitations that finance teams should plan around rather than assume away.

‍

• Most billing platforms, including Stripe, do not natively capture the granular usage data needed to automate SSP allocation between a subscription and bundled credits. The accounting logic exists; the underlying data pipeline frequently does not.

‍

• Percent-complete revenue recognized against a large prepaid balance is only as auditable as the underlying event-level data. If usage events cannot be traced back to the aggregate recognized number, the estimate is difficult to defend under audit scrutiny.

‍

• A single contract with metered usage, credit grants, and promotional balances is manageable by hand. The same logic applied across a customer base generating millions of usage events per period is not, without purpose-built automation.

‍

• Timing mismatches between when usage occurs, when it is applied to a burndown balance, and when it is billed to create ongoing reconciliation work that does not fully go away, even with strong automation. It can be systematized, but it cannot be eliminated.

‍

Conclusion

‍

Usage-based billing is not going away. It is becoming the default monetization model for infrastructure, AI, and increasingly for mainstream SaaS. That makes usage-based revenue accounting a core competency for finance teams, not a one-off project to solve and move past.

‍

The complexity is real: percent-complete recognition, bill-in-arrears accrual cycles, two distinct flavors of credit grants, and an SSP allocation problem the industry has not fully solved. But the underlying model is consistent. Accrue as usage happens, reverse when billed, replace with actuals, and track every credit grant back to the invoices it eventually offsets. Applied consistently and automated at scale, that model is what turns usage-based revenue from a source of audit risk into a number finance can stand behind.

‍