Menu
Claude Enterprise Training Claude Code Consulting AR Agent Products About Workflow implementation AI agent consulting All services Case Studies Resources Industries Why us Founders Contact Schedule video call

For controllers and shared-service finance teams

Your AR ledger, tied out before you open it

Cash application, short-pays, unapplied cash and the aged list — the part of the receivables close that no rule has ever finished. An agent that reads the remittance, proposes the match, and hands a person everything it could not settle on its own.

  • Cash application across split, lumped and short-paid receipts
  • An exception queue ordered by value and age, with the evidence attached
  • Nothing reaches the ledger until a person approves it
Open the working demo
Claude Partner Badge — Claude Code
Claude Partner Network Finance Agents
Built as an engagement, not a licence
Working demo · live Open in new tab ↗

CashApp, running the same flow end to end on dummy bank and open-AR files. Sample numbers, real mechanism.

Receivables is one of the few finance processes where an agent has an unfair advantage: the volume is high, the context is written down somewhere, and the right answer is checkable against a ledger that already closed. That last part matters more than the first two — it means the work can be evaluated instead of believed.

This is a build engagement, not a product licence. It runs on the AR data you already have, inside the approval structure your controller already owns, and it is scoped the same way as the rest of our AI agent consulting and workflow implementation work. Focus20 Labs is a Claude Partner Network member, delivering to teams in India, Germany and globally.

There is a working example you can click through rather than take on trust: CashApp, a reconciliation dashboard running the same ideas end to end — bank feed ingestion, a work queue, matching against open AR, then an exception queue with suspense and disputes behind it. It runs on dummy bank and open-AR files, so treat the numbers on it as sample data and the flow as the real thing.

We have shipped reconciliation agents against property and trading ledgers — see AI for property management for that work. An AR pilot starts where any honest one should: one real month you already know the answers to.

The agents

Four jobs, named separately

Receivables is not one task, and one undifferentiated “AI for finance” is how automation projects end up owning none of it. Each agent below has a single job, its own definition of done, and its own escalation path.

Matching

AR Reconciliation Agent

Ties receipts to open invoices and keeps the sub-ledger agreeing with the bank. Where the two disagree it says why, rather than closing the gap quietly.

Cash application

Cash Application Agent

Reads the remittance — PDF, spreadsheet or email body — and applies one payment across the invoices it actually settles, including split and lumped receipts.

Exceptions

Exception Agent

Owns everything the ladder could not settle. Traces likely origin, attaches the history, and refuses to let an unmatched item age quietly into the write-off pile.

Collections

Collections Agent

Keeps a worklist ordered by value, age and payment behaviour, and drafts the follow-up per account for a person to send.

How it works

Three stages, and one of them is yours

Data comes in from systems you already run, the agent proposes, and what goes back is reviewed before it lands. The third column is the one that keeps this defensible.

Stage one

Connected sources

  • Open AR from your ERP or accounting system
  • Cleared bank transactions
  • Remittance advices, however they arrive
  • Prior disputes, deductions and payment behaviour
Stage two

The agent reasons

  • Works the match ladder, exact first
  • Reads unstructured remittance text
  • Traces a short-pay to its deduction
  • Scores its own confidence, and says when it is low
Stage three

Outcomes, once approved

  • Proposed applications, with the reasoning attached
  • An exception queue a person actually works
  • Drafted chasers and dispute notes
  • An audit trail of every approval and override
Overheard · then reconciled

Things AR Analysts Say Every Close

Every receivables close comes with the same familiar phrases — and the hours of digging that follow. On the left, what actually gets said. On the right, the agent that ties it out.

Open

“The customer paid.”

They paid £8,410 against an invoice for £8,900. Nobody coded the difference, so it sits in AR as a live receivable that will never arrive.

AR Reconciliation Agent Cleared ✓

Reads the remittance advice, ties the short-pay to the deduction it belongs to — a promotional allowance, a freight claim, a credit already raised — and proposes the write-off or the dispute for approval.

Open

“It's all in the bank feed.”

One ACH lands for £61,240. It covers fourteen invoices, two of them partial, and the reference field says “PAYMENT”.

Cash Application Agent Cleared ✓

Splits the lump across the open invoices it actually settles, using the remittance, the amounts and the aging pattern — and shows its working for every line it applied.

