Financial Model Specification Template (FAST Standard)

Financial Model Specification: [Model name]

Specification for a spreadsheet-based financial model, written before the model is built or rebuilt and kept up to date while it is in use: purpose, users and decisions, scope and timeline, architecture and sheet map, inputs register, calculation logic and key formulas, outputs, design conventions, scenarios and sensitivities, checks and error flags, version control, testing and review, and known limitations. Design conventions are informed by the FAST Standard (version 02c, July 2019, FAST Standard Organisation, CC BY 4.0); the ICAEW Financial Modelling Code is cited by name as further reading. Replace every [bracketed] value and every row marked Example. This is a document format, not financial, investment, tax, legal or accounting advice.

Document control

Approvals

Revision history

Contents

1. Purpose, users and decisions
2. Scope, timeline and granularity
3. Architecture and sheet map
4. Inputs register
5. Calculation logic and key formulas
6. Outputs and reports
7. Design conventions
8. Scenarios and sensitivities
9. Checks and error flags
10. Version control and change management
11. Testing and model review plan
12. Known limitations and qualifications
13. Glossary and references

1. Purpose, users and decisions

[Two or three paragraphs: the business question, the decisions, the users and the consequence of an error.]

Example: MOD-CCG-001 is Corvid Commerce Group's single source for the annual budget, the quarterly rolling forecast and the quarterly covenant tests. It turns operational drivers (ARR movements, commerce orders, services days, hiring plan, capital projects, FX rates) into a monthly income statement, balance sheet and cash flow for the parent, each of the four operating subsidiaries and the group. The board approves the budget from its outputs and the lenders receive covenant calculations derived from it, so an error could lead to a wrong funding decision or a misstatement to lenders.

Out of scope: [list]. Example: statutory consolidation and tax filings, transfer pricing calculations, valuation for impairment testing (Impairment Test Memo, finance/impairment-test-memo), weekly cash (13-Week Cash Flow Forecast, finance/13-week-cash-flow-forecast).

2. Scope, timeline and granularity

3. Architecture and sheet map

The FAST Standard groups sheets into four functional classes: foundation (inputs, timing, indexation), workings (calculations), presentation (statements, charts, summaries) and control (checks, scenario control, change log, contents). The sheet map follows that grouping.

Import of actuals: the ledger extract is pasted as values into S09 through a fixed mapping table; no direct external links to other workbooks. If several workbooks are unavoidable, exchange data through dedicated import and export sheets.

4. Inputs register

Input rules:

• Every input row has a label, a unit, a source note and an owner in a dedicated comments column.
• Constants (single values) and time series (one value per period) are clearly distinguished by layout and format.
• Data validation restricts inputs to plausible ranges (for example, rates between 0% and 25%); values outside the range trigger an input alert on S02.
• Scenario inputs sit in one table on S03, selected by a single scenario switch (section 8).

5. Calculation logic and key formulas

5.1 Calculation block catalogue

5.2 Key formulas

ARR corkscrew (CALC-001), for month t:

Subscription revenue (CALC-002):

Working capital balance (CALC-006), receivables shown, on the ASM-012 convention of the flow of the three months ending in month t; inventories use commerce cost of sales and payables use total cost of sales:

Interest (CALC-007):

Covenants (CALC-010):

The model also reports the management ratio (borrowings less all cash, excluding leases, over LTM EBITDA) on a separate, clearly labelled row, because the budget pack uses it as a headline; the covenant row is the only one that feeds the compliance certificate.

Discounting for appraisal outputs: discount factors are calculated on their own line from the period flags and the discount rate, and present values are their product with the cash flow line. The spreadsheet NPV function is not used, because it assumes equally spaced periods and discounts the first cash flow in the range by one full period, hiding the timing assumption.

where the time in years from the valuation date to the cash flow is calculated from period end dates on S08.

5.3 Worked check of the logic

Example: with the FY2027 budget inputs, ARR opens at EUR 86,000k and closes at EUR 106,000k. If the monthly movements are spread evenly, subscription revenue is close to (86,000 + 106,000) / 2 = EUR 96,000k, the figure in the budget. Management leverage at 2027-12-31 is (30,000 - 26,400) / 21,600 = 0.17x; covenant leverage, with lease liabilities of 6,400 and trapped cash of 1,000, is (30,000 + 6,400 - 25,400) / 21,600 = 11,000 / 21,600 = 0.51x. Net finance cost is 1,200: term loan interest 1,200 plus lease interest 360 less interest income 360 (Annual Budget ASM-011). These are the first regression tests in section 11.

6. Outputs and reports

Output rules:

• Each presentation sheet states the units (for example EUR thousand), the scenario shown and the model version in its header.
• The scenario name and the master check status are printed on every output page.
• Charts match the data type: lines for time series, bars for comparisons, a waterfall for bridges.
• Outputs that go to lenders use the facility agreement definitions; see Covenant Compliance Certificate (finance/covenant-compliance-certificate).

