Most of us have had that evening. The work was real, the outcome was real, and the detail that would make it legible to anyone else has quietly dissolved into storage nobody organised. So we write the thin version and move on.

That evening happened to me recently, while I was preparing for an internal recruitment process. What I took out of it had almost nothing to do with recruitment and a great deal to do with how we prepare for a review of any kind: the self - assessment in the appraisal system, the budget round, the business case, the monthly review - choose your fighter.

A recruitment process is just a review where somebody bothered to write the requirement down.

A review is a proposal, not a presentation

Think about it as a deal. There’s a request for proposal, and there’s the proposal answering it. A CV is a proposal. So is a business case, a budget submission, a summary of a monthly financial performance, and the self-assessment sitting in your appraisal system very soon. In each one, somebody in the room is holding a decision, and the job is to meet the requirement behind it rather than present a complete account of our work and hope the relevance is obvious.

The difference sounds academic until you watch both versions land. The account of work is thorough, reconciled, and strangely inert. The proposal moves something. Under time pressure we tend to produce the first one - accurate, exhaustive, and answering a question nobody asked.

In a recruitment the requirement is handed over. A job description is an unusually honest document: someone has written down what they need, in their own order, with their own emphasis. Before I opened any of my own material I put it in front of me and treated it as the specification it is.

Most reviews don’t come with a clear requirement, so it has to be reconstructed - who is sitting there, what they’re being asked to approve, what they’re personally accountable for, and what would make them say no. That reconstruction is the preparation; everything after it is assembly. It also tells you what isn’t required, which is the harder half. We over-prepare the material we enjoy: five slides on the market that’s performing, one on the thing that needed addressing. We rarely actively and consciously decide to do that. It’s what happens when the comfortable section is the one that expands at eleven at night.

Understand the request, then understand what you have, then work out which of it meets the requirement, then rehearse the gaps rather than the answers. The order carries more weight than the steps - starting at the second part (what we have) is how you end up with a beautiful deck answering the wrong question.

Subscribe now

What AI did with four years of my own material

Here’s where I expected the tool to do something clever, and the useful part turned out to be elsewhere.

I had material: four years of self-assessments, my manager’s assessments, objectives, development items, notes written as projects closed. None of it was written for this particular purpose. It existed because I keep a record, and it sat in an archive I almost never reopened.

I put the relevant years in front of Copilot together with the job description, and told it to invent nothing, exaggerate nothing, and help me surface what genuinely met the requirement.

Lens work: filtering what I already had

It didn’t find anything that wasn’t there. Everything it surfaced, I had written myself. What it did was read four years of my own material against a specification and filter it - work I could have done by hand over a weekend, and would have done worse, because by hour three I’d have been skimming.

That’s worth being precise about, because it’s the version most people recognise and the version most posts overstate. The tool is a lens. The material is yours, the judgment is yours, and what comes back is your own record sorted by relevance to a question you supplied.

Retrieval: finding what I’d lost

Then it did something I couldn’t have done at all.

There was a transformation project that belonged on the page, and I couldn’t recall the detail. The archive had never quantified it - I’d written down that it happened, not what it was worth. But the evidence existed: in the thread where the scope was agreed, in the files, in whichever version of the model turned out to be final. A tool sitting natively inside that environment reads across all of it.

What came back was the scale, the unit and a figure of an annualised saving. I verified it against the source before it went anywhere near the page. Verification isn’t optional, and it never becomes optional. But honestly, I I wouldn't have found it in reasonable time without working through my context with an AI tool.

Two different jobs, worth separating. Against material you deliberately kept, the tool does lens work - filtering what you already hold against a requirement. Against the exhaust of everyday work that nobody organised, the threads and attachments and version four of the model, it does retrieval. The second only works because the tool lives where the work happens, and it’s the one that saves you from the thin version.

The constraint that doesn’t make it into the headline

The retrieval half comes with a condition attached, and it’s worth saying plainly because it cuts against the enthusiasm.

It only works inside the environment where the work actually sits, with your permissions, under whatever your organisation has already agreed to. That makes it a real argument for the platform you’re on - which is also an argument for lock-in, and anyone selling you the capability will be slower to mention the second half.

Three things follow. The filtering is portable: any tool you can hand your own documents to will do it, so you can use the one you prefer and the one your policy allows. The retrieval isn’t, and no amount of prompt craft substitutes for access. And both inherit whatever your organisation permits - if retention cleared the 2023 mailbox, there is nothing to retrieve, and if the model that mattered lives on someone’s personal drive, it isn’t in scope either.

Worth establishing which of those applies to you before you plan an evening around it.

How to use AI as your reviewer, not your supporter

Assembled context earns its keep when you stop using it to support the case and start using it to attack it.

I asked for the reviewer’s position instead of my own: what would this be assessed on, where is the evidence thin, what gets pushed on first. I asked for disagreement explicitly, because a tool that agrees with us is producing a transcript of our own assumptions in a more confident way.

