"Where should we be using AI in finance?"
It is the most common question I'm asked now, and it's the second question wearing the first one's clothes. Before it can be answered there's a duller one to get through: what does your finance function actually do all day, and how long does each of those things take? Very few owners can answer that with any precision. Until somebody can, choosing what to automate is guesswork with a subscription attached.
The mechanic underneath is worth being blunt about. Automation is a multiplier, not a repair. Point it at a process that works and you get the same output, faster and cheaper. Point it at a process that doesn't work and you get the same errors, faster, in greater volume, and considerably harder to spot — because now they arrive with the quiet authority of something a machine produced. What that does to a P&L is a subject I've covered elsewhere.
So the order matters more than the tool. Here is the order.
The Grid
Two questions place almost any finance task. How often does it happen? And how complex is it — rules you could write down, or judgement you can't?
Happens daily to monthly, rules-based — automate first. Invoice capture and coding. Bank reconciliation matching. Expense claims checked against policy. Supplier statement matching. Drafting the debtor chase — the draft, not the decision to send it. This is where the hours actually are, and none of it is where anybody's expertise lives. In most SME finance functions this box is the majority of the working week, which is precisely why it's the majority of the return.
Happens daily to monthly, needs judgement — draft it, then check it. Variance commentary. The narrative half of a board pack. First-cut customer or product profitability. Scenario scaffolding. Here a model gets you to a decent draft in minutes instead of hours, and it will be wrong in ways only somebody who knows the business will catch. That's an acceptable trade: a flawed first draft you correct beats a blank page you keep postponing. But nothing from this box leaves the building unread.
Happens a few times a year, rules-based — count the hours first. This is the box people get wrong in both directions, and it's the one that deserves arithmetic rather than instinct.
The usual advice is to ignore anything infrequent. That's lazy. A year-end pack that swallows three days of your controller's time is thirty-six days a decade, and it arrives in the week when everybody is already stretched — so its real cost is higher than the calendar suggests. Automating that is obviously worth it. The annual filing that takes an afternoon is not, however satisfying it would be to never do it again.
So do the sum before you decide: hours per occurrence, times occurrences per year, against what the build will cost you to make and to maintain. Maintenance is the part people forget. Something you touch once a year is something you'll have forgotten how to fix by the time it breaks, which is a real cost that doesn't appear in the business case. As a rough line: if it doesn't save you a week a year, it probably isn't worth building — but do the sum rather than guessing, because a founder's instinct about which tasks are painful is famously unreliable.
Happens a few times a year, needs judgement — decide it yourself. Pricing. Which client to let go. Whether the second location makes sense. Whether the offer on the table is a good one. These are the decisions you're paid to make and the ones you'll be asked to defend, so they stay with you. Use a model to lay out the options and pressure-test your reasoning by all means. Just don't let it hold the pen.
The Override: Never Automate a Control
One rule beats the grid, and it deserves stating on its own.
Wherever a task sits, if it is a control — a step that exists precisely because someone might get it wrong, or take advantage — a named human keeps it. Payment approval. Changes to master data: bank details, supplier records, payroll rates. Journal entries above a threshold. Anything an auditor expects to trace back to a person.
The reason isn't that software would do it badly. It's that a control's entire value is accountability, and you cannot hold software accountable. When something goes wrong, "the system approved it" is not an answer anybody accepts — not your auditor, not your bank, and not you at two in the morning.
The useful distinction is between preparing and approving. Automate the preparation generously: assemble the payment run, match it against purchase orders, flag the exceptions, present the lot with the evidence attached. Then a person approves. That person's job just got faster, and their attention got pointed at the twelve items that deserve it rather than the four hundred that don't. The delegation-of-authority thresholds you'd write for people apply here unchanged — same limits, same logic, same named owners.
Three Questions Before You Automate Anything
Does it happen often enough to matter? Count it for one month before deciding. Founders are reliably wrong about this in both directions: the task that feels maddening is often twenty minutes a week, and the one nobody mentions is eleven hours.
Will you know immediately when it goes wrong? If the honest answer is "we'd find out at year-end", stop. A silent error compounding for eleven months costs more than the entire process it was meant to improve. Automate where the feedback is fast and visible.
Does a human still own the outcome? If nobody's name is against it, you haven't automated a task. You've abandoned one.
The Trap Nobody Warns You About
Don't automate a process you're about to change.
Building around a process cements it. The cost isn't the build — it's the year you then spend defending a bad way of working because you paid for it, and because rebuilding feels like admitting the first decision was wrong. If a process is due to change, change it first, then automate the version you actually meant.
The same goes for a process nobody has ever written down. If it lives entirely in one person's head, automating it captures their habits — including the ones they'd have dropped had anybody asked them why.
The Order, Once More
Records, then reliability, then automation. It's the same ladder as hiring, for the same reason: you cannot automate your way to trustworthy numbers. You can only automate the handling of numbers that are already trustworthy.
Which is why the first phase of any programme worth scoping is the unglamorous one — chart of accounts, the close, who owns what — and why the sequence we scope to puts foundations before anything clever. Nobody has ever been thrilled by that phase. It is also the only reason the later ones work.
Automation multiplies whatever process you point it at. That is the whole promise, and the whole risk, in one sentence.
Where to Start on Monday
Take one week. Ask whoever does the finance work to log every task and how long it took — no tooling required, a notebook is fine. At the end of the week, put each line on the grid.
The top-left box is your list. Start with the single most frequent item on it, not the most interesting one. The most interesting one is nearly always in the top right, which is exactly where a first attempt is least likely to survive contact with reality.
If you'd like a structured version of that exercise, the AI readiness check covers the same ground in about three minutes, and tells you which of the four boxes you're actually ready for.