CFO-Proof Your ROI Model: Surviving the Finance Review

There is a particular silence that falls in a finance review when a sponsor is asked where a number came from and does not know. Everything after that silence is damage control. The model might be right; it no longer matters, because the reviewer has learnt that at least one input is unexamined, and a model with one unexamined input must be treated as if they all are.

Finance reviewers are not trying to kill your project. They are doing their job, which is to allocate limited capital between competing claims, most of which are optimistic. Their method is a fairly stable set of questions, refined over years of watching benefits fail to arrive. If you know the questions, you can build the answers into the model before anyone asks — which is the entire art of CFO-proofing.

This guide covers the seven questions, the single artefact that answers most of them, and a worked example of a case taking fire and surviving.

The seven questions finance will ask

1. Where does each input come from?

This is the first question because it is the cheapest test of the whole model. Every input has a provenance, and provenance has a hierarchy: measured internal data beats a published benchmark with a named source and date, which beats a vendor claim, which beats an unsourced "industry average" — the last of which should not be in the model at all.

The answer that survives is specific: "Call volume is from our telephony platform, twelve-month average to June. Cost per call is our own loaded figure; for reference it sits close to the ContactBabel UK 2024 benchmark of £5.58 per inbound call." The answer that dies is "it's a standard assumption".

Expect follow-ups on the labour numbers specifically, because they are where models most often flatter themselves. If you costed saved hours at bare salary, expect to be corrected: per the BLS Employer Costs for Employee Compensation series, wages are only about 70% of total compensation in US private industry, implying roughly a 1.4× multiplier — itself a floor, since it excludes recruiting, equipment, and overhead. And if you assumed a 2,000-hour working year for a European team, note that the OECD Employment database puts actual annual hours worked at roughly 1,533 in the UK and 1,332 in Germany. Getting these right unprompted signals that the rest of the model was built with the same care.

2. How sensitive is the result to each assumption?

Finance knows that in most ROI models, one or two inputs do most of the work. The question is whether you know. A sensitivity analysis — vary each input across a plausible range, rank by effect on the outcome — answers it. Present it as a ranked list or tornado chart.

The deeper purpose is scrutiny-routing. If the case is highly sensitive to the deflection rate and barely sensitive to the licence cost, the review can spend its time where it matters. Volunteering that map, rather than having it extracted from you, converts the review from interrogation to collaboration.

3. What is the downside case?

Not the conservative scenario — the bad one. What if the improvement is half your conservative assumption? What if adoption stalls? The reviewable answer has two parts: the financial exposure (typically implementation cost plus any committed licence term, minus whatever is salvageable) and the exit route (roll back, renegotiate, stop). A bounded, stated downside is approvable; an unexamined one is not, because the reviewer must then assume it is unbounded.

4. Are the costs complete?

The benefits side of an ROI model is usually over-engineered and the cost side under-counted. Finance reviewers check for the habitual omissions:

• Implementation: internal time — engineering, project management, data migration — costed at loaded rates, not treated as free because those people are "already paid for".
• Ongoing: licences and support, but also maintenance, content upkeep, retraining, and the fractional headcount that owns the thing after launch.
• Transition: the productivity dip while the operation changes over, and the period of running old and new in parallel.

A model that shows only licence fees against gross benefits reads as either naive or salesmanlike. Neither survives.

5. How are the benefits phased?

A model that books January's benefits at full rate is announcing that its author has never launched anything. Real benefits ramp: adoption takes months, and steady state arrives later than the pilot suggested — practitioners' own reported payback on automation pilots lengthened from 16 to 22 months between Deloitte's surveys (Intelligent Automation Survey, 2022). Build the ramp into year one, state its shape, and be ready to defend the steady-state date. Phasing feeds directly into payback and NPV, so an unphased model overstates both.

6. What discount rate, and why?

Multi-year benefits must be discounted, and the rate is not yours to invent. Ask finance for the organisation's rate — typically the weighted average cost of capital, sometimes with a risk premium for uncertain projects — and compute NPV and IRR at that rate. Asking is itself a good sign; sponsors who guess (or discount at zero) reveal that the model was never meant to survive contact with finance. If your NPV only turns positive at a suspiciously low rate, the model is telling you something; listen to it before the reviewer does.

7. What would break the case?

The final question is the character test: name the conditions under which this investment turns out to be a mistake, and the checkpoint at which you would stop. Sponsors who answer crisply — "if measured deflection is below X at month six, we halt the rollout" — get trusted, because they have converted a promise into a testable commitment. Sponsors who answer "I don't see how it fails" get their models re-reviewed line by line, on the reasonable theory that someone this certain has not looked hard enough.