The gaps were the output. Not all of them could be closed, but knowing which ones were real changed what I prepared and what I was willing to say I didn’t yet have.

The same move works through the lens of the role rather than the person. Annual reports, strategy documents, external announcements - all of it reads differently against a specific question than it does in general.

Then rehearse against the actual room: how long, who’s in it, where the first question usually comes from. Less about having answers ready, more about finding out which parts of your own case you can’t yet say out loud.

Why AI can’t prepare you without an archive

None of this works without the record, and the record is the part nobody writes posts about.

The tool didn’t build my context. I did, over the years, in a habit that felt purely administrative at the time. A paragraph at the end of a project. The self-assessment I’d have written anyway. Notes that existed because writing them took ten minutes and I’d already decided that was cheaper than reconstructing them later.

It’s worth being clear about what that habit actually buys, because it does two separate things. It gives the filtering something to filter: without it you get your own job description handed back to you in different words. And it gives the retrieval something to anchor to. I knew the project existed and roughly when, which is what made the search tractable in the first place. Retrieval across four years of everything, with no idea what you’re looking for, returns noise.

So, the honest version of this isn’t about tooling at all. Keep the record: what a project was for, what changed, what it was worth, written down while you still remember. Everything above is downstream of that, and the preparation only felt quick because the slow part had already happened, in pieces, years earlier.

The tool isn’t the differentiator. The context is.

Subscribe now

Questions people frequently ask about using AI for review preparation

Does this only work with Copilot? The filtering works with any tool you can hand your own documents to. The retrieval doesn’t. Finding a number inside four years of emails and file versions needs a tool that already lives in that environment, with your permissions and inside your organisation’s policy.

Can AI write my performance review self-assessment? It shouldn’t, and the output gives it away. What it does well is read material you wrote yourself against the requirement you’re answering, and tell you which parts are relevant. The writing stays yours.

What should I give it before asking anything? Two things, in this order: the requirement - a job description, a meeting agenda, the decision being taken - and your own material. Without the first you get a summary of yourself. With it you get a filter.

What if I haven’t kept a record? Then this is a slower month, and the useful move is to start now. The next review is always coming.

Share

We grew 0.4%. We sold 1.6% less. The growth slide goes up. Revenue €80.2m, up 0.4%. Someone says “flat but holding.” The room nods. Nobody asks how many boxes we actually shipped.

We shipped 1.6% fewer.

Prices went up 2%. Volume went down 1.6%. The two roughly cancelled, and what survived the collision was a €300k increase that got presented as growth, filed as growth, and rewarded as growth.

Gross profit that year fell €248k.

The bridge nobody builds

Here is the same year, decomposed:

Nothing here is hidden. Every number is available in the same system that produced the €80.2m. The bridge takes an afternoon to build the first time and twenty minutes every time after.

It doesn’t get built because the headline already answered the question the meeting asked.

The part that actually matters

Most people who do build the bridge stop here. Revenue split into its legs, presented, understood. Fine.

But a revenue bridge is only half a thought. The legs have to be converted into gross profit, because price and volume do not drop through at the same rate.

Every euro of price we won brought 12 cents of gross profit with it. Every euro of volume we lost took 35 cents out.

That is the whole story. Revenue nets to positive because the legs are similar in size. Gross profit nets to negative because the legs have completely different economics.

We passed cost inflation through to customers, which is what a 12% drop-through on price means - we recovered cost, we didn’t expand margin. And we lost volume that was carrying three times that rate.

Why the lost volume was expensive

The 35p figure is the interesting one, because the business-wide gross margin is 23.9%. If volume had declined evenly across the portfolio, the drop-through would be 24p. It was 35p.

So the volume didn’t leave evenly. It left from the top.

The categories that grew were the cheap ones - Bolts & Screws at 21.5% margin, Nuts & Washers at 19.6%, commodity hardware at 11.7%. The categories that shrank were the ones we actually make money on: Sealants & Chemicals at 33%, Tools & Consumables at 32%, Anchors & Fixings at 27%.

Aggregate volume decline is almost always a mix question in disguise. A 1.6% drop tells you nothing on its own. A 1.6% drop concentrated in your 33% margin lines is a different business.

Two years of the same thing

This wasn’t a one-year anomaly. Run the previous year and the shape is identical: revenue +€300k, gross profit −€246k.

Two years:

• Revenue: +€600k

• Gross profit: −€493k

• Gross margin: 24.7% → 23.9%

Two consecutive years of reported growth, and the business is €493k worse off at the gross profit line than when it started. Both years were signed off. Neither year had a variance large enough to trigger a conversation, because the variance being measured was revenue.

What to put on the slide instead

Three changes, none of which require a system, a project, or a consultant.

1. Never show revenue growth without the price/volume split beside it. Same slide, not the appendix. If the split isn’t there, the number isn’t finished.

