Six Accounting Headaches Hiding Inside Your Usage-Based Billing Model

A few years ago, most finance teams ran everything through one system. Orders, invoicing, cash application, and the accounting rules that governed them all lived inside the ERP, but that world is gone. 

‍

Monetization now happens across Stripe, Metronome, Orb, and a handful of other platforms that were never built with accountants in mind. Some of it is genuinely new, and some of it is an old subscription model wearing a usage-based costume. Either way, the accounting team is the one left reconciling it.

‍

The shift has accelerated because of AI. Companies like Cursor went from zero to a multi-billion dollar run rate in a couple of years, and every founder and board member wants to know how to replicate that curve. The answer usually involves a credit card, a third-party billing platform, and a monetization model built around consumption rather than seats, which is great for growth, not for the accounting team. 

‍

We spent a recent session in our ERP Unbundling series walking through the specific use cases that trip up revenue accounting teams as they take on usage-based billing. Here are the six that come up again and again.

‍

1. Meter-based billing in arrears

This is the most common issue we see, and it's also the source of the most quietly expensive problem in usage accounting: revenue leakage. A customer generates usage in January. The invoice for that usage doesn't get created until February. Proper accounting requires an accrual in January for activity that hasn't been billed yet, followed by a reversal once the real invoice lands.

‍

The trouble starts when what gets accrued doesn't match what actually gets billed. That gap is revenue leakage, and it's rarely an accounting problem at its root, it's usually operational:

‍

An invoice that was never finalized, usage tied to the wrong SKU, or a free trial that got metered by mistake. Occasionally it's fraud. 

‍

Either way, someone in finance ends up asking engineering why the metering data and the billing data don't agree, and the honest answer is often that engineering built the pipeline to track what got paid, not what happened.

‍

2. Prepaid credits (and prepaid credits)

Two things get called "prepaid credits" and they are not the same:

‍

1. General prepaid credits are essentially a customer deposit. Someone pays you money, you owe them something eventually, but there's no contract specifying what or when. That's a liability, though whether it qualifies as deferred revenue is a matter of policy.

‍

2. Specific prepaid credits are different. A customer pays in advance against a defined product SKU, with an expectation of usage over a set window. That looks more like a milestone-based or percent-complete revenue recognition problem. 

‍

If you treat the two the same way in your GL, you'll misstate the balance sheet.

‍

3. Rollovers

Credits don't always stay in their original bucket. A general prepaid balance can get applied toward a specific product SKU, which means it moves from a customer deposit liability into deferred revenue without any cash changing hands. 

‍

Getting this right requires tracking both where the credit came from and where it ended up. Miss either data point and the accounting won't hold up.

‍

4. Expiry and breakage

Prepaid and gifted balances don't last forever. Figuring out how long a customer has before a credit expires, and whether unused balances should be recognized as revenue through breakage, requires historical usage data and a defensible policy. It also requires distinguishing real breakage from promotional revenue that was essentially given away. 

‍

The latter often belongs in revenue and marketing expense, not straight to the top line, and auditors will want to see the argument.

5. Free credit grants

Referral bonuses, promotional usage, free subscription upgrades all create a policy question. Does the credit have standalone value? If so, there's an argument for booking a marketing expense against a liability that behaves like deferred revenue. If not, it may sit as a future variable consideration that only becomes a real liability once it's applied to a contract.

‍

The complication is that marketing teams change these programs constantly, sometimes month to month, and rarely loop in accounting before launching a new promotion. 

‍

One program might target new customer acquisition. Another might be a retention credit for an existing customer. Same mechanism, different accounting treatment, and finance often finds out only after the transactions have already piled up.

‍

6. Standalone selling price

This is the one most likely to be quietly understating your usage revenue. A customer pays for a subscription and also gets a bundle of free usage units. That free usage often has a standalone value, which means a portion of the subscription price may actually belong to the usage revenue line under an SSP analysis. 

‍

Companies that hide the token or usage line from customers, because nobody likes seeing a line item they can't control, end up with the same blind spot internally. The P&L looks like it's mostly subscription revenue when a meaningful chunk of that value was really used all along.

‍

Build or partner?

The typical path looks like this: a company hires its first accountant, who does everything manually until volume makes that impossible. At that point, the decision is whether to build automation internally or bring in a partner. 

‍

Companies with deep engineering resources and patience for a long build sometimes make that work. Most don't have the runway for a multi-year internal project that might not pan out, especially when the SOC 1 and SOC 2 compliance bar for a vendor is meaningfully lower than what auditors expect from internally built financial software under SOX. That asymmetry alone pushes a lot of fast-growing companies toward partnering rather than building.

‍

The deeper pattern across all six use cases is the same: usage-based monetization generates transactions that were never designed with accounting in mind. Getting the treatment right depends on tracking origin, destination, and intent for every credit, every accrual, and every rollover. Do that well and revenue leakage stops being a mystery. Skip it and you'll find out about the gap the hard way, usually during an audit.

‍

Want the deeper dive on the accounting standards behind these use cases? Join Cody Leach, CPA and Head of Product Experience at HubiFi, for our upcoming webinar on usage-based billing accounting, eligible for one CPE credit.