Usage-Based Revenue Model: What Consumption Pricing Forces You to Build

A usage-based revenue model charges customers for what they consume rather than for a seat they occupy. The customer runs a query, sends a message, stores a gigabyte, or resolves a support ticket, and the meter moves. Nothing gets billed for capacity nobody used.

That sounds like a pricing decision. It isn't. Once revenue depends on consumption, the company has to capture usage accurately enough to invoice on it, recognize that revenue in a way an auditor accepts, pay sellers who never signed a fixed contract value, forecast a number that arrives as a distribution, and explain to a board why ARR is now partly an estimate. This is a reference on all of that, part of the wider family of growth frameworks; the pricing mechanics themselves live in usage-based pricing and seat-based pricing.

Key Facts: The Usage-Based Revenue Model

• 85% of surveyed software companies have adopted usage-based pricing, per a January 2025 survey of 100 SaaS companies run by billing vendor Metronome with Greyhound Capital; the report never defines the term or separates pure consumption from hybrid, so treat it as directional on a small vendor-run sample. (Metronome, State of Usage-Based Pricing 2025)
• 44% of software executives report challenges capturing and measuring customer usage in pay-per-use models, in a March 2026 survey of 350 software executives covering the United Kingdom only. (m3ter and PwC UK, March 2026)
• In that same UK survey, 62% lacked confidence in their exposure to revenue leakage, rising to 72% among companies running usage-based pricing, against leakage estimated at 4 to 7% of annual recurring revenue. (m3ter and PwC UK, March 2026)
• 87% of those UK executives reported no integration between billing and their ERP or general ledger, and 48% none between billing and CRM. (m3ter and PwC UK, March 2026)
• Just over a third had introduced pay-per-use pricing alongside traditional pricing for AI, and half had changed pricing at least twice in the previous year. (m3ter and PwC UK, March 2026)
• Intercom prices its Fin AI agent per outcome, listing "From $0.99 per Fin outcome" alongside its seat plans and charging once per conversation (confirmed September 2026). (Intercom pricing)

What a Usage-Based Revenue Model Actually Is

The defining feature isn't that the price varies. It's that the billable quantity is produced by the customer's behavior after signature, not fixed at it. A seat-based contract knows its own value on day one: 200 seats times a rate, times a term. A consumption contract knows a rate card and a guess, and that gap is where all the operational work lives.

That last row is the one teams underestimate. Under a subscription, a customer who stops caring still pays until renewal, which buys time to intervene. Under consumption, disengagement shows up in the revenue line immediately, which is either an early warning system or a fast bleed depending on whether anyone is watching. That's why usage monitoring alerts become revenue infrastructure.

The Five Structures People Call Usage-Based

"Usage-based" is a single label for at least five commercial structures that behave differently in billing, in the customer's budgeting process, and in how revenue lands in the P&L. Most companies run two or three at once, on different products or segments.

Credits are the structure most often adopted for the wrong reason. They get sold as a customer-friendly innovation when they're really a concession to procurement: a buyer who can't approve open-ended spend can approve a fixed credit purchase. But credits move money before value is delivered, which creates deferred revenue, a breakage estimate, and an expiry policy customers read as either fair or predatory.

Outcome pricing is the newest and hardest to run. Intercom counts a Fin outcome when a customer confirms resolution, doesn't ask for further help, or Fin completes a workflow including a handoff (Intercom pricing, confirmed September 2026). That definition does enormous commercial work, and every ambiguous case in it is a future billing dispute, which is why outcome pricing appears mostly where the outcome is machine-observable.

Why the Published Adoption Numbers Disagree So Badly

Search for how many software companies use usage-based pricing and you'll find figures from the high thirties to the high eighties, cited confidently and often circularly. They aren't fabricated so much as incomparable, because the five structures above get counted as one thing. Metronome's 85% counts any company with "some level" of usage-based pricing, so one metered add-on beside an otherwise per-seat product qualifies, and the report never defines the term. The m3ter and PwC figure of just over a third asks something much narrower: pay-per-use introduced alongside traditional pricing, for AI specifically, in the United Kingdom only. Different question, different country, different year, and neither is wrong.

