How to automate invoice chasing with AI

The sequence, before the theory

Start with one invoice and watch what a good chase looks like. Acme Ltd is invoiced for £4,850.00 on 1 September on thirty-day terms, so payment is due on 1 October. Nothing in the sequence below is clever. It is what a diligent credit controller would do by hand, written down so that an agent can do it instead.

1. Day 0: the invoice goes outSent to the named contact with the PDF attached and the due date in the subject line. The record shows sent, not merely created.
2. Three days before due: a courtesy noteShort and friendly: the invoice is due on the date, here is a copy, reply if anything is wrong. Most invoices that were always going to be paid are paid at this point.
3. One day after due: the first reminderPlain and specific: the invoice number, the balance outstanding, the date it was due. No apology and no threat.
4. Seven days after: a second reminder with a statementThe reminder now carries a statement of account listing everything outstanding, in case the real problem is that the customer's own records are behind.
5. Fourteen days after: a person callsThe agent creates a task for the account owner with the history attached. A call at this stage finds out whether the problem is cash, a dispute or a lost invoice.
6. Thirty days after: the escalation decisionThe agent lays out the options (final notice, statutory interest, a hold on new orders) and a person chooses. The agent does not choose.

Read it again and notice the shape. Five of the six steps are routine and follow from the calendar. One is a judgement. That ratio is why invoice chasing is one of the first jobs a business should hand to an agent, and why it is a mistake to hand over the sixth step as well.

A chase is a policy plus a record

Chasing goes wrong in two ways. Either nobody writes the policy down, so reminders go out when someone remembers, in whatever tone they are in that day; or the policy exists but the record is scattered across an accounting package, an inbox and someone's memory, so the reminder that goes out contradicts the payment that arrived yesterday. An agent fixes neither on its own. It needs both to be explicit.

The policy is short. It states the terms, which message goes out at which stage, the tone of each stage, what stops the sequence (payment, a dispute, a promise to pay by a date, a colleague saying leave it) and who the exceptions go to. If you cannot fit it on one page, your agent cannot run it reliably either, because the gaps get filled with guesses.

The record is the harder part, and the part most tooling gets wrong. To chase correctly the agent needs, for every invoice, the balance still due (not the amount invoiced), the named contact and their address, the date it was sent, every reminder already sent, any pause a person has set, and whether a payment has been recorded since the last run. When those live in one system the chase is a query and a few sends. When they live in three, the agent spends its effort reconciling, and sooner or later a customer gets a reminder for an invoice they paid.

What the agent does, tool by tool

Here is the same policy running in Sois, where invoicing, contacts, email and tasks are one workspace exposed to the agent as tools over the Model Context Protocol. The person's request is a standing one; the agent runs it each morning and reports back.

The tools are ordinary, named things, which is what makes the behaviour reviewable. These are the accounting tools the request above touched, as the workspace publishes them to a connected agent.

{
  "tools": [
    { "name": "searchInvoices",
      "description": "Search invoices by number, reference, contact, amount, status, type, date range. For unpaid or outstanding invoices pass outstanding_only: true." },
    { "name": "sendInvoiceReminders",
      "description": "BULK payment reminders: email every unpaid invoice to its contact with a reminder message, in one action. Optionally pass invoice_ids to limit the set. Requires user confirmation." },
    { "name": "sendContactStatement",
      "description": "Email ONE contact a statement of account: all their outstanding sales invoices with per-invoice balances and the total due." },
    { "name": "snoozeInvoiceChase",
      "description": "Pause payment chasing for ONE invoice. Sets a snooze date; sendInvoiceReminders skips the invoice until then." },
    { "name": "recordPayment",
      "description": "Record a payment against an invoice. Updates amount_paid and status." }
  ]
}

Tool names and descriptions as the Sois accounting module publishes them. The bulk reminder tool says in its description that it requires confirmation, so the client asks before any email goes, which is the human-in-the-loop the MCP specification recommends for consequential operations.

Two details deserve attention. The reminder tool works on invoices with a balance outstanding, so a part-paid invoice is chased for the right amount. And the pause is a property of the invoice, set by a person in plain language ("leave Acme until the eighteenth"), which the reminder tool honours on every run. The agent never has to remember who asked for what. The record remembers.

Exceptions are the job

Once the routine is automated, the work that remains is the exceptions, and they are where the money is. The table sets out the ones that come up every week and who owns each.

Measure the exceptions, not the tasks. A count of reminders sent only tells you the agent is busy. The number of invoices that needed a person, and how many days overdue they were when they did, tells you whether the policy is working. Over a few months the first number should stay flat while the second falls.

Tone, the law and the relationship

In the United Kingdom, late payment legislation gives a supplier the right to statutory interest at eight percentage points above the Bank of England base rate, plus a fixed recovery sum that steps up with the size of the debt, once a commercial invoice is late. If no date was agreed, an invoice is late thirty days after the customer received it or the goods, whichever is later, and agreed terms between businesses are normally limited to sixty days unless a longer period is fair to both sides. Other jurisdictions have their own versions of these rules. The agent can calculate the interest exactly; whether to charge it is a commercial decision about the relationship, and it belongs with the person who owns the account.

Tone follows the same principle. The first two messages should be the ones a good credit controller would send: specific, polite, unembarrassed. Anything firmer is a change of stage, and changes of stage are approvals. The failure mode of automated chasing is rarely that the messages are rude. It is that they go to the wrong person, about the wrong amount, on the wrong day, and a customer who has done nothing wrong feels pursued. Every control in this article exists to prevent that, which is why the record matters more than the wording.

Setting it up in a week

If your invoicing, contacts and email already live in one system that exposes them as tools, the setup is the policy document and a standing request. If they do not, the order is: bring the open invoices and their contacts into one workspace, write the one-page policy, run it by hand for a week so you know the messages are right, then hand the routine to the agent and keep the exceptions.

In Sois that means launching a workspace, raising or importing the invoices, connecting the agent you already use (Claude, ChatGPT or any MCP client) with a single OAuth sign-in, and telling it the policy. The agent acts with your permissions and no more. A colleague whose role can read invoices but not send email cannot send reminders through their agent either, and every send and every pause is logged against the person whose agent did it. If you have no agent of your own, the Chat Agent Gateway takes the same standing request as a single message and replies when the run is done.

What you should see after a month is fewer reminders, not more. The courtesy note before the due date catches the invoices that were only ever waiting for a nudge, and what remains is a short list, each with a reason attached and a person's name against it.

Questions people ask

This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.