Cash application agent
We design, build and deploy an AI agent that reads your bank feed, POS settlements and emailed remittances, fuzzy-matches each receipt to the open invoices it pays — including part-payments and one lump sum covering several invoices — and clears the matched items in your ledger, surfacing only the receipts it genuinely can't place to your finance team.
At a glance
Cash is applied the same day it lands instead of days later, so receivables clear faster (lower DSO), the unapplied cash sitting in a suspense account shrinks, and month-end stops being a scramble.
Fuzzy many-to-one matching across bank, POS and remittance formats, multi-currency (RM/SGD) and part-payments — and it writes the clearing entry into your ledger, so idempotency and the eval bar matter more than for a read-only flagger.
What changes when it works
Time per application
Clearing a receipt by hand
~3–6 min
With the agent
~15–30 sec review (exceptions only)
Time saved
≈ 80–90% of receipts cleared without a human touch — roughly 40–70 hours a month at 1,000–1,500 receipts. And faster application means cash is recognised days sooner: shaving even 2–3 days off DSO frees working capital that dwarfs the monthly AI cost.
Indicative; the actual match rate and time saved depend on receipt volume, how clean your payment references are, and how many payments are part-payments or lump-sums.
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
A finance team in the region downloads the day's bank statement and POS settlement file, then has to work out which customer paid, and which invoice each receipt clears. Most of it is detective work, not judgement — a statement line reads 'PYMT-4471' with no invoice number, a customer sends one round RM 4,300 that actually covers three invoices, another pays RM 500 short because of bank charges. The clerk hunts the open-invoice ledger, reasons out the split, posts the allocation in the ERP — and parks anything they can't identify in a suspense account. It's slow, it backs up, and when it backs up receipts sit unapplied, so DSO looks worse than the business actually is and month-end becomes a scramble to clear the pile.
Stage 2 · Map
The manual workflow today
- 01Download the bank statement / POS settlement file and open the AR ledger
- 02Read each receipt's amount, date and payment reference
- 03Search the open invoices for the customer and the matching amount(s)
- 04Work out part-payments and lump-sums covering several invoices
- 05Post the allocation and clear the invoice(s) in the ERP
- 06Park whatever can't be identified in a suspense / unapplied account
Where it breaks: The slow part is the detective work — a vague reference or a round lump sum has to be reasoned back to the right open invoices — and when it backs up, receipts get parked as unapplied, so DSO looks worse than the business really is.
Stage 3 · Design
The agentic workflow
We build it as a routing workflow: every receipt is first classified — a clean 1:1 match, a lump-sum across several invoices, a part-payment, or an unidentifiable one — and dispatched down the right path. Clean matches run a short chain and auto-clear; anything ambiguous is verified and, if it still can't be placed confidently, routed to your finance team with the agent's best candidate matches attached.
Re-checks the candidate allocation — does the maths reconcile to the cent? — and re-matches before it clears anything; if confidence stays low it routes to a human instead of forcing a match.
Watch a case flow through the agent — it does the reading and matching; a human still makes the decision.
See it in action
In the bank feed
How the agent applies it
- Matched to customer 'Sunrise Enterprise' from the reference and prior payment pattern
- RM 4,300 = INV-1021 (RM 1,800) + INV-1044 (RM 2,000) + RM 500 part-payment of INV-1050
- INV-1021 and INV-1044 cleared in full; INV-1050 part-paid, RM 700 still open
- Nothing left unapplied — the full RM 4,300 is allocated
Every allocation traces to the receipt and invoice IDs · reversible in one step if a human overrides · ~RM 0.05–0.15 per receipt in AI cost.
Step by step
- 1
Read & normalise the receipt
The agent ingests the day's receipts from wherever they land — a bank feed (CAMT/MT940), a CSV, a POS settlement file, or an emailed remittance advice — and normalises each into a common shape: amount, currency, value date, payer and whatever reference text came with it, reading PDFs and images with vision where needed.
- 2
Classify the receipt
It routes each receipt by type — a clean single-invoice match, one lump sum covering several invoices, a part-payment, or one it can't yet identify — because each needs different handling. This is the routing step that keeps the common case fast and the hard cases careful.
- 3
Fuzzy-match against the open ledger
Using the customer's live open invoices and their prior payment pattern, it matches the receipt to the invoice(s) it pays — reasoning past a cryptic reference, a name that doesn't quite match, or a round sum that has to be split across several open items.
- 4
Verify and re-check (the loop)
Before clearing anything it re-checks that the allocation reconciles exactly — the picked invoices sum to the receipt, the currency and open status are right — and re-matches if not. Where it still can't reconcile confidently, it stops rather than force a match.
- 5
Clear the matched items
For confident, reconciled matches it posts the allocation to your ledger and clears the invoice(s) — with an idempotency key so a replayed statement can't double-apply, and as a reversible entry so your team can override it in one step.
- 6
Hand exceptions to a human
Whatever it can't place — an unknown payer, a mismatch, a reference that leads nowhere — is routed to your finance team with the candidates it considered, so the detective work is already done. Nothing is cleared on a guess.
Stage 4 · Build
How we build it with Claude
It works from your live open-invoice ledger, so it matches against what is actually outstanding right now — an invoice already paid or credited can't be matched twice. When it clears an item it writes a structured allocation through a connected tool carrying an idempotency key, so a re-run or a duplicated bank line can't double-apply a receipt, and every allocation is a reversible journal your team can undo in one step. It never moves money — it only allocates receipts you have already banked against the invoices they pay, and it starts in shadow mode, proposing matches for a human to confirm until its accuracy on your real receipts has earned the auto-clear.
Integrations
- Bank feed / statement import (CAMT / MT940, CSV or PDF remittance)
- POS settlement / payment-gateway payout files
- ERP / accounting ledger (AR open items, cash posting)
Under the hood
- Pattern: a routing front-end on the Claude Agent SDK dispatches each receipt (clean 1:1 · lump-sum · part-payment · unidentified) into a short per-type chain; each tool is exposed via an in-process MCP server.
- Context: the customer's live open-invoice ledger and their recent payment history are loaded per receipt, so matching is against what is outstanding now and informed by how this payer usually pays — their references, rounding, and which entity they settle to.
- Tools: read-only open-AR and payment-history lookups, a normaliser for bank/POS/remittance formats, a deterministic allocation solver (which open invoices sum to this receipt), and one write tool that posts an allocation to the ledger — no tool can move money or create, edit or delete an invoice.
- Idempotency & reversibility: every posting carries an idempotency key (bank-line ID + amount + value date) so a replayed statement or duplicated feed can't double-apply, and each allocation is a single-step reversible journal, never a silent overwrite.
- Guardrails & gate: auto-clear fires only above a confidence threshold and only when the allocation reconciles to the cent; part-payments, over-payments, FX rounding beyond tolerance and anything below threshold route to a human queue with candidate matches attached — never a forced match.
- Untrusted input & PDPA/PDPC: statement narratives and remittance emails are treated as untrusted text (a crafted reference can't steer a match), and bank details, customer names and amounts are handled PDPA/PDPC-aligned across the MY and SG entities.
- Multi-currency: RM and SGD receipts are matched in each invoice's currency using the booked FX, with a tolerance for bank charges and rounding, so a receipt short by a few cents of fees still clears cleanly.
- Observability & audit: every match decision, the candidates considered, and each posting or reversal are logged and traceable to the bank-line and invoice IDs — a machine-readable audit trail suited to Finance controls and an external audit.
- Eval harness: a golden set of real historical receipts — clean, lump-sum, part-paid, mis-referenced and unidentifiable — with deterministic reconciliation checks plus an LLM-as-judge on the fuzzy calls, regression-tested before any change touches live posting.
Stage 5 · Architect
Single model or multi-agent?
Applying a receipt shares one context — the receipt and the customer's open items — so a single well-instrumented model runs the judgement, with cheaper Haiku on the many clean matches and Opus reserved only for the tangled ones. Reliable, cheap per receipt, and easy to audit.
We reserve multi-agent designs (≈15× the tokens) for genuinely parallel, breadth-first work — not for a single receipt-to-invoice reconciliation.
Which model does what
Classify & fuzzy-match receipts to invoices
Reads messy references and reasons out lump-sums and part-payments — the core judgement, at moderate cost.
High-volume clean 1:1 matches
Most receipts are a clean single-invoice match; cheapest and fastest for the bulk of the volume.
Normalise varied statement / remittance formats
Structured extraction from CSV / MT940 / PDF lines — a light, high-frequency task.
Resolve tangled or disputed allocations
Invoked only for the hardest lump-sums and disputes Sonnet flags — a small fraction of receipts.
What it costs — an estimate
AI usage — per receipt
normalise + match + verify + posting, mostly at Claude Haiku/Sonnet token rates
~RM 0.05–0.15
AI usage — at 1,500 receipts/month
lower again with the Batch API for end-of-day, non-urgent runs
~RM 75–225 / month
Build (one-off)
connecting your bank feed, POS payouts and ERP posting is a few weeks; we quote fixed after a short discovery
scoped per integration
Ongoing
small next to the working capital freed by even a couple of days lower DSO
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 receipt volume, how many are part-payments or lump-sums, and how clean your references are. 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 the allocation sum exactly to the receipt, is the invoice actually open, is the currency right
- Self-verification — the agent re-checks the maths and re-matches before it clears, and queues rather than force a match
- Business KPIs — auto-match rate, cash-application time, unapplied-cash balance, DSO
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 cash application on a sample — time per receipt, what share you match automatically today, how much sits unapplied at month-end, and how often two clerks allocate a tricky receipt the same way. 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
Allocation vs a senior AR clerk
Its cleared/queued decision and the invoices it picks agree with an expert's on held-out receipts
Required checks executed
Every candidate check is run — customer, amount, reference, open status, currency — nothing skipped
No forced matches
It queues rather than guess when candidates don't reconcile to the receipt
Allocation accuracy
The invoices and amounts it clears are exactly right, to the cent
Auto-match rate
Share of receipts cleared without a human, at the accuracy bar
Mis-application rate
How often it clears the wrong invoice
No unapplied leakage
Every cleared receipt is fully allocated to the cent — no stray balance
The go-live gate
The agent does not post to a live ledger until it beats the human baseline and clears these GPA targets on a golden set of historical receipts — clean, lump-sum, part-paid and mis-referenced. Auto-clear starts in shadow mode (it proposes, a human confirms) and only goes live per receipt-type once its accuracy holds. 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 bank statements and open-invoice ledger — including the lump-sums and mis-referenced payments — running in shadow mode so you can see its matches before it clears anything. A focused single-account rollout is a matter of weeks.
Free consultation
Is your team clearing bank receipts by hand?
Tell us your receipt volume, banks and ERP, and we'll tell you honestly whether a cash application agent is worth building — and what auto-match rate to expect.
Related use cases
Frequently asked questions
- Does the agent move or touch our money?
- No. It never initiates a payment or transfer. It only allocates receipts you have already banked against the open invoices they pay, and posts that allocation in your ledger — every posting is reversible in one step, and money movement is never in scope.
- How does it handle one payment covering several invoices, or a part-payment?
- That's the core of it. It reasons a lump sum back to the invoices that sum to it, splits a part-payment against the right invoice and leaves the balance open, and where the maths doesn't reconcile it queues the receipt with its best candidates rather than forcing a match.
- What about receipts it can't identify?
- They don't get guessed. Anything below the confidence bar — a cryptic reference, a mismatch, an unknown payer — is routed to your finance team with the candidates the agent considered: the same ones that would have sat in unapplied cash anyway, but with the detective work already done.
- Does it work across Malaysia and Singapore and multiple currencies?
- Yes. It matches RM and SGD receipts in each invoice's currency using the booked FX with a tolerance for bank charges, and it handles both entities' ledgers. 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 bank account or entity is usually a matter of weeks, running in shadow mode first; a full rollout takes longer — mostly ERP posting integration and your team getting comfortable letting it auto-clear, 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.