From manual matching to managed exceptions

Every treasury team reconciles bank statements. The question is how much of that work happens by hand, and how much of it happens before anyone has to look at a screen.

For most teams, reconciliation still means two windows open side by side: the cash forecast in one, the bank statement in the other, and a person checking that each line in one has a matching line in the other. Account by account, currency by currency, day after day.

The cost of that is not just time, though the time adds up quickly. Every hour spent matching transactions that were always going to match is an hour not spent on the things that genuinely need a treasurer’s judgement: an unexplained payment, a missing receipt, a forecast drifting away from reality. And when reconciliation runs late, everything downstream runs late with it, including the cash position, the liquidity decisions built on top of it, and the records an auditor will eventually ask to see.

Why manual reconciliation breaks down at scale

The usual response to this is to add more checks, more spreadsheets, or more people. None of it fixes the underlying problem, which is that manual reconciliation has no consistent categorisation layer underneath it.

Every bank, and often every branch of the same bank, codes its transactions differently. A receipt might mean one thing on one bank’s statement and something else entirely on a statement from a different market. Without a reliable way of translating those codes into the organisation’s own transaction types, every reconciliation exercise starts from a slightly different baseline, and every new bank relationship adds another layer of inconsistency.

That is the gap automation closes. Not by removing reconciliation, but by removing everything inside it that never needed a person in the first place.

Two layers of automation: tagging and matching

Automated reconciliation, as Salmon builds it, works in two layers. It is worth separating them, because they solve two different problems.

The first layer is tagging. Tagging takes the bank’s own transaction codes and adds the organisation’s transaction type alongside them, the classification a treasury team actually uses for reporting and cash flow analysis. A rule might state that any transaction carrying a particular word in its reference field, or a particular instrument code, gets classified as a specific transaction type. Once that rule exists, it applies automatically and consistently, whether the statement arrives overnight through a scheduled job or gets reprocessed manually after a correction. A team handling statements from several banks across several markets only has to write the rule once per pattern. The system applies it every time after that.

The second layer is reconciliation itself: matching a recorded forecast against the actual transaction it corresponds to. The matching criteria are exactly what you would expect: account, value date, amount, currency, and, where it adds precision, the transaction reference. Where they line up, the system reconciles them and moves on. Where they do not, that is where exception handling takes over.

What happens when it does not match

Automation is sometimes pitched as something that should remove exceptions altogether. It cannot, and should not try to. Reconciliation will always surface a payment that has not arrived, a forecast nobody logged, or a discrepancy somebody needs to explain. What automation changes is how that exception is found, and how much context arrives with it.

Rather than a treasurer scanning two screens for whatever does not match, the system narrows the field to a handful of predictable categories:

Each category points to a different kind of follow-up. A numerical discrepancy is usually a data problem, easily corrected once it is flagged. A missing forecast is usually a process problem, worth raising with whoever issued the payment regardless of which reconciliation tool is in use. A missing actual can be the early warning of a settlement that is stuck, worth chasing with the counterparty or the bank before it becomes a liquidity problem.

The system does not make those judgement calls. It makes sure they are the only calls left to make.

Control and auditability you can put in front of an auditor

There is a second benefit to automated reconciliation that is easy to undervalue until an auditor asks for it: a clean, consistent record of what was reconciled, when, and against what.

Once a transaction is matched, it is locked. Nobody can quietly edit a reconciled entry. If something needs correcting, it has to be unreconciled first, which means there is always a record of the change rather than a silent edit. That same reconciled status follows the transaction everywhere it appears, in the account statement, in the underlying deal record, and in any reporting dashboard built on top of it, so there is one consistent answer to whether something has been reconciled, rather than several systems that might disagree.

For a treasury function under any kind of audit or regulatory scrutiny, that consistency is worth as much as the time saved.

What good looks like

None of this removes the treasurer from the process. It removes the parts of the process that never needed a treasurer in the first place.

What is left is a queue of genuine exceptions, each one with enough context attached to act on quickly, alongside a dashboard that shows, at a glance, what is reconciled, what is not, and why. Month end stops being a race against unmatched transactions and starts being a short review of the handful that actually needed attention.

That is the practical version of seeing clearly and planning confidently: not a slogan, but a treasury team that knows exactly where its cash position stands, and can prove it.

If reconciliation in your organisation still depends on someone matching two screens by hand, it is worth seeing what automated tagging and reconciliation looks like in practice. Get in touch with Salmon to arrange a walkthrough.