2. Convert both legs to gross profit before you present them. Revenue legs tell you what happened. Gross profit legs tell you whether it mattered. The drop-through rates are the argument - 12p versus 35p is a sentence anyone in the room can act on.

3. Ask which categories the volume left. Then ask whether those categories share a margin profile. If they do, you don’t have a volume problem - you have a mix problem that will keep compounding after the pricing lever is exhausted.

And the pricing lever does get exhausted. It’s currently doing all the work of holding the top line flat. There is a year, not far away, where price can’t cover the volume gap any more, and the revenue line finally shows what gross profit has been showing for two years.

The point of the bridge is to have that conversation before it’s a headline.

Most measurement conversations start in the wrong place. Someone asks what we should be tracking, a list gets built, everyone agrees it’s the right list, and then it quietly dies somewhere between the meeting where it was agreed and the month it was supposed to start.

The reason is almost never that the metrics were wrong. It’s that nobody checked whether they could be produced.

So this issue is about the order of operations - the questions that come before metric selection, what makes a data source genuinely usable rather than nominally available, and a distinction that changes how we think about what we’re measuring in the first place.

The four questions ( to be asked in order)

1. What question am I actually trying to answer?

Not which metric sounds useful. What decision is waiting on this.

The test is whether we can name the action that changes depending on the answer. If margin by channel comes back worse than expected, what happens next - do we reprice, do we shift investment, do we renegotiate, do we exit? If nothing changes regardless of the answer, we’re building a number for reassurance rather than for use, and it will be the first thing dropped when the month gets tight.

This question also does quiet work on scope. “How is the business performing” has no answer. “Which channels are eroding faster than we’re replacing them” has a very specific one, and it tells us exactly what data we’re going to need.

2. What data would answer it?

Down to the level of granularity the answer actually requires, which is nearly always lower than anyone assumes in the meeting.

Channel margin sounds like a single number. It isn’t. It only exists if we can get to individual products, at the prices actually paid, with the customers behind them correctly attributed to a channel, and the relevant costs sitting alongside - and then roll all of that back up cleanly. That’s four separate data requirements hiding inside one innocuous-sounding metric.

The rule of thumb: any metric that requires attribution - by channel, by segment, by customer type - is a granularity question wearing a reporting question’s clothes.

3. Does that data exist, is it current, and can I trust it?

These are separate tests and a source can fail any one of them independently.

Current. How fresh is it by the time we’d use it? A source refreshed monthly cannot support a weekly view, and a source updated in arrears cannot support a decision taken in the first week.

Complete. Are all the dimensions actually populated, or is the channel tag present on 80% of records and blank on the rest? Partial attribution produces a number that looks precise and is systematically wrong, which is worse than no number at all.

Reconcilable. Does it tie back to what we already publish? If our new channel view sums to something different from reported revenue, the first meeting will be about the reconciliation rather than the decision. We will lose time and trust, however good the underlying analysis is.

Owned. Is there a person accountable for the source, or does it exist because someone maintains it as an unofficial favour? Unowned sources fail silently, and usually at the worst moment.

4. How does this get built so it survives me being away?

A view only one person can refresh isn’t a measurement system. It’s a dependency.

The practical version of this question is: what happens on the third refresh, when the person who built it is on holiday and the underlying file has changed shape? If the answer involves anyone reverse-engineering anything, the design isn’t finished.

Leading and lagging aren’t a choice

There’s a related question that comes up as soon as the list is agreed: should we be measuring outcomes, or the things that produce them?

The usual framing is that leading indicators are better than lagging ones, because a lagging metric tells us what happened after we can no longer act on it. Sales results close the month, and the month is closed. Leading indicators are the only ones we can still steer.

That’s true as far as it goes, and I think the underlying instinct is right - building a system of consistent behaviour is a better management frame than chasing an outcome number. But the framing hides the part that actually matters:

A leading indicator is a hypothesis about cause.

If the hypothesis is untested, we haven’t built an early warning system. We’ve made activity easier to measure. A team can hit its leading indicator perfectly and produce nothing, if the link between the activity and the outcome was assumed rather than demonstrated.

So they aren’t alternatives. The lagging metric defines what we’re trying to achieve. The leading metric is our bet on what produces it. And the discipline - the part almost nobody does - is periodically checking whether the bet still holds. Most organisations set the pair once and never revisit it, which means the leading indicator carries on being reported long after it stopped predicting anything.

The distinction that matters more: threshold or lead indicator

Here’s where this gets uncomfortable for finance specifically.

Ask an FP&A team what their leading indicator is and the answer is usually some version of delivered on time, right first time. It’s a reasonable answer. It’s measurable, it’s within our control, and it’s the thing that most visibly fails.

But it’s worth being precise about what kind of metric it is.

