Usage-Based Billing and Revenue Recognition: What AI Companies Get Wrong

Usage-based pricing is eating SaaS. Pay-per-API-call, per-token, per-compute-hour, per-seat-used — the models are everywhere. And for AI companies especially, usage-based billing isn't a trend. It's the default.

The problem: ASC 606 treats usage-based fees differently depending on the structure of your deal. The same usage charge can follow three completely different accounting paths — and picking the wrong one means your revenue is wrong. Not wrong in a theoretical sense. Wrong in the sense that your auditor will flag it.

We pulled the relevant guidance from KPMG's Revenue for Software and SaaS handbook. Here's what you need to know.

Three Ways ASC 606 Treats Usage-Based Fees

This is the part that trips up most companies. Not all usage fees are created equal under 606. The treatment depends on what the customer is paying for and how the deal is structured.

Path 1: Variable consideration

If your customer pays a base subscription plus overage charges based on usage, those overages are typically variable consideration under ASC 606. You estimate the total transaction price at contract inception using either the expected value method (probability-weighted) or most likely amount method (single best estimate). The estimate gets updated each reporting period.

The constraint applies: only include amounts where you're confident there won't be a significant revenue reversal. Uncertain about how much the customer will use? Pull the estimate down. This means you might recognize some usage revenue before the usage actually happens — or less than what eventually occurs.

Path 2: Sales/usage-based royalty exception

If usage-based fees are paid in exchange for a license of intellectual property — and the license is the predominant item the fees relate to — a special exception applies. Revenue is recognized only as usage occurs. Never estimated upfront. Never constrained. Just recognized when the customer actually uses.

This is huge for AI companies. If you're licensing a proprietary model and charging per API call or per token against that license, the royalty exception likely governs. You don't touch the revenue until the customer uses the software.

Path 3: Customer option (material right)

Sometimes usage-based pricing is really an option for the customer to purchase additional services. If a SaaS contract includes the right to buy additional compute at a discounted rate, that option might be a separate performance obligation — a material right. Revenue gets allocated to it and deferred until the customer exercises the option or it expires.

This path is less common but shows up in contracts with committed-use discounts or tiered pricing where the discount on higher tiers is incremental to what similar customers normally receive.

How to Tell Which Path Applies

The decision tree:

• Are the usage fees tied to a license of IP (and is the license the predominant item)? Royalty exception. Recognize as usage occurs.
• Are the fees variable amounts within an existing contract for services? Variable consideration. Estimate, constrain, update each period.
• Do the fees represent an option to purchase additional goods/services at a discount? Evaluate whether it's a material right (separate obligation).

In practice, the line between these can blur. A contract that includes both a software license and SaaS access with usage fees might have different components following different paths within the same deal.

The As-Invoiced Practical Expedient

There's a shortcut. ASC 606 includes a practical expedient that lets you recognize revenue equal to what you have the right to invoice — but only if both conditions are met:

• The amount you can invoice corresponds directly to the value delivered to the customer
• You're invoicing a fixed amount per unit of service (e.g., $0.01 per API call)

When this applies, you skip the estimation and allocation complexity entirely. You invoice for actual usage, you recognize that amount. Clean.

Most pure usage-based SaaS contracts qualify. Where it breaks down: contracts with minimum commitments, volume discounts that change the per-unit rate retroactively, or arrangements where the usage fee doesn't correspond directly to value delivered in that period.

Why AI Companies Face Unique Challenges

AI companies sit at the intersection of all three paths — and sometimes within a single contract.

Consider a typical AI company deal: the customer gets access to a proprietary model (license of IP), hosted through an API (SaaS), with per-token pricing (usage-based), a monthly minimum commit, and volume discounts at higher tiers.

That one contract might involve:

• A software license (if the customer can download the model weights)
• A SaaS service (if they access it only through your hosted API)
• Usage fees that follow the royalty exception (if tied to the license)
• Usage fees that are variable consideration (if tied to the SaaS service)
• A material right (if the volume discount is incremental)
• A minimum commit that's a fixed fee (recognized ratably)

The classification of the underlying arrangement — license vs. SaaS — determines which path the usage fees follow. Get the classification wrong and the entire revenue treatment cascades in the wrong direction.

Minimum Commitments and Prepaid Usage

Many usage-based contracts include a minimum spend — "use at least $10,000/month or forfeit the difference." Under 606, that minimum is typically a fixed component of the transaction price. It gets recognized ratably over the contract period regardless of whether the customer hits the threshold.

Prepaid usage credits are similar. Customer buys $100,000 in credits upfront and draws them down over time. Revenue is recognized as credits are consumed — not when you receive the cash. Unused credits (breakage) are recognized in proportion to the pattern of usage if you can reasonably estimate the breakage amount.

If you can't estimate breakage? Recognize when it becomes remote that the customer will use the remaining credits. That's a judgment call with real dollar impact.

How JustPaid Handles Usage-Based Revenue

Usage-based billing requires real-time metering, accurate invoicing, and revenue recognition that matches the right accounting path for each contract. Most billing tools handle the metering and invoicing. Few handle the revenue recognition correctly — especially when the same company has contracts following different paths.

JustPaid was built for this. The platform supports token-based, outcome-based, and hybrid pricing models natively. AI Contract Extraction identifies whether usage fees follow the royalty exception, variable consideration, or the as-invoiced expedient based on the contract terms. Revenue schedules adjust automatically as usage data flows in.

No manual classification. No spreadsheet reconciliation between metering and revenue.

Key Takeaways

• Usage-based fees follow three possible paths under ASC 606: variable consideration, royalty exception, or material right. The path depends on the deal structure.
• The sales/usage-based royalty exception applies when fees are tied to a license of IP. Revenue is recognized only as usage occurs — never estimated upfront.
• The as-invoiced practical expedient simplifies recognition for pure usage-based SaaS — but breaks down with minimum commits or retroactive volume discounts.
• AI companies often have contracts that straddle multiple paths within a single deal. The underlying SaaS-vs-license classification determines which path the usage fees follow.
• Minimum commitments are fixed fees recognized ratably. Prepaid credits are recognized as consumed, with breakage estimated if predictable.

Frequently Asked Questions

Sources

• KPMG LLP, Revenue for Software and SaaS Handbook, December 2025 Edition.
• Financial Accounting Standards Board (FASB), ASC Topic 606: Revenue from Contracts with Customers (ASU 2014-09).

Selling usage-based? Schedule a demo to see how JustPaid handles token-based, outcome-based, and hybrid pricing models.