Top-Down, Bottom-Up, Driver-Based, Statistical: A Straight Guide to Forecasting Methods

Ask three FP&A analysts which forecasting method is “correct” and you will get three different answers, usually argued with some heat. That is the wrong argument. Top-down, bottom-up, driver-based, and statistical forecasting are not competing philosophies where one wins. They are four different tools, each suited to different line items, and treating them as a single choice is why so many forecasts are either too coarse to act on or too detailed to maintain.

The more useful question, especially now that AI is starting to generate parts of the forecast, is not “which method is best.” It is “what is this number anchored to, and can I trust that anchor.” Get that answer right per line item and the method choice mostly falls out on its own.

The four methods, plainly

Top-down starts from a macro figure (total addressable market, last year’s revenue plus a target growth rate, an industry benchmark) and allocates it down to departments, regions, or products. It is fast and useful for setting an initial target or sanity-checking a bottom-up build, but the allocation logic is often a guess dressed as precision. Splitting $10M target revenue 40/35/25 across three regions because that was last year’s split is not analysis; it is inertia with a spreadsheet.

Bottom-up builds the same number from the ground: sales reps’ pipeline by deal, headcount plan by role, unit economics by SKU, summed upward into a total. It takes longer to build and maintain but the number means something: you can trace $4.2M in projected Q3 revenue back to 340 individual pipeline opportunities weighted by stage. The tradeoff is maintenance cost. A bottom-up model with stale pipeline data is worse than no model, because it looks precise while being wrong.

Driver-based forecasting picks the handful of operational levers that actually move a line item (headcount and average salary for payroll, seat count and net revenue retention for SaaS ARR, units and price for a product line) and expresses the forecast as an explicit formula over those drivers. It sits between top-down and bottom-up: more disciplined than a growth-rate guess, less granular (and less maintenance-heavy) than modeling every transaction.

Statistical / ML forecasting fits a model to historical time series (moving averages, exponential smoothing, ARIMA, or a trained regression) and projects forward. It is the only one of the four that does not require you to specify a causal story; it just finds the pattern in the data and extends it. That is also its weakness: it extends the pattern, not the business logic. A statistical model has no idea your biggest customer just gave 90-day notice.

Method	Anchored to	Best for	Weak for
Top-down	A target or benchmark	Initial planning targets, quick sanity checks	Line items where allocation logic is arbitrary
Bottom-up	Individual transactions or deals	Sales-driven revenue, headcount cost	Line items with too many components to track individually
Driver-based	A small set of causal levers	Recurring revenue, cost lines with clear drivers	Line items with no stable driver relationship
Statistical / ML	Historical time series	High-volume, stable-pattern lines (utilities, card fees)	Anything with a step-change or no history yet

Why “which method” is the wrong first question

Real forecasts blend all four, by line item, not by company-wide edict. A SaaS company might drive ARR bottom-up from the sales pipeline, project churn statistically off two years of cohort data, build payroll driver-based off a hiring plan, and set a top-down ceiling on total opex growth to keep the board honest. None of that is inconsistent. Each line item gets the method that matches how it actually behaves.

The mistake is picking one method as house style and forcing every line through it, bottom-up modeling every SaaS renewal by hand when a cohort-retention curve would do, or a single top-down growth rate applied to a cost base that is actually driven by headcount decisions someone already made. The method should follow the nature of the number, not a template.

The one question that applies to all four

Here is where the four methods stop being different and start being the same problem: whichever method you pick, the actuals it is anchored to have to be real.

A statistical model trained on historical revenue that includes a duplicated invoice from a botched ERP migration will confidently extend that error forward: the trend line is a guess dressed as math, and a bad input makes the guess worse without changing how confident the output looks. A driver-based build is not automatically safer; “arithmetic on reconciled actuals” is only true if the actuals feeding the drivers are actually reconciled. Headcount times average salary is simple math, but if the headcount figure double-counts a contractor who was already in the HRIS export, the simple math produces a wrong number with total confidence. Bottom-up is not immune either: a pipeline forecast built from a CRM that has not been reconciled against closed-won revenue in the ledger will double-count deals that already closed, or miss ones that closed off-cycle.

This is the part that matters most once AI enters the picture. An AI system generating or explaining a forecast can apply any of the four methods competently (the reasoning step is usually fine). What it cannot do is verify, on its own, that the historical actuals it is extending, allocating, or driving off are correct. That verification has to happen upstream, in the data layer, before the forecasting method ever runs. A forecast built on unreconciled actuals is wrong regardless of which of the four techniques generated it, and no amount of forecasting sophistication fixes a bad anchor.

Putting it together: a practical selection rule

A workable default, per line item:

1. Is there a stable, high-volume history with no expected structural change? Use statistical. Recurring bank fees, utility costs, predictable seasonal patterns.
2. Is there a small number of clear causal drivers you can name? Use driver-based. Payroll, subscription revenue, cost of goods tied to unit volume.
3. Is the line item made of individually trackable, material transactions? Use bottom-up. Enterprise sales pipeline, capital projects, a headcount plan by named role.
4. Do you need a fast target before a detailed build exists, or a sanity ceiling on an aggregate? Use top-down. Early-stage planning, board-level growth targets, cross-checking a bottom-up roll-up.

Then reconcile the four back to each other. If driver-based payroll and bottom-up headcount planning disagree on total heads, that disagreement is signal, not noise: one of the two inputs is stale.

Takeaway

There is no single best forecasting method, and the search for one is a waste of a planning cycle. Top-down, bottom-up, driver-based, and statistical each fit a different shape of line item, and most real forecasts use three or four of them at once. What every method shares is a dependency on the actuals underneath it. A statistical trend, a driver formula, and a bottom-up roll-up are each only as trustworthy as the ledger data they are built on, and if that foundation is not reconciled, the method choice is a debate about the wrong layer of the problem.

Rexfin’s role is that foundation: one reconciled model, tied to the ledger, that any of these forecasting methods can be built on with a traceable answer to “where did this number come from.” Book a demo to see it against your own chart of accounts.

For the driver-based method in more depth, see driver-based forecasting and deterministic math. For how Rexfin sets the historical anchor any of these methods run from, see forecast baselines. And for how a rolling cadence keeps whichever method you pick current, see rolling forecast cadence.