Bank reconciliation agent
We design, build and deploy an AI agent that reconciles your bank statement against the cash book or general ledger — matching every line both ways, auto-posting bank-only items like charges and interest, explaining timing differences such as unpresented cheques, and producing a reconciliation that balances to zero — surfacing only the genuine discrepancies for your controller to resolve.
At a glance
Month-end close stops waiting on a manual reconciliation, bank charges and errors are caught the same day, and an unexplained difference — the thing that hides a missing entry, a duplicate, or fraud — is investigated instead of forced to balance.
Two-sided matching across varied statement formats and the cash book, timing-difference logic, and it posts bank-only items to the GL — so the balancing bar, idempotency and the eval bar matter more than a one-way flagger, though a human still approves the postings.
What changes when it works
Time per application
Reconciling an account by hand
~30–90 min per account
With the agent
~5 min review (exceptions only)
Time saved
≈ 25–85 minutes per account each cycle — and across many accounts at month-end that's days of controller time back — while a single caught error, duplicate payment or fraudulent debit can outweigh the whole AI cost for the month.
Indicative; the actual time and match rate depend on the number of accounts, transaction volume, how clean your cash-book references are, and how many bank-only items recur.
Our agentic development process
Every use case follows the same seven stages — from framing the problem to production.
Our process, built on Anthropic's agent guidance and the Agent GPA eval framework: Building Effective Agents · Agent GPA
Stage 1 · Frame
The business problem
Finance downloads each bank statement, opens the cash book or general ledger, and ticks off every line — matching receipts and payments both ways, spotting the bank charges and interest that were never booked, working out which cheques haven't cleared yet and which deposits are still in transit, and chasing any difference that won't balance. Across many accounts at month-end it's a slog, and under deadline pressure the temptation is to plug the last unexplained difference to a suspense line just to make it balance. That plug is exactly how a missing entry, a duplicate payment, or a fraudulent debit gets buried — the reconciliation is meant to be the control that catches them, and manual, rushed reconciliation is where the control quietly fails.
Stage 2 · Map
The manual workflow today
- 01Download each bank statement and open the cash book / GL
- 02Tick off matching lines both ways — receipts and payments
- 03Spot bank-only items — charges, interest, FX — never booked
- 04Work out timing differences — unpresented cheques, deposits in transit
- 05Chase and explain any difference that won't balance
- 06Post the adjustments and file the reconciliation statement
Where it breaks: The slow, thankless part is ticking hundreds of lines and hunting the last stubborn difference — and under deadline that difference gets plugged to a suspense account just to balance, which is exactly how a missing entry or a fraudulent debit stays hidden.
Stage 3 · Design
The agentic workflow
We build it as an evaluator-optimizer workflow: the agent matches the statement to the cash book, then evaluates the one thing that matters — does the reconciliation balance to zero, with every residual explained? If a difference is unexplained, it loops back to re-match, post the bank-only items and classify timing differences, refining until the statement balances or what's left is a named, evidenced exception for a human — never a plug.
If the reconciliation doesn't balance, it loops back to re-match, hunt the missing or duplicated entry and re-classify timing differences — refining until it balances or the residual is a named exception, never plugged to suspense.
Watch a case flow through the agent — it does the reading and matching; a human still makes the decision.
See it in action
Statement vs cash book
How the agent reconciles it
- 40 lines matched both ways; the RM 3,365 gap traced to 3 reconciling items
- Deposit in transit RM 3,300 — banked 30 Mar, not yet on the statement; timing difference, not an error
- Bank charges RM 105 and interest RM 40 — bank-only, drafted as GL postings for approval
- Bridge: 131,905 − 105 + 40 − 3,300 = 128,540; residual RM 0.00
Every reconciling item cites the statement line and cash-book entry · postings approved by your controller · ~RM 0.15–0.40 per account per cycle in AI cost.
Step by step
- 1
Ingest the statement and the cash book
The agent takes the bank statement in whatever form it arrives — a bank feed (CAMT/MT940), a CSV, or a PDF — and the cash-book or GL entries for the period, normalising both into a common shape: date, amount, direction, counterparty and reference, reading PDFs with vision where needed.
- 2
Match every line, both directions
It matches statement lines to cash-book entries in both directions — receipts and payments — exact where it can and fuzzy on date, amount and reference where it can't, so a payment recorded a day early or under a slightly different reference still ties out.
- 3
Post bank-only items and classify timing differences
For lines on the statement but not the books — bank charges, interest, FX, transfers — it drafts a GL posting for approval. For lines in the books but not yet on the statement — unpresented cheques, deposits in transit — it classifies them as timing differences and carries them forward, not as errors.
- 4
Evaluate and refine (the loop)
It checks the one thing that matters: does the reconciliation now balance to zero with every residual explained? If not, it loops back — re-matching, hunting a missing or duplicated entry, re-testing a timing classification — refining until it balances or the difference is isolated to a named exception.
- 5
Produce the reconciliation, flag discrepancies
It outputs the reconciliation statement — the bridge from cash-book balance to bank balance with every reconciling item evidenced — and a short list of genuine discrepancies to look at: an unmatched debit, a duplicate, a wrong-amount match, anything out of pattern.
- 6
Hand to a human
Your controller reviews the flagged discrepancies and approves the drafted postings. Nothing is posted to the live ledger automatically, and no difference is ever plugged to force a balance.
Stage 4 · Build
How we build it with Claude
It reconciles to zero or it doesn't finish — where a difference can't be explained it surfaces a named exception rather than plugging it to a suspense line to force a balance, which is the whole point of the control. It works from your live cash book and the actual statement, matching against real entries, and it posts bank-only items only as a draft your controller approves, each carrying an idempotency key so re-running a statement can't double-post charges or interest. Every reconciling item — a matched line, a timing difference, or a flagged discrepancy — cites the exact statement line and cash-book entry it came from, so the reconciliation is reconstructable end to end.
Integrations
- Bank statement import (CAMT / MT940, CSV or PDF) across your accounts
- General ledger / cash book (your accounting system)
- Optional: the cash-application feed, so applied customer receipts match cleanly
Under the hood
- Pattern: an evaluator-optimizer loop on the Claude Agent SDK — match → evaluate 'does it balance and is every residual explained?' → refine — with each tool exposed via an in-process MCP server.
- Context: the actual bank statement and the live cash-book / GL entries for the period are loaded per run, so matching is against real, current entries and the reconciliation reflects today's books rather than an export.
- Tools: read-only statement and cash-book lookups, a two-way line matcher (exact plus fuzzy on date/amount/reference), a timing-difference classifier (unpresented cheques, deposits in transit), and one write tool that only drafts GL postings for bank-only items — no tool can plug a suspense balance or edit a matched entry.
- The balancing gate: the run completes only when the reconciliation balances to zero with every residual explained, or when the unexplained difference is isolated to a named, evidenced exception — it is structurally unable to force a balance by plugging.
- Idempotency: every GL posting carries an idempotency key (statement-line ID + amount + date) so re-running a statement or a re-import can't double-post charges, interest or FX.
- Guardrails: least-privilege — the agent drafts postings and a controller approves; it cannot move money, delete entries, or write outside the bank-only posting set; schema-locked output.
- Fraud & error surfacing: unmatched debits, duplicates, wrong-amount matches and out-of-pattern items are raised as discrepancies with evidence, never absorbed into a balancing figure — the control's real purpose.
- Observability & audit: every match, timing classification, posting and the final reconciliation statement is logged and traceable to its source lines — a machine-readable audit trail for Finance controls and external audit.
- Eval harness: a golden set of real historical reconciliations — clean, timing-heavy, and seeded with errors, duplicates and fraudulent debits — with deterministic balance checks plus an LLM-as-judge on the fuzzy matches, regression-tested before it posts to a live GL.
Stage 5 · Architect
Single model or multi-agent?
A reconciliation shares one context — the statement and the cash book for that account and period — so a single well-instrumented model runs the matching and the balancing loop, with cheaper Haiku on the many exact matches and Opus reserved only for a difference that won't resolve. Reliable, cheap per account, and easy to audit.
We reserve multi-agent designs (≈15× the tokens) for genuinely parallel, breadth-first work — not for a single account's reconciliation.
Which model does what
Match & reconcile statement to cash book
The core two-way reasoning across dates, amounts and messy references, at moderate cost.
High-volume exact-line matching & normalisation
Most lines match exactly; cheapest and fastest for the bulk and for parsing statement formats.
Classify timing differences & bank-only items
Deciding unpresented-cheque vs deposit-in-transit vs a genuine miss needs real reasoning.
Hunt stubborn unexplained differences / suspected fraud
Invoked only when the reconciliation won't balance after refinement — a small fraction of runs.
What it costs — an estimate
AI usage — per account, per reconciliation
statement + cash-book context + two-way matching + balancing loop + postings, at Claude Sonnet/Haiku rates
~RM 0.15–0.40
AI usage — 50 accounts reconciled daily
lower with the Batch API for overnight month-end runs
~RM 300–800 / month
Build (one-off)
connecting your bank feeds and GL is a few weeks; we quote fixed after a short discovery
scoped per integration
Ongoing
small next to a single caught duplicate payment or fraudulent debit a month
monitoring + support
Indicative only, shown in Ringgit at roughly RM 4.70 to the USD; per-token rates follow Anthropic's published pricing (confirm current figures). Actual AI usage depends on the number of accounts, transaction volume and how many timing differences recur. You can model the same figures in SGD or your currency with our Claude cost calculator.
Stage 6 · Evaluate
How we measure success
- Deterministic checks first — does it balance to zero, is every reconciling item evidenced, do the postings equal the bank-only total
- Self-verification — the agent won't finish on an unexplained difference; it loops or flags, and never plugs to suspense
- Business KPIs — time per reconciliation, share auto-reconciled, unexplained-difference rate, days to close
We score the agent with the Agent GPA framework — Goal, Plan, Action, a current standard for agent reliability — on top of the human baseline. (reference)
Setting the baseline
First we measure your current reconciliation on a sample — time per account, how consistently two accountants reconcile the same account, and how often a difference gets plugged to suspense today. That human baseline is what every agent metric is measured against, so the lift is provable rather than assumed.
What we test — Goal · Plan · Action
Reconciliation vs a senior GL accountant
Its matched set, reconciling items and flagged discrepancies agree with an expert's on held-out accounts
Balances or isolates — never plugs
It reaches a zero balance with every residual explained, or isolates a named exception
Required checks executed
Both-way match, bank-only posting and timing classification all run — nothing skipped
Line-match accuracy
Matched statement and cash-book lines are genuinely the same transaction
Discrepancy recall (catch rate)
Of the seeded errors, duplicates and fraudulent debits, how many it flags
Posting accuracy
Bank-only postings are the right amount, sign and GL account
No forced balances
An unexplained difference is never absorbed into a plug to make it balance
The go-live gate
The agent does not post to a live GL until it beats the human baseline and clears these GPA targets on a golden set of historical reconciliations — including timing-heavy months and seeded errors, duplicates and fraudulent debits — running in shadow mode first. Every change is regression-tested against the same set before it ships.
Stage 7 · Deliver
How we'd deliver it
We start with a proof-of-concept on your real historical statements and cash book — including the timing-heavy months and, seeded in, the errors and duplicates — running in shadow mode so you can see its reconciliations before anything is posted. A focused single-account rollout is a matter of weeks.
Free consultation
Still reconciling bank accounts by hand?
Tell us how many accounts you reconcile, your banks and your accounting system, and we'll tell you honestly whether a bank reconciliation agent is worth building — and how much it could auto-reconcile.
Related use cases
Frequently asked questions
- How is this different from the cash application agent?
- The cash application agent matches incoming customer receipts to open invoices (the accounts-receivable side). The bank reconciliation agent reconciles the whole bank statement against your cash book or GL — both directions, bank charges and interest, timing differences — and produces the reconciliation statement. They're complementary: the cash-application agent can feed clean applied receipts into the reconciliation.
- Does it move money or change our ledger on its own?
- No. It drafts bank-only postings — charges, interest, FX — for a controller to approve, and it never moves money, deletes entries, or plugs a suspense balance. A human approves every posting; the agent's job is to reconcile and evidence, not to write to the ledger unsupervised.
- What happens when it can't make it balance?
- It won't force it. An unexplained difference is isolated and surfaced as a named, evidenced exception — the missing entry, the duplicate, the suspicious debit — which is exactly the point of the control. It never plugs a difference to suspense to hit a deadline.
- How does it handle unpresented cheques and deposits in transit?
- It classifies them as timing differences, not errors — showing them on the reconciliation and carrying them forward until they clear, kept distinct from a genuine discrepancy that needs action.
- Does it work across Malaysia and Singapore, multiple banks and currencies?
- Yes. It reconciles multiple bank accounts, in RM and SGD, across varied statement formats (CAMT/MT940/CSV/PDF); FX differences are reconciled with the booked rate and a tolerance for charges. Treat tax and audit specifics as a starting point for your finance team, not accounting advice.
- How long does it take to deploy?
- A proof-of-concept on one account is usually a matter of weeks, running in shadow mode first; a full rollout across accounts takes longer, mostly bank-feed and GL integration and getting your finance team comfortable, not the AI.
Examples are based on real, anonymised engagements; details are generalised. Anchor Sprint is a member of the Anthropic Claude Partner Network — a deployment and rollout partner, not a reseller. This is general information, not legal or compliance advice.