In most SMEs, dunning looks the same. Once a week the accountant pulls a list of overdue invoices from the ERP, opens Excel, sorts it by date and starts making calls. It works — until the company grows enough that the list no longer fits on a screen.
That's when problems start that nobody wants to name out loud. Customer A got three reminders in one week because two people called independently. Customer B has been paying late for six months but nobody sees it, because someone different handles them each time. At month-end, management finds out "we've got 400 thousand in overdue" and asks "why am I only hearing this now?" The answer is always the same: because until now, nobody was counting it in a way that could be seen earlier.
Automating dunning isn't about replacing a human with a robot that calls customers. It's about lifting the routine off the accountant and leaving her the work that actually needs a conversation.
Why your dunning lives in Excel
Because your ERP shows you the state today, but doesn't run the process. You know that invoice FV/2026/05/234 is 14 days overdue — but you don't know whether anyone has already called this customer, whether there was a payment promise for Tuesday, and whether that Tuesday has already passed. That information lives either in the accountant's head, in Excel, or in an email nobody will ever find again.
Comarch Optima has a "Receivables" module. enova365 has something similar. Subiekt too. Almost no SME uses it, because either it needs a separate licence nobody knows about, or it needs manual configuration for the specific scenario — and nobody has time for that between posting invoices and pulling reports.
The result is always the same. The "Excel process" holds together as long as one person runs it. If she falls ill or leaves, the whole process starts from zero.
What good automated dunning looks like
Four principles. None is a discovery on its own, but together they produce a real effect.
- Customer segmentation, not one queue. A strategic customer three days late doesn't deserve the same message as a one-off buyer 45 days overdue. Splitting the base into 3–4 segments (key, regular, occasional, risky) changes the tone of communication.
- A reminder cascade, not a single shot. A soft pre-reminder 3 days before due date ("just confirming"), a polite one 7 days overdue, firmer at 21, a final demand at 45. Every step automatic, but with a manual override.
- One source of truth about status. If a customer promised to pay on the 15th, the system has to remember it and hold the next reminder until the 16th. Without this you're back to "two people called customer A".
- Visibility for management without being asked. A weekly report by email: how much in dunning, how much under payment promise, how much in dispute, DSO this month vs the last six. Without it, management will find out anyway — just too late.
The rest is integration. The ERP as the source of receivables state, a simple rules engine (can be low-code, can be custom middleware), a gateway for email and SMS, and a status cache where you record what was sent, when, and whether the customer responded.
What you can do in a week vs a month
In a week you can ship a first version — one customer segment, two reminder steps, email only. It won't be pretty and won't handle edge cases, but suddenly the accountant isn't stuck in Excel every Friday. That's enough to believe it's worth pushing further.
A month gets you the good version: full segmentation, SMS (SMS reminders convert dramatically better than email, especially for customers who "didn't see the email"), payment-promise handling, a management report, dispute handling ("we're not paying because the invoice is wrong"), and a hold mechanism for customers currently in dispute.
A quarter closes the loop on the things nobody initially thought of: escalation rules routing to the account rep (because they have the relationship, not the accountant), integration with e-delivery for final demands, and a link to a debt-collection bureau for cases that outgrow what you can handle internally.
A concrete example
At one of our clients — a 32-person plumbing and heating wholesaler in Wielkopolska serving ~350 active B2B customers and issuing an average of 450 invoices a month — the dunning process before automation looked like this: one accountant spent about 10 hours a week pulling the overdue list out of Comarch Optima, calling and writing reminders in Word (because the Optima template "didn't quite fit"). The company's DSO was 52 days on a standard 21-day payment term.
We built a simple middleware layer: overnight it reads the overdue list from Optima, assigns a segment based on the customer record, sends email or SMS (or both) per the cascade, and writes status to a table the accountant sees in a web view. Manual switches: "payment promise by date X" (holds reminders), "in dispute" (fully excluded from automation), "escalate to rep" (sends the mail to the account owner instead of the customer).
After three months, DSO dropped to 38 days. The accountant's time on dunning dropped from 10 to about 2 hours a week — not because she stopped doing it, but because now she does what needs her brain (disputes, negotiation, escalation calls), not what only needs her time (sending standard reminders). Every Monday, management gets a report by email and for the first time in years is not learning about a "bad invoice" after the fact.
Cost of the build: a 4-week project, one round of tweaks after the first month of use. Maintenance: a few hours a month.
What you can't automate
The call with a customer shouting into the receiver. The decision "escalate to court, or write it off and issue a credit note". The gut feeling that a customer who always paid is now in quiet financial trouble — because they're asking for "a small push" for the third time in a row. Nobody can do that for you and nobody should.
Automation is there to take the routine off your plate — so the things that need a human finally get the time.
Where to start
Before you configure anything, spend an evening with Excel and count: how much is overdue right now, what your DSO is, how many hours a week your accounting spends on dunning, and how many invoices you issue in a month. Without these four numbers you can't measure whether anything actually changed after go-live.
Then check what your ERP does natively. You may find you already have a module in your licence nobody has switched on — and two weeks of configuration might replace the need for custom middleware entirely.
If the native tool doesn't cut it (and usually it doesn't, because the message templates are rigid and customer segmentation is primitive) — that's the moment to talk to someone who has already laid out these processes in SMEs. Not to sell you a hundred-thousand-złoty system, but to tell you where the lowest-hanging fruit is in your specific case.
Automating dunning isn't about having a robot call customers. It's about letting the accountant handle the things that actually need a conversation — instead of sending the same email for the hundredth time.