Forecast Model Build Checklist
Executive Summary
Key Takeaways
- ✓ This is a construction-time self-check for building a forecast, distinct from a post-hoc structural audit, and is most useful applied progressively rather than only once the forecast is complete.
- ✓ Every forecast line should trace to a labelled driver on a dedicated assumptions tab, with no value typed directly into a forecast formula.
- ✓ A scenario switch should be documented and tested to confirm it does not silently break a dependent formula when the active case changes.
- ✓ Drivers should be applied consistently period-over-period, using the same referenced cell or an equivalent period-shifted reference, rather than a formula pattern that changes partway through the forecast.
- ✓ Where the forecast is structured as a rolling forecast, its update cadence and version history should be clearly documented, not left implicit.
Objective¶
This checklist sets out the construction-time checks a model builder should apply while building a financial forecast. It targets the areas most commonly responsible for a forecast that looks structurally complete but is not actually reliable: an assumption typed directly into a formula rather than referencing a labelled driver, an incomplete or unsensitizable assumptions tab, a scenario switch that silently fails to update a dependent calculation, a driver applied inconsistently across periods, or, for a rolling forecast, an undocumented update cadence. It complements the DCF-specific Forecast Assumptions & Driver Checklist with broader coverage applicable to any forecast build, not only a DCF.
Applicability¶
Applicable to any financial model containing a forecast, during its initial construction or a significant revision, regardless of the specific forecasting methodology used. Most useful applied progressively as forecast lines are built, consistent with the general construction-time discipline set out in the Financial Modelling Best-Practice Checklist.
Checklist¶
| # | Check Item | Why It Matters | Evidence to Collect |
|---|---|---|---|
| 1 | Every forecast output line traces to a labelled driver cell, with no value typed directly into the forecast formula | A hardcoded assumption inside a forecast formula does not respond when the model's stated inputs change | Formula audit confirming every forecast line references a driver cell |
| 2 | A dedicated assumptions tab exists and holds every driver the forecast uses | Scattered inputs across calculation worksheets cannot be reviewed as a complete set | Assumptions tab structure confirmed against the full driver inventory |
| 3 | Every driver on the assumptions tab is labelled with its unit and, where practical, a documented basis | An unlabelled driver forces a reader to trace the formula that consumes it to understand what it represents | Spot-check of driver labelling and units |
| 4 | Every driver on the assumptions tab is actually referenced by a live forecast formula | An orphaned driver misleadingly implies the model is more driver-based than it actually is | Reference-trace from each assumptions-tab cell to its consuming formula |
| 5 | Each driver is entered once (single point of entry), not re-typed in a second location | A duplicated driver value can be updated in one place and silently left stale in another | Duplicate-value scan across the assumptions tab and calculation worksheets |
| 6 | Input cells are structured simply enough to be sensitized cleanly by a data table or scenario switch | An input cell with embedded conditional logic behaves unpredictably when sensitized | Spot-check of input cell formulas for embedded logic |
| 7 | Where a scenario or case structure exists, each case's driver values and rationale are documented | An undocumented case cannot be assessed or defended by a reviewer | Case rationale documentation reviewed against each case's actual driver values |
| 8 | The scenario switch cell is referenced consistently by every formula that should vary by case | A formula that still references a fixed case's driver directly does not respond to the scenario switch | Reference-trace confirming every case-dependent formula reads from the switch-controlled driver |
| 9 | The scenario switch has been tested by changing the active case and confirming every dependent output updates as expected | A silent formula break under an inactive case can go unnoticed until that case is actually selected | Test log showing outputs recalculated correctly under every defined case |
| 10 | Each driver is applied consistently across every period column of the forecast | Silent formula divergence within a row is one of the hardest errors to catch on a visual scan | Row-consistency test results across the forecast period |
| 11 | Where the forecast is structured as a rolling forecast, its update cadence is documented and its version history is retained | A rolling forecast with no clear cadence or version control loses its advantage over a static forecast | Rolling forecast version log with dated entries |
Common Failures¶
- A driver correctly placed on the assumptions tab during initial construction, then re-typed directly into a formula during a later, late-stage revision, reintroducing a hardcode after the forecast was believed complete.
- A scenario switch that updates most, but not all, dependent formulas, because a formula added during a later revision was built referencing a fixed case directly rather than the switch-controlled driver.
- A forecast period column that diverges in formula structure partway through the forecast, often introduced when a later period was built by a different contributor without checking the pattern established in earlier periods.
- A rolling forecast nominally updated monthly but with several intervening months skipped, with no record retained of what was forecast during the gap.
Recommended Evidence¶
A completed pass against this checklist should be accompanied by a short build-log entry recording the date, the forecast sections checked, and any items corrected during the pass, consistent with the lighter-weight construction-time record recommended for the Financial Modelling Best-Practice Checklist. Where a scenario switch is tested (item 9), retain the test log showing the recalculated output under each defined case, since this is the evidence that demonstrates the switch works correctly rather than merely appearing to.
How to Use This Checklist¶
Apply the checklist progressively during construction — after the assumptions tab is built, after each forecast line is completed, and again after any scenario or case structure is added. Item 9, testing the scenario switch under every defined case, should be repeated whenever a new formula is added to the forecast, since a single untested addition is enough to reintroduce a silent break. For a DCF-specific forecast, follow this checklist alongside the narrower Forecast Assumptions & Driver Checklist, which adds DCF-specific checks such as terminal-year convergence.
Continue Reading¶
Prerequisites¶
- Financial Forecasting in Financial Models — the parent pillar
Related Technical Guides¶
Related Checklists¶
Related Products¶
- Financial Model Audit Engine (FMAE) — deterministic structural auditing referenced throughout this checklist
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
What is the Forecast Model Build Checklist for?
A construction-time self-check for a model builder building a financial forecast, covering driver traceability, assumptions tab completeness, scenario switch integrity, period-over-period consistency, and rolling forecast version control.
How is this different from the DCF Forecast Assumptions & Driver Checklist?
The DCF-specific checklist focuses narrowly on the forecast driver layer feeding a DCF valuation, including DCF-specific concerns such as terminal-year convergence. This checklist applies more broadly to any forecast build, covering the full construction discipline including scenario switch integrity and rolling forecast version control, not only DCF-specific driver traceability.
When should this checklist be applied during a build?
Progressively, as sections of the forecast are built, rather than only once at the end. Applying it only after the entire forecast is complete means a systemic habit, such as a hardcoded assumption pattern, may already have been repeated across every forecast line before it is caught.
Does passing this checklist mean the forecast's assumptions are accurate?
No. This checklist tests structural reliability - whether the forecast is built on traceable, consistently applied drivers - not whether the specific assumed growth rates, margins, or other driver values are themselves commercially reasonable, which is a separate judgement.
What does it mean for a scenario switch to 'silently break' a formula?
A formula that was written to reference the active scenario's driver value but, due to a structural error, continues to reference a fixed case's value regardless of which scenario is selected - producing an output that looks like it responded to the scenario change but did not, addressed in item 9 of the checklist below.
Why does rolling forecast cadence appear on a build checklist?
Because a rolling forecast's reliability depends on its update cadence actually being followed and its version history being retained, both of which are structural, checkable properties of the forecast build rather than judgement calls about specific assumption values.
Related Articles
Financial Forecasting in Financial Models
Financial forecasting is the process of projecting a business's future financial performance from a defined set of operating drivers and assumptions, structured so that every forecast line traces back to a labelled, auditable input rather than a value typed directly into a calculation. It underpins every model built for valuation, budgeting, financing, or investment decision-making, and it is also one of the areas of a financial model most prone to silent structural failure, since a forecast that looks complete can still rest on drivers that are hardcoded, undocumented, or inconsistently applied from one period to the next. This page is the hub for the Knowledge Centre's forecasting content: what a forecast driver is, the major forecasting methodologies and when each applies, the governance distinction between a budget and a forecast, rolling forecasts, and how forecasting failure modes map onto FMAE's existing structural audit rule taxonomy.
DCF Forecast Assumptions & Driver Checklist
A DCF is only as reliable as the forecast drivers feeding it, and those drivers are frequently the least scrutinized part of the model relative to the discount rate and terminal value. This checklist isolates the forecast assumption layer for focused review — the length and granularity of the forecast period, the traceability of revenue and margin drivers, the linkage of capex, depreciation, and working capital to their supporting schedules, consistency between real and nominal treatment, and ownership of each driver — for a model builder, reviewer, or investment committee member to work through before relying on the forecast.
Assumption Design Best Practices
How a forecast's assumptions are designed determines whether the forecast can actually be audited, sensitized, and defended in front of a reviewer, independent of whether the assumed values themselves are reasonable. This guide sets out five construction disciplines for assumption design: separating input cells from calculation formulas, labelling every assumption clearly with its unit, consolidating assumptions onto a dedicated tab, entering each driver once at a single point rather than repeating it, and structuring input cells so they can be sensitized cleanly without breaking the calculations that depend on them.
Financial Modelling Best-Practice Checklist
This checklist sets out the construction-time disciplines a financial modelling team should apply while a model is being built, synthesising the common ground across the FAST Standard, the ICAEW Financial Modelling Code, and general spreadsheet engineering practice. It is not a certification checklist and does not test whether a model's calculations are correct — it is a builder's self-check aid, distinct from the Financial Model Audit Checklist, which is used for independent, post-hoc structural verification rather than during construction.