Account Reconciliation Automation: A Bookkeeper's Guide

Reconciliation add-ons for ERPs now sweep bank lines, match them to ledger entries, and post the matches in minutes. Used sensibly, they save real time at month end. Used carelessly, they produce a clean-looking reconciliation that is wrong in ways the eye cannot see.

Matching is the easy part

The add-on applies rules you define: same amount, same date, a reference that appears on both sides, or a tolerance band around the figure. It can match several invoices to one payment, flag short and over payments, and carry unmatched lines forward. What it cannot do is know what a transaction means. A match is a guess with evidence attached.

Design the rules before you run anything

Set the rules in order, weakest first, strongest last, so the system does not grab the first line that merely resembles another. Tight tolerances reject too much; wide ones invite false matches. A payment of 1,200.00 with a tolerance of 10 will match an invoice for 1,190.00 and an invoice for 1,205.00. Both may be wrong, and the exception list will not tell you.

After a week of live running, review what the rules matched and what they rejected. The reject list tells you more than the match list.

A worked example: the same amount problem

Two customer payments of 842.10 arrive on the same day, one for invoice 1041 and one for invoice 1042. The add-on matches by amount and date, so it pairs the newest payment with the oldest posting, or matches in the order the bank feed lands. The ledger balances, the bank reconciles, and both invoices show paid. One is right and one is wrong.

That is the difference between a matching system and a bookkeeper. It is why someone still reads the detail. The fault shows up later as a credit note or a customer call, and it looks like an ordinary posting mistake because in the ledger it is one. The clue is in the match report: the reference on one side did not match the reference on the other.

The exception list is the real work

Automation moves the bookkeeper from keying to judging. The daily routine becomes: open the exception list, trace the unmatched lines, decide which are timing differences and which are errors, and adjust only what is genuinely wrong. Unmatched lines are not a failure of the tool. They are the part that still needs a human.

Check the aged unmatched items at every close. A line that sits for three months is either a payment that never posted or an invoice that never left. The software will not notice. You have to.

Evidence before automation

Before you switch on any add-on, export the trial balance, the bank detail and the current reconciliation working papers. Store the rule set, the add-on version and the go-live date. Keep the match reports, not just the ticked boxes, so a later reviewer can see exactly what the software saw.

The close needs an audit trail. If a rule misfires and posts a thousand matches you never reviewed, preserved evidence is what lets you unwind it. It also tells you whether the damage sits in transactions or in the matching tables, which is the difference between a repost and a rebuild.

When does it stop being bookkeeping?

If the add-on starts writing transactions you did not approve, if clearing entries disappear, or if the bank figure will not tie and the file itself behaves oddly, stop. Get specialist advice before anyone touches the file. Trial-and-error fixes, repeated imports and manual edits to matched lines can compound the damage.

At that point it is data damage, not bookkeeping. Our specialists handle damaged company files and the move between systems; hand it over rather than carrying on.