The open item list is reviewed once a month, and nobody likes to send reminders.
The open item list lands on the desk once a month, usually after the close, when someone finally has an hour to spare. By then the oldest invoices are six weeks overdue. The dunning run is a block of one to two days in which one person does nothing else.
Asking for money is socially uncomfortable. It feels like accusing a partner you want to keep working with. So the task slips behind everything that feels more urgent, and the friendly reminder goes out weeks too late or not at all.
Payment promises from phone calls live in a notepad or in one person’s mailbox. Clarification cases eat the time that was meant for following up: partial payments without a payment reference, promised credit notes that were never written, cash discount taken without justification. And because nobody looks at it weekly, DSO rises unnoticed. The money is earned, invoiced, and sitting in the customer’s account.
We started with the matching, not with the reminder letter.
Dunning projects fail when they start with the writing. As long as payment matching is unreliable, every automatic reminder is a risk. And the team’s conditions became the specification: the tone stays the tone of the house, every letter stays editable before sending, and the dunning levels still belong to the team.
- Map the dunning practice as it is lived: Not the levels from the ERP manual, but the practice. Which customers are never chased, who has an informal installment agreement, when someone prefers to call instead of write.
- Daily matching first: Bank data in, payments allocated, remaining balances correct. The team checks that list for a few weeks before a single reminder is created automatically.
- Tone and levels with the specialist team: The wording per level is created with the people who sign today, and it is tested on real overdue cases.
- Clarification cases last: Partial payments, cash discount differences, and missing credit notes need judgement. The AI employee prepares them with context, the team decides.
80 percent is done by the AI employee. The human decides at two points.
Every morning the AI employee pulls the open items from the ERP and the incoming payments from the bank feed. Payments are allocated by payment reference, amount, and customer. What matches is cleared. What matches only partly keeps its remaining balance with its own due date. Only from this matched list does it derive what is truly overdue today.
For every overdue item it drafts the right level of your dunning logic, with invoice number, amount, and the last agreement on record. Customers with a payment plan, an open complaint, or a logged promise stay out of the run automatically. The human releases the dunning level, and before any escalation towards collections or a lawyer the human decides.
Invoice for 8,400 euros, overdue by 12 days. The customer transferred 5,000 euros without a payment reference, a phone note mentions a promise for the rest.
One field is flagged for review: the customer has a framework contract and an open promise. Whether a letter or a call is right here stays a decision for the team.
That was before, this is today.
This is how dunning ran before, and this is how it runs today with the AI employee. A block of one to two days per month turns into a few minutes of releases per working day.
| Before | Today | |
|---|---|---|
| View of the open items | Once a month, after the close | Every morning, matched against the bank data |
| Effort | 1 to 2 days of block work per month | A few minutes of releases per working day |
| Reminders | Late, in batches, sometimes not at all | Drafted on the due date, released by a human |
| Payment promises | In one person’s head or mailbox | Logged with a date, reminder paused until then |
| Clarification cases | Open for weeks, researched from scratch each time | Prepared with payment reference, difference, and reason |
| DSO | Rises unnoticed between two closes | Visible daily, with named drivers |
* Savings conservatively calculated: before, a dunning run of 1 to 2 days per month, so 8 to 16 hours. Today about 5 minutes of releases on 21 working days, so about 1.75 hours per month. Even against the lower baseline, more than three quarters of the effort disappears. The DSO effect depends on your customers’ payment behavior and is not claimed here as a measured figure.
How do you build an AI employee like this, technically?
The knowledge from this use case to take away, whether you build with us or on your own:
Matching: the bank feed is the truth
Incoming payments arrive daily as an MT940 or CAMT statement or through a banking API. Matching runs on payment reference, amount, and customer, and it runs daily. A monthly run works on stale balances and chases customers who paid long ago. Only daily matching makes an automatic letter defensible.
Reading promises: this is where a language model belongs
What counts as a promise in an email or a phone note is language, not a rule. GPT from OpenAI or Claude from Anthropic read the thread and pull out date, amount, and source. That becomes an entry with a follow-up date, not a sentence in a notes field.
Dunning levels stay the team’s rulebook
Levels, intervals, fees, and exceptions are fixed rules, not an AI decision. The AI employee picks the level according to your rulebook and invents no new one. Above a threshold you set, every letter goes out as a draft for release.
Integration: DATEV, SAP, and the existing mailbox
The open items come from the existing bookkeeping, typically DATEV or SAP. Sending runs through the existing mailbox. There is no new platform, and the dunning level is written back into the source system so bookkeeping keeps its familiar view.
UX: the interface decides adoption
The open item list shows the context per customer: history, last agreement, open complaint. The reminder drafts are written in the tone of the house and stay editable. And escalation is a deliberate click, never an automatism. Exactly this takes away the fear of losing a good customer.
What does it cost in comparison?
Superkind charges per use case. The price grows with the number of open items, not with headcount. Here is the honest comparison:
| Accounts receivable clerk | ERP dunning automation | Superkind AI employee | |
|---|---|---|---|
| Cost | 55,000 to 75,000 € per year for one position | Included in the license, plus customizing | Price per use case, a fraction of a full-time position |
| What is included | The whole process, by hand | Form letters on fixed intervals | Matching, reminder drafts, promises, and clarification cases |
| Rhythm | Once a month, when there is time | Batch run by interval | Daily, matched against the bank data |
| Exceptions | Live in one person’s head | Knows no promises, keeps chasing rigidly | Promises, complaints, and payment plans stay out of the run |
| Rollout | Recruiting and onboarding | Customizing inside the ERP project | 2 to 3 weeks to the first productive version |
The honest comparison is not against zero cost, but against the full cost of manual dunning: the block days themselves, the searching in clarification cases, and above all the money sitting in your customers’ accounts instead of yours. In B2B, 30 to 45 days of DSO is common, and every day below that is liquidity.
What we learned about dunning.
The real problem is rarely the customer. Most overdue invoices are not disputes, they are invoices nobody followed up on. Because dunning is uncomfortable, it loses every day against work that feels more productive. That is exactly why an AI employee helps more here than where a task is merely tedious.
The value is created before the writing, in the matching. Teams ask for automatic dunning letters and get nervous about the tone. But the writing is the easy part. What makes dunning defensible is knowing every morning what exactly is still open, what was partly paid, and what was promised. Once that holds, the fear of embarrassing a good customer largely disappears with it.
What it is not suited for: If you invoice a handful of customers you speak to weekly anyway, dunning is a conversation and not a process. In project business with progress billing and retentions, the rules are too complex as a first step. And disputed receivables belong with your lawyer, not in a dunning level.
