Reconciliation automation for treasury and the daily close: a practical guide

What reconciliation automation actually does

Most finance teams already do bank reconciliation in some form. The difference is cadence and discipline. Manual reconciliation tends to happen at month-end, relies on exported files and too often ends with a single number typed into a cell to make the totals agree. Automated reconciliation runs every day after a defined cutoff, reads every source the same way, and refuses to close a difference with an unexplained figure

The three inputs of a reliable match

Every match needs three things: the ledger balance and the entries behind it, an independent balance from the source itself, and a record of when that balance was read. The ledger is the reference system, but it only earns trust when it is compared with something it did not produce. A bank statement, a gateway settlement report or a partner statement plays the role of that independent witness

• The ledger side: balances built from balanced double entries, where every change is an event and mistakes are corrected with reversing entries rather than edits or deletions
• The source side: the balance and transaction rows reported by the bank, gateway, wallet or partner at the moment of reading
• The context: cutoff time, currency, exchange rate source and the version of the matching rules that were applied

If you want the ledger side explained in depth, read our guide to the immutable double-entry ledger and its audit trail

How an automated daily close runs

A daily close is a fixed sequence. When it runs the same way every night, a difference means something real changed, not that someone followed a different procedure

1. Cut off the day at a defined time, so late rows fall into the next day instead of silently changing yesterday
2. Read every source with read-only access and record each source's balance at the moment of reading as a witness
3. Convert new rows into events and balanced entries, and check that the trial balance is zero
4. Match each ledger account against its independent source using the agreed rules and tolerances
5. List every unmatched item as an exception with a probable cause
6. Produce a one-page morning report with balances, the day's movements, open exceptions and the decisions waiting for a person

A missing source is not a zero

The most dangerous shortcut in any close is treating missing data as zero. If a gateway does not respond or a statement has not arrived, a careless system reports the account as balanced simply because nothing was compared. A sound process does the opposite: the day stays marked as not carried forward, the affected balance is shown as unknown with its last known time, and the report says so plainly. Nobody signs off a close that is quietly incomplete

The Arfinex nightly close and source reconciliation service follows this rule: entries the engine did not create are reported separately every night, and late-arriving rows or status changes to earlier rows are detected rather than absorbed into the balances

The exception lifecycle: from detection to resolution

An exception is any difference between the ledger and its source that the rules cannot explain. What separates a mature process from a fragile one is not how few exceptions appear but how each one is handled. Every exception should move through the same lifecycle

• Detected: the system records the account, amount, currency, source row and probable cause, such as a timing difference, a fee deducted at source or a duplicate
• Owned: a named person or team is assigned, so nothing sits unattended in a shared inbox
• Aged: the exception carries its age in days, and ageing thresholds trigger escalation
• Evidenced: the owner attaches the supporting document, for example a bank confirmation, a settlement file or a transaction reference
• Resolved: the difference clears because the source or the ledger is corrected with a proper entry, or because an adjustment is recorded by one person and approved by a second

A worked example

Suppose a payment gateway settles less than the ledger expects for the day. The match fails and an exception opens with the gap and the settlement report attached. The treasury analyst who owns gateway accounts sees that the gateway deducted a fee the fee rules did not anticipate. Instead of overwriting the balance, she proposes a fee entry with the settlement report as evidence. A controller approves it, the entry posts, the exception closes, and the audit trail shows who did what and why. If the fee rule itself was wrong, a new version of the rule is issued so that tomorrow's close matches automatically

The rule that matters most is simple: no exception is ever closed with a manual number that has no source. Adjustments are allowed, but only with evidence and a second approver

Treasury management on top of a reconciled ledger

Treasury management is only as good as the balances it starts from. Once the daily close has matched the ledger to its sources, the treasury view can show a cash position the finance team can actually rely on, alongside what is about to leave and arrive

• Cash position by location, currency and economic class, with every figure carrying its source and time
• Obligations and their due dates: payables, payroll, taxes, partner settlements and recurring bills
• Expected receipts from open invoices and their ageing
• Coverage: whether available cash meets obligations over the coming days, and where it falls short

Payment schedules with dual control

From that view, the system can propose a payment schedule that orders obligations by due date and available funds. The proposal is exactly that, a proposal. A person reviews it, and payments above defined limits need two separate people, one who records and one who approves. Payments and currency conversion run only through licensed providers in supported jurisdictions; Arfinex prepares, records and reconciles, but it is not a bank or a payment institution. The payments, invoicing and corporate treasury service covers this cycle from invoice to settlement

For groups operating in several currencies, the treasury view also depends on a consistent rate source and clear revaluation rules, which belong to multi-currency accounting as much as to treasury

What to automate and what to keep human

Automation earns its place where the work is repetitive, rule-based and testable. Judgement stays with people, especially where money moves or the books change. In practice, software should handle

• Reading sources, recording witness balances and applying the cutoff
• Matching under defined rules and tolerances
• Calculating totals, rates, fees and postings with deterministic, testable code
• Opening exceptions, assigning owners by rule and tracking their age
• Drafting the morning report and a proposed payment schedule
• Watching source freshness and alerting when a feed stops or a queue grows

People should keep the decisions that carry accountability

• Approving adjustments, opening balances and post-hoc rate changes
• Approving payments and transfers above limits
• Reopening a closed period
• Changing matching rules and tolerances
• Deciding the cause of an unusual exception when the evidence is ambiguous

AI can help here, for instance by suggesting a likely cause or drafting the commentary on an exception, but its output is labelled as a proposal and never posts on its own. Our article on AI financial reporting with human approval explains where that boundary sits. Continuous live monitoring with actionable alerts complements the close by telling you during the day that a source has gone silent, rather than at night when the close cannot complete

Implementation: from mapping sources to a parallel run

Reconciliation automation most often fails because it is switched on before anyone has agreed what a match means. A staged implementation avoids that

1. Map every source: each bank account, gateway, wallet and partner, with its owner, access method, statement format and the ledger account it supports
2. Define the cutoff, the rate source for each currency and how late rows are treated
3. Write matching rules and tolerances per source, for example an exact match on reference and amount, or a small rounding tolerance for currency conversion, and have the controller approve them
4. Set exception owners, ageing thresholds and escalation paths
5. Build and test in a sandbox with synthetic or anonymized data
6. Run in parallel with the current method and compare outputs every day until they match, investigating every difference in both directions
7. Go live only with the customer's approval, keeping the parallel-run records as evidence

Pitfalls to avoid

• Treating a successful connection as proof that the data is complete
• Tolerances so wide that real errors pass silently
• Exceptions without an owner, which simply grow older
• Closing differences with plug figures to make the report look clean
• Skipping the parallel run under deadline pressure

Local tax and accounting treatment, such as how fees or revaluation differences are classified, should be confirmed by your accountant or local adviser before the rules are fixed

A close you can trust every morning

Reconciliation automation is not about removing people from the close. It is about letting software do the repetitive matching every day, keeping every difference visible with an owner and evidence, and reserving human attention for approvals and judgement. The result is a daily close that does not hide gaps, a cash position with a source and a time behind every figure, and payments that never leave without the right approvals