A threshold is something we clear and then stop optimising. A lead indicator is something we keep pushing. Confusing the two produces a team that polishes punctuality indefinitely - and a mandate to be right first time, every time, taken literally, is a mandate to over-check. Which is how forty minutes gets spent on an immaterial variance that changes nothing.

There’s a sharper problem underneath. On time and error-free is a reporting quality metric. If the thesis is that finance exists to support decisions rather than to produce reports, then optimising the delivery of the artefact rather than its influence builds a team that is reliably punctual and entirely ignored. We’ve all seen that team. Perfect accuracy, perfect timing, nobody reading it.

The thing that actually predicts influence is different: how often finance is in the conversation before the decision is framed, rather than being asked to validate one already made.

I’d hold that as a principle rather than a metric, because I don’t think it can be honestly measured. There are proxies - requests arriving as “help us think about this” versus “check this for me,” being on the invite where options are still open, the lead time between question and decision - but every one of them is soft, and none survives being turned into a target. The moment we incentivise early requests, requests get reclassified.

Which brings this back to where we started

Notice what just happened.

The metric that’s easy to source - on-time delivery, error rate - can be pulled from a calendar and a version history in about ten minutes. The one that actually predicts whether our work matters has no system of record at all.

So teams optimise the first one. Not because anyone decided it was more important, but because it was the one already being tracked.

That’s the argument of this issue arriving from the other end. The four questions exist to stop us committing to metrics we can’t produce. But it’s worth being awake to what that constraint does to us over time - measurement availability shapes priorities more powerfully than importance does, and it does it invisibly.

The practical response isn’t to measure the unmeasurable. It’s to keep the principle explicitly on the table alongside the metrics, so the dashboard doesn’t quietly become the whole definition of the job.

We’ve crossed the chasm.

A year ago, AI in finance was a demo. Now it’s in the workflow. We can ship - decks, models, commentary, first drafts of almost anything - faster than we can read what we shipped. Context engineering turned out to matter more than prompt tricks. And the same tools that let us produce more have quietly filled our drives, our inboxes and our feeds with something we didn’t have a word for two years ago: slop.

That’s the real tell that the experiment is over. Not the wins - the mess. When a technology moves from novelty to daily operations, the interesting question stops being what can it do and becomes what is it actually for.

The bill lands at desk level first

Let me be precise about the scale I mean here. Not enterprise AI strategy. Not agentic transformation of the close. I mean desk-level, individual usage - the thing each of us actually reaches for on a Tuesday. Because that’s where the cost shows up first, and quietly.

The pattern is familiar by now. You adopt an AI tool for one genuinely useful thing. It works. You lean on it. It becomes part of your day - more advanced, more recurring, more embedded. And precisely as that happens, the pricing follows you there: more tokens, more credits, a higher tier for the features you now depend on. Somewhere along the way, a headcount line quietly became a licence line.

That can be a perfectly good trade. But if the usage underneath it stays casual - generate, generate, generate - you end up paying real money for piles of output you then have to review. And a model’s output with no professional skepticism applied to it isn’t an asset. It’s a liability with good grammar.

The encouraging half of the picture

Because there’s another half, and it’s just as real.

The most interesting AI work I see isn’t coming from the people chasing the newest tool. It’s coming from people with deep business context - years of accumulated judgment about how their organisation actually makes money, where the numbers lie, what a stakeholder genuinely needs. Not tenure for its own sake. Diversified, hands-in experience. Those are the people rolling up their sleeves, getting into the tools themselves, and building genuinely clever proofs of concept.

The tool isn’t the differentiator - the context is. AI amplifies judgment you already have; it doesn’t manufacture judgment you don’t.

Which is exactly why we’ve reached the next stage. The experiment produced results. Now the harder work begins: scaling and structuring what worked - and deciding, honestly, where AI makes a difference and where it doesn’t.

Technology as an accelerator

Jim Collins made this point a quarter of a century ago and it has aged remarkably well. In Good to Great, his team studied companies that sustained exceptional results consistently over the period of fifteen years and asked (amongst other questions) what role technology played in getting them there. The finding: used well, technology is an accelerator of momentum, never the creator of it. None of the great companies began their transformation with pioneering technology. They got disciplined about their strengths first, then applied carefully chosen technology to what was already working. If a technology didn’t fit, they ignored it.

For us in finance, that discipline has a name: judgment. Our job has never been to deploy the most tools. It’s to decide how to spend the organisation’s scarcest resources - people, money, time - to enable performance and deliver value to the people who rely on our numbers. AI is one line in that allocation. It is not the whole budget.

So before reaching for a new solution, it’s worth visiting the good one already sitting in your Excel ribbon.

Three tools we’re too quick to replace

None of these is glamorous. All three are quietly excellent at exactly the jobs we’re now tempted to hand to an agent.

Power Query: repeatable data cleaning, consolidating files, joining and reshaping exports. You build the steps once; every month you press refresh and get the same result, every time, for free. It’s built into Excel, and every transformation is recorded.

