What does bank reconciliation cost you today?
Reconciliation in a practice that manages ledgers for multiple clients is a shifting target. The statement arrives. The ledger is not quite closed. A payment is in the bank but not in the books. A direct debit nobody recognises. A credit that cannot be matched to an invoice because the client does not know what it is either.
Most of it is not difficult. It is persistent. The half-hour to match three client accounts becomes a half-day when you are also finding the missing supplier invoice, querying the bank charge, and waiting for a client to search their records. By the time month-end arrives, three reconciliations are in progress and none of them is finished, because each one stalled when something billable turned up.
There is no credible non-vendor benchmark for what this costs in hours per account, because every published figure we could find comes from a software company measuring its own product. What we ask instead: take last month, count the client accounts you reconciled, and note how many were complete within seven days of the statement date. That count, and the age of the oldest unresolved item at close, is the baseline any build needs to be worth doing.
What exactly gets automated?
Five things. The fifth separates a build from a demonstration.
Reading the feed and the ledger on a schedule. The bank statement and the ledger are pulled on the days you choose. No waiting for someone to open the accounts package. If a statement has not arrived, the system says so rather than running on stale data.
Matching on more than reference number. A direct debit matched by amount and payee pattern. A payment that came in one day late matched to the invoice it corresponds to. A supplier whose name in the bank description reads differently from the ledger entry matched by the identifiers that do not change. The rules are yours, not the system's defaults.
Scoring the unmatched. Each unreconciled item gets a reason in plain words: amount matches but payee does not; no corresponding item anywhere in the period; possible duplicate. Not a confidence percentage. A description a bookkeeper can read in two seconds and act on.
Flagging the things the system cannot explain. Duplicates. Amounts that look right but came in twice. Transactions with no clear counterpart anywhere in a two-week window. These go to a queue, not back to a spreadsheet. The queue has a name on it.
Keeping the state of each account. Which accounts are clean, which have open items, which have not moved since last month. One view across all the client accounts you carry, not one spreadsheet per client. This is what makes a build useful across a practice rather than for a single ledger.
What still needs a person?
Three things.
Clearing every flagged item. The exceptions are the work, not the interruption to it. A transaction flagged as unmatched is flagged because it genuinely does not match anything the system knows, and it needs someone who knows the client, the supplier or the period to look at it and decide what it is. A queue of forty real questions is a better day than a queue of four hundred trivial ones.
Setting and tuning the sensitivity. The rules that govern what counts as a match are yours to own and adjust. If the system flags too many things it would have matched correctly, the sensitivity setting needs tightening. If it is matching things that turn out to be wrong, it needs loosening. Neither direction is ours to set without your sign-off, and neither is a sign that the build is failing.
The judgement about a systematic pattern. Ten unmatched items of similar size over three months is a different problem from ten random ones. The system points to the pattern. Deciding what it means is not something it does.
How is the result measured?
Against what you already produce, using numbers taken before the build starts.
Three things to measure now. The age of the oldest unresolved item across all client accounts at month-end close: this is the headline, and it usually moves first and moves most. The proportion of accounts fully reconciled within seven days of the statement date: this is what the build is aimed at. The number of errors found when a partner spot-checks a reconciliation after the system has run: this is the one that tells you whether the automation is reliable or just fast.
Take three months of history on all three before anything is built. They are numbers the practice already produces, if not in one place. A comparison without a baseline is a story rather than a measurement, and the story is usually more optimistic than the ledger.
What could go wrong?
Two transactions matched that should not have been. The most invisible failure mode. A match looks clean on the report, nobody reviews it again, and several months later a client notices one payment was posted twice and one was never posted at all. Every proposed match carries a reason trail so it can be reviewed, and any match that writes off an amount the system is not confident about goes to the queue rather than through it.
Alert fatigue if the flags are set too loose. A queue of fifty unmatched items a week, most of which turn out to be fine, trains the person working it to move quickly through everything. That is how a real problem gets past them. The flags need to be tight enough to be taken seriously. Calibrating them against three to four weeks of live data is part of the build, not an afterthought.
A clean queue on a ledger that was already wrong. The system matches what is in the ledger to what is in the bank. If the ledger has an error in it before the reconciliation starts, the reconciliation reports clean on the same error. This is not a failure of the reconciliation; it is why the management accounts review still needs a person, and why the two workflows connect.
How long does it take to put in?
One to two weeks. This is one of the quicker builds in a practice, because the logic is well-bounded and the data is already structured on both sides.
A session on the accounts in scope, the matching rules that apply, and the people who clear the exceptions. A connection to the ledger and to the bank feeds. A week of shadow matching, where the system proposes matches against last month's already-closed accounts and you check the proposals against what was done by hand. Then live, with the exception queue flowing to the right person each day rather than accumulating until month-end.
Then we hand it over. No retainer, the matching rules are yours to tune, and adding a new client account is a configuration rather than a rebuild. If you want to know where this sits against the other workflows worth automating in your practice, that conversation is the opportunity review, and it starts with last month's oldest unresolved item rather than with software.