Forecasting Revenue After Moving Part of Pricing to Usage or Credits

Under subscription pricing, next quarter's revenue is mostly a known quantity. You have contracts, you have renewal dates, and the forecast is a question of churn and expansion against a fixed base.

Move part of the price to usage or credits and that certainty goes. Revenue becomes a function of what customers choose to do, which is a behaviour you observe rather than a number you hold.

This is the part of the shift finance teams consistently flag as the hardest.

It is the most cited difficulty, not a minor one

In the State of B2B Monetization in 2026, Kyle Poyar found that companies on usage and outcome pricing say forecasting revenue is their main difficulty. Not billing complexity. Not customer confusion. The forecast.

Zuora's 2025 survey of 991 finance leaders puts numbers against it: 95% say forecasting is harder under usage pricing, and 71% report breakdowns or major problems implementing usage pricing, particularly when usage, billing and revenue data sit in separate systems. Zuora sells billing software, so the framing favours their product, but the specific failure they identify is one that shows up independently.

In text: Say forecasting is harder under usage pricing: 95%. Report breakdowns or major implementation problems: 71%.

The difficulty is mostly a data problem

The Zuora finding contains the useful detail: the problems concentrate where usage, billing and revenue data are in separate systems.

That is worth separating from the pricing model itself. Forecasting consumption is genuinely harder than forecasting a contracted subscription. But a large share of the pain companies describe is not forecasting difficulty, it is the inability to see what has already happened quickly enough to forecast from it.

If usage lives in the product database, billing lives in the billing system, and recognised revenue lives in the finance system, then answering a basic question requires three exports and a reconciliation. By the time the analysis is done the month has closed.

What a usable forecast needs

Four things, none of which are exotic.

Usage at the customer level, available daily. A monthly roll-up is too coarse. The signal that a customer is ramping up or falling away appears within a month and matters most when it is early.

A link from usage to revenue. Consumption units have to translate into recognised revenue through whatever rates, allowances, tiers and overage rules apply. If that translation happens in a spreadsheet, the forecast inherits every error in it.

Cohort history. The ramp pattern of a customer in their first ninety days is usually very different from one in year two. Forecasting from a blended average across both produces a number that describes neither.

Allowance consumption, not just usage. Under a credit model what matters is how far through their allowance each customer is and how fast they are moving. Two customers with identical usage are in completely different positions if one has consumed 20% of their credits and the other 90%.

In text: 1. Daily usage at customer level 2. Rules that turn usage into revenue 3. Cohort ramp patterns by tenure 4. Allowance consumption and pace

Forecast the base and the variable separately

Most companies moving to usage keep a committed component. Forecasting the whole thing as one number loses the structure that makes it tractable.

The committed portion forecasts like a subscription. It is contracted and it behaves predictably.

The variable portion needs a different method: cohort ramp curves, seasonality, and a view of which accounts are approaching their allowance. Modelled separately, the uncertainty is confined to the part that is genuinely uncertain, and the size of that part is itself useful information for the board.

Narrow the range rather than chasing a point

The expectation that needs to change is the one about precision. A usage-based forecast is a range, and the honest version is presented as one.

That is a different conversation with a board than a single number, and it is better had explicitly at the point the pricing model changes rather than discovered in the first quarter that misses.

What you can commit to is narrowing the range over time as cohort data accumulates. The first two quarters after a model change will be wide. That is a function of not yet having the history, not a failure of method.

Do the data work before the pricing change

The sequencing matters. Companies that move to usage pricing and then try to build the reporting spend their first few quarters unable to explain their own revenue.

If a usage or credit component is on your roadmap, connecting usage, billing and cost data belongs before the launch rather than after it.

If you are moving part of your pricing to usage or credits, our pricing and packaging work covers the data foundation it needs.

Related reading: How to Set AI Credit Rates and Allowances Customers Can Predict and The Four Data Sources Every Pricing Decision Needs.