What Nobody Tells You About Accounting for Usage-Based Billing

Every finance team watching the shift from subscription SaaS to usage-based pricing is watching the same thing: the growth curves look incredible. The problem is that the accounting playbook that used to work doesn't anymore. 

‍

The growth is real. So is the negative margin nobody shows on the slide.

The AI-era growth curves are genuinely unusual: companies reaching nine figures in ARR within a couple of years, in some cases with headcounts in the single digits. But behind those curves sits a cost structure SaaS never had to deal with: every new user requires real compute, which gets paid out to whatever model is answering their questions. 

‍

Unlike traditional software, where a new signup costs almost nothing incrementally, usage-based AI businesses can be growing revenue fast while running deeply negative margins at the same time. 

‍

That tension, chasing the growth curve while actually figuring out unit economics, is a big part of why usage-based billing exists in the first place. It's as much a margin-tracking exercise as a monetization strategy.

‍

There's no single "usage-based billing" model: there are at least five

‍

Companies aren't converging on one approach yet, and each version creates a different accounting problem:

‍

• Pure pay-as-you-go, billed in arrears: Usage happens, then gets invoiced the following month. This is the most common pattern and the one most likely to leave revenue sitting in the wrong period.
• Pay-as-you-go with true-ups: The model Cursor uses. Extend a small amount of credit, bill as soon as it's consumed, and let the credit line grow with usage. This keeps billing much closer to actual usage and reduces both AR risk and the need for accruals.
• Subscription with block credits: A flat fee plus a bucket of usage. Now you're tracking entitlement timing, burn-down, and whether unused credits expire.
• Subscription mixed with credits: Part of the fee is "access," part is a credit allocation with its own standalone selling price. If credits are effectively given away for free, that triggers an SSP allocation question.
• Ad hoc top-ups: A customer runs out mid-period and gets billed for more, which can mean a contract modification and a fresh SSP allocation.

‍

Some companies are testing multiple billing structures within months of each other, which means the accounting team is trying to hit a moving target, rather than a one-time system migration.

‍

Contract, billing, and payment are not the same event, and usage widens the gap

Under subscription accounting, most teams treat "invoice received" and "book deferred revenue" as effectively the same moment, and 99% of the time that's a fine simplification. 

‍

Usage-based billing breaks that assumption. The contract (performance obligation), the recognition (based on time, percent complete, or usage), the billing, and the collection are four genuinely separate events with their own source-of-truth systems, and the lag between when revenue is earned and when it's billed is often too wide to ignore. 

‍

Most legacy revenue processes were built assuming that gap doesn't really exist, which is exactly why they break under usage-based models.

‍

Revenue recognition only ever has two dimensions: percent complete and time

‍

It's easy to treat usage-based rev rec as a brand-new discipline, but at the highest level of abstraction, it isn't. Every recognition pattern (point-of-sale, milestone-based services, subscription, project accounting, usage) is just some combination of percent complete and time. 

‍

A subscription recognizes a fixed percentage every day or month. Usage recognizes a percentage of tokens issued as they're consumed. Reframing it this way makes usage-based accounting feel like a variation on familiar patterns rather than an entirely new problem.

‍

Free credits aren't automatically a marketing expense or automatically deferred revenue: the reason you gave them matters

‍

This is one of the least understood corners of usage-based accounting, and it has real P&L consequences. The GAAP treatment depends entirely on why the credit was issued:

‍

• Credits issued to acquire a new customer (e.g., "sign up and get 100 free tokens") are typically a marketing expense, recognized immediately when granted.
• Credits issued to an existing customer as a goodwill gesture typically fall under consideration payable to a customer, with no immediate P&L impact. Instead it's a liability that offsets against revenue (contra revenue) only once the customer actually uses the credit.

‍

The practical problem is that most upstream systems don't capture why a credit was granted. That context usually lives with the marketing or customer success team, not in the billing data. 

‍

Without that metadata, accounting can't apply the right treatment, which is a strong argument for finance getting embedded in how the growth team designs credit programs, not just reconciling after the fact.

‍

Payment processor fees: expense them immediately, or match them to revenue?

‍

There isn't one right answer to if teams should expense payment processor fees or match them to revenue. Rather, it depends on the nature of the relationship with the processor. 

‍

Some companies treat processor fees as a straightforward expense taken as incurred whereas others treat them as a cost of obtaining the contract, either expensed immediately as a practical expedient or matched against revenue over time. 

‍

For usage-based businesses specifically, matching fees to revenue is usually the only way to answer the question management actually cares about: did we make money on this SKU, or did a marketing push just generate volume at a loss? 

‍

One nuance worth catching early: processor fees are typically charged on the payment, not the invoice, so an invoiced amount that's never collected may never generate a fee to accrue for in the first place.

‍

Waiting until cash is collected to recognize revenue is usually less compliant, not more

‍

The reflex is to treat "hasn't paid yet" as a reason to hold off on revenue, because it feels conservative. But ASC 606's collectability test isn't about any single transaction, it's about your overall collection rate. If a business collects on 98% of its invoices, that supports recognizing revenue on any given transaction (with a reserve for the expected 2% shortfall), not waiting for cash. 

‍

The exception is when a business's realistic collection rate is low enough, well under half in some of the cases discussed, that individual transactions can't be presumed collectible; in that scenario, waiting for cash is the more defensible position. 

‍

Usage-based, bill-in-arrears models tend to carry more non-payment risk than traditional subscriptions, since customers can consume usage and simply never pay for it, which makes this judgment call more common than it used to be.

‍

The real bottleneck isn't the accounting rules, it's the data

None of the ASC 606 concepts above are new in isolation. What's new is where the data lives. Usage data typically sits in engineering-owned systems, a data warehouse or a dedicated telemetry platform, never designed with accounting controls in mind. That creates a few recurring headaches:

‍

• Volume: A single usage-based SKU can generate over a million transactions a month, well past what's workable in a spreadsheet.
• Mutability: Because the data lives in operational databases rather than a controlled ledger, historical numbers can change after the fact. An entry booked in January might not match a re-run report in June, which is a serious problem from an audit standpoint.
• Expiration and metadata tracking: Credit lots often have expiration windows, and knowing which lot funded which usage event requires metadata that isn't always captured cleanly upstream.

‍

Manually reconciling all of this isn't just labor-intensive. It usually means running an ad hoc engineering project just to get a usable report, with meaningful risk of manual error, and an end product that's really only good for passing an audit rather than helping the business actually manage margins in real time.

‍

The bigger opportunity: usage data as AI-ready context

‍

One of the more interesting threads from the session: companies that have automated their usage accounting aren't just saving headcount on the revenue team. They're generating clean, granular financial data that can feed directly into AI-driven FP&A. 

‍

Several of the fastest-scaling usage-based companies mentioned are running their financial planning through their own AI tools, which only works because the underlying revenue-to-cash data is structured and reliable. 

‍

That's a value prop usage-based businesses didn't really have during the SaaS era: solid usage accounting doesn't just support compliance, it becomes the context an AI model needs to actually reason about the business.

‍

The bottom line: usage-based billing doesn't require new accounting principles, but it does require rethinking where your source-of-truth data lives, how granular your tracking needs to be, and whether manual processes can realistically keep pace with a billing model your product and growth teams may keep changing.

‍