Power Automate: rules-based workflows: approvals, notifications, moving files, scheduled handoffs between systems. It runs identically every time and leaves a run history you can inspect.

Python in Excel: the heavier analytics native Excel strains at: forecasting, scenario modelling, statistics, large-dataset cleaning, richer visuals. It needs a licence and runs in Microsoft’s cloud, but the code sits in the cell - transparent, traceable, and reviewable.

Notice the word that keeps surfacing: auditable. Same input, same output, and you can show your working. That is not a nice-to-have in finance. It’s the job.

Now hold that against AI in the same grid. Copilot’s agent mode in Excel became generally available in early 2026 - it can plan and execute multi-step tasks directly in your workbook, and you can even choose which underlying model runs it. It’s genuinely useful. But it is non-deterministic - the same prompt can produce different work each time. It is metered - you pay per run. And its output has to be verified every single time. Microsoft is now bolting verification layers onto it precisely because confidently-wrong answers are the known failure mode.

Put the two columns side by side and the rule almost writes itself.

The rule

Reach for Power Query, Power Automate or Python when the task is deterministic, recurring and has to be auditable - month-end mechanics, reconciliations, the reports that must run the same way forever.

Reach for AI when the task is ambiguous, exploratory, one-off or language-shaped - drafting commentary you’ll edit, interrogating a messy dataset you don’t yet understand, getting a first version of something you can’t yet structure.

Sending an agent to re-clean the same file every month is paying a consultant’s day rate to press a button you already automated.

The point isn’t less AI

It’s the opposite. Being deliberate about where AI earns its cost is exactly what lets you spend the budget (and your attention) where it genuinely compounds. Technology as an accelerator, not a creator. The momentum still has to be yours.

This issue’s action

Block one hour this week, and protect it - no meetings, no notifications, just you and a blank page. List out the things you actually do with AI at your desk right now, and put each one into one of two columns: the deterministic work, where the same input should always give the same output and you need to be able to show your working, and the non-deterministic work, where the task is genuinely ambiguous, exploratory or one-off. Then, honestly, decide which tool belongs to which - where ‘classic’ solution is quietly the better answer, and where an AI model is worth what it costs. You won’t get every line right first time, and that’s fine. The point isn’t a perfect map. It’s that you’ve stopped defaulting to AI for everything and started spending it on purpose.

e for training prep — same routine as always.

Except the button that’s always been there — the one that lets me choose Work or Web — is gone. In its place: a new button. Work IQ.

I’m a curious person, so the questions came fast: What is this? Where is the data actually coming from now? Is it still grounded in my work environment, or is it reaching wherever it wants? And the question that matters most to me as a finance professional - does this change my halluci

nation risk?

A quick search online didn’t answer it. Asking Copilot about its own feature didn’t either - I got the shiny version: “a new intelligent layer that makes your answers better.” I asked it to explain like I was sixteen. It gave me a metaphor about my phone and my brain. None of that told me the one thing I actually wanted to know: when I pick “work,” am I still only getting work data - or not?

So I did what I always do when I want a real answer on Copilot: I went to Microsoft’s own technical documentation. It’s long — over a thousand pages — but well cross-linked, and worth the time if you want the actual mechanics instead of the marketing layer. (If you want a faster way in: drop it into NotebookLM and let it build you a mind map. I can’t recommend that enough.)

Here’s what I found

:

What actually changed

The Work/Web toggle is gone, and it isn’t coming back. Microsoft replaced it with Work IQ - and the rollout was happening in phases between May and July 2026, switched on at the tenant level. That means your IT admin decides when your organisation gets it, not you individually

.

Under the old model, you told Copilot where to look. Work meant work. Web meant web. You knew the boundary.

Under Work IQ, Copilot decides for you. It reads your prompt, blends your emails, files, meetings and the web together, and hands you one combined answer - not separate ones. It’s described as an intelligence layer: something that understands not just your data, but how your data connects - who you work with, what’s active right now, your patterns. A brain behind the tool, rather than a switch on it.

More context, built in a smarter way. On paper, that’s a good thing.

Can you get your old control back?

Yes - but the lever moved. It used to be a button. Now it’s a prompt.

• Work-only”Based on my emails, summarize...”

• Web-only”Use the latest market data on...”

• Work-only (again)”Check my files and meetings about...”

Copilot still listens. You just have to tell it where to look, every time, instead of setting it once and trusting the boundary to hold.

The question that actually matters: does this raise hallucination risk?

A hallucination, in plain terms, is an answer that sounds right but isn’t. A wrong number stated with full confidence. A conclusion that was never actually supported. It happens because the model is predicting language, not verifying facts the way we do.

Work IQ doesn’t remove that risk. It changes its shape.

Under the old model, if Copilot got something wrong in work mode, it was wrong using your own data — bounded, and usually recognisable to a finance person who knows that data.