So stop asking what share of companies have adopted usage-based pricing and start asking what share of your own revenue is metered. That's computable, it moves for real reasons, and it's the input the forecasting and comp problems below actually need. The same rule runs through the growth metrics hierarchy: a metric with an undefined denominator can be quoted but not managed.

Choosing the Meter: What Makes a Value Metric Hold Up

The meter is the unit the model charges on, and it's the highest-consequence decision in the design. Three tests separate a durable meter from a fragile one: it scales with the value the customer receives rather than with vendor effort, the customer can predict it roughly before the bill arrives, and it's cheap to measure honestly, so the vendor can show the customer the same number the invoice used. That first test is the same arithmetic a value selling framework runs before a deal, with one difference: here the number gets re-tested every billing period instead of once in a business case.

The failure pattern worth naming is the meter that only ratchets up. A cumulative lifetime counter, whether of records created or messages sent, guarantees that every long-tenured account eventually crosses into a higher tier for reasons unrelated to the value it's getting this quarter. Loyal customers get billed more for tenure, which reads as a penalty rather than a price. Meters that reset, or that measure current state rather than an all-time total, avoid that entirely.

What the Company Has to Build Before It Can Bill

A subscription business invoices from a contract. A consumption business invoices from an event stream, which means billing sits downstream of production telemetry that was never built to be financially accurate. The gap is real: 44% of the 350 UK software executives m3ter and PwC surveyed reported challenges capturing and measuring usage, and almost two-thirds lacked full confidence their finance systems could capture usage data and invoice correctly (m3ter and PwC UK, March 2026).

Integration matters as much as the systems themselves, because leakage in a metered business is rarely theft. It's unbilled events, rate cards applied wrongly, credits that expired unrecognized, and overages nobody caught, and every one of those is an integration gap. The same survey found 87% with no link between billing and the general ledger. This plumbing belongs in growth tech stack design, not a scramble the week before the first invoice run.

Revenue Recognition Finance Can Defend

Under ASC 606, the simplest consumption contract has a clean answer. The right-to-invoice practical expedient in ASC 606-10-55-18 lets an entity recognize revenue in the amount it has a right to invoice when that right "corresponds directly with the value to the customer of the entity's performance completed to date" (PwC, Revenue from contracts with customers guide, chapter 6). Bill a flat rate per unit in arrears and revenue lands in the period consumed.

The expedient is not automatic, and PwC's guide is explicit: management "should not presume that a negotiated payment schedule automatically implies that the invoiced amounts represent the value transferred to the customer." The moment the rate stops corresponding to value delivered, the shortcut stops applying, and most of the structures above do exactly that.

Every clever pricing structure carries an accounting cost, so bringing accounting in while the rate card is still a draft costs far less than discovering the problem at the first audit.

Forecasting When Revenue Is a Distribution, Not a Number

Subscription forecasting is arithmetic on a contract file: you know the values, the renewal dates and a churn assumption, and the rest is judgment about new bookings. Consumption forecasting is different, because the contracted base tells you little when the same signed customers can consume far more or far less next quarter without a single commercial event.

Two habits make the range credible. Model at cohort level, grouping accounts by signup period and segment and letting the aggregate emerge, instead of forecasting one company-wide growth rate. And separate the base from the tail, because a handful of accounts usually drive a large share of the meter and have to be modeled individually. ARR forecasting covers the mechanics in more depth.

What It Does to Sales Compensation and Customer Success

A commission plan needs a number to pay on, and under consumption there isn't one at signature. Every workable answer is a compromise between paying reps promptly and paying them for revenue that materialized.

Reps optimize for the number they're paid on, so the plan is really a statement about which behavior the company wants. Pay entirely on commit and you get oversized commitments customers never consume and refuse to renew. Pay entirely on realized consumption and reps won't touch enterprise deals with long ramps. Most land on a split, and that ratio is the most revealing artifact of what a company believes about its own model, which is why it belongs in the same conversation as land and expand strategy.

Customer success changes more. Under subscription the job is retention measured at a renewal date; under consumption it's consumption health measured continuously, so a CSM's dashboard has to show usage trend, dormancy, and how concentrated usage is in one team or use case. A flat week is a signal, and a change in which teams are consuming is a bigger one. Usage-based expansion covers how those signals become revenue motions rather than alerts.

