"Automate reconciliations" is good advice delivered at unhelpful altitude. Some reconciliations are almost entirely mechanical and return time immediately. Others are judgement-heavy and automating them badly creates false confidence.
Here is how we sequence it.
The highest-volume, most rules-friendly reconciliation in any business. Bank feeds provide structured data, and the matching logic — amount, date window, reference, counterparty — handles the overwhelming majority of lines.
What good looks like: the system matches the routine population, and a human reviews an exception queue. If your team is confirming matches the system already made, the rules are not tuned.
Watch for: payment processors that settle net of fees. Stripe deposits a net amount covering many gross transactions less fees. Matching the net deposit to a single invoice will not work — you need the settlement report expanded to gross plus fee.
Closely related and often the messiest part of a SaaS close. Every processor has its own settlement timing, fee structure, chargeback handling and reporting format.
This one repays automation heavily because it is high volume, highly structured, and genuinely tedious. It is also where under-recognised revenue hides, because fees netted at source are easy to miss when grossing up.
For groups, this is where automation changes the nature of the work rather than just the speed.
The mechanism that matters is not matching after the fact — it is generating both sides of the transaction from a single event, so they cannot diverge. Matching intercompany balances that were recorded independently is treating a symptom.
More on this in intercompany eliminations for Australian groups.
AP and AR subledgers reconciling to their control accounts should be continuously true rather than periodically verified. In a properly integrated ledger this is automatic; in a stitched-together stack it needs checking.
If yours regularly disagrees, the problem is usually a manual journal posted directly to the control account, bypassing the subledger. That is worth preventing at source with posting restrictions rather than detecting monthly.
Here judgement starts to matter. Recurring accruals with stable amounts can be templated safely. Estimates — bonus provisions, doubtful debts, warranty, restructuring — should not be automated into a number nobody reviews.
Templating the process is fine. Templating the judgement is how a stale assumption survives four quarters unnoticed.
Automate the calculation, absolutely — that is what a revenue engine does. But the reconciliation of deferred revenue to the contract population should be reviewed by a person every month, because it is the control that catches contract data errors.
If the schedule is derived from the contracts and nobody checks the contracts, an error in the contract record becomes an error in revenue with no detection point.
Three things should never become fully automatic:
The measure is not the percentage of lines auto-matched. It is whether the exception queue is genuinely exceptional — small, varied, and worth a human looking at.
If your team reviews a large exception queue every month with the same recurring items in it, the rules need work rather than the people.
Reconciliation configuration is a core part of our implementations — tuning matching rules against your actual transaction patterns rather than accepting defaults, and connecting processor settlements properly.
See the full sequence in our month-end close checklist, or talk to us.