Automating Dunning: The Parameters You Need to Adjust for 90% Less Manual Work

Why automated dunning stays manual: 4 configuration mistakes 

Finance teams that want to dun overdue invoices automatically switch on the ERP’s dunning module, expecting to hand it off. Not long after, they realize: it’s running, but not really.

Customers complain about reminders they’ve already paid. The team steps in manually because there are no exceptions defined. First reminders go out so early they cause friction with no payment result. These are the outcomes of the four most common configuration mistakes in dunning.

Mistake 1: Dunning levels active, but no payment reconciliation 

The system reminds customers who paid days ago. If payment reconciliation isn’t kept current every day, you’re dunning based on stale data. The result: manual corrections, customer friction, lost trust, and a finance team spending too much time apologizing (and not enough on actual overdue accounts).

Mistake 2: Deadlines that are too short 

Automating reminders with tight deadlines creates pressure but no payment. A first reminder three days after the due date usually surprises B2C customers and is simply wrong for B2B customers with longer payment terms.

Short deadlines increase your reminder volume, not your collection rate. And every unnecessary reminder burns processing time on both sides.

Mistake 3: No exception flags 

Disputed invoices, payment plans, and large customers with framework agreements get treated exactly like standard debtors. That produces reminders someone has to stop by hand internally, right away.

If exceptions aren’t configured cleanly in the ERP, you’ve got a semi-automated process that needs constant babysitting. And you can’t prevent duplicate reminders without exception flags. Full stop.

Mistake 4: Dunning text isn’t channel-specific 

When B2B customers and end consumers get the same reminder, the tone, deadlines, and phrasing rarely fit the actual relationship.

A corporate customer who’s paid on time for years and suddenly gets a standardized, hard-toned reminder reacts differently than an end consumer with a one-off payment delay. Either the reminder loses its effect, or worse, it damages the relationship.

Setting dunning levels and deadlines correctly 

Once the dunning levels in the ERP are configured, the foundation for everything else is in place. The job is to find the right staggering for your customer base and configure the deadlines so they neither pressure customers too early nor kick in too late.

These baseline settings have proven themselves for B2C commerce businesses:

Note: These deadlines are practice-based reference values, not legal advice. Coordinate the configuration with your legal or tax advisor.

The staggering follows clear logic.

Every level escalates, but not abruptly. Seven days sit between the payment reminder and reminder 1: enough time to react, not so much that the delay hardens. Between reminders 2 and 3, another ten days pass in which the customer can still resolve things without legal consequences.

B2B adjustment: shift deadlines back 

In B2B, longer payment terms are the norm. 30- or 60-day terms are standard. A payment reminder three days after the due date doesn’t feel friendly here. It feels off. The recommendation for B2B:

• Payment reminder: Day +7 after due date
• Reminder 1: Day +14
• Reminder 2: Day +25
• Reminder 3: Day +40

The principle is the same: staggered, with clear escalation logic, but adjusted to the relationship. If you sell to both B2C and B2B, set up separate dunning configurations and assign them by project or language.

Configuring exceptions without hollowing out the system 

Configuring exceptions correctly in the ERP is one of the most demanding tasks in dunning, because there’s no universal recipe. It takes company-specific judgment.

Exceptions are necessary. But they’re also the top reason automated dunning quietly drifts back to manual. Exceptions without an expiration date or a condition grow into a widening gray zone. The system still runs technically, but in practice, nothing gets dunned automatically anymore.

Rule of thumb: every exception needs either an expiration date or a condition that automatically lifts it. Otherwise it stays active forever, and the system never dun.

Exceptions can be set per invoice in Xentral. That gives you the flexibility you need without undermining the automation. What matters is discipline in setting them: every exception without an expiration date is a potential permanent gap in the system.

A common mistake is simply pulling disputed invoices out of the dunning process without creating a follow-up task. The invoice ends up sitting silently, nobody handles it, and weeks later someone notices it’s still open.

Better: set the flag, create the task, define the condition. Then the exception stays controlled.

Payment reconciliation: the prerequisite that holds everything together 

No dunning process works without daily payment reconciliation. That sounds obvious. In practice, it isn’t.

The reason is technical. Payment data sits in the banking system, while open items sit in the ERP. As long as those two sources aren’t synced automatically and daily, they operate independently. The ERP doesn’t know what the bank knows.

That creates a structural problem. The dunning process pulls from the state of open items as of the last manual update, not the actual payment status.

The longer the gap since the last reconciliation, the wider the delta. And the wider the delta, the more reminders go to customers who already paid.

Payment reconciliation is the prerequisite for dunning to work correctly and for invoice status in the ERP to update automatically the moment a payment lands.

For growing midmarket retail businesses, this is a core piece of finance automation in the ERP: no more manual reconciliation, let the system maintain the data foundation.

The payment reconciliation agent in Xentral (currently in beta) 

The payment reconciliation agent in Xentral handles the matching automatically. It reconciles incoming payment data with open items, closes matched invoices, and gives the dunning process the right data to work from.

The principle: the agent matches, your finance team only decides on exceptions that can’t be assigned cleanly. Instead of reconciling daily by hand, your team only reviews the cases that need a call. In practice, that’s rare.

Xentral Flows: two dunning workflows from the library 

In addition to the agent, there are two workflows in the Xentral Flows library that support dunning proactively, before payment even becomes overdue. Both can be activated directly from the Xentral Workflow library:

• Set payment terms on new orders: This workflow sets the payment terms automatically when a new order is created. No manual entry, no forgotten payment terms that cause problems later.
• Start automatic payment reconciliation: Connects the bank integration to the payment intake module and starts the reconciliation automatically. No manual trigger needed. Reconciliation runs daily in the background.

Bottom line: configuration isn’t a one-time job 

Automated dunning works when the parameters are configured correctly. Dunning levels, deadlines, exceptions, and payment reconciliation have to fit together. Miss or misconfigure any of these, and manual work stays, even if the system is technically running.

At the same time, configuration isn’t a one-time job. Customer relationships evolve, payment behavior shifts, exceptions expire.

Set the dunning process up cleanly once, then review it regularly. That’s how you build a finance process that grows with your business, without adding proportional overhead.