Planning & Forecasting
How do you forecast usage-based revenue?
Simplify21 September 20269 min read
In short
Forecast usage-based revenue from drivers rather than from a growth rate: accounts, usage per account, and price per unit, each built separately and each with its own history. Model the cost of serving that usage in the same place, because on an AI product the two move together and margin is the thing at risk. Report a range with the assumptions named, and separate committed revenue from consumption when you talk to investors, because they will separate it anyway.
A company forecasts ₹52 lakh for the month and bills ₹71 lakh. The next month it forecasts ₹71 lakh, because that is what happened, and bills ₹46 lakh. Nothing is broken and no customer churned. Two large accounts ran a batch job in the first month and did not in the second.
This is the ordinary condition of a usage-based business, and it breaks the forecasting method most startups learn first. A subscription forecast works because last month's revenue is most of this month's revenue. Usage revenue has no such floor, and applying a growth rate to it produces a number that is confidently wrong in both directions.
More companies are in this position than were three years ago. Usage pricing has spread from infrastructure into applications, and any product whose own costs scale with a model call has a strong reason to charge the same way.
Why a growth rate fails here
A growth rate is a summary of something, and the question is what. In a subscription business it summarises net new customers and their prices, both of which move slowly. The summary holds because the underlying things are stable.
In a usage business the same percentage is summarising at least three things that move independently: how many accounts there are, how much each one consumes, and what you charge per unit. They can move in opposite directions in the same month, which a single rate cannot represent.
The practical symptom is that the forecast is never wrong by a little. It is right for two months and then out by 40%, and nobody can say which of the three things caused it, because the model never separated them.
If your forecast cannot tell you whether a miss came from fewer customers or quieter ones, it cannot tell you what to do about it either.
Build it from drivers
The structure that works is deliberately plain: accounts, multiplied by usage per account, multiplied by price per unit. Each of those gets forecast on its own, from its own history.
Accounts
This behaves like any other customer count and forecasts the same way: new accounts from the pipeline and from marketing, less churn. It is the most predictable of the three and usually the one teams spend the most time on, which is a misallocation.
Usage per account
This is where the variance lives, and it needs splitting before it can be forecast. Three splits do most of the work.
- By cohort age. New accounts almost always ramp: they consume little in month one and reach a steady level over three to six months. A forecast that applies the average usage per account to accounts signed last week will overstate revenue every time.
- By size. A handful of accounts usually drive most of the consumption, and their behaviour is not statistical. Forecast the top ten individually, by talking to whoever owns those relationships, and forecast the rest as a pool.
- By whether usage is habitual or episodic. A workflow customers run daily is forecastable. A batch job run when a client of theirs asks for it is not, and pretending otherwise is where the 40% misses come from.
Price per unit
Usually the most stable of the three, and it moves for reasons you control: pricing changes, volume tiers, negotiated rates for large accounts. The one to watch is tier slippage, where growing accounts cross into lower per-unit pricing, so revenue grows more slowly than usage does. A model that holds price flat will overstate revenue precisely when the business is doing well.
The cost line moves with it
On a subscription product, costs and revenue are loosely coupled in a month. On a usage product they are tightly coupled, and on a product built over paid models they are almost mechanically linked.
This changes what the forecast is for. In a subscription business the forecast mostly answers how much revenue there will be. Here it has to answer what the margin will be, because the same usage that produces the revenue produces the cost, and the gap between them can move even when both are growing.
So the model needs cost per unit alongside price per unit, and it needs to reflect the things that move it.
- Model or infrastructure pricing, which has generally fallen over time but not on your schedule, and which you do not control.
- Your own efficiency work: caching, smaller models for easier requests, batching. This is real margin improvement and it belongs in the forecast only once it has actually shipped.
- Mix. A heavy account on a volume tier can consume at a cost per unit close to its price per unit, so growth in that account adds revenue and almost no contribution.
- Committed spend or reserved capacity, which lowers cost per unit and converts a variable cost into a fixed one, which is a different risk rather than a smaller one.
The failure worth naming: a company whose revenue grows 20% a month while its cost per unit holds flat, celebrating the revenue line for two quarters, and discovering that its heaviest accounts have been close to break-even the whole time. That is a blended margin problem wearing a usage-pricing costume, and the fix is the same: split it by segment.
A worked example
Illustrative figures for a fictional company. It charges ₹4 per thousand units processed and its cost is ₹1.55 per thousand.
- 180 accounts at the start of the month, 22 new, 6 churned, so 196 at the end. Of those, 22 are in their first three months and 10 are large enough to forecast one by one.
- The 154 mature pool accounts consume an average of 9.4 million units a month, so 1.45 billion between them. The 22 ramping accounts average 3.1 million, so 68 million.
- The ten large accounts are estimated individually, by asking whoever owns each relationship, at 620 million units between them. They are 29% of volume and 5% of accounts.
- That gives about 2.14 billion units: roughly ₹85.4 lakh of revenue against ₹33.1 lakh of direct cost, so contribution of about ₹52.3 lakh, or 61%.
The useful part is what happens next. Say the two largest accounts, 205 million units between them, each run 30% below forecast. Revenue falls by about ₹2.5 lakh and contribution by about ₹1.5 lakh: a disappointing month, and the margin holds. If instead the model provider raises prices 25%, revenue does not move at all, cost rises by about ₹8.3 lakh, and contribution margin falls from 61% to about 52%.
Those are two very different problems arriving in the same month's numbers. A forecast built on a growth rate shows one line moving and gives you no way to tell them apart.
Forecasting a number you cannot know
Usage variance cannot be removed, only described. Three habits make the forecast useful despite it.
- 01Give a range, not a point, and say what decides where in the range you land. Naming the two accounts that swing it is more informative than any single number.
- 02Separate the floor from the upside. Committed minimums, annual commitments and the habitual base usage of mature accounts form a floor you can plan costs against. Everything above it is genuinely uncertain and should be labelled as such.
- 03Track forecast against actual by driver, not just in total. Within two quarters you will know which of the three drivers you systematically get wrong, and that is worth more than any single month's accuracy.
What investors will ask
Usage revenue is the current fault line in how early-stage companies are valued, and the questions are predictable enough to prepare for.
The first is whether it counts as recurring. The strict answer is that consumption with no contractual minimum is not contracted recurring revenue, however reliably it repeats. Companies that present it as ARR without qualification invite an adjustment in diligence, and the adjustment is larger than the honest presentation would have cost.
The better framing separates the two. Contracted minimums and committed annual spend on one line, consumption above it on another, with the historical relationship between them shown. A business where consumption has exceeded commitments every month for two years is telling a strong story, and it is a more credible one than a single inflated ARR figure.
The second question is about concentration, and it bites harder here than in subscription businesses, because usage concentrates faster than logos do. Twelve percent of accounts producing sixty percent of consumption is a normal finding and it needs an answer.
The third is net revenue retention, which is usually the strongest thing a usage business has to say. When customers consume more as they grow, expansion happens without a sales conversation, and retention above 100% falls out of the model naturally. It is worth calculating properly and showing.
Building a floor on purpose
Everything above treats the floor as a fact to be measured. It is also something you can deliberately grow, and doing so is usually the single most valuable change available to a usage business.
The mechanisms are ordinary commercial ones. An annual commitment at a discount to list, so the customer gets a better unit price and you get a contracted minimum. A platform fee alongside consumption, which covers the cost of serving an account whether or not it is busy. Volume tiers that reward a committed level rather than an achieved one.
Each of those trades some revenue for predictability, and the trade is worth making well before you need it. A business with 60% of its revenue committed can plan a cost base and hire against it. The same business with nothing committed is running payroll against a number two customers decide each month, which is a poor position from which to do anything except worry.
How to report it monthly
- Revenue split into committed and consumption, every month, in the same format.
- Accounts, average usage per account, and price per unit as three separate lines, so a change in the total can be traced to one of them.
- Cost per unit next to price per unit, and contribution margin below both.
- The top ten accounts by consumption, with the month's movement, because that is where the variance came from.
- Forecast against actual for the month just closed, by driver, with one line on what was wrong and why.
This is more lines than a subscription business needs and it is not more work once the model is built that way, because every line already exists inside the forecast. Reporting the drivers rather than only the total is what lets a monthly review reach a conclusion instead of a shrug.
What to do this month
If your current model is a growth rate applied to last month, the first version of the better one takes an afternoon. Export usage by account by month for the last year. Split accounts into their first three months and everything after. Work out average usage per account for each group, and pull the top ten out to forecast individually. Put price per unit and cost per unit next to each other.
Then run it backwards over the last six months and see how close it gets. It will not be perfect, and it will tell you immediately which driver you have been wrong about, which is the thing a growth rate can never do.
About Simplify
Simplify is a finance clarity and investment readiness practice working with founders across India, built on six years inside startups. We write about the questions founders bring before a decision, not after it.
Planning happening after the problem rather than before it?