Notes on automating invoice reminders with agents

Invoice reminders seem like a good candidate for automation. You have a fixed trigger (overdue date), a clear action (send a reminder), and a desired outcome (payment received). The logic isn't complicated. Why does it still require someone's time every month?

Because the hard part isn't the sending. It's what surrounds it.

What people underestimate

A client who is two weeks overdue and has paid reliably for three years is different from a client who is two weeks overdue and has disputed the last two invoices. Sending the same reminder to both isn't just inefficient — it can damage a relationship or complicate a dispute in ways that create more work for finance and account management.

People who handle reminders manually already know this. They've built up a model, often tacit, of which clients need what kind of treatment. The automation challenge is making that model explicit enough to encode.

The decision tree most reminder automations miss

Before writing a line of code, it's worth mapping the decisions that currently happen inside a human's head when they look at the overdue invoice list. In almost every company we've worked with, the real decision tree looks something like this:

Is this client in active dispute about this invoice? Route to account manager. Has this client been contacted in the last five days by someone other than the automated system? Hold. Is this invoice part of a project that is still ongoing and where the deliverable is disputed? Flag for review. Has this client paid within 48 hours of the first reminder on the last three invoices? Send a lighter-touch message. Is the outstanding amount above a certain threshold? Escalate earlier than normal.

None of this is in the standard "send a reminder at day 7, day 14, day 30" logic that most off-the-shelf tools offer. All of it lives in someone's memory and judgement.

Where an agent adds value

An agent can read the invoice record, check the payment history, look at any open support or dispute tickets, and make a categorisation decision. "This one goes to the standard sequence." "This one needs a human to look at it." "This one should be paused while the project status is resolved."

That's the useful part. Not the sending — any email tool can send — but the triage. The model earns its cost in the classification step, not in the delivery step.

A few things that go wrong

The systems that fail are usually the ones that automate the sending without automating the triage. They send on a schedule, without context, and create incidents: a reminder goes to a client who called yesterday to explain a bank processing delay; a reminder goes to a client who is in the middle of a contract negotiation; a reminder goes to a client who has already paid but where the payment hasn't cleared in the accounting system yet.

The fix isn't always obvious. Sometimes the problem is the reminder logic. Sometimes it's that the data sources the agent needs to make good decisions aren't accessible or aren't current. An agent can only make good decisions with the information it has.

What works

The reminder agents that work well in practice tend to be conservative. They automate the low-ambiguity cases — clear overdue, no disputes, no recent contact, within normal amount range — and surface everything else to a human. The human's queue gets shorter, not empty. But shorter is the win.

Over time, as you see what the agent flags and why, the logic can be refined. The boundary of what the agent handles autonomously moves as confidence in its categorisation increases. Starting narrow and expanding is less risky than starting broad and pulling back.