Assumption Design Best Practices

Overview¶

A forecast's reliability depends on more than the reasonableness of its assumed values — it depends on how those assumptions are structured in the model. Two forecasts can use identical growth-rate and margin assumptions and differ substantially in how auditable, sensitizable, and defensible they are, purely as a function of assumption design. This guide sets out five disciplines that together define good assumption design: separating inputs from calculations, clear labelling, a dedicated assumptions tab, single point of entry per driver, and sensitizable cell design. It builds directly on the definition of a Forecast Driver and applies the general modelling discipline of Financial Model Standards specifically to forecast assumptions.

Separating Inputs from Calculations¶

The foundational discipline behind every other practice on this page is a strict separation between cells that hold an assumption (inputs) and cells that compute a result from those assumptions (calculations). An input cell should contain either a plain typed value or, where the driver is itself derived, a simple formula drawing only from other input cells — never a mix of an assumed value and calculation logic in the same cell.

Poor practice:    =Prior_Revenue * 1.08          (assumption and calculation fused in one formula)
Good practice:    Assumptions!Growth_Rate = 8%     (input cell, separately labelled)
                   Revenue formula: =Prior_Revenue * (1 + Assumptions!Growth_Rate)

This separation is what makes every other assumption design practice possible. A reviewer scanning a calculation worksheet should be able to distinguish, from formatting alone, which cells are assumptions and which are computed results — most institutional conventions use a consistent colour (commonly blue text) for input cells specifically to make this distinction visible at a glance.

Clear Labelling and Units¶

Every assumption should be labelled with a short description of what it represents and its unit — a percentage, a currency amount per unit, a count, a number of days — stated explicitly next to the cell rather than left for a reader to infer from the formula that consumes it.

An unlabelled assumption forces every reader to trace forward into the calculation layer to understand what a number means, which is slow, error-prone, and defeats the purpose of separating inputs from calculations in the first place. A labelled assumption, by contrast, is legible on its own: "Revenue Growth Rate (% p.a.)" tells a reader everything they need to know about the cell without opening a single formula.

Where a driver's basis is not self-evident — a margin assumption derived from a specific historical period, or a market-share figure sourced from a third-party estimate — that basis should be documented alongside the assumption, consistent with the broader discipline set out in Model Documentation Standards for Financial Models.

A Dedicated Assumptions Tab¶

Every driver a model uses should be consolidated onto a dedicated assumptions tab, or a small number of clearly labelled assumption blocks, rather than scattered as individual input cells across multiple calculation worksheets. A dedicated assumptions tab gives a reviewer a single location to review the entire set of judgement calls behind the forecast, and is the structural feature a scenario switch typically controls.

The assumptions tab should be organised logically — commonly grouped by forecast line (revenue drivers, cost drivers, working capital drivers) or by forecast period — and should be one of the first worksheets a reader encounters, consistent with the general information-flow ordering (inputs, then calculations, then outputs) that institutional modelling standards recommend.

Single Point of Entry per Driver¶

A given driver value should be entered in exactly one cell and referenced by every formula throughout the model that depends on it. It should never be re-typed a second time in another location, even where the second location appears, superficially, to need "the same number."

Poor practice:    Assumptions!Growth_Rate = 8%
                   A separate formula elsewhere re-types 8% directly instead of referencing the cell
Good practice:    Every formula that needs the growth rate references Assumptions!Growth_Rate directly

Single point of entry is what prevents the most damaging class of forecast error: an assumption updated in one location, believed by its author to now be reflected throughout the model, while a second, disconnected copy of the same value elsewhere continues to drive part of the forecast unchanged. A named range can help enforce single point of entry by giving the driver cell a clear, referenceable name used consistently wherever it is needed.

Sensitizable Cell Design¶

An input cell is sensitizable when it is a plain value, or a simple, self-contained formula with no embedded conditional logic that would break if the cell's value changed, structured so a data table, a scenario switch, or a manual override can vary it cleanly.

A driver cell that contains nested conditional logic, or that references a specific hardcoded period boundary inside its own formula, is difficult to sensitize reliably, because changing the intended assumption can interact unpredictably with the embedded logic. The cleanest sensitizable design keeps the input cell itself simple, and moves any conditional logic (for example, a rate that changes after a defined ramp-up period) into the calculation layer that consumes the driver, referencing the input cell rather than embedding logic inside it.

Common Errors¶

Best Practices¶

Treat assumption design as a distinct discipline from choosing a forecasting methodology — a well-chosen method built on poorly designed assumptions is still difficult to audit or defend. Apply all five practices together: separate inputs from calculations, label every assumption with its unit, consolidate assumptions onto a dedicated tab, enforce single point of entry, and keep input cells simple enough to sensitize cleanly. Review the assumptions tab specifically, on its own, before a model is passed to a reviewer, rather than relying on a general read-through of the calculation worksheets to catch assumption-design issues.

Continue Reading¶

Prerequisites¶

• Financial Forecasting in Financial Models — the parent pillar

Related Glossary¶

• Forecast Driver
• Named Range

Related Technical Guides¶

• Financial Model Standards
• Model Documentation Standards for Financial Models

Related Checklists¶

• Forecast Model Build Checklist