Skip to main content
Back to Blog
Automation5 min read26.07.2026Sophera Consulting

What Automated Payment Reminders Take Off Your Desk and Where They Still Need a Decision

Automated dunning saves time daily until one deadline is miscalculated. Which rules must be fixed first, and what genuinely disappears afterwards.

This article was generated by AI. Labelled in accordance with Article 50 of the EU AI Act. Responsible for publication: Sophera Consulting.

The question that comes up most often in conversations about automated payment reminders is this: what does the system do when a customer is right not to have paid? It is a fair question, and it points straight at where the value of this kind of automation actually sits. Not in sending more reminders, but in sending the right ones and withholding the wrong ones.

What the process actually removes

The work in credit control is not writing the reminder. It is the daily scan of open items, the reconciliation against incoming payments, digging out the matching invoice, checking whether a complaint is open against it, and recording that a reminder went out. These are many small motions that together consume a serious share of a working day, and nobody enjoys them.

That is precisely the part that can be handed over reliably, because it consists of rules you can write down. What does not get handed over is the judgement call and the phone conversation with a customer you want to keep. A quote that promises otherwise deserves suspicion.

The rule that is almost always missing

Most payment terms are expressed in working days. Most automations calculate in calendar days, because that is the default on every platform and because fourteen days sounds like fourteen days in conversation.

The gap stays invisible for a long time. It becomes visible on exactly those dates where several public holidays cluster, so around Easter, Christmas, Ascension and Whitsun. Then a reminder reaches a customer whose accounts department was closed on four of those fourteen days and who processed the invoice on time.

That is not a technical bug. It is a gap in the specification. The automation calculates correctly, just not the thing the contract says.

Why the working-day rule is only the first layer

Underneath it sit several decisions your business has never had to state out loud, because a person made them without noticing.

Which holidays count? In Germany public holidays are set by each federal state, so a date can be a holiday in one state and an ordinary Thursday in the next. Do you calculate against your own registered office or against the customer's? Either is defensible, but it has to be chosen, otherwise a library default chooses for you.

When does the clock start? At invoice date, at dispatch date, or on the day the customer demonstrably received the invoice? For anything sent by post those are several days apart.

When does a payment count as received? On the booking date in your account or on the value date? For payments initiated on a Friday that is two to three days, and a dunning run is fond of firing inside exactly that window.

The cases where no reminder may go out

This is where an automated process either earns trust or loses it. Several states make a reminder wrong even though the deadline has passed.

A complaint is open against the invoice. A part payment has been made and a credit note is pending. The customer has different terms in a framework agreement that do not appear on the document itself. An instalment arrangement is running. Or sales has just agreed something else with that account.

Every one of those states has to live in a system the automation can read. If it only lives in someone's head or in an email thread, it will be ignored. So the honest order of work is to decide first where these markers are maintained, and to build afterwards. Otherwise you automate a process whose most important input is missing.

How many escalation levels you need

A first reminder can go out fully automatically. Its tone is friendly, the damage from a wrong send is small, and it clears the majority of cases on its own.

From the second level onwards, being wrong gets expensive. Human approval belongs here, but not as a case-by-case review. It belongs as a short list on someone's desk each morning that takes a few minutes to clear. The automation prepares, a person confirms. The third level, meaning formal proceedings or collection, does not belong in an automation at all. It belongs in a deliberate decision.

That gradation is where good quotes separate from bad ones. Anyone treating all levels the same has built in either too much risk or too much manual work.

What to fix before you request a quote

Write down four things before you speak to any provider. First, calendar days or working days, and against which region's holiday calendar. Second, when the clock starts and when a payment counts as received. Third, the complete list of states in which no reminder may be sent, and where each of those states is recorded. Fourth, from which level a human approves.

These four answers are worth more than any feature list, because they describe the actual effort. A provider who asks for them before naming a price is costing the work. One who names a number without them is pricing the happy path and will invoice the exceptions later.

The recommendation

Automate credit control, but start with the rules rather than the tooling. The benefit appears where time leaks away every day, and the damage appears where a deadline is calculated against a contract that says something different. Both hang on the same four decisions, and you can make them in an hour.

Sophera Consulting puts exactly those rules in writing before building, implements them including holiday logic and hold reasons, and then names a fixed price with no subscription. The entry point is free in the Automation Check.

This article was created with the help of AI.

#Werktage#Feiertage#Fristen berechnen#Mahnwesen#SLA#Automatisierung#Make#n8n