Making the case for accounting automation internally

The standard internal case for finance automation is a time-saving calculation: hours currently spent, hours after, a cost per hour, a payback period.

It is usually rejected, and the reasons are consistent.

Why the time-saving case fails

Nobody believes the hours. They are estimates produced by the person who wants the purchase, about work only they can see.

The saving does not appear anywhere. If nobody leaves, the cost line is unchanged. The finance director sees a new subscription and no offsetting reduction, and is correct to notice.

It competes badly. Every department has a time-saving proposal. Yours is one of several and there is no reason to prefer it.

It is easy to defer. Efficiency has no deadline. Next quarter is always available.

The case fails not because it is wrong but because it answers a question nobody was asking.

What gets approved instead

Proposals that answer a question the decision-maker already has. Four framings that work, roughly in order of strength.

"We cannot grow without this"

The strongest, when true. If transaction volume is rising and the current process needs another person per increment, the choice is not software versus nothing — it is software versus hiring, or versus declining the growth.

Frame as: at current growth we need another person by Q3. This costs less and does not depend on recruitment.

When it is true, use it. When it is not, do not pretend, because the growth number is checkable.

"There is money we are not collecting"

The most persuasive framing available, because it is revenue rather than cost.

Concrete versions:

• Marketplace and gateway deductions never verified, some of which are wrong
• Credit notes on supplier statements never recorded, which are liabilities you do not owe
• Duplicate payments never found
• Debtors not chased consistently, extending collection

These are checkable before you propose anything, which is the point. Reconcile three supplier statements manually. Check one settlement line by line. If you find something, you have evidence rather than a projection — and a small verified finding beats a large estimated one.

"We have a control problem"

Effective with anyone carrying professional or governance responsibility.

If reconciliations are behind, if balances will not decompose, if supplier statements go unchecked, if nobody samples anything — those are control weaknesses. An auditor will eventually raise them, and it is better to raise them yourself with a proposed remedy attached.

Use carefully. It is an argument about risk and it invites the question of how long the weakness has existed.

"The close is why we cannot answer questions"

Effective where management is frustrated by slow reporting.

The argument: the close takes eight days because most of it is chasing and assembling rather than accounting. Remove that and the numbers arrive in three days, and the finance team has capacity to explain them rather than only produce them.

Connects to something the audience already experiences.

What to include

A baseline they can verify. Days to close, unreconciled items, transaction volume — figures from the system rather than estimates.

One thing you already found. The strongest element by a distance. A specific unexplained deduction, a duplicate payment, a supplier statement difference. Evidence that the problem is real, not projected.

The pilot, not the programme. Ask for one process, run in parallel, with a decision point. Much easier to approve than a transformation, and it is what you should be doing anyway.

What happens if it does not work. Naming the reversal path is a credibility signal, and it makes approval cheaper because the downside is bounded — see rolling back an automation that failed.

An honest transition cost. Say that months one and two are more work, not less. Saying so in advance converts a future complaint into a prediction you got right.

What to leave out

Precise hour estimates. They will be challenged and you cannot defend them.

Headcount reduction, unless you genuinely mean it. Most teams stay the same size and absorb more, and implying otherwise creates a promise you will be held to.

Vendor ROI figures. Their model, their assumptions, their reference customers. It weakens the case rather than strengthening it.

"AI" as the reason. The technology is not the argument. The problem it solves is.

Common questions

Why do finance automation business cases get rejected?

Because they are built on hours saved, which nobody believes, which produces no visible cost reduction if headcount is unchanged, which competes against every other department's efficiency proposal, and which has no deadline so can always be deferred. The case is not wrong so much as answering a question the decision-maker was not asking.

What framing works best?

Money not being collected, because it is revenue rather than cost and it is checkable in advance. Reconciling three supplier statements by hand or checking one settlement line by line before proposing anything produces a specific verified finding, and a small real number is more persuasive than a large estimated one.

What should be included in the proposal?

A verifiable baseline taken from the system rather than estimated, one concrete problem you already found, a request for a single process run in parallel rather than a programme, an explicit reversal path if it does not work, and an honest statement that the first two months involve more work rather than less.

What should be left out?

Precise hour estimates you cannot defend, headcount reductions you do not genuinely intend, vendor-supplied ROI figures based on their reference customers, and AI as the justification. The technology is not the argument — the problem it solves is.

Related: measuring whether AI accounting worked · running an AI accounting pilot · the cost of doing nothing