A revenue forecast worth trusting is built from the bottom up. Model each product, region, and channel at the grain where its drivers live, then reconcile those component forecasts into a total that adds up. A single top-line curve reads well in a board deck and tells you nothing when the number misses. This piece covers how to build the hierarchy, wire in the drivers, and evaluate the result the way a CFO will.
Revenue at an operating company is really hundreds of small series stacked together: products, regions, channels, customer cohorts, each with its own seasonality and its own reasons to move. Fit a curve to the top line and you erase all of it. When the number misses, you cannot say whether volume softened, price moved, a cohort churned, or one large account slipped a quarter. You have a wrong number and no way to interrogate it.
Forecast the components, reconcile the total
The structure worth building is hierarchical. You forecast at a granularity where a human can name the driver: units per SKU per region per week, or active accounts per plan per segment. From there you aggregate upward to the operating plan. Two properties make the extra plumbing worth it.
- The bottom-level series are where the signal is. Seasonality, promotions, sales-rep ramp, and cohort decay all show up cleanly at the grain and get washed out in the aggregate.
- Reconciliation keeps the levels honest. Independent forecasts at each level of the tree will not add up on their own. You reconcile them so the sum of the parts equals the forecast of the whole, and the residuals get distributed by how reliable each level is rather than by accident.
In practice we lean on a global model, one learner trained across all the series rather than a separate model per SKU. A gradient-boosted model or a single deep net sees thousands of series at once and borrows strength across them, which is what lets a product with eight weeks of history inherit the seasonal shape of its category. Per-series ARIMA cannot do that. It falls apart exactly where you have the least data and the most need.
Drivers are features, and features have provenance
A revenue forecast that ignores the operational drivers finance already plans against is a forecast nobody will put in the plan. Pipeline coverage, headcount ramp, marketing spend, price changes, contract renewals. These are the levers the business pulls, and they belong in the model as features rather than as a manual overlay bolted on afterward.
The hard part is not adding them. It is adding them correctly. The failure mode that quietly ruins forecasting projects is lookahead: training on the restated, cleaned-up version of a driver that only existed weeks after the forecast date. Your backtest looks excellent and production disappoints, because in production you never had the numbers you trained on.
- Build every feature point-in-time. A driver used to forecast week 27 must reflect what was known on the cutoff for week 27, including the reporting lag and any values that were later revised.
- Keep lineage on each feature. When a forecast moves, you need to trace which driver moved it, and that means knowing where each input came from and which snapshot it was drawn from.
- Treat late-arriving drivers as their own problem. Pipeline data that lands three days after quarter-end is not a reason to peek. It is a reason to model the delay and forecast with the information you would actually have had.
A feature store that versions inputs by as-of date, rather than overwriting them, is what makes this tractable. Without it you are reconstructing history by hand every time you retrain, and you will get it wrong under deadline.
Evaluate the way you will be judged
Most forecasting eval fails the same way: a single random holdout, one accuracy number, reported to two decimal places. That is not how the model gets used, and it is not how the CFO will grade it.
Evaluate on rolling origins. Pick a sequence of cutoff dates, forecast forward from each with only the data available then, and measure the error across all of them. This mirrors the monthly cadence of an operating plan, and it exposes models that are fragile to a particular starting point.
Match the metric to the decision. Percentage errors like MAPE blow up on low-volume series and near-zero weeks, which is exactly where a fast-moving product lives early on. Scaled errors such as MASE behave better across a heterogeneous hierarchy. And report error at the level people commit to. If the plan is set by segment and quarter, a precise weekly-SKU accuracy number is not what is being decided.
Two operational habits matter more than any single metric.
- Watch drift. A revenue model degrades when the business changes shape: a new pricing tier, a channel that suddenly takes off, a cohort that behaves unlike its predecessors. Monitor forecast error by segment over time and route the outliers to a human before they quietly poison the aggregate.
- Keep the human override, and log it. Sales knows the large deal that slipped; the model does not. Let planners adjust the forecast, but capture every override with its rationale as an audit trail, so you can measure later whether the overrides helped or hurt. Over a few quarters that log tells you which parts of the model to trust and which to keep a hand on.
None of this is about chasing a lower error number for its own sake. What you want is a forecast whose movements you can explain in the language of the business, that reconciles from SKU up to the operating plan, and that survives a controller asking where every number came from.
FAQ
Why not just forecast total revenue directly?
A single top-line series hides the offsetting movements that actually explain the number, and it gives you no way to reconcile against the operational drivers finance already tracks. Forecasting the components and rolling them up keeps the total consistent with volume, price, and churn assumptions you can defend.
How much history do I need before ML beats a simple baseline?
For a series with clean weekly seasonality, two to three years is usually enough for a global model to earn its keep. Below that, or for products launched recently, a driver-based or pooled model that borrows strength across similar series will beat a per-series learner.
How do you stop the forecast from leaking future information?
Every feature is built as of the forecast cutoff, using the data that was actually available on that date, not the latest restated values. We reconstruct point-in-time versions of drivers and validate on rolling origins so the eval reflects what the model would have known in production.