Dunning for B2B Subscriptions: Default, Reminders, When to Pause

Many SaaS dunning flows were built for cards: the payment fails, three emails go out a few days apart, then the account is locked. That fits poorly with business customers who pay by bank transfer or direct debit. The first email lands with an accounts payable team waiting for a purchase order number. The lock hits users who know nothing about the unpaid invoice. And nobody checked whether the customer was legally in default at all.

This article covers how to design a dunning sequence for B2B subscriptions, using German law as the example: how payment retries differ from reminders, when default begins, what you can then charge, and when the automation has to stop. Germany's late payment rules are based on the EU Late Payment Directive 2011/7/EU, so other member states have comparable rules, with local differences.

Payment retries and reminders are two separate processes

A retry is a technical event: the card is charged again, the direct debit resubmitted. A reminder is a message to the customer with legal effect. Put both into one flow called "dunning" and you get the familiar failures. The customer receives a reminder although the second card attempt went through two hours later. Or a direct debit is collected again after the customer disputed it, because the retry schedule doesn't know the customer acted deliberately.

So run two flows. The payment flow knows attempts, return codes and dates. The dunning flow knows due dates, invoice delivery, reminder levels and deadlines. Dunning only starts when the payment flow has given up or, for customers paying by transfer, when the due date has passed. Which direct debit return codes allow a retry and which don't is covered in our article on SEPA Direct Debit for SaaS.

When a business customer is in default

Default (Verzug) is the point from which you can charge interest and the flat fee. Section 286 BGB (German Civil Code, in German) gives three routes to it, and all three matter for a dunning sequence:

• Reminder after the due date (subsection 1): if the customer doesn't pay after receiving a reminder sent after the due date, they're in default from then.
• Calendar date (subsection 2 no. 1): if a payment date is fixed by the calendar, default begins without a reminder. Don't rely on a payment term that only appears on the invoice for this; agree the date in the contract.
• 30 days (subsection 3): a business customer is in default at the latest 30 days after the due date and receipt of the invoice, even without a reminder.

For B2B subscriptions that means you don't have to wait 30 days. A reminder shortly after the due date starts default earlier, and a contractually agreed payment date makes the reminder unnecessary for that purpose. Delivery is what matters. Your system should record for every invoice when and through which channel it was delivered. If an e-invoice was rejected by the customer's portal, delivery is questionable at best, and so is default.

What you can charge once they're in default: a worked example

Between businesses, default interest is nine percentage points above the base rate, and you're also entitled to a flat fee of €40 (Section 288(2) and (5) BGB). The flat fee is offset against later legal costs. An advance agreement excluding default interest is void (Section 288(6)).

An example with made-up figures and an assumed base rate of 2.0%: an invoice for €5,712 gross is due, the customer is in default from 1 April and pays on 16 May, 45 days later.

• Rate: 2.0 + 9 = 11% a year.
• Interest: €5,712 × 11% × 45 / 365 = €77.46.
• Flat fee: €40.
• Total claim: €5,829.46.

Two things follow. On small subscription invoices, the flat fee is often larger than the interest. And to calculate interest you need the exact start of default, which your system only knows if it stores due date, delivery and reminders with dates. Check the current base rate before each calculation. Whether you actually claim these amounts is a relationship decision. One possible middle ground: show them in the second reminder and waive them if the customer pays within the deadline.

A B2B dunning sequence, day by day

A proposal for customers paying by invoice, counted from the due date. The days are your choice; the order follows from the rules above. Note that whether a letter legally counts as a reminder (Mahnung) depends on its content, not its title. A friendly note that clearly asks for payment can be enough.

For direct debit customers the sequence only starts after the last failed collection, and the day +3 reminder becomes a request for new bank details or a new mandate.

The day +35 restriction should never delete data, and for usage-based services it shouldn't switch off metering. Otherwise you'll lack the usage data for the next invoice once the customer has paid.

When the sequence must pause

An automatic reminder that shouldn't have gone out costs more goodwill than a late payment. Pause the sequence and hand over to a person when:

1. The customer has disputed the invoice, for example the usage quantity or the VAT treatment.
2. A credit note or invoice correction is in progress. Only the corrected invoice gets reminders.
3. The invoice demonstrably wasn't delivered, or was rejected as an e-invoice.
4. A payment arrangement, such as instalments, has been agreed.
5. There are signs the customer is insolvent. Finance decides then, not the automation.
6. A partial payment came in that can't be matched to an invoice unambiguously.

Every pause needs a reason, an owner and an expiry date. Without an expiry date, paused cases sit untouched for months.

Five questions for your dunning setup

Whether you're choosing a tool or reviewing your current sequence, start with these:

1. Are payment retries and reminders separate flows, and does an incoming payment stop both immediately?
2. Does the system store due date, delivery and every reminder with a date, so the start of default can be read off per invoice?
3. Can interest and the flat fee be calculated from that data, instead of in a spreadsheet?
4. Can the sequence pause per invoice, with a reason and an expiry date?
5. Does a lock restrict access without losing data or metering?

Kontier treats reminder levels as states of the invoice, with delivery date and reminder history, in the same system as invoicing and payment. More on billing German business customers.