Open

“That one's on the aged list.”

It has been on the aged list for eleven months. The context that would explain it left with the analyst who understood it.

Exception Agent Cleared ✓

Never lets an unmatched item quietly age. It surfaces each stale receivable with its full history, traces the likely origin, and drafts the chaser or the clearing entry.

Open

“We'll chase them next week.”

Next week is the same fifty accounts, prioritised by whoever shouted loudest rather than by what is actually collectable.

Collections Agent Cleared ✓

Keeps a live worklist ordered by value, age and payment behaviour, and drafts the follow-up per account — in the tone that account has responded to before.

Open

“Unapplied cash is only a few lines.”

Until quarter end, when a few lines is forty-one and none of them can be closed without three people agreeing what they were for.

Cash Application Agent Cleared ✓

Works unapplied cash down continuously instead of at quarter end, proposing the application with its evidence chain and escalating only what genuinely needs a human decision.

The match ladder

Easy first, then the long tail

Nothing is guessed. Each rung is tried in order, and whatever survives all of them becomes an exception with a name on it rather than a silent mismatch.

How a payment gets matched

  • Exact — invoice number and amount agree. Cleared without ceremony.
  • Reference — a PO, account or customer reference resolves it, including references typed by hand into a payment narrative.
  • Remittance-led — the advice is read from PDF, spreadsheet or email body, and the invoices it names are settled against it.
  • Split and lumped — one payment across many invoices, or many payments against one, reconstructed from amounts, dates and aging.
  • Partial and short-pay — the gap is traced to a deduction, credit or claim rather than left as a live receivable.
  • Exception — everything else, queued with its evidence for a person.

What the agent produces

  • A proposed application per payment, with the reasoning attached
  • An exception queue ordered by value and age, not arrival
  • Drafted chasers and dispute notes, per account, for review
  • A plain-language rationale and evidence chain on every proposal

Delivery modes

Controls

Where the human stays

An AR agent that can post unattended is not a productivity gain, it is an audit finding. The control structure is part of the build, not a setting discovered afterwards:

  • Nothing posts without approval. The agent proposes; a person accepts. One-click for the confident majority, and a queue for everything else.
  • You set the thresholds. Write-off limits, credit tolerances and the confidence line above which a proposal is one-click are yours to set before anything goes live, and yours to move.
  • Every proposal carries its evidence. Which remittance, which invoice, which prior behaviour — in plain language, so a reviewer can disagree with the reasoning rather than just the number.
  • Segregation of duties survives. The agent is an analyst, not an approver. It does not gain a permission your own staff would not be given for the same task.
  • Full audit trail. Every proposal, approval, rejection and override is logged with its rationale, which is what makes the process defensible rather than merely fast.

Connectors

What it has to plug into

Grouped by what the connection has to do, not by vendor. The integration is scoped against what you actually run and how it lets data out — which is the real constraint, and rarely the one on the datasheet.

System of record

ERP & accounting

The open-invoice ledger, however it leaves that system — API, scheduled export or file drop. Read access is enough to start a pilot.

Cash in

Banks & lockboxes

Cleared transactions by feed or statement file, including the batched ACH that arrives as one line against fourteen invoices.

Cash in

Payment processors & portals

Card and gateway settlements, and the customer AP portals that hold a remittance behind a login rather than sending it.

The messy input

Remittance sources

PDF attachments, spreadsheets, EDI and plain text in an email body — read rather than re-keyed, which is most of the work.

Where it sits

A reconciliation layer on top of the finance stack you already run. Nothing is migrated and nothing is replaced — the ERP stays the system of record, and the agent is a proposer in front of it.

  • Which ERP: deliberately unnamed here. Bring the stack to the scoping call and we will tell you where the work is.
  • One worked example: the CashApp demo is built against a property ledger, with bank feeds, a work queue, matching, suspense and disputes all wired together.
  • Write access is a separate conversation with its own approvals. A pilot does not need it.
