Anatomy of a Traced Variance Claim

Take a line many analysts write every month:

Revenue down EUR 0.4m vs budget due to timing.

It holds two different kinds of statement.

• What changed: "Revenue down EUR 0.4m vs budget." This is the variance, the difference between an actual figure and a comparison figure such as budget, forecast or prior year. You have already calculated it, so it usually rests on a number.
• Why it changed: "due to timing." This is the cause. It is your explanation of the variance, and it is the part that most often has nothing behind it.

When the CFO asks what backs a line, they are almost always asking about the cause. Nobody doubts that revenue fell by EUR 0.4m, because that comes straight from the ledger and the budget. The question is whether timing really explains it, and how much of it.

So the first habit is to read every comment in two halves. Find the variance. Then find the cause and ask one question about it: which figure shows this?

A traced claim is a statement in your commentary that someone else can check against a specific number. It has four parts:

1. The claim. The statement itself, for example "EUR 0.3m of the shortfall is timing."
2. The figure. The number that supports it, for example two orders worth EUR 0.3m in total.
3. The source. Where that figure lives: file, tab, report or system export, and the cell or line.
4. The basis. The reporting period, currency, units and calculation method of the figure.

If any part is missing, the claim cannot be fully checked. A claim with a figure but no source sends you scrambling through spreadsheets when someone asks. A figure with no basis can mislead, because EUR 300 and EUR 300k look the same once the units are dropped.

Think of the four parts as the minimum a colleague needs to repeat your work without asking you anything.

The basis tells the reader what kind of number they are looking at. It has four elements:

• Reporting period: the time the figure covers, such as March, Q1 or the year to date.
• Currency: for example EUR, USD or GBP. Say whether it is local currency (the currency the entity trades in) or reporting currency (the currency the group reports in).
• Units: the scale, such as units, thousands (k) or millions (m).
• Calculation method: what was compared with what, such as actual vs budget, March vs March last year, or year to date (YTD, from the start of the financial year to the end of the current month) vs YTD budget.

Write the basis beside each cited figure, not once at the top of the page. A short bracket works well:

Revenue EUR 0.4m below budget (March, actual vs budget, EUR millions).

This looks fussy at first. It pays off when a reader compares figures across lines and can see straight away that they share a basis, or that they do not.

Here is the vague line rebuilt as a traced claim:

Revenue EUR 0.4m below budget for March (actual vs budget, EUR millions). Of this, EUR 0.3m relates to two orders recognised as revenue on 2 April that the budget phased into March (sources: April revenue report, lines 14 and 22; budget phasing file, March tab).

Notice three things.

It sizes the cause. Timing explains EUR 0.3m, not the whole EUR 0.4m. The other EUR 0.1m is still unexplained and should not be quietly absorbed into "timing".

It traces both sides. A timing cause compares two dates: when the revenue actually happened (April revenue report) and when it was expected (budget phasing, which spreads the annual budget across months). One source alone cannot prove timing.

It uses the right date. Before you use invoice dates as evidence, confirm which date your ledger uses to recognise revenue. If revenue is recognised on delivery, the invoice date may not show when the revenue landed.

"Source: revenue report" is not a source. Which revenue report? Which version? Which line?

A good source reference is precise enough that a colleague could open it and land on the number without messaging you. Work from the general to the specific:

1. System or report name, for example ledger revenue report or planning system export.
2. File name and version or run date, because reports are often rerun during close.
3. Tab or sheet.
4. Line, row or cell.
5. Any filter applied, such as entity, region or product line, if the number only appears after filtering.

For the timing example:

Ledger revenue report, file Revenue_Apr_run_2025-05-03.xlsx, tab Detail, lines 14 and 22, filtered to entity DE01.

(The file name and entity code are illustrations; use your own.) This takes a few seconds more to write. It saves the scramble later, and it lets a reviewer check your work while you are busy on something else.

Sometimes you look for the figure behind a cause and cannot find one. Perhaps a sales manager told you a customer delayed an order, but nothing in the actuals or the order book shows it yet.

That cause may well be true. It is still not a traced claim, because nobody can check it against a number. It should not sit in the commentary written as fact.

You have two honest options:

• Find the figure. Look in the order book, revenue detail or budget phasing. If you find it, record the source and basis and keep the claim.
• Treat it as a hypothesis. A hypothesis is a possible cause that you have not yet proven. The next lesson covers how to label one clearly and name the check that would confirm or reject it.

What you should not do is keep the original wording because it sounds plausible. "Revenue down due to customer delays" reads as a confirmed fact to a CFO, even when it is a guess.

An evidence log is a simple table you keep next to your commentary, with one row per claim. Its columns follow the four parts of a traced claim:

Claim	Figure	Source	Period	Currency	Units	Method
March revenue below budget	0.4	Revenue report, Summary tab, line 3	March	EUR	m	Actual vs budget
Of which timing (2 orders)	0.3	April revenue report, lines 14 and 22; budget phasing file, March tab	March vs April	EUR	m	Recognition date vs budget phasing

(Line references are illustrations.) A spreadsheet tab works fine. You do not need a special tool.

The log is what you show when the CFO asks what backs a line. Instead of searching through spreadsheets, you read across one row. It also helps you while drafting: if you cannot fill in a row, the claim is not yet traced.

In later lessons, this same log is what you give an AI tool to draft from, and what you check its draft against.

Writing the basis beside each figure catches a common hidden error: comparing figures with mixed bases.

Two typical cases:

• Monthly vs year to date. March actual revenue of EUR 2.6m is compared with a YTD budget of EUR 8.7m. The result, EUR 6.1m below budget, is meaningless. Against the March budget of EUR 3.0m, the real shortfall is EUR 0.4m.
• Local vs reporting currency. A US subsidiary's costs in USD are added to EUR figures without translation, so the total combines two currencies.

Both errors are easy to make when figures come from different exports. Both are hard to spot when the commentary shows only "2.6" and "8.7". Once each figure carries its basis (March, EUR m, actual; YTD to March, EUR m, budget), the mismatch is visible to you and to any reviewer.

Try the sliders below. Change the March actual and both budgets, and compare the correct variance with the mismatched one.