The artefact that answers all seven: the assumptions audit trail

Notice what the seven questions have in common: none attacks your arithmetic. Reviewers rarely find multiplication errors; they find unexamined assumptions. Which means the defence is not a cleverer model — it is a completely itemised one.

An assumptions audit trail is a table with one row per input: value · source · date · caveat. Ours renders as a receipt-style ledger in every report; a spreadsheet tab does the same job. The test it must pass: a reviewer can trace every figure in the headline back to either a number you entered (with provenance) or an assumption stated explicitly — with no hidden adjustments in between.

This changes what a challenge is. Without an audit trail, "where did that come from?" is an attack on your credibility. With one, it is a row lookup — and if the reviewer prefers a different value, you re-run the model with their number in front of them. The argument shifts from whether you are trustworthy to which input is best, which is an argument you can afford to lose gracefully: swap the input, show the result, and the case now carries the reviewer's fingerprints. Co-authored cases get approved.

One rule keeps the trail honest: if a number has no defensible source, it does not go in the model — even if that means shipping a smaller, duller case. Our own methodology follows the same policy: where no credible public source exists for a commonly quoted figure, no benchmark ships. A dull number that survives is worth ten exciting ones that do not.

A worked example: one case, under fire

Illustrative example — every figure below is hypothetical, chosen to show the mechanics, not to describe any real operation.

The case: a UK support operation proposes a self-service knowledge base to deflect routine inbound calls.

The setup. The sponsor's ledger reads: 10,000 inbound calls per month (telephony platform, 12-month average); £6.00 loaded cost per call (own finance data; noted as consistent with the ContactBabel UK benchmark of £5.58); 40% of calls classified as routine and deflectable in a two-week ticket audit; and an assumed 30% deflection of that routine segment in the conservative case. Conservative annual benefit: 10,000 × 40% × 30% × £6.00 × 12 = £86,400. Costs: £45,000 implementation (including internal time at loaded rates) plus £18,000 per year ongoing (licence plus a 0.15 FTE content owner).

Challenge one: "Why 30% deflection? Vendors quote far higher." The sponsor points at the ledger row and its caveat: customer-side evidence says full self-service resolution is rare — Gartner's 2024 survey found only 14% of issues fully resolved in self-service, and only 36% even for issues customers call very simple. The 30% assumption applies only to the pre-audited routine segment, which is why the two-week audit exists as its own sourced row. The vendor's headline number is in the appendix, labelled as a vendor claim, deliberately unused.

Challenge two: "What does saving a call actually save?" The ledger's caveat row already concedes it: deflecting a call does not fire an agent. The £6.00 figure is defended as the marginal cost of handled volume — and the model's benefit is framed as capacity released, with a note that cash realisation depends on redeploying or reducing that capacity, which is an operational decision outside the model. The reviewer, who has seen "savings" that never touched the P&L, visibly relaxes: the model is not pretending.

Challenge three: "Cut the deflection assumption to 20%." Re-run live: benefit drops to £57,600 against £18,000 ongoing — payback stretches but the case still clears at the reviewer's own number. Because the conservative case survives the reviewer's haircut, the meeting ends with a condition rather than a rejection: proceed, with measured deflection reviewed at month six and a stop threshold agreed in writing.

Nothing in that meeting was rhetoric. The case survived because every input had a row, every row had a source, and the model could be re-run with hostile inputs in real time.

The pre-review checklist

1. Every input has value, source, date, and caveat — no orphan numbers.
2. Labour costed at loaded rates and regionally honest hours, not salary and a 2,000-hour year.
3. Sensitivity ranked; you know your two dominant inputs and volunteer them.
4. Downside case written: exposure bounded, exit route named.
5. Costs complete: implementation, ongoing, transition — internal time included.
6. Benefits phased with a stated ramp; payback computed on phased figures.
7. NPV and IRR at finance's discount rate, obtained by asking.
8. Kill criteria and checkpoint date written into the proposal.

A LeadersToolset Projection report produces this structure by default: an itemised receipt-style ledger of inputs and assumptions, conservative/moderate/optimistic scenarios, multi-year NPV and IRR at a discount rate you set, and a sensitivity view — with every benchmark traceable through the methodology page to a named source. See the format in the sample report, then build your own: the first calculator is free, with unlimited re-runs for the inevitable "re-run it with my number" moment.