How to Review a Financial Model Before It Leaves Your Desk

The maker cannot be the checker

The person who built the model knows what they intended it to do. That knowledge is exactly what prevents them from seeing what it actually does. They will read the formula they meant to write rather than the one on screen, and they will skip the schedule they are confident about — which is disproportionately often the one that is wrong.

This is not a comment on anyone’s competence. It is why banks operate maker-checker separation as policy rather than as a suggestion, and why any model going to an external party should have been through at least one person who was not involved in building it.

Where the team is too small for full separation, the next best thing is time and structure: review against an explicit checklist, in a different session from the build, working through the layers in order rather than browsing.

Layer 1 — Structural integrity

Assess the architecture before evaluating a single formula. A structurally unsound model cannot be reliably audited at the later layers, because errors you find in the formulas may be symptoms of structural problems you should have caught first.

What you are checking: whether inputs, calculations and outputs are separated; whether assumptions are centralised or scattered; whether any numbers are hardcoded inside formula cells; whether circular references exist and, if so, whether they are intentional and controlled; whether the file is versioned sensibly and carries a changelog; and whether colour coding is applied consistently enough to make the tab readable at a glance.

Pass standard: zero unintentional hardcodes in formula cells, all inputs in a labelled assumptions area, any circularity documented and toggleable, version log present.

Layer 2 — Formula logic

This layer is mechanical and benefits from tooling — Trace Precedents and Trace Dependents, and Ctrl+` to reveal every formula at once. The goal is not to re-derive every calculation but to confirm that formulas do what they claim and are consistent across the model.

The highest-yield single check is consistency across a row. Select a projection row and confirm the formula is identical in every period. An exception is either deliberate and needs flagging, or it is the error you were looking for.

Then the ties: does the balance sheet balance to zero in every period and every scenario; does closing cash on the cash flow statement equal the balance sheet cash line; do the debt schedule closing balances agree with the balance sheet; does interest reference the correct opening or average balance; does the revolver behave correctly at both zero and its cap.

Pass standard: balance sheet balances to zero tolerance in all scenarios, all ties reconcile, no formula inconsistency across equivalent periods, and every sensitivity table verified by manually reproducing one corner.

Layer 3 — Assumption defensibility

This is the layer teams compress or skip, and it is the one external reviewers care about most. A structurally perfect model with indefensible assumptions will not survive a sophisticated counterparty — it will just fail more precisely.

The test for each material assumption is simple: can it be traced to something outside the model? Historical performance, a comparable company, a transaction precedent, a signed contract, a market data source. An assumption whose only basis is the builder’s judgement is not automatically wrong, but it needs to be labelled as such so the reviewer knows where the model rests.

Specific things worth challenging every time: revenue built from growth percentages rather than volume and price drivers; margins that expand without an explicit operating leverage assumption behind them; working capital modelled as a percentage of revenue rather than from days; capex not split between maintenance and growth; and a terminal growth rate that is inconsistent with the reinvestment the model assumes.

Pass standard: every material driver traceable to a stated basis, working capital driver-based, terminal assumptions internally consistent, and nothing that requires the reviewer to take the builder’s word for it.

Layer 4 — Output coherence

The final pass asks whether the outputs tell a consistent story, and whether that story matches the thesis the model is supposed to support.

For a transaction model, does the returns bridge attribute value creation correctly across growth, margin, multiple and deleveraging, and does it reconcile to the total? For a valuation, do the DCF, comparable company and precedent transaction ranges sit in a sensible relationship on the football field — and if the DCF sits entirely outside the market-based ranges, is that explained rather than ignored?

Then the scenario test: is the downside case a plausible stress with identified triggers, or is it the base case with every input mechanically reduced by ten percent? Lenders and investment committees test this specifically, because a downside that is just arithmetic tells them nothing about the actual risk.

Pass standard: the output page answers the central question without opening a calculation tab, the returns or valuation reconciliation is complete, and the downside is a documented stress case rather than a mathematical compression.

Documentation that makes the review durable

A review produces no lasting value if its outputs are not recorded. Three conventions carry most of the weight.

File naming: [Project]_[ModelType]_[Version]_[YYYYMMDD], with no spaces and no "Final_FINAL" variants. A changelog tab recording what changed between versions, who changed it and why — which is the evidence trail that explains why an assumption differs between the version sent to the lender and the version shown to the board.

And assumption documentation: a stated basis for every material input. "Management estimate" is not a basis. "Management estimate, benchmarked against three-year historical average and two comparable companies" is.

When to get an outside pair of eyes

Internal review has a structural ceiling. The team that built the model also shaped the assumptions, and shares whatever view of the business produced them. That is a bias internal review cannot fully correct for, however rigorous the process.

Three situations warrant external review: any model going to a lender, investment committee or transaction counterparty; anything used in a regulatory or audit context, where documentation standards are higher than most internally built models meet; and any team whose modelling skills were self-taught, where the architecture will reflect gaps the team cannot see precisely because they do not know what bank-grade structure looks like.

The right response to a model that fails external review is not to fix the flagged errors and move on. It is to work out why the internal process did not catch them, and change the process.