Under Work IQ, sources get blended before you ever see the answer. That opens a specific, harder-to-catch failure: a correct internal number wrapped around an incorrect external assumption, delivered as one confident, well-structured answer. It doesn’t read like a guess. It reads like a finished executive summary.

Work IQ reduces the obvious errors. It increases the risk of the believable ones. Your professional judgment - not mode selection - is now the control mechanism.

What this means for how we use Copilot

Professional scepticism isn’t new to finance. We’ve just gained a new place to apply it.

• Treat every Copilot answer as a first draft, never a source of truth.

• Cross-check the numbers and the assumptions underneath them - not just the headline.

• Prompt precisely. If you need it grounded only in your own files, say so, every time.

• Ask it to cite its sources. If it can’t, that’s information too.

It’s the same discipline we’ve always used to check a column ties out to the control total before month-end goes out the door. We didn’t stop doing that because the tool got smarter. We shouldn’t stop now either.

This issue’s action

Find out whether Work IQ is already live in your tenant — ask IT, or just look at your own Copilot interface for the new button. Then run one test: ask the same work question twice. Once letting Work IQ decide. Once forcing work-only with an explicit prompt. Compare not the wording, but where each answer actually pulled from.

There is a particular kind of project that finance teams run every few years.

It goes by different names — systems migration, digital transformation, reporting overhaul, platform upgrade. The language changes. The outcome is surprisingly consistent.

Six months after go-live, the team is producing the same outputs they produced before. Same structure. Same logic. Same reports that nobody reads all the way to the bottom.

The technology worked. The process audit didn’t happen.

This issue is about the audit that should happen before every systems project, AI rollout, or reporting redesign in finance. It takes less time than the project kickoff meeting. It is almost never done.

The three questions

Before you automate, accelerate, or recreate anything in finance — stop and answer these three questions. In order. Do not skip to question two until question one has a clear answer.

Question 1: Do you need this at all?

This is the question that feels rude to ask. It implies that someone built something unnecessary, which implies that someone approved something unnecessary, which implies that the meeting where it was approved was also unnecessary.

Ask it anyway.

The test: what decision does this output change? Name the decision. Name the person who makes it. Name how the output changes what they do.

If you cannot complete that sentence — “This report changes [decision] made by [person] in [role] by [specific mechanism]” — the output does not have a purpose. It has a history.

History is not a requirement.

Question 2: Does something else already do the same job?

Finance teams accumulate outputs the way organisations accumulate meetings — incrementally, without anyone formally deciding to add them, and without anyone formally deciding to stop.

Before building or migrating anything, map what already exists. For each output, answer: what question does this answer? Then check whether another output answers the same question.

In practice, most finance reporting suites contain at least 30–40% overlap when mapped this way. That overlap migrates. It gets automated. It runs forever.

The most common response when someone points this out is: “Yes, but people are used to seeing it in this format.”

Format familiarity is not a business requirement.

Question 3: Do you know what you’re actually asking for?

This is the question that exposes the gap between what a stakeholder requests and what they need.

“Can we recreate the old monthly pack?” is a format request. “Can we understand what’s driving margin deterioration by the 3rd of each month?” is a decision requirement.

These are not the same question. They frequently get answered as if they are.

The discipline is to translate every reporting request into its underlying decision requirement before scoping the build. If the requester cannot articulate the decision, the scoping conversation is not ready to happen yet.

Slow down here. The project will move faster for it.

How this looks like in practice

This is a pattern I see repeatedly in finance transformation projects:

A team migrates to a new planning tool. The migration is scoped by asking stakeholders what they currently receive and whether they want to keep it. Almost everyone says yes — because saying no feels like losing something, even if that something is a report they stopped reading in 2022.

The result: a new platform running 40 reports, of which perhaps 15 are actively used to make decisions. The remaining 25 run automatically, land in inboxes, and are filed without being opened.

The cost is not just the platform licence. It is the maintenance overhead of outputs nobody challenges because they have always existed, now embedded in a system that makes them feel permanent.

The three questions above, asked before scoping, typically reduce that number significantly. Not because the outputs are bad — but because when forced to name the decision they support, half of them cannot.

The principle underneath all three questions

Elimination is not a cost-cutting exercise. It is a clarity exercise.

A finance function that knows exactly what it produces, why it produces it, and what changes as a result is a finance function that can move fast when it needs to. It automates the right things. It builds the right reports. It walks into executive meetings with the right ask.

The teams that skip the audit don’t produce more. They produce faster — and spend the time they saved maintaining outputs nobody questions because nobody ever stopped to ask whether they should exist.

Stop before you build.

The question is not “can we recreate this?”

The question is “should we?”

If this is useful, forward it to one person in finance who is about to kick off a systems project. The three questions above will save them more time than the project plan will.

You’ve built the bridge chart. Every bar is correct. The maths reconciles perfectly. You put it on the screen.

