SEPA Direct Debit for SaaS: Mandates, Pre-notification, Returns

With a card payment, your system usually knows straight away whether the charge went through. SEPA Direct Debit works differently. The collection is accepted, the money arrives, and weeks later it can leave again. That's why many direct debit problems in SaaS only show up after the first successful collection: a mandate you can't produce, a pre-notification that went out too late, or a return that the system treats like an expired card.

This article walks through the pieces in the order you need them in operation: creditor identifier, mandate, pre-notification, collection, return. For business customers there's also the choice between the Core and the B2B scheme. The legal references are German, because that's where the examples are set; the scheme rules are the same across SEPA.

Before the first collection: creditor identifier and mandate reference

To collect by direct debit in Germany you need a creditor identifier from the Deutsche Bundesbank (page in German). The number alone doesn't let you collect, though. Your bank also has to agree, and that collection agreement is a separate step with its own lead time. If you use a payment service provider, it often collects under its own creditor identifier. Check which name then appears on your customer's bank statement. An unfamiliar name leads to queries and, at worst, to returns.

The creditor identifier and the mandate reference together identify a mandate uniquely. You assign the mandate reference yourself. Two rules save trouble later: never reuse a reference, not even after cancellation. And attach it to the mandate, not the customer. A customer with two bank accounts has two mandates.

The mandate is your evidence

A mandate is your customer's permission to debit their account. Store it so you can still produce it 13 months after the last collection: the mandate text in the version the customer saw, IBAN, account holder name, date, mandate reference and, for online sign-up, the technical proof of consent. A ticked box on the signup form without the stored text won't do.

Two deadlines show why. For an authorised Core debit, the payer can demand a refund within eight weeks of the debit without giving a reason (Section 675x(4) BGB, German Civil Code). If instead they deny ever giving a mandate and you can't produce one, the payment counts as unauthorised. They can then go to their bank up to 13 months after the debit (Section 676b BGB).

For cash planning, that means a Core collection is only reasonably safe after eight weeks, and without a mandate you can prove, only after 13 months.

Core or B2B scheme for business customers

The SEPA B2B scheme is only available between businesses. There's no eight-week refund right. In return, your customer has to confirm the mandate with their own bank, and that bank checks every collection against those mandate details. Without the confirmation, the debit is returned.

A practical rule: Core as the default for self-serve and smaller contracts, B2B for high-value annual contracts where a reversal after seven weeks would really hurt. With B2B, expect the first collection to fail because the confirmation hasn't reached the payer's bank yet, and build that buffer into onboarding.

Pre-notification with variable amounts

Before each collection your customer has to know the amount and the due date. Unless agreed otherwise, the notice period is 14 calendar days. You can agree a shorter period in your terms, and with usage-based billing you should.

An example with made-up figures: a customer's October usage comes to €2,380. The invoice is issued on 1 November and doubles as the pre-notification, showing amount, due date, mandate reference and creditor identifier.

• Without an agreement: earliest collection on 15 November.
• With an agreed five-day period: collection on 6 November, nine days earlier.

The typical failure with variable amounts: the invoice is corrected after the notice went out, say because late usage events came in, but the new amount is collected on the old date. You've now collected an amount that was never announced. Your system should treat any change after the notice as a new notice with a new date. Handling late events reliably is covered in our article on idempotent usage event processing.

The return reason decides the next step

A returned debit comes with an ISO 20022 reason code. How precisely that code reaches you depends on your bank or payment provider; some group codes together. If you store everything as "payment failed", you react the same way to every case, and often wrongly:

With MD06 and MS02 your customer has acted deliberately. An automatic second attempt reads as escalation and can easily come back as the next return. With AM04 a retry usually makes sense, and that collection needs its own notice with the new date. Banks normally charge a fee for each return. Whether you can pass it on depends on your terms.

In the billing system you need more states than "paid" and "open": scheduled, submitted, collected, refund_window (up to eight weeks after the debit), returned with code, blocked. Which dunning step follows and when to restrict access is covered in our article on dunning for subscriptions.

What to check before your first collection run

You should be able to answer these before the first direct debit run goes live:

1. Whose creditor identifier is used, yours or your provider's, and which name appears on the customer's statement?
2. Can you produce text, date, IBAN and consent evidence for any mandate within a day?
3. Is a shorter pre-notification period agreed in your terms, and does your collection date respect it?
4. Does an invoice correction after the notice automatically trigger a new notice?
5. Are return codes stored and mapped to different reactions?
6. Can finance and cash planning see which amounts are still inside the eight-week window?

Kontier keeps mandates as separate objects with reference and evidence, and writes return codes back to the affected invoice as events. The systems it connects to are listed under integrations.