Starting with AI in accounting — the sequence that works

Accounting automation rarely fails because the software was wrong. It fails because things were done in an order that made each step harder than it needed to be.

The general question of where to begin with automation is covered in which process should you automate first. This is the accounting-specific version — what the sequence looks like when the processes are AP, AR, reconciliation and the close.

Stage one: fix the data

Before any software decision.

Deduplicate suppliers and customers. Prune the chart of accounts and write one sentence defining each account that survives. Clear the historical backlog of unmatched items. Resolve inconsistent coding on your largest recurring suppliers.

Two or three days for most small finance teams, and it changes the outcome more than the product choice does. Data quality is the real constraint explains why, and preparing your data before automating is the practical checklist.

Why first: everything downstream inherits this. Automation applied to inconsistent data learns the inconsistency and reproduces it at speed.

Stage two: pick one process

Not a programme — one process. High volume, low judgement, currently painful, with a checkable right answer.

For most businesses that is supplier invoice capture or reconciliation of one sales channel. Not the month-end close, which touches everything and fails visibly.

Choosing the first accounting process to automate works through the candidates.

Why one: a single process can be run in parallel, compared and reversed. A programme cannot, and when something goes wrong nobody can tell which part caused it.

Stage three: write down how it works today

Including the exceptions and who handles them. Including what happens when the expected information is missing.

This is where most of the useful discovery happens, because it surfaces decisions nobody has made — what tolerance is acceptable, what happens with no purchase order, how long before something escalates. See why accountants should learn to describe processes.

Why before configuring: you cannot automate a process you cannot describe, and the description is what the configuration is built from.

Stage four: run it in parallel

Both ways, for one full cycle. The system processes; the existing method continues; you compare.

You are looking for where they disagree, and specifically why. Every disagreement is either a system error, a threshold set wrongly, or — surprisingly often — a case where the old manual treatment was inconsistent and nobody realised.

Why a full cycle: accounting processes have monthly rhythm. A two-week trial misses period end, which is where the problems are.

Stage five: switch over, with the thresholds high

Start conservative. A large exception queue in the first weeks is expected and useful — you are gathering evidence about where the system is reliable.

Track what reviewers actually change. Where they approve a confidence band without amendment consistently, that band can move to automatic. Lower the threshold in steps, on evidence. See why confidence scores matter in finance.

Why not straight to full automation: you have no basis yet for knowing where it is reliable in your business, and a vendor's benchmark is about their customers rather than yours.

Stage six: establish the ongoing controls

The stage that gets skipped, and the one that determines whether this still works in two years.

• Quarterly sampling of confidently-processed transactions
• A named owner per automated process
• A configuration change log
• A scheduled review of whether thresholds still fit the business

None of this is difficult. All of it is invisible work with no deadline attached, which is why it does not happen unless someone is assigned it.

Then, and only then, the second process

Add the next one when the first is genuinely being used rather than merely installed — the exception queue is short and worked daily, and nobody is correcting things downstream with journals.

Businesses that add the second process while the first is still unstable end up with two unstable processes and no way to tell which is causing what.

What this costs in time

Realistically, for a small finance team automating one process:

• Data preparation: 2–3 days
• Process description: half a day
• Configuration and setup: varies
• Parallel run: one full cycle, mostly comparison time
• Stabilisation: 1–2 months of higher-than-normal exception handling

The pattern to expect is that months one and two feel like more work, not less. That is normal and it is worth telling the team in advance, because the alternative is a team that concludes it does not work in week three.

Common questions

What is the right order to automate accounting processes?

Fix the data first, pick one process rather than a programme, write down how that process works today including its exceptions, run it in parallel with the existing method for a full cycle, switch over with conservative thresholds and lower them on evidence, then put the ongoing controls in place before adding a second process. Most failures come from doing the right things in the wrong order rather than from choosing wrong software.

Why run in parallel for a full month?

Because accounting processes have a monthly rhythm and the difficult cases cluster at period end. A two-week trial misses cut-off, accruals and the close entirely, which is where disagreements between the automated and manual treatment are most informative — and where a mistake would be most visible if you had switched over without knowing.

How long before automation feels like less work?

Usually two months. The first weeks involve a long exception queue containing both genuine items and historical backlog, plus the work of comparing parallel results, so the team is doing more rather than less. Telling them this in advance matters, because otherwise the natural conclusion in week three is that it does not work.

When should a second process be automated?

When the first is genuinely in use rather than merely installed — the exception queue is short and worked daily, and nobody is correcting output downstream with manual journals. Adding a second while the first is unstable produces two unstable processes and removes any ability to tell which is causing a given problem.

Related: choosing the first accounting process to automate · preparing your data before automating · running an AI accounting pilot