Then you watch the CFO’s eyes scan left to right, squinting slightly. The COO leans forward. Someone asks “sorry — which of these is the biggest issue?” Someone else asks “is this good or bad compared to last year?”

You know the answers. You built the thing. But the fact that the room is asking those questions means the chart has failed at its primary job — which is not to show the numbers, but to make the conclusion obvious before anyone has to ask.

This is the gap between a chart that reports and a chart that convinces. And it lives entirely in how the chart is set up, labelled, and narrated — not in the numbers themselves.

Why the waterfall chart is uniquely powerful — and uniquely misused

No other standard finance visual does what the bridge chart does: it shows causality. Not just where you ended up, but how you got there, and which forces drove the movement. That is exactly the information executives need to make decisions.

But most bridge charts in practice are built for accuracy, not communication. They’re technically correct. Every bar ties out. The totals foot. And they communicate almost nothing to someone who didn’t build them.

The problem is structural. Bridge charts carry three layers of information — the starting point, the movements, and the ending point — but most teams only label two of them clearly. The movements — the bars in the middle — are left to speak for themselves. They don’t.

The four-layer annotation framework

A bridge chart that drives decisions needs four things that most charts are missing:

Before and after: the same chart, two completely different conversations

The numbers below are identical in both versions. What changes is everything around them.

The numbers are identical. In the “before” version, the room asks three questions and someone requests a follow-up. In the “after” version, the room reads the headline, glances at the “Lead” flag on volume, sees “Temporary,” reads the footer, and moves on. Decision made in 90 seconds.

That’s not a different analysis. That’s a different standard of communication.

The narration sentence — say this out loud

Even with a perfectly annotated chart, the moment you put it on the screen you need to say something. Most people narrate the bars. Don’t.

Use this template instead — every time, without exception:

“The net movement is [direction + amount]. The single biggest driver is [named bar] — and it’s [permanent / temporary / planned], which means [implication for what the business should do or not do].”

That sentence takes eight seconds to say. It answers the three questions every executive is silently asking — how much, why, and should I act — before they have to ask them.

Practise it. It feels unnatural at first because it forces you to have an opinion, not just a summary. That discomfort is the point. Finance’s job is to have an opinion, not to describe the data and wait for someone else to form one.

The one rule that changes everything

If your bridge chart could exist without a headline — if you could remove the title and the chart would still “make sense” — it isn’t doing its job.

Every bridge chart should carry a headline that would be false if the numbers were different. That’s how you know the headline is doing real work, not just decorating the visual.

“Gross profit bridge — April” is always true. It describes the chart regardless of what the numbers show.

“Volume shortfall offset by pricing strength — margin stable” is only true if that’s what actually happened. It can be wrong. Which means it can also be right. And being specifically right is what moves a room.

This week’s action

Pull up your last bridge chart. Read the title. Ask yourself: could this title have been written before I ran the numbers?

If yes — rewrite it. One sentence. Make a claim the data either proves or disproves. That’s your new standard for every bridge chart from here on.

Join my newsletter for more finance content!

Picture this.

Your team spent three weeks building the analysis. The model is airtight. The slides are clean. The narrative flows. You walk into the executive meeting confident.

Four minutes in, the CFO says: “I’m not sure this is the right direction.”

The room shifts. Someone nods. The conversation moves somewhere else entirely. You leave without a decision — and with a follow-up request that adds another two weeks to the project.

Here’s what went wrong: nothing in the meeting.

Everything that broke had already broken before you walked through the door.

The real dynamic in executive decision meetings

Most finance professionals treat a decision meeting as the place where a decision gets made.

It isn’t.

Executive meetings are where decisions get ratified — or stalled. The actual decision-making happens in the corridors, the 1:1s, and the five-minute conversations before someone pulls up the agenda.

This is not cynicism. This is organisational physics.

People with authority rarely change their minds in public. They change their minds in private — when there’s no status risk, no audience, and enough time to think. By the time they’re sitting across from your waterfall chart, they’ve already formed a view. Your job in that room is to speak to a position they already hold, or give them a new piece of information that’s compelling enough to shift it.

If you haven’t done the pre-work, you are hoping they’ll change their mind publicly.

They almost never will.

Why finance teams skip the pre-work

It’s not laziness. It’s three structural habits:

We equate effort with the model. The analysis is where the intellectual work lives, so that’s where time goes. Pre-meeting conversations feel like admin — not finance.

We assume the slides speak for themselves. We built them. We know what they say. So we assume everyone else will understand them the same way we do.

We confuse presenting with influencing. Presenting is putting information in front of someone. Influencing is connecting that information to a decision they already care about. They require completely different preparation.

The result: brilliant analysis, delivered to a room that was never ready to receive it.

The Pre-Meeting Playbook — three tools

These are not elaborate processes. Each takes under 20 minutes. Together, they change the outcome of more meetings than any slide deck ever will.

