Reviewing a Financial Model: What the ICAEW Financial Modelling Code Recommends

A financial model can look polished and still be wrong. Reviewing one is hard because the logic is spread across cells, sheets and sometimes macros, and the person who built it is rarely the best person to find its flaws. This post looks at what the ICAEW Financial Modelling Code recommends and how its checks can be turned into a practical review. ICAEW is a UK professional body, and the Code is published good-practice guidance, not Irish law or a mandatory standard, so use it as a reference point rather than a rulebook. If you are still setting up your own approach, our guide to financial modelling in Excel for Irish finance teams is a useful companion.

What the Code is, and what it is not

ICAEW's Financial Modelling Code is an ICAEW publication; the copy we read carries an August 2024 mark and a 2024 copyright notice. It sets out principles-based good practice for building and using spreadsheet financial models. According to the document, it was created because no widely accepted set of principles existed, it draws on a review of existing methodologies and input from a number of organisations, and it builds on ICAEW's earlier "Twenty principles for good spreadsheet practice". It is written for Microsoft Excel, and the Code says many of its lessons are appropriate for other kinds of spreadsheets or models built in other software.

Importantly for reviewers, the Introduction says the Code "is not intended to be a tick-box compliance tool". It is a framework for setting standards and informing decisions, and it expects judgement rather than rigid application. In practice that means you should scale the review to the model's risk, not apply every check to every workbook. ICAEW's web page for the Code carries no date, so the document itself is the better reference.

The areas the Code covers

The Code groups its guidance under seven headings. Each one is a useful lens when you review someone else's model:

• Model definition and purpose: understand the scope and determine the goals of the model.
• Layout and structure: plan the workbook layout, make navigation simple and make inputs easy to find.
• User interface and transparency: include user guidance, avoid duplication, separate forecast and dummy data, and do not hide things.
• Consistency: use consistent formulas and consistent placement.
• Clarity: use clear formatting, labels, units, sign conventions and names.
• Error reduction: review and test models, include checks and a master check, and consider restrictions on inputs.
• Calculation techniques: minimise complexity, build traceable references, avoid hardcoding and circular references, avoid unnecessary rounding, and use VBA and macros sparingly.

Checks the Code recommends

The following points are drawn from the Code's own wording; we have paraphrased most of them and quoted short phrases where the exact words matter.

Purpose and tool choice

The Code's first section asks you to understand the scope and determine the goals of the model, and to identify whether a spreadsheet is the right solution or another medium should be used. A reviewer can start there: does the model do what it says it does, and is a spreadsheet still a sensible home for it?

Inputs and transparency

The Code asks for a unique location for each input value, with calculations referring to it. It asks for a user guide to be embedded in the workbook, warning against storing documentation in a separate file or email that "may become separated from the model itself". It says forecast and actual data should be kept in separate areas, dummy data labelled, and everything left visible, noting that "Hidden rows are easily missed" (with the narrow exception of empty columns beyond the used range).

Error reduction

The Code recommends a review and testing regime in proportion to the risk the model presents. It suggests predicting how outputs should change when inputs change and comparing that with what the model does, and operating peer review where a model's impact is particularly significant. It asks for an equality check for each set of values calculated separately, with a small tolerance for rounding, and a master check that flags any failing check to the user. It also says data validation should be used to limit invalid inputs but not excessively, and warns against validation "with a generic error message and no guidance".

Calculation techniques

For calculations, the Code says to break complex calculations into multiple stages and to avoid manual calculation mode because users may not realise that outputs are not live. It says hardcoding should never be used for values that could change during the model's life, recommends disabling the iterative calculations setting, and says to keep calculations unrounded and round only final outputs. It describes VBA as "a weapon of last resort" and asks that native Excel functions be used for anything that affects results.

A staged review, using ICAEW's review guide

ICAEW also publishes a document called "How to review a spreadsheet" (also marked August 2024). It describes a staged approach, which we have summarised here:

1. Initial review: the big picture, including purpose, risk level, the author's competence, earlier reviews, life cycle and construction controls.
2. Structural review: layout and soundness without going into detail, such as documentation, separation of inputs, workings and outputs, built-in checks, external links and complex features like macros.
3. Data review: whether input data makes sense and agrees to its sources, using methods such as test data with known results, zero inputs and stress testing.
4. Analytical review: whether the output looks right overall, through reasonableness, trend analysis, ratio analysis and reperformance.
5. Detailed review: formula-level testing, proportionate to risk, including circular references, nested IF statements and IFERROR masking errors.
6. Post-review activities: documenting the review, communicating findings, implementing corrections and maintaining the file.

The guide stresses that no review can prove a spreadsheet error-free, that human judgement is central, and that independent review is preferred over self-review. It also names Excel features that help, including Inspect Workbook, Edit Links, Trace Precedents and Dependents, Show Formulas, Error Checking and Evaluate Formula. Menu names change between Excel versions, so check the current Microsoft documentation for your version.

An illustrative check

Illustrative example (made-up round numbers, not real data). A forecast balance sheet shows total assets of 1,200 and total liabilities plus equity of 1,150. A balance check cell should show a difference of 50 and turn the master check to "fail". The reviewer's job is then to trace why: a missing cash flow link, a hardcoded opening balance or a circular reference that has been switched off. Without the check, the sheet might have been circulated unnoticed. Building such checks in from the start is what the Code means by error reduction.

Our suggestions for a practical review process

These are our suggestions, not requirements of the Code or of any Irish rule.

• Agree the risk level first. A model supporting a board decision deserves more review than a one-off analysis.
• Use a different reviewer from the builder. ICAEW's guide prefers independent review.
• Keep a short review log inside the workbook. Record what was checked, by whom, on which version and what was changed.
• Test with simple inputs. Set growth to zero or a round number and see whether the outputs move as you would expect.
• Link review to your terminology. If colleagues use terms differently, our financial modelling glossary can help agree meanings, and our guide to building a three-statement financial model shows the structure many reviewers will expect to find.

Learnsignal's offices are off Baggot Street in Dublin, and we offer in-person training from there. For current details, see our CPD pages.

Frequently asked questions

Is the ICAEW Financial Modelling Code mandatory in Ireland?

No. ICAEW is a UK body and publishes the Code as guidance. The document itself says it is not intended to be a tick-box compliance tool. Irish finance teams can use it voluntarily as a reference point.

What is a master check?

The Code describes it as a summary check that flags any failing check to the user, so that one cell tells you whether the individual checks in the model have passed.

Does the Code require a second reviewer?

It recommends peer review, by a colleague or a professional audit, where a model's impact is particularly significant. It does not set out a fixed rule for every model; proportionality to risk is its theme.

Should I avoid VBA entirely?

The Code calls VBA "a weapon of last resort" and asks for native Excel functions for anything affecting results, and for VBA code to be well documented where it is used. It does not say VBA must never be used.

Does a reviewed model prove the numbers are right?

No. ICAEW's review guide says no review can prove a spreadsheet error-free. Review reduces risk and gives you evidence of care; it does not give a guarantee.

In short: use the Code as a checklist for conversation, scale your review to the risk, and have someone other than the builder do it.