Formatting, sign conventions, units and period labelling

Formatting in a financial model is not decoration; it is information. The universal convention is that input cells are visually distinct from calculated cells, most commonly blue font (often with a light shaded fill) for inputs and black font for formulae. Some teams add a third style for cells linked in from other workbooks or sheets. The exact colours matter less than the discipline: a user must be able to see, without clicking, which cells they may change. Both Excel and Google Sheets support reusable cell styles or simple manual formatting; the convention, not the tool, is what the exam tests. An immediate corollary: if a "calculated" cell is formatted as an input, or an input is buried in black font mid-formula-block, the convention has been violated even if the numbers are right.

Sign convention must be chosen once and applied everywhere. The two defensible options are: (a) all values positive, with subtraction written into the formulae (gross profit = revenue - COGS); or (b) natural signs, where costs and outflows are negative and every subtotal is a plain SUM or addition (as in Worked example 1, where COGS is negative and gross profit is =C7+C8). Convention (b) scales better because subtotals never need to "know" which lines are costs, and a new cost line inserted into a summed block is picked up automatically with the right sign. What is never acceptable is mixing conventions, showing costs positive on one sheet and negative on another, because every cross-sheet formula then needs a sign correction that will eventually be forgotten. On the exam, a described model in which "depreciation is entered as a positive number on the cost sheet but subtracted on the P&L, while other costs are negative and added" is a sign convention violation waiting to produce a doubled or vanished cost.

Units belong in row labels, not in readers' assumptions: "Revenue (GBP m)", "Volume (m cases)", "Price (GBP per case)". Unit errors are among the most expensive in practice, a model mixing GBP thousands and GBP millions can be out by a factor of a thousand while every formula is individually "correct". Keep one base unit per workbook wherever possible (Halcyon uses GBP m for money and m cases for volume) and convert at the edges, at input or presentation, never mid-calculation. Percentages should be stored as true percentages (0.06 formatted as 6.0%), not as the number 6, so formulae read *(1+rate) without hidden division by 100.

Period labelling means every column carries its label and date from the timeline rows, and every sheet shows them. A block of numbers with no visible period header cannot be reviewed. Label whether periods are years, quarters or months, and whether a column is actual or forecast; the flag row from Worked example 1 does this in a machine-readable way, and a text label row does it for humans. When a model mixes an actual base year with forecast periods, the boundary must be visible: many teams shade actual columns differently. Never label periods by typing "Year 1", "Year 2" as unrelated text strings in each column; derive labels from one seed cell so an extended or re-based timeline relabels itself.

Two smaller conventions complete the set. Negative numbers should display in a way the audience reads correctly, commonly parentheses in UK financial reporting, and the display format must not disguise the underlying sign used in calculation. And row structure should follow a stable rhythm: label in column A, units in the label, constants (if any per-row constant exists) in an early column, then the timeline. Consistent rhythm is what lets both a human reviewer and an AI assistant asked to "check this sheet" parse the model without a manual.