The Board-Metric Problem: ARR Becomes an Estimate

Annual recurring revenue was designed for fixed contracts, where it's clean because the contract says what it is. Under consumption it becomes an annualization of something that varies, which makes it a modeling choice, and different choices produce materially different numbers for the same business.

The failure here is rarely dishonesty. It's a definition that drifts one quarter at a time until the trend line stops meaning anything. A company that annualizes the trailing month in a strong quarter and the trailing quarter in a weak one has built a metric that flatters itself automatically. The defense is boring: write the definition down, state the window in every reporting pack, and treat a change to either as a disclosure. Revenue architecture covers how those definitions hang together.

Where the Model Wins and Where It Fails

Consumption pricing works beautifully for some products and is a slow-motion disaster for others, and the difference is structural rather than a matter of execution. The question isn't whether the model is modern, but whether the product has an honest unit and the buyer can live with a variable bill. It also pairs with a motion: consumption suits the low-touch end of the market, where a transactional sales model already keeps cost to serve well under what a single deal returns.

Infrastructure, data platforms and developer tools sit in the left column, which is why they adopted the model first and why it feels native there. That's the world the devtools growth model is built around, where the unit was obvious before anyone designed a rate card. The right column deserves equal respect. A security tool whose value is that an incident never happened has no honest meter, and charging per scan rewards noise. Forcing consumption onto that gives you a model that's harder to sell, harder to bill, and no better aligned to value.

The AI Pricing Angle: Why Variable Costs Broke Per-Seat

This is the live reason the model is spreading beyond infrastructure. Traditional software has near-zero marginal cost, so a flat per-seat price works: heavy and light users cost about the same to serve. An AI feature breaks that, because every inference costs real money and a heavy user can cost orders of magnitude more than a light one. Sell that at a flat seat price and the heaviest users, usually the ones getting the most value, are the ones destroying the margin. The vendors selling the underlying capability meter it precisely, which is why the layer above struggles to absorb the cost into a seat.

Two patterns run across those five. Hybrid wins, because almost nobody replaced seats outright: Intercom and Salesforce both kept their seat plans and added a meter beside them. And the customer-facing AI meter is usually a credit or an outcome rather than a raw token count, because a token is a unit the buyer can't forecast, price, or explain to their own finance team. Credits abstract that volatility into something procurement can approve.

Half of those UK executives had changed pricing at least twice in the previous year (m3ter and PwC UK, March 2026), and that churn is the real signal: nobody has settled this. Any company adding an AI feature to a per-seat product should model gross margin at the heaviest decile of usage, not the average, with the discipline applied in CAC payback optimization. The average case is not the case that kills you.

Migrating a Seat-Based Base Without a Revenue Shock

Moving an existing base from seats to consumption is the hardest version of this project, because every account has a current bill it considers normal and a renewal conversation in which it will discover the change. Do it badly and a pricing decision becomes a churn event.

Two mechanics do most of the work. A price-protection window, capping how much more an account can pay for a defined period, turns an open-ended threat into a bounded one. And a modeled invoice showing what the last three months would have cost under the new meter moves the conversation from fear to arithmetic. The accounts that get more expensive deserve individual handling before the announcement, because a small number of heavy users generate most of the resistance and they're often the most engaged customers you have.

Conclusion

A usage-based revenue model is a company decision disguised as a pricing decision. The rate card is the easy part. The hard parts are a meter that tracks value the customer recognizes, telemetry accurate enough to invoice from, revenue recognition an auditor accepts, a comp plan that pays for the behavior you want, a forecast honest enough to be a range, and a board metric whose definition doesn't drift.

Companies that get this right share one habit: they instrument before they price. The ones that get it wrong picked a structure because a competitor moved, then spent a year discovering which of those systems they hadn't built.

Related Topics

• What Are Growth Frameworks
• Revenue Architecture
• Growth Metrics Hierarchy
• API-First Product Growth
• Land and Expand Strategy
• Usage-Based Pricing
• Seat-Based Pricing
• ARR Forecasting