How AI agents work in accounts receivable

An AI agent in accounts receivable works on a loop: it reads the current state of an account, decides the single next action most likely to move that account toward payment, takes the action across the systems it is connected to, then watches what happens and reads the state again. It repeats this across every open invoice in the ledger, continuously, escalating to a person only when a case needs human judgment.

That loop is the whole difference between an agent and the tools that came before it. A reminder scheduler fires on a calendar. A dashboard shows you the work. An agent does the work, account by account, and is measured on the cash it brings in. The mechanics below are engineered and auditable, not magic, and understanding them is the fastest way to judge whether a vendor is selling a real agent or a relabeled workflow.

The anatomy of an AR agent

An AR agent has four parts that map directly onto the loop.

• Perception. A way to read account state from your ERP, your inbox, and your payment feeds.
• Reasoning. A model that weighs the context and chooses the next best action against your policy.
• Action. Connections that let it send the email, post the cash, or open the dispute in the systems of record.
• Memory and audit. A log of what it read, what it did, and why, so outcomes feed back in and a human can review.

Strip any one of these out and you are left with something less than an agent. Perception without action is a dashboard. Action without reasoning is RPA. Reasoning without memory is an agent that re-learns every account from scratch each morning. The value comes from all four working together on the same loop, which is why a real agent feels less like a tool you operate and more like a worker you supervise.

It helps to picture the loop running on a single invoice. Day one, the agent reads a freshly issued invoice and does nothing but note the due date. Day twenty-eight, it reads the same account, sees the due date approaching and no payment, and sends a short pre-due reminder. Day thirty-five, it reads a reply: the customer is disputing a line item. The agent pauses dunning, routes the dispute, and waits. Day forty-two, the dispute resolves, the agent resumes, and a payment lands two days later. The agent applies it and closes the loop. No person touched any of that, but every step is on record.

Reading account, invoice, and contact context

Before the agent acts, it builds a picture of the account. It pulls the invoice and its age, the customer's payment history, the agreed terms, any open dispute or promise to pay, and the thread of recent contact. It reads inbound email too, so a customer reply saying "we paid this last week" or "this is under dispute" becomes part of the state, not a message sitting unread in a shared inbox.

This is the step most legacy automation skips. A rules engine fires the day-30 reminder whether or not the customer already disputed the charge on day 12. An agent sees the dispute first and does not send the reminder, because the context told it not to.

Reading context also means reconciling sources that disagree. The ERP says an invoice is open, but an email says it was paid last week, and the bank feed shows a deposit that has not been applied yet. A person resolves that by piecing the three together. The agent does the same: it cross-reads the ledger, the inbox, and the payment feed, and forms a single picture of where the account truly stands before it decides anything. The quality of every later step depends on getting this picture right, which is why a serious agent spends most of its effort here, not on writing the email.

Reasoning over the next best action

With the picture assembled, the agent decides. Not from a fixed if-this-then-that table, but by weighing the specific account against your policy and goals. A first-time late payer on a small balance gets a gentle nudge. A serial late payer on a large balance, past terms, with no response to two emails, gets a firmer message and a flag for a call.

The reasoning is bounded by the rules you set: tone limits, contact frequency caps, and the dollar thresholds above which it must ask a person. Inside those bounds it chooses freely, which is what lets it handle cases a script never anticipated. When a case sits outside the bounds, it stops and escalates rather than guessing.

The word "decide" is doing real work here, and it is worth being precise about what it does not mean. The agent is not inventing collections policy. You define the policy, the cadence, the tone ceilings, the escalation rules, and the agent applies judgment within it, the way an experienced collector applies the company's playbook to the account on their screen. Two accounts that look identical on paper can warrant different moves because one replied politely last month and the other ghosted three reminders. A fixed schedule cannot see that difference. The agent can, and that is the whole reason to reason over each account instead of looping the same steps through all of them.

Acting across email, ERP, and payment systems

A decision only matters if the agent can carry it out. So it acts in the systems of record: it sends the reminder, pauses a sequence, applies an incoming payment to the right open invoice, opens or routes a dispute, and writes each result back so the aging report reflects reality. This is where the manual handoffs disappear. The same agent that reads a short payment can code it, route the deduction, and pause dunning on the affected invoice without a person stitching those steps together. The mechanics of matching payments to invoices are covered in what is cash application, and the same loop drives how to handle payment disputes end to end.

Learning from outcomes

Every action produces a result the agent can read. The reminder got a reply, or it did not. The payment landed on the promised date, or it slipped. Those outcomes become memory the agent uses to time and tune its next move on that account, and across similar accounts. A customer who always pays the day after a statement gets a statement, not a chase. The point is not a model that retrains overnight, but a system that does not start from zero on every invoice.

Two kinds of learning are worth separating. Account-level learning is local and immediate: the agent remembers that this customer responds to a phone-style direct tone but ignores soft language, and it adjusts the next message accordingly. Pattern-level learning is broader and slower: across the whole ledger, the agent sees which timing and which channel tend to produce payment for accounts that look a certain way, and it leans on what works. Neither replaces the policy you set. Both make the agent's choices inside that policy sharper over time, the way a collector gets better at a book the longer they work it.

Auditing what the agent did and why

Autonomy in finance is only acceptable if it is reviewable. So the agent logs the context it read, the action it took, and the reason, on every step. A controller can open any account and see the full trail: why dunning paused, why an account escalated, why a payment applied the way it did. That record is what earns the agent more of the ledger over time. It also means the agent's work holds up in an audit the same way a careful analyst's notes would.

How Rex runs this loop across your ledger

Rex is an AI AR agent built on exactly this loop. It reads each account in your ERP and inbox, decides the next best action against the policy your team sets, and acts across email, the ERP, and your payment feeds, continuously, across the whole book. It applies cash, chases what is genuinely overdue, routes disputes, and pauses outreach when a customer has a live objection. When a case crosses a threshold you defined, a strategic account, a large write-off, an ambiguous dispute, Rex stops and hands it to a person with the context already assembled.

Every step is logged with its reasoning, so your team supervises the work instead of doing it, and the agent is measured on the only thing that matters, cash recovered and DSO down. See how Rex runs collections end to end.