Project Finance & Financial ModellingFinancial modelling structure and best practice · Lesson 8 of 20

Model standards, review and audit

Article · 18 min · 8 min lecture

Video lecture

Model standards, review and audit

9 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 9

Standards that make models auditable

  • FAST and other published modelling conventions
  • A reviewer's checklist
  • Model audit, and where AI and code help

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Why standards exist

Financial models used for project finance decisions are large, long-lived and read by many parties. Published conventions make them consistent, so reviewers can spot the row that breaks the pattern. Two widely referenced examples:

  • The FAST Standard (Flexible, Appropriate, Structured, Transparent), published openly by the FAST Standard Organisation and made available under a Creative Commons licence. It is one of the most widely adopted, independently administered modelling standards. Check fast-standard.org for the current version.
  • The ICAEW Financial Modelling Code (published 2018), which sets out principles of good practice drawn from a comparison of several organisations' modelling standards and methodologies.

Other published standards and firm-specific methodologies exist. Treat all of them as industry conventions: the value comes from applying one consistently across a team, not from choosing the "best" one.

The shared rules

AreaConventionWhy
LayoutInputs, calculations and outputs separatedAssumptions can be found, changed and audited in one place
TimelineSame columns and periods on every calculation sheetRows can be compared and linked without offsets
FormulasOne formula per row, consistent across the timelineReviewing one cell reviews the row
ConstantsNo hard-coded numbers in formulasAssumptions are visible, labelled and sourced
ComplexityShort formulas; split logic into stepsErrors are easier to see
Units and signsEvery row labelled; a stated sign conventionAvoids sign and scale errors
FormattingDistinct styles for inputs, calculations, links, checksReaders know what they can change
IntegrityNo hidden sheets, external links or unmanaged circularityNothing happens out of sight
ChecksChecks sheet with a master check on outputsBreakages are visible immediately
DocumentationModel book (inputs and sources) and version logAnyone can trace and reproduce results

Running a model review

  1. Agree scope and version. Record the file name and version reviewed.
  2. Understand the deal. Read the term sheet and key contracts first; a model can calculate perfectly and still not reflect the contracts.
  3. Map the model. Sheet list, flow of calculations, where each output comes from.
  4. Mechanical checks. Inconsistent rows, hard-codes, external links, hidden items, circularity handling, check sheet status.
  5. Logic review. Timing and flags, revenue, opex and indexation, tax, working capital, CFADS definition, debt sizing, waterfall, reserves, ratios.
  6. Reasonableness. Reconcile the first operating year by hand; compare ratios and returns against expectations; run the agreed sensitivities and confirm checks still pass.
  7. Log findings with location, description, severity, proposed fix and status; agree resolutions with the modeller and re-test.

Findings log template

IDSheetRow/cellFindingSeverity (H/M/L)Proposed fixStatus
F-01Calc_Rev214, period 17Hard-coded value overrides row formulaHRestore formula; add labelled override input with switchOpen
F-02DebtDSRASized on next 12 months; term sheet says next 6 monthsHLink sizing period to input per term sheetOpen

Hands-on: flag inconsistent rows and hard-codes with Python

import re
from openpyxl import load_workbook
from openpyxl.formula.translate import Translator

wb = load_workbook("model.xlsx", data_only=False)       # formulas, not cached values
CONST = re.compile(r"(?<![A-Z$])\b(?!0\b|1\b)\d+(\.\d+)?\b")  # numeric constants other than 0 and 1

def rel(formula, origin):
    """Translate a formula as if it sat in column A, so row-consistent formulas compare equal."""
    col_row = re.match(r"([A-Z]+)(\d+)", origin)
    return Translator(formula, origin=origin).translate_formula(f"A{col_row.group(2)}")

findings = []
for ws in (wb[s] for s in wb.sheetnames if s.startswith("Calc")):
    for row in ws.iter_rows(min_row=5, min_col=6):              # timeline starts in column F
        prev = None
        for cell in row:
            v = cell.value
            if v is None:
                continue
            if not (isinstance(v, str) and v.startswith("=")):
                findings.append((ws.title, cell.coordinate, "hard-coded value in calculation area"))
                continue
            if CONST.search(v):
                findings.append((ws.title, cell.coordinate, f"numeric constant in formula: {v[:40]}"))
            r = rel(v, cell.coordinate)
            if prev is not None and r != prev:
                findings.append((ws.title, cell.coordinate, "formula differs from left neighbour"))
            prev = r

for f in findings[:50]:
    print(*f, sep=" | ")
print(f"{len(findings)} flags for human review")

Install with pip install openpyxl. Adapt the sheet prefix and timeline start column to your model's layout. The first column of each row (period 1) sometimes legitimately differs; the reviewer decides. Commercial review add-ins (for example Operis OAK or PerfectXL) and Excel's own Inquire add-in, where your licence includes it, offer richer versions of these checks; confirm current features with the vendor.

Using AI in a review (approved tools only)

Useful: explaining a long formula in plain English; drafting test cases ("what should happen to DSCR if the construction delay input is 6 months?"); summarising differences between two versions from a change log; improving the wording of findings. Not acceptable: treating an AI explanation as proof that a formula is correct, or uploading a confidential deal model to a tool your organisation has not approved. Every AI-suggested issue is confirmed in the model before it is logged.

How to measure success

  • Findings per review falling over successive versions, with no high-severity items open at audit.
  • Mechanical checks automated and run on every version.
  • Formal model audit completed with a sign-off letter on the version used for financial close.

Key takeaways

  • Published conventions such as the FAST Standard and the ICAEW Financial Modelling Code exist to make models transparent and errors visible.
  • Adopt one convention consistently across a team; the shared rules matter more than the choice of standard.
  • Review with a checklist: understand the deal, map the model, run mechanical checks, review logic, test reasonableness, log findings.
  • Automate mechanical checks (inconsistent rows, hard-codes); spend human attention on logic, contracts and tax.
  • AI can explain formulas and draft tests but never signs off a model; lenders require an independent model audit.

Check your understanding

Quick questions to lock in the lesson. They don’t count towards your certificate.

  1. A revenue row uses the same formula in every period except period 17, which contains a typed number. What is the best finding?
  2. What is the main purpose of modelling standards such as FAST?
  3. An AI assistant explains that a DSRA formula is correct. What should the reviewer do?

Put it into practice

Take ten calculation rows from a model you use, review them against the shared rules table, and write a findings log with location, severity and proposed fix.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.