Financial Model Review Checklist

Structure

• Purpose and decision question stated — a model built to answer "is this deal worth doing" looks different from one built to answer "how much working capital will we need next quarter"; state the question up front or the model quietly drifts toward answering the wrong one.
• Inputs, calculations and outputs separated — the standard convention (blue text for hardcoded inputs, black for formulas, green for cross-sheet links) exists so a reviewer can tell an assumption from a calculation at a glance, and so nobody overwrites a formula thinking it's an input cell.
• Units, dates and scenarios labelled — ₹ crore mistaken for ₹ lakh, or a stale "as of" date carried into a live model, is one of the most common and most consequential modelling errors, precisely because it doesn't throw an error.
• Version and reviewer recorded — without this, two people can each be confident they're looking at "the" model while working from different versions.

Logic

• Historical statements reconcile — opening historical figures should tie to the actual audited or reported financials, not be independently re-derived and silently drift from them.
• Balance sheet and cash checks pass — a visible zero-check row (assets minus liabilities minus equity; modelled cash minus the cash-flow-statement closing balance) should read zero in every period, not just the first one.
• Debt and interest link correctly — interest expense depends on the debt balance, which depends on cash flow, which depends on interest expense; this circularity needs either a circularity breaker/switch or an iterative-calculation setting, or the model can silently return the wrong answer or a broken reference.
• Tax, working capital and capex schedules link — these should flow into the three statements, not sit as orphaned side calculations that the income statement or balance sheet never actually references.
• No unexplained hardcodes in formula blocks — a hardcoded number pasted into an otherwise-formula cell breaks traceability and is one of the top causes of a model going stale without anyone noticing.

Decision quality

• Downside case tested — a model that only shows the base or management case cannot support a real decision; build the downside deliberately, don't just haircut revenue by an arbitrary percentage.
• Key sensitivities presented — show how the output moves across a grid of the one or two assumptions the conclusion is most sensitive to (see the DCF Sensitivity Matrix tool for a worked example of this specifically for terminal value).
• Covenant/liquidity thresholds shown — for a lending or credit context, the model should show explicitly whether covenants are breached in the downside case, not just in the base case.
• Limitations and judgment areas disclosed — no model should be handed over as if every number in it were a fact rather than an assumption; say plainly which lines are estimates and why.