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.