7. Design conventions

7.1 Principles

The FAST acronym sets four priorities: models are flexible (users can run scenarios and adapt the model over time, which comes from simplicity rather than a switch for every case), appropriate (assumptions are reflected faithfully without detail or precision beyond what the decision needs), structured (a consistent layout of workbooks, sheets and formulas keeps logic intact as authors change) and transparent (simple formulas and clear layout that another person can follow).

7.2 Conventions for this model

7.3 Departures from the conventions

The ICAEW Financial Modelling Code and the Best Practice Spreadsheet Modelling Standards (BPM, Spreadsheet Standards Review Board) are alternative style frameworks; if the organisation adopts one of them instead, replace the rule references in 7.2 and keep the same table.

8. Scenarios and sensitivities

8.1 Scenario mechanics

• A single selector on S03 chooses the live scenario; the selected values flow to the input sheets through one lookup row per scenario input.
• Scenario values are stored side by side in one table with a column per scenario; the base case is a column like the others.
• Every output carries the live scenario name. Stored results for comparison are pasted as values on S03 by a documented step, with the model version and date.

The scenarios match those in Rolling Forecast (finance/rolling-forecast) section 7.

8.2 Required sensitivities

Break-even outputs: the model reports the EBITDA fall at which each covenant breaches (as in the management report) and the lowest month-end liquidity in each scenario.

9. Checks and error flags

Master check = sum of absolute error check values; shown in the frozen header of every sheet and on every output page. Outputs are not released while the master check is not zero. Alerts are listed separately and explained in the cycle's commentary.

10. Version control and change management

Where a model falls within the organisation's model risk framework, record it in the model inventory and follow Model Risk Management Policy (finance/model-risk-management-policy).

11. Testing and model review plan

11.1 Review layers

11.2 Test cases

11.3 Traceability matrix

11.4 Review findings

Model validation for regulated or high-risk models uses Model Validation Report (ai-data/model-validation-report); model design documentation for risk models uses Model Development Document (finance/model-development-document).

11.5 How to run a review and what reviewers most often find

Give the reviewer the specification, the model, the input register and the expected results before the review starts, and agree the scope in writing: which sheets, which versions and which outputs. A reviewer who receives only the workbook will test what is easy to test, usually formula consistency, and miss the questions that matter to the decision makers, such as whether the covenant calculation uses the facility definitions.

Reviewers should work from outputs back to inputs. Start with the numbers that leave the model (the budget P&L, closing cash, covenant ratios) and rebuild them independently, in a separate small workbook or by hand, from the input register. Where the rebuild and the model disagree, trace the difference to a block, then to a row. Only after the key outputs agree should the reviewer scan the whole model for convention breaches, because a model can follow every layout rule and still compute the wrong thing.

Findings that recur in planning models of this kind:

• Definitions that drift from the contract. Covenant net debt that leaves out lease liabilities, nets trapped or pledged cash, or uses management EBITDA instead of the agreement's Consolidated EBITDA. The fix is a covenant block that reads the definitions from an input sheet referencing clause numbers, with a separate row for the management ratio.
• Double counting between operating expense and capital expenditure, typically capitalised development whose people cost is also left in the expense lines. Test it by reconciling gross spend by function to the sum of expensed and capitalised amounts.
• Interest on the wrong balance: closing instead of average, or leases and cash deposits left out of net finance cost.
• Timing errors at year boundaries, such as a pay review or a price increase applied from the first month of the year instead of its effective month.
• Hard-coded plugs left from an earlier cycle, often in working capital or tax rows, that make the balance sheet balance while hiding an error.
• Currency translation applied twice, or balances translated at average instead of closing rates.

Record each finding with a severity, the owner of the fix and the version in which it was closed, as in the table above. A finding is closed only when the regression tests in section 11.2 pass on the corrected version; re-run the full test set, not just the test for the changed block, because fixes in one calculation often move another.

12. Known limitations and qualifications

13. Glossary and references

13.1 Glossary

13.2 References

Standard and licence note

Structure aligned with common financial modelling practice for model specifications. Design conventions informed by the FAST Standard 02c, FAST Standard Organisation, CC BY 4.0 (fast-standard.org): the four FAST principles, the four sheet classes and the rule references in section 7 are adapted from that standard in original wording, with changes (selection, rewording and model-specific examples); the FAST Standard Organisation does not endorse this template. The ICAEW Financial Modelling Code and the SSRB Best Practice Spreadsheet Modelling Standards are cited by name only; no text from them is reproduced. Corvid Commerce Group and every figure are fictional. This template is original text written for this collection. Check the current official version of each cited standard before use. Template licence: MIT.