When not to automate an accounting process

We sell accounting automation, so treat the source accordingly. But the fastest way to kill an automation programme is to automate something that should not have been automated — the failure is visible, expensive, and it poisons everything you try afterwards.

Six tests. If a process fails two or more, leave it alone.

Test one: is the right answer in the inputs?

If the correct treatment depends on information that does not appear in any document the system receives, no amount of capability will produce it.

The clearest example is capital versus revenue. An invoice for RM 8,000 of materials could be a repair or part of a capital project. The invoice does not say, because the distinction is about intent.

Failing this test does not always mean don't automate — it may mean fix the input. If purchase orders carried the classification, the invoice would inherit it. That is often the better project.

Test two: is it reversible?

If it runs wrong for two weeks before anyone notices, what does unwinding look like?

Miscoded transactions: reclassify. Annoying, not serious. Payments released: money has left, and recovery depends on the goodwill of whoever received it. A statement filed with an authority: a correction process with consequences.

Irreversibility is the strongest single argument for keeping a person in the step. The saving on payment approval is small; the tail risk is not.

Test three: does it happen often enough to learn from?

Automation pays where volume is high and patterns repeat. A process running four times a year with different circumstances each time gives a model nothing to learn from and gives you no opportunity to build confidence.

Year-end consolidation adjustments, unusual transactions, one-off restructures — these are low-volume and high-judgement, which is the worst combination for automation and the best for an experienced person.

Test four: is being wrong recoverable in the relationship?

Some errors cost money. Others cost trust, and trust is harder to restore.

Automated dunning sent to your largest customer over an invoice they have already queried. A supplier put on payment hold by a rule during a delicate negotiation. A customer's statement showing a balance they dispute.

The financial exposure is trivial and the relationship damage is not. Any process where an error reaches a customer or supplier directly needs a person, or at minimum a suppression mechanism anyone in the business can trigger.

Test five: can you tell if it went wrong?

A process you cannot check is a process you should not automate, because automated error is consistent and invisible rather than obvious.

If there is no independent source to reconcile against, no sampling method, and no downstream step that would notice, then automating it means never knowing whether it works. Some processes are genuinely like this, and they should stay where a person's judgement is applied each time.

Test six: is the process actually understood?

If nobody can describe how it currently works — including the exceptions and who handles them — automating it means encoding a misunderstanding.

This is more common than it sounds. Many processes exist as a confident summary plus a large amount of unexamined judgement that nobody has articulated. See why accountants should learn to describe processes.

Failing this test is temporary and fixable. Write the process down properly, then reassess. The writing frequently improves the process regardless of whether anything gets automated.

The processes that reliably fail these tests

• Period cut-off decisions
• Estimates, provisions, impairment assessments
• Year-end consolidation adjustments
• Anything involving a negotiation in progress
• First transactions with a new counterparty
• Payment release above a material amount
• Anything requiring judgement about the future

And the ones that reliably pass

• Document capture and extraction
• Bank and settlement reconciliation
• Matching payments to invoices
• Coding of recurring supplier spend
• Recurring journals, accrual reversals, depreciation
• Reminders, follow-ups and escalations
• Supplier statement reconciliation

The pattern across both lists: high volume, clear right answer, checkable, reversible on one side; low volume, judgement-dependent, unverifiable, irreversible on the other.

The question to ask yourself

Before automating anything: if this ran wrong for a month and nobody noticed, what would I be dealing with?

If the answer is a tidying exercise, proceed. If it is a conversation with a regulator, a customer, or a bank, keep a person in the loop — and be honest that the reason is consequence rather than capability.

Common questions

Which accounting processes should not be automated?

Period cut-off decisions, estimates and provisions, year-end consolidation adjustments, anything involving an active negotiation, first transactions with a new counterparty, material payment releases, and anything requiring a judgement about the future. These share low volume, dependence on judgement, difficulty of verification, or irreversibility — frequently several at once.

How do I decide whether a process is a good automation candidate?

Test whether the correct answer is actually present in the inputs, whether the action is reversible, whether it occurs often enough with repeating patterns to learn from, whether an error would damage a customer or supplier relationship, whether you could detect it going wrong, and whether the process is currently understood well enough to describe including its exceptions. Failing two or more suggests leaving it alone.

What if the right answer isn't in the documents?

That often points to fixing the input rather than abandoning automation. Capital versus revenue classification is absent from most invoices but present on a purchase order, so requiring the classification at the ordering stage lets the invoice inherit it. Improving what is captured upstream is frequently a better project than trying to infer the missing information downstream.

What is the biggest risk of automating the wrong process?

Losing credibility for the whole programme. A visible failure in something that should have stayed human makes every subsequent proposal harder to get agreed, regardless of whether those would have worked. This is why irreversible and relationship-facing processes are worth leaving manual even when the technology could handle them.

Related: where AI in accounting still falls short · choosing the first accounting process to automate · keeping a human in the loop