graph TD BANK["Bank Transactions"] --> ING[Ingestion Layer] ERP["Open AR
ERP / Accounting"] --> ING REM["Remittance Advices
PDF / Email / Sheet"] --> ING ING --> AG[Claude AR Reconciliation Agent] AG -->|Proposed application| APR[Approval Queue] AG -->|Exception| REV[Analyst Review] APR --> LEDGER[(Posted to Ledger)] REV --> APR

Plainly

What AR reconciliation automation actually is

Accounts receivable reconciliation is the work of agreeing three things that rarely agree on their own: what you invoiced, what the customer paid, and what the bank says arrived. Automating it has meant rules-based auto-match for twenty years — clear the exact matches, and leave the rest in a queue for a person.

What changes with an agent is the long tail, not the easy majority. A rule cannot read “short paid, freight claim per our email” typed into a payment narrative, or work out that one receipt covers fourteen invoices and two credit notes. A language model can, and can show the reasoning it used. That is the whole of the difference, and it is why the honest measure of one of these systems is the exception rate rather than the match rate.

It is also why this is sold as a build engagement rather than a licence. The work is in your remittance formats, your deduction codes and your approval thresholds — none of which arrive in a box. Related reading: AI agent consulting, workflow implementation, and reconciliation for property management.

How it starts

A month you already know the answers to

The pilot runs against one real, already-closed month of your own AR. Because the month is closed, every proposal the agent makes can be checked line by line against what your team actually decided — matches it got right, matches it got wrong, and exceptions it correctly refused to guess at. That is a measurement, not a demo, and it is the only honest basis for deciding whether a build is worth doing.

We will tell you if the answer is no. The most common reason is not the model: it is that open AR lives across several spreadsheets with no single source of truth, in which case the first project is a data one and we would rather scope that than pretend otherwise.

Before you ask

Questions a controller asks

Does the agent post to our ledger on its own?

No, and that is a design decision rather than a limitation. The agent proposes — a match, an application, a write-off, a chaser — and a person approves before anything reaches the ledger. You set the thresholds that decide what can be approved in one click and what has to be argued about first. An agent with unattended write access to AR is a control failure, not a feature.

How is this different from the auto-match already in our ERP?

Rules-based auto-match clears the easy majority and then stops. What it leaves behind is the long tail that consumes the close: short-pays with no code, lumped ACH batches, remittances that arrive as a PDF attachment, references typed by a human in a hurry. The agent reads that context the way an analyst does. It is a layer on top of the matching you already have, not a replacement for it.

What does it need access to?

Open AR from your ERP or accounting system, the bank transactions, and wherever remittance advices land — commonly an inbox with PDF and spreadsheet attachments. Read access is enough to start; write access is a separate conversation with its own approvals, and a pilot does not need it.

We have not automated anything in finance before. Is this the wrong first step?

Possibly, and we would rather say so during scoping than after. AR reconciliation is a good candidate because the work is high-volume, the right answer is checkable, and a wrong proposal is caught by the approval step rather than by a customer. If your AR data is scattered across spreadsheets with no single source of open invoices, that gets fixed first, and it is a data project rather than an agent one.

What does it cost?

There is no per-seat licence, because this is not a product being resold — it is scoped per engagement, against the pilot first and the build second. What moves the number is the number of source systems, how cleanly open AR leaves your ERP, and how much of the remittance flow arrives as unstructured documents. We would rather quote that after a scoping call than publish a figure that turns out to mean nothing for your stack.

How does this hold up in an audit?

The control that matters is that the agent proposes and a person approves, so every ledger entry still has a human decision behind it. Each proposal is logged with its evidence chain and plain-language rationale, and every approval, rejection and override is recorded. In practice that is a better trail than manual matching leaves, because the reasoning is written down rather than remembered.

Can we see it working before committing to anything?

Yes. There is a clickable demo at cashapp.focus20labs.com running the full flow — bank ingestion, work queue, matching against open AR, then exceptions, suspense and disputes. It runs on dummy files, so the numbers on it are sample data; the mechanism is the real one. After that, the pilot runs the same flow against a closed month of your own ledger, which is the only version of this that proves anything.

What does an engagement look like?

A scoping conversation, then a pilot against one real month of your own closed ledger — a month you already know the answers to, so the output can be checked line by line rather than admired. What that shows determines whether there is a build worth doing. It is scoped as a build engagement, and anything we ship is handed over with the code, the docs and a runbook.

AR reconciliation pilot

Bring one month of real AR

Tell us what your close actually looks like and which system open AR lives in. If an agent is the wrong answer for it, that is a short conversation and a useful one.