On 30 October 1935, at Wright Field in Ohio, the US Army Air Corps gathered to watch a formality. Boeing’s Model 299 was faster, flew further and carried more than anything its rivals had entered; the army had all but signed the order. The aircraft lifted off, climbed to around three hundred feet, stalled, and fell out of the sky in a fireball that killed two of the five men aboard, including the pilot, Major Ployer Hill — who happened to be the Air Corps’ chief of flight testing, about as experienced as a pilot could be.
The investigation found no fault with the aircraft. Hill, occupied with the many controls of a far more complex machine than anyone had flown, had simply forgotten to release a lock on the elevator. A newspaper summed it up: this was too much aeroplane for one man to fly. The instructive part is what the test pilots did next. They did not prescribe more training — their most trained pilot had just died. They wrote a short checklist of the steps every pilot already knew, to be read aloud before take-off. The Model 299 went on, as the B-17, to fly well over a million miles without a comparable accident.
The story travelled into medicine through the surgeon Atul Gawande, whose teams tested a nineteen-item surgical checklist across eight hospitals. Major complications fell from 11% to 7%, and inpatient deaths from 1.5% to 0.8%, both by more than a third. It is worth noting the honest counter-evidence too: a later rollout across Ontario found no significant improvement, which tells you something important — a checklist read out while everyone ticks boxes and stares at the floor does nothing. It works only when the people using it actually stop and verify.
A serious financial model is, in this exact sense, too much model for one analyst to hold in their head. The most expensive spreadsheet errors on record were built by experts, not novices. So the case for reviewing a model against a fixed list is the same as the case for the pilot’s checklist: not that you are careless, but that the task has more moving parts than working memory can police, and the failures are quiet. What follows is the list I would run before letting a model leave my hands. Treat it as something to verify, not to tick.
1. Integrity — does it actually add up?
- The balance sheet balances in every period and every scenario. Assets equal liabilities plus equity, year by year, in the base, optimistic and pessimistic cases — not just the one you presented.
- The three statements tie together. Net income lands in retained earnings; the cash flow reconciles to the cash line on the balance sheet. A model where they drift apart is wrong somewhere you have not looked.
- No numbers are hard-coded inside formulas. Inputs live in input cells, not buried mid-calculation where no one will ever find them to update.
- Totals capture every row. This is the Reinhart-Rogoff failure: an average or a sum that quietly stops a few rows short and shifts the entire conclusion.
- Signs and units are consistent throughout. No costs accidentally added as income, no monthly figures multiplied by annual ones.
2. Traceability — can someone else follow it?
- Every material assumption has a visible source or rationale. A number with no provenance is a guess you will later have to defend with nothing.
- The logic runs in one direction, inputs to drivers to outputs. Any circularity is intentional, documented and explicable.
- A new reader can find the two or three key drivers within minutes. If they cannot, neither will the client, and neither will you in six months.
- The model can be reproduced from its inputs. The same inputs return the same outputs, with no manual adjustments that exist only in the author’s memory.
- There is a real version history. You can say what changed between this version and the last, and why — beyond a filename ending in
_final_v3.
3. Robustness — does it survive contact with uncertainty?
- The assumptions that move the outcome most are identified. A sensitivity analysis names them; intuition usually gets them wrong.
- There is a genuine downside case. Not the base case with smaller numbers, but a scenario in which an actual decision — hiring, pricing, funding timing — would change.
- The model has been tested across the full range, not three hand-picked points. Scenario analysis, and Monte Carlo simulation where the stakes justify it.
- Cash is checked month by month, not only as an NPV over the horizon. A project can be solvent across five years and insolvent in month fourteen.
- Break-even and the conditions for it are explicit. You can state plainly the level at which the plan stops working.
4. Deliverability — can it leave your hands safely?
- The client could interrogate it without you in the room. The handover test: a model whose logic dies with its author is a liability, not an asset.
- The headline outputs match the narrative in the deck. No drift between what the model says and what the slides claim.
- Confidential and sensitive inputs are handled deliberately. Hidden data leaking through a pivot table or a “removed” column is a documented category of disaster, not a hypothetical.
- The file you hand over is the file you reviewed. One version, identified, not a folder of near-duplicates.
- Someone other than the author has reviewed it. The four-eyes principle earns its place because the error that flatters your conclusion is the one you are least inclined to go looking for.
How to use it, and where the work goes
Run the list as four passes, not twenty scattered glances, and resist the urge to tick from memory — the Ontario result is what mechanical ticking buys you. A few of these checks are tedious by hand and quietly automatic when the model sits on the right foundation. A deterministic engine makes “reproducible from its inputs” a guarantee rather than an aspiration; built-in version history makes “what changed and why” a single comparison; native scenarios and Monte Carlo turn the robustness section from a separate project into a tab. FinModeler is built around precisely those properties, which means a good part of this checklist is less a chore to perform than a description of what decent infrastructure gives you for nothing.
The remaining items — provenance, narrative consistency, a real downside, the second pair of eyes — are judgement, and no tool performs them for you. That is the point of writing them down. Major Hill knew how to fly the aircraft. He needed the list anyway.
Compare your model versions before you decide — build and review your model on FinModeler. Want the one-page version to keep beside your screen? Download the Model Review Checklist as a printable PDF.
FAQs
Who is this checklist for?
Anyone who delivers a financial model someone else will rely on — consultants and advisers above all, but also founders preparing for investors and teachers assessing students’ models. The common thread is accountability: you have to defend the model, not merely build it.
Isn’t a checklist a bit basic for an experienced modeller?
Experience is exactly why it helps. The most-cited modelling disasters were produced by skilled people whose working memory simply could not police every moving part. A checklist offloads the remembering so attention can go to judgement.
Does the order of the four sections matter?
Broadly, yes. Integrity comes first because a model that does not add up makes every later check meaningless. Traceability and robustness follow, and deliverability last, since it is the final gate before the model leaves your hands.
Sources
- The Boeing Model 299 crash, the gust-lock omission and the origin of the pilot’s checklist; the surgical-checklist results (complications 11%→7%, deaths 1.5%→0.8%) and the later Ontario null result: Atul Gawande, The Checklist Manifesto; Haynes et al., A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population, NEJM (2009); Urbach et al. on the Ontario rollout, NEJM.
- Spreadsheet-error categories referenced in the checklist (totals, confidentiality, four-eyes): the European Spreadsheet Risks Interest Group archive, as discussed in the companion piece on spreadsheet chaos.