The hidden power of the pre-alignment call

Of the three tools above, the pre-alignment call is the one most finance professionals resist — and the one that delivers the most return.

The resistance is understandable. It feels presumptuous. “Won’t they think I’m fishing for the answer?” No. What they think is: this person respects my time enough to do their homework before they get in front of me.

Here’s what the call actually does that no slide can:

It tells you the real agenda. Every executive carries into every meeting a list of concerns they didn’t put on the formal agenda. The pre-call surfaces those concerns before they derail yours.

It changes the room dynamics. When you’ve spoken to someone before the meeting, they become an implicit ally in the room rather than an evaluator. They already know where you’re going. They help steer others toward the same conclusion.

It compresses the decision cycle. Meetings where people are hearing something for the first time take longer, produce more questions, and are more likely to end without a decision. Pre-informed rooms move faster.

What this looks like in practice

Let’s say you’re presenting the Q1 management accounts with a recommendation to reduce discretionary spend by 8%.

Without pre-work: you present. The CFO raises a concern about cutting the marketing budget in a growth quarter. The Sales Director agrees with the CFO. The recommendation gets deferred to a working group. Three weeks later, nothing has moved.

With pre-work: three days before, you call the CFO. You learn that her concern is specifically about the marketing budget — everything else she’s aligned with. You adjust one slide to address that concern directly, and frame the recommendation as “an 8% reduction excluding demand generation.” You walk into the meeting, the CFO is already on side, and the recommendation passes in 12 minutes.

Same analysis. Same numbers. Completely different outcome.

This week’s action

Before your next executive presentation — identify the one person whose silent approval determines the outcome. Pick up the phone. Ask them one question: “What’s your biggest concern going into this?”

That’s it. The deck can wait.

Join my newsletter for more financial content!

Everything I’ve learned about writing variance commentary that actually drives decisions — in one place.

I’ve reviewed hundreds of variance reports over the years. Most of them answered one question: what happened?

The best ones answered a different question entirely: what do we do now?

That gap — between a report that records history and one that drives action — usually comes down to how the commentary is written. Not the data. Not the tool. The narrative around the numbers.

This issue pulls together the framework I use, the most common mistake I see, and the one question that separates good commentary from great.

The framework I always come back to

When something moves — revenue, cost, margin — a good variance comment answers five things, in this order:

1. What happened? State the variance clearly. Direction, size, period. No jargon. “Revenue missed plan by €2.3M in March.”

2. Why did it happen? Dig past the surface. One cause rarely explains everything — but one cause is usually primary. If you can’t name it, keep digging.

3. What’s the business impact? Connect the number to something that matters — margin, cash, a strategic target. Numbers without consequences are just bookkeeping.

4. Is it permanent or temporary? This is the question leadership always asks. Answer it before they do — and be honest if you’re not sure yet.

5. What happens next? A comment without a next step isn’t finished. Either name the corrective action, or give an honest read on what you’re monitoring.

That last question is where most commentary stops short. It’s also where the most value is.

The hardest call: permanent or temporary?

This is the hinge of every good variance commentary. Get it right, and the rest of the conversation flows — forecast adjustments, resource decisions, corrective actions. Get it wrong, and you’re rebuilding trust one reforecast at a time.

Four questions I run through every time:

• What would have to be true for this to reverse? If you can’t name the specific condition, you don’t have enough to call it temporary yet.

• Is the underlying driver still active? A supplier price increase still in the contract is not a one-off.

• What does the forward data actually say? Optimism is not a forecast. There should be something concrete — a signed order, a confirmed date — supporting a “temporary” call.

• Has the business adapted, or is it still exposed? If costs have risen permanently and pricing hasn’t moved, the variance will keep coming back.

And three ways to write it, depending on what you actually know:

✅ Temporary: Name the reversal condition + expected timing “Volume shortfall of €1.2M expected to recover in Q2 — two delayed enterprise deals confirmed for April close.”

✅ Permanent: Name the structural shift + forecast implication “Logistics costs up €0.4M/month reflecting new carrier contract from February. Forecast updated accordingly.”

✅ Uncertain: Say so — with what you’re watching “Driver unclear at this stage. Monitoring B2B pipeline through April before updating the forecast assumption.”

That last one takes confidence to write. But it’s more useful than a false call in either direction.

One thing to try this cycle

Before you send your next variance commentary, run this quick check:

• Is the variance actually stated — direction, size, period?

• Is there one lead driver named?

• Is there a so-what — a consequence that matters?

• Is there a next step or an honest status?

If all four are there, it’s done. If one is missing, that’s your fix.

Same data. A comment that passes this check is a completely different read from one that doesn’t.

A question for you

Which of the five framework questions do you find hardest to answer consistently — and why? Hit reply, I read everything.

If someone forwarded this to you and you’d like to receive future issues, you can subscribe here. Finance with Ola is published bi-weekly.