Rolling back an accounting automation that failed

Most writing about automation assumes it works. Sometimes it does not, and the ability to stop cleanly is part of doing this responsibly.

Two things need separating first, because they are frequently confused and the responses are opposite.

Is it failing, or is it month one?

Transition difficulty looks like: a long exception queue, frequent corrections, the team saying it is more work, days-to-close unchanged. All expected in the first month, all normally resolving by month two. See what month two of automation looks like.

Genuine failure looks like:

• Errors nobody can explain, including the vendor
• Exception volume rising rather than falling after a full cycle
• Corrections consistently made downstream because the workflow does not fit the process
• A control you needed that turns out not to exist
• Reconciliations that no longer decompose

The distinguishing question: is it getting better? Transition difficulty improves. Failure does not, or worsens.

Abandoning at week three is the more common error. But persisting with something that is genuinely not working — because stopping would be embarrassing — is the more expensive one.

Deciding to stop

Three conditions that justify reversing rather than persisting:

You cannot explain the output. If neither you nor the vendor can say why a treatment was applied, that is not a configuration problem you will grow out of. It becomes an audit problem.

The error rate is not acceptable and the cause is not identifiable. Fixable causes are fine. Unfindable ones mean you cannot bound the risk.

The process does not fit and cannot be made to fit. Sometimes the software encodes assumptions about how a process works that do not match your business, and configuration cannot bridge it.

Not on the list: the team dislikes it, it is taking longer than expected, or the exception queue is long. Those are transition problems.

Reversing cleanly

Stop the specific process, not everything. If invoice capture is failing, that does not mean bank reconciliation should stop.

Establish what needs reversing. Which transactions, over what period, processed under what rule. This depends on the system having recorded rule versions — the capability discussed in what happens when the AI is wrong, and the thing that determines whether this takes hours or weeks.

Reverse visibly. Reversing entries, not deletion. The original entries stay, the reversals are on the record, and the audit trail shows what happened. A rollback that erases history is worse than the problem it is fixing.

Restore the manual process deliberately. It will have decayed — people have lost the habit, the spreadsheet is out of date, someone who knew it has left. Restoring it needs the same attention as implementing something new, and this is the step most often underestimated.

Reconcile after reversal. Every affected balance should decompose to what it would have been. Do not assume the reversal was complete; check it.

Write down what happened. What failed, when it was detected, what was reversed, what the position is now. An auditor will ask, and a documented reversal is far better received than one nobody recorded.

What to keep

A rollback does not have to be total, and total rollbacks throw away real gains.

Keep the data cleanup. Deduplicated suppliers, a pruned chart of accounts, cleared historical items — all valuable regardless of what software you run.

Keep the process documentation. You wrote down how the process actually works, including exceptions. That is worth having whatever happens next.

Keep whatever was working. Document capture might have been fine while the coding was not. Reverse what failed.

Keep the disagreement log. It tells you what to require from the next attempt, and it is the most useful input to any subsequent evaluation.

The conversation with the vendor

Have it before reversing, not after. Two things worth establishing:

Is this fixable, specifically and with a timeframe? A vague assurance is a no. A specific diagnosis with a date is worth waiting for.

What are the exit terms? Data export in a readable format, including processing records, and how long data is retained after termination. Ideally agreed at signing — see record retention when records are generated — and if not, established now while you still have leverage.

Trying again later

A failed attempt is not a reason never to automate. It is information about what went wrong, and the causes are usually specific.

Most failures trace to data that was not prepared, a process nobody had described properly, a first choice that was too ambitious, or thresholds set without evidence. All addressable. The businesses that succeed on a second attempt are usually the ones that fixed the preparation rather than changed the software.

Which is worth knowing before concluding the technology was the problem.

Common questions

How do I tell whether an automation is failing or just settling in?

Ask whether it is getting better. Transition difficulty — a long exception queue, frequent corrections, the team saying it is more work — is expected in month one and normally resolves by month two. Genuine failure shows as errors nobody including the vendor can explain, exception volume rising after a full cycle, or reconciliations that no longer decompose, and it does not improve on its own.

What justifies rolling back an accounting automation?

Output you cannot explain, an unacceptable error rate whose cause cannot be identified, or a process mismatch that configuration cannot bridge. A team disliking it, the project running late, or a long exception queue are transition problems rather than grounds for reversal.

How do you reverse automated entries cleanly?

Stop the specific process rather than everything, establish the full affected population using recorded rule versions, reverse visibly with reversing entries rather than deletions so the history remains intact, restore the manual process with the same care as a new implementation since it will have decayed, reconcile every affected balance afterwards, and document what happened for the auditor.

Should everything be rolled back?

No. Keep the data cleanup, which is valuable regardless of software; keep the process documentation you produced; keep whichever parts were working, since document capture may be fine while coding is not; and keep the disagreement log, which is the most useful input to any future evaluation.

Related: what happens when the AI is wrong · what month two of automation looks like · common mistakes when you start automating