Count the emails before you switch dunning on.

Twelve invoices already late.

The usual advice is a ladder. A guide published last week sets a reminder before the due date, then steps at 7, 15, 30 and 45 days past due, one invoice per message. That is a good ladder for an invoice that goes late after you start. It does not say what the first run sends to invoices that went late before you started, and every company switching on dunning has some.

Here is an example receivables ledger on the morning the sequence is switched on. Five customers, twelve overdue invoices. We used the same ladder, 7, 15, 30 and 45 days, for every rule.

Five rules, one first morning.

Rule 1 is what an engine does when it treats each step as owed. Harbor, a customer who pays in batches at month end, gets eight emails in one morning. Pine gets the 7, 15, 30 and 45 day messages for an invoice it has already disputed, all at once. Ember’s only contact left the company, so the final demand lands in an inbox nobody reads.

Rules 2 and 3 cut the volume, but both still pick the step from the invoice’s age. Pine and Ember hear from you for the first time through a final demand. Rule 4 fixes the tone: every customer starts at the polite first step and the ladder runs from go-live day, so the final step for those five customers arrives 38 days later. Rule 5 adds the two things a collector would do anyway. The disputed invoice waits for its answer, and the two accounts past the last step get a phone call, since an email is unlikely to move them.

What the big systems do with a backlog.

Dynamics 365 Finance creates collection letters per customer when collections process automation runs, and picks the step from the oldest invoice that is due. By default it does the step closest to the run date, which is rule 3: Microsoft’s own example has an invoice 17 days late skipping straight past three letters. Its Track step option starts with the first relevant step instead and runs the rest from that date, which is rule 4. Invoices with a collections status of Disputed or Promised to pay are skipped.

NetSuite’s Dunning Letters SuiteApp recommends customer level dunning, one letter listing the overdue invoices, with the level set by the customer’s oldest invoice. A minimum dunning interval stops letters reaching the same customer more often than a set number of days. Dunning can be paused with a reason for a customer or a single invoice, and clearing the pause triggers an evaluation straight away, so lift a pause when you are ready for a letter to go.

SAP S/4HANA puts all of an account’s items, at all their levels, on one notice in standard dunning. A dunning interval keeps an account from being dunned again too soon, minimum amounts stop small balances reaching the higher levels, and dunning block reasons hold accounts or items out of the run.

In the documentation we read, each of the three sets one level per customer or invoice rather than sending every step reached, and each leaves the first run to a choice you make in setup. Behaviour can differ by release, so run the go-live count in a sandbox.

A go-live checklist.

• Export the overdue list on the day before go-live and run each sequence against it on paper. Count the messages per customer. If any customer gets more than one, change the rule before you change the wording.
• Send one message per customer, listing every overdue invoice with the invoice attached. Per invoice messages suit a single late invoice; on a backlog they arrive as a pile.
• Start every customer at the first step on day one, then let the ladder run from that date. The first message a customer receives from a new process should be the polite one.
• Take anything older than your last step out of the email run and give it to a person to call. An automated final demand is a poor first contact.
• Mark disputed invoices and promised payments before the first run, with a reason, and keep them out until the reason is cleared.
• Set a minimum gap between messages to the same customer, seven days is a common choice, so a new invoice going overdue does not trigger a second email that week.

How Rivane runs dunning today.

In Rivane a dunning sequence is a named list of steps, each with a number of days past due, a subject and a body template. An invoice counts as overdue when it has a balance due and its due date is before the run date; voided and archived invoices are left out. Each message is recorded with its step, days overdue, channel and outcome, and a customer with no deliverable email is recorded as skipped rather than stopping the run.

# How a Rivane dunning run works today.

sequence     named, enabled or disabled
step         days past due, subject, body template
             template fields: customer name, invoice
             number, due date, amount due, days overdue
overdue      balance due above zero and due date
             before the run date; voided and archived
             invoices left out
scope        every enabled sequence, every overdue
             invoice in the entity
message      one per invoice per step reached
repeat       an invoice and step pair is sent once;
             running again sends nothing new
no address   recorded as skipped, run carries on
run log      step, days overdue, channel, outcome
             (sent, failed, skipped), kept if the
             sequence is later deleted

On a backlog, Rivane behaves like rule 1 today. A run sends one message per invoice for every step the invoice has reached, so an invoice 60 days late gets four messages on the first run; the engine’s own test checks exactly that. After that each step is sent once, and running again sends nothing new. Some limits to plan around: there is no pause or dispute flag, no minimum amount, no minimum gap between messages, and no choice of starting step. Every enabled sequence applies to every overdue invoice in the entity, so keep one enabled. A run is started on demand through the API; there is no built-in daily schedule yet. Before enabling a sequence on an existing ledger, count what the first run will send using the checklist above, and work the oldest accounts by hand first.

Keep the record your auditor and customers will ask for.

• The sequence in force on each run date: steps, day thresholds and the template used.
• For every message: invoice, customer, step, days overdue, channel, outcome, and the date sent.
• The list of paused invoices with the reason, who paused them and when the pause was lifted.
• The go-live count you reviewed before enabling the sequence, kept with the approval.

Plan the first morning, then the ladder.

Any sensible ladder will do once it is running. The first run is the one customers remember, and on this example it ranged from 23 emails with two final demands to three polite emails and two phone calls. Decide per customer, start at step 1, pause disputes, and call the oldest accounts.

If you are planning a move and want to walk through your own overdue list against these rules, book a session with the Rivane team.

Sources

• Microsoft Learn, Dynamics 365 Finance, Collections process automation FAQ. Read in the page for letters created per customer, the step chosen from the oldest invoice that is due, the run doing only the step closest to the date, invoices with a status of Disputed or Promised to pay being skipped, and the Track step option that starts with the first relevant step.
• Microsoft Learn, Dynamics 365 Finance, Process collection letters example (updated 2026). Read in the page for the Create collection letter per parameter set to Customer, and the option to ignore payments and credit memos when calculating the collection letter code.
• Oracle NetSuite Help, Creating Dunning Procedures. Read in the page for the Applies To choice of customer, invoice or invoice group, and the Minimum Dunning Interval that stops letters going to the same customer more often than a set number of days.
• Oracle NetSuite Help, Specifying the Basis for Determining the Dunning Level. Read in the page for the customer level being set by the days overdue of the customer’s oldest invoice.
• Oracle NetSuite Help, Pausing and Resuming Dunning. Read in the page for pausing a customer, invoice or invoice group while a query or dispute is resolved, with a reason, and for clearing the pause triggering an evaluation straight away.
• SAP Learning, Configuring the Dunning Program (SAP S/4HANA). Read in the page for the dunning interval in days, standard dunning putting all items at all levels on one notice, minimum amounts that keep small balances from reaching high levels, and dunning block reasons.
• Beancount.io, The 7/15/30-Day Dunning Cadence (6 October 2026). Read as the current answer. It sets a pre-due reminder and steps at 7, 15, 30 and 45 days past due, one invoice per message, and does not cover what to send to invoices already overdue when the cadence starts.

A note on how this was researched. The Microsoft, NetSuite and SAP behaviour comes from each vendor’s own documentation, read in the page, and may differ by release. The backlog is an example, and every figure was calculated in a script, which you can repeat with a spreadsheet. The Rivane section describes the dunning engine as built today, checked against the code rather than marketing copy.

On embedded social posts: we looked for public posts from vendors or practitioners on switching on dunning against an existing backlog and found none we could verify as current, relevant and authentic, so this article uses ordinary citations instead.