Automating invoice chasing with an AI agent that reads the replies

Every accounting tool can send a dunning sequence. What none of them do well is the part that actually collects money: reading the reply. "We never got the invoice", "it is with our AP team", "we are disputing line three", and "can we split this over two months" all require someone to understand a sentence and do something specific. That is the work an agent can take, and it is why invoice chasing is one of the highest return email use cases in a company.

25 July 2026 · 6 min read

Why blind sequences underperform#

A fixed reminder schedule treats every unpaid invoice as the same event. In reality overdue invoices fall into a handful of buckets, and each has a different next action.

A sequence can only produce the left column. An agent that reads the reply can produce the right one, and can do it the same day rather than at the next scheduled step.

Set it up as a reply-first workflow#

The agent needs an address on your domain, something like billing@agents.yourcompany.com, with its own identity and key. Setup is the quickstart, and the reasons not to run this from a finance team's shared mailbox are in agent inbox or shared mailbox: you want every message attributable, and you want the ability to revoke this agent without disturbing anyone's personal login.

Most of the traffic here is replies, which is the safest and most deliverable category of mail there is. The first reminder is technically first contact, but it is contact with an existing customer about a commercial relationship they entered, which is a very different thing from cold outreach. Keep it on the same authenticated subdomain as the rest of your agent mail, per deliverability for agent senders.

The chase, with judgement in the loop#

1. Your billing system flags an overdue invoice and calls the agent, or posts to it. The agent does not decide what is overdue; your ledger does.
2. The agent checks context first. lookup_contact for who this is and what was recorded before, search_inbox for prior threads about this invoice or this account. Remittance advice and disputed invoices usually arrive as files, so see attachments. An account that disputed something last quarter should not receive a cheerful first reminder.
3. It sends a short, specific message. Invoice number, amount, due date, payment link, one question.
4. It waits. wait_for_reply holds the thread open for days without a polling loop.
5. It classifies the answer into the buckets above and takes the matching action: resend, supply a reference, route to a new contact, or escalate.
6. It records the outcome on the contact and stops. A resolved thread should never receive the next scheduled reminder, and this is the single most common failure of tool-driven dunning.

send_email {
  to: ["ap@customer.com"],
  subject: "Invoice 2291, due 8 July",
  body: "Invoice 2291 for EUR 4,800 was due on 8 July and is still showing as unpaid.\n\nPayment link: https://pay.example.com/2291\n\nIf it is already scheduled, just reply with the date and I will note it. If it needs a PO number, tell me and I will add it."
}

Two useful details in that message. It gives an easy out that is not payment ("reply with the date"), which converts silence into information. And it pre-empts the single most common blocker, the missing PO, instead of waiting a week to discover it.

Tone escalates slowly, and stops before it gets ugly#

The relationship is worth more than the invoice in most cases, so the ladder should be shallow and finite: a neutral reminder, a specific follow-up, a firmer note that references the terms, then a human. The agent should never threaten collections, never mention legal action, and never apply late fees on its own. Those are commercial decisions with consequences, and they belong to a person who owns the account.

The things that must escalate immediately#

• Any dispute about the work, the amount, or the contract.
• Any mention of insolvency, administration, or a payment plan.
• Any request to change bank details, in either direction. This is the classic invoice fraud vector and no agent should touch it.
• Any customer who asks for a person.
• Anything above an amount you set.

The same rule applies on the buying side, where the coordination work is covered in chasing quotes and vendors. The bank details rule deserves emphasis. Payment redirection fraud usually arrives as a polite email about updated account information, and it is convincing precisely because it looks like routine AP correspondence. The agent's only correct response is to escalate, and your process should require out-of-band verification by a human.

Firms that bill by the hour have the same shape one step earlier, in intake and document chasing, covered in client intake for a firm that bills by the hour.

Keep secrets out of the conversation#

Agents doing finance work often need credentials: a portal login, an API token, a one-time code. Never put those in a prompt or a message body. The vault holds them encrypted at rest and grants them per agent, so get_secret opens only what this agent was given and get_totp_code clears a two-factor prompt without a person relaying digits. An agent that was not granted a secret cannot see that it exists. Details in contacts, notes, and vault.

What it is worth#

Two numbers move. Days sales outstanding drops, because the median reply is handled the day it arrives instead of at the next scheduled step. And the proportion of invoices that need a human at all falls, because the "nobody saw it" and "needs a PO" buckets, which are most of them, resolve without one.

What does not change is the hard cases: real disputes and real cash flow problems still need a person, and should reach that person faster and better briefed than they do today. The full use case, including what your finance team sees, is on the invoice chasing page.

Questions#

Can an AI agent chase overdue invoices by email?

Yes, and the valuable part is not the reminder, it is reading the reply and doing the right thing with it: resending to the correct AP contact, supplying a PO reference, or escalating a dispute to the account owner the same day.

How is this different from dunning in my accounting tool?

Dunning sends on a schedule and stops thinking when someone answers. An agent classifies the reply and acts on it, which is where most unpaid invoices are actually resolved.

What should never be automated here?

Disputes, payment plans, late fees, legal or collections language, and anything involving a change of bank details. That last one is a common fraud vector and must be verified by a person out of band.

Will chasing emails hurt our sending reputation?

Not materially. These go to existing customers about a commercial relationship, in threads that get replies. Send from an authenticated agent subdomain and suppress on bounces, as covered in deliverability for agent senders.

How does the agent handle credentials for a payment portal?

Through the vault, granted per agent. get_secret opens only what that agent was granted, get_totp_code supplies a second factor, and values are encrypted at rest. Never put a credential in a prompt or an email body.