Automating invoice dunning without annoying your customers
TechnoVision Engineering
Publication date pending · 9 min read
Most late payment is not refusal. It is an invoice that was filed and forgotten, on both sides. The money arrives when somebody asks — and the asking is exactly the job that slides down the list every week, because it is nobody’s favourite and there is always something more urgent.
So automate the asking. That part is easy. The parts that decide whether the automation helps or quietly costs you a customer are the ones nobody writes into the requirement.
One email per customer, not one per invoice
This is the first thing to get right and the most common thing to get wrong. A customer with six overdue invoices should receive one email listing six invoices.
Six emails about six invoices is not six reminders. It is harassment, and it gets your address filtered — after which none of your reminders arrive, including the ones that would have worked.
The failure mode is worse than annoyance. Once your domain is filtered by their mail server, you have lost the channel for that customer permanently, and you will not be told.
Group by the commercial partner
In Odoo, invoices are often addressed to a child contact rather than the company. If you chase per partner record, a customer with three contacts and eight overdue invoices gets three separate emails, and their parent account looks clean in your own reporting while the contacts are in arrears.
Group by commercial_partner_id. The customer is the company, not the contact the invoice happened to be addressed to.
The oldest invoice sets the tone
A customer with one invoice ninety days late and one invoice five days late has a ninety-day problem. The escalation level should come from the oldest overdue invoice, not the newest and not the average.
The alternative — sending a gentle first-reminder because the most recent invoice is only a week old — is how a serious arrears situation gets a polite note for three months running.
Escalation that means something
Three levels is usually enough, and each one should do something genuinely different rather than repeating the last with more exclamation marks.
| When | What happens | Why |
|---|---|---|
| ~7 days | A short, friendly email | Most of these are simply forgotten. Assume that. |
| ~30 days | A firmer email, and a task in someone’s diary | By now a person needs to be involved, not just a template |
| ~60 days | A phone call scheduled, and the account flagged | If two emails have not worked, a third will not either |
The third level being an activity rather than an email is the point. Escalation means changing the channel, not increasing the font size.
The pause button is not optional
Every dunning system needs a way to stop
Start with it switched off
The most dangerous moment for any dunning automation is the first hour after installation, when it discovers three years of historical overdue invoices and emails everyone about them.
Any system worth using ships with the master switch off. Install it, look at the list of who it thinks is overdue and at what level, send a few by hand, and only then turn it on. If the list looks wrong, the wrongness is in your data, and you have just found it before your customers did.
Record what was sent
When a customer says "nobody told us", the answer should be a date, a recipient, an amount and the text that went out. A dunning system that sends but does not record is one that will lose you an argument at some point, and the argument will be about money.
Our Customer Payment Reminders module does all of the above, and it ships with the switch off for the reason described. But the principles here are not ours and are worth applying whatever you use — the grouping, the oldest-invoice rule, the pause, and the record.