In a company of fifty people, collections tends to belong to whoever has a free afternoon. Someone exports the aged receivables report, holds it against the bank statement, crosses off what has been paid and emails the rest. During close week it waits. In the summer it waits longer. And because half the customers are people you have met, the second reminder often gets pushed back another week out of politeness.
An AI agent can take the routine part of that job. Each morning it works out which invoices are still open after the latest payments, picks the reminder each overdue customer should get and drafts it. Disputes, payment plans and anything that goes to court stay with your people. In my overview of AI agent examples, receivables only come up as part of reconciliation. This article covers the full follow-up loop. I describe how such an agent is put together, not a client project. I have none to show yet, and the Monday-morning example further down is made up.
Write the policy down before anyone builds
The person who chases payments today carries most of the rules in their head. They know that one customer always pays on the 25th and that another needs a phone call before any letter. An agent can only follow rules it can read. Four things need to exist first.
Clean customer master data. For every customer, an accounts payable email address, a named contact, the agreed payment terms and a flag for key accounts. If the invoice address is a salesperson's inbox, reminders will go there too.
A written reminder policy. How many stages, how many days apart, from what amount, in what tone, and whether you charge late fees or interest at all. Plenty of companies never charge them to good customers. That is a fair choice, as long as it is written down rather than decided case by case at the keyboard.
A hold list. Customers who never get an automatic reminder: key accounts, anyone with an open complaint, anyone on an agreed payment plan and anyone in insolvency proceedings. Someone owns this list and keeps it where the agent can read it.
An owner for escalation. At some stage sales usually gets involved. Decide who takes over when, and who decides on a credit hold, a collection agency or legal action.
Late-payment rules depend on where you are
The agent applies your policy, and your policy has to sit inside the law that governs the debt. That law differs between countries, so I won't pretend there is one answer.
To take one jurisdiction as an example, in the United Kingdom the Late Payment of Commercial Debts (Interest) Act 1998 applies to contracts for goods or services where both sides act in the course of a business. It gives the supplier a right to statutory interest on a late qualifying debt, and section 5A adds a fixed sum of £40, £70 or £100 depending on the size of the debt. Other countries set their own rates and fees, and your contracts may set different terms again.
For the build, that means two things. Any interest or fee in a reminder is calculated in code, from a rate table that a named person maintains and dates. The language model never produces a legal figure. Whether you charge it to a given customer is a business decision that sits in your policy. None of this is legal advice. Check the rules for your contracts and countries with a lawyer before the first reminder that mentions interest goes out.
What the agent does, in six steps
1. Build the day's overdue list
Every morning the agent pulls the open items from your accounting system or ERP: customer, invoice number, amount, due date, terms, the last reminder stage and the date of the last contact. It runs after the bank statement import, never before it.
What goes wrong. A stale list. The customer paid yesterday, the statement lands tonight, and the reminder goes out this morning anyway. Customers forgive a late reminder far more easily than one for an invoice they have already paid. So right before sending, the agent checks the latest receipts once more.
2. Match incoming payments to invoices
This is cash application. The agent reads the bank statement lines and any remittance advice customers send by email, then allocates each receipt to one or more open invoices using the reference, the amount, the payer and the invoice numbers it knows. Clean matches go to your accounts team as proposals. The agent does not post them.
What goes wrong. A customer pays five invoices with one transfer and deducts something without saying why. A parent company pays for its subsidiary from an account the agent has never seen. A round amount arrives with no reference at all. When the match is not certain, the agent skips that customer for the day and puts the case on the review queue. Chasing someone who has paid costs you more goodwill than waiting a week. The patterns behind most of these are in where automated matching breaks.
3. Decide who gets which reminder
For every item still open, rules in code decide the next action: days past due, the previous stage, the amount, the minimum gap since the last reminder and the hold list. Several overdue invoices from one customer go into a single message.
The language model earns its place in the check before that. The agent searches the accounts inbox and the helpdesk for messages about this customer and these invoices. A customer who wrote that half a delivery arrived damaged, or who asked for a credit note, has a disputed invoice. That invoice goes to a person and does not move up a stage.
What goes wrong. The customer complained to their sales rep on the phone, and nobody wrote it down. The agent can only find what someone recorded. A rule that sales logs every complaint in the CRM with the invoice number fixes most of this. Keep the first-stage reminder friendly enough that it does no harm if a dispute slipped through.
4. Draft the payment reminder
The agent fills in the template for the stage. Invoice numbers, amounts, due dates and bank details come from your data, never from the model. It attaches a statement of account and, where useful, a copy of the invoice. The model may adjust the wording to the situation, for example when the customer's last email asked for an invoice copy. It does not invent deadlines, amounts or consequences.
What goes wrong. An out-of-date rate in the table, or a customer coded with the wrong terms, and the reminder asks for more than you are owed. For the first weeks a person reads every reminder that includes interest or a fee, and every rate in the table carries the date it took effect.
5. Hand disputes, short payments and replies to a person
Anything a rule cannot settle goes to the review queue with the reason, the invoice, the payments and the correspondence on one screen, plus a drafted next step. Short payments with an unexplained remainder, discounts taken after the discount date, overdue key accounts and requests for more time all end up here.
Replies to reminders land here too, sorted first. "Paid on the 3rd" gets checked against the bank. "We never received the invoice" gets a drafted reply with the copy attached, which someone approves. A complaint or a proposal to pay in instalments goes to the person responsible, with a two-line summary. How to build a queue that people actually work through is in an escalation queue people trust.
What goes wrong. The queue grows and nobody clears it, so collections stalls exactly as before, just in a new place. Decide before go-live who works the queue and when, and make each item answerable on one screen.
6. Send and log
At first a person approves every reminder. After shadow mode you may decide that the first friendly reminder goes out on its own for customers who are not on the hold list. From the second stage on, approval stays. After sending, the agent writes the stage and date back to the accounting system and files the message against the customer.
Every run leaves a log: which items it read, which payment it matched to what, which stage it proposed, who approved it and under which version of the policy. When a customer asks why they got a reminder, the answer is there.
What goes wrong. The mail server times out, the agent retries, and the customer gets the same reminder twice. Every send needs a unique key per customer, stage and day, so a retry sends nothing new. Bounced emails to an old address only surface if the agent reads the bounce messages and flags them.
Where a person stays in the loop
Some decisions never move to the agent, however well shadow mode goes. These limits live in the connector code, not in the prompt, so a cleverly worded customer email cannot talk the agent into granting an extension. Hard limits in code explains why a prompt instruction is not enough.
- Disputes. Whether a complaint is justified is for sales or quality to decide. The agent pulls the correspondence together.
- Key accounts. Someone picks up the phone before anything is sent.
- Payment plans and extensions. They are an agreement with your customer. The agent can prepare one and track the instalments afterwards, but it cannot agree to it.
- Anything that goes to court or to a third party. Legal action, a collection agency, a solicitor's letter or a credit hold. The agent assembles the file, a person decides.
- Write-offs and waived fees. Giving up money stays with whoever holds that authority.
The data it needs, and where it comes from
Almost everything the agent reads already exists in your company. What is usually new is that the policy and the hold list sit somewhere software can reach.
- Accounting system or ERP. Open items, customer master data, terms and reminder stages. The agent reads these and writes back only the stage, the date and a note.
- Bank. Statement files or a bank feed, read only.
- Accounts inbox. Remittance advice, replies, complaints and bounces. The agent reads, creates drafts and sends after approval.
- CRM or helpdesk. Complaints, key-account flags and contacts, read only.
- Templates and rate table. Owned by finance, with dates and versions.
A made-up example: Monday morning at a distributor
Picture an invented packaging distributor with forty staff, selling to food producers on 30-day terms. On Monday morning the agent has read Friday's bank statement and works through the overdue items. Five of them show how the rules play out.
- A bakery paid on Friday and emailed a remittance advice listing two invoices. The agent matches both and sends nothing.
- A dairy paid three invoices in one transfer but deducted the price of a pallet it says arrived damaged. The agent matches the payment, finds the complaint in the inbox and sends the remainder to sales as a dispute.
- A caterer is twelve days past due, not on the hold list, with no correspondence. The agent drafts the first reminder.
- A juice maker asked last week whether it could pay a large invoice in three parts. The agent sends no reminder and puts the request, with the customer's payment history, in front of the finance lead.
- The distributor's largest customer has two invoices three weeks overdue. It is on the hold list, so the account manager gets a note with the statement and no reminder goes out.
That morning the accounts team approves one reminder. Sales and the account manager hear about their customers before anyone calls in annoyed.
How to start: shadow mode first
Give the agent read access and run it in shadow mode for a full reminder cycle, two if you can. It matches, proposes stages and drafts reminders, and sends nothing. Then compare who it would have chased with who your team actually chased. Every difference is worth a look. Sometimes the agent was wrong, and sometimes it found a rule nobody had written down. Agree the pass mark before the run. A reminder to a customer who has already paid should not appear even once.
Go live with the first, friendly stage only. Add the later stages once payment matching has held up for several weeks.
Payment matching here is the same work as bank reconciliation in AI agents for the month-end close, and the payables side of the same ledger is covered in how an AI invoice processing agent works. Cost depends mostly on how many systems the agent touches and how many cases fall out as exceptions, and how much an AI agent costs to build goes through the drivers. Our agent build service takes one workflow like this from shadow mode into production on the software you already run.
Bring your aged receivables report to a scoping call
Bring your aged receivables report, anonymised if you prefer, a few reminders you sent last quarter and the cases where you hesitated to a thirty-minute scoping call. We go through them with you, mark which steps an agent could take over and which stay with your team, and tell you what building the first version would cost. If your reminder policy only exists in one person's head, you hear that too.