SEPA / Learning brief
SEPA Direct Debit exceptions and refunds
Your notes
In simple terms / 01
What this means in plain language
Explains how a SEPA Direct Debit collection can fail or unwind — rejects, refusals, returns, refunds, and reversals — including the eight-week no-questions refund window for authorised collections and the thirteen-month window for unauthorised ones.
The most surprising feature of a direct debit is that the money can come back. Under the Single Euro Payments Area (SEPA) Direct Debit (SDD) Core scheme, a debtor can ask their bank to reverse a collection within eight weeks of the debit, with no reason required and no need to argue with the creditor first. If a collection was never authorised at all — no valid mandate behind it — the window stretches to thirteen months. These rights exist because a pull payment happens without the debtor acting each time, so a safety valve compensates for the standing permission given once. Around these refunds sits a wider family of ways a collection can fail, known as R-transactions: a bank can reject a collection before settlement, the debtor's bank can return one shortly after, and the creditor can reverse money it should not have collected. Each of these travels back along the same path the collection took, carrying a reason code that explains what happened.
Complete lesson / 02
Understand the full idea, step by step
Money that was pulled can be pushed back — and a direct-debit scheme spends much of its rulebook describing exactly how. It sounds like a catalogue of failures. It is better read as a catalogue of safety valves, each releasing pressure at a different moment in the collection's life.
One question sorts them all
The question is: had settlement happened yet? Before settlement, a collection can be stopped. After settlement, the money has already moved, so undoing it means sending value back the way it came. Every one of these events travels back along the same clearing path the original collection took, and each carries an ISO (International Organization for Standardization) reason code naming why it happened. Collectively they are called R-transactions — the 'R' standing for the reject-and-return family.
R-transactions — the reject / refusal / return / refund / reversal family
An R-transaction is any message that stops or unwinds a collection. Five names matter, split by the settlement line: before settlement, a bank or the clearing mechanism can reject a collection (account closed, format wrong), and the debtor can refuse it in advance (telling their bank not to pay). After settlement, the debtor's bank can return it within a short scheme window, the debtor can demand a refund, and the creditor can send a reversal — voluntarily giving back money it realises it should not have collected.
| R-transaction | Before or after settlement | Started by |
|---|---|---|
| Reject | Before | A bank or the clearing mechanism |
| Refusal | Before | The debtor, in advance of the debit |
| Return | After | The debtor's bank, within a short window |
| Refund | After | The debtor, reclaiming a debited amount |
| Reversal | After | The creditor, giving money back voluntarily |
Two refund windows
The refund right is the heart of SDD Core, and it comes in two lengths as a matter of scheme right. For an authorised collection — made under a valid mandate — the debtor may request a refund within an eight-week no-questions window after the debit, and needs to give no reason. For a collection claimed to be unauthorised — no valid mandate behind it at all — the window is far longer, up to thirteen months after the debit. That longer right is anchored in European Union payment-services law and reflected in the scheme rulebook; the eight-week no-questions right is the scheme's unconditional, no-questions version of a refund right that itself rests on EU payment-services law.
COMMON CONFUSION
“A refund settles the argument — if the money comes back, the debtor did not owe it.”
A refund is not a verdict on the bill. It answers only 'should this collection have been taken from the account?', not 'was the amount owed?'. When Riya is refunded, the money returns, but any genuine debt survives — so a creditor that has been refunded must still pursue the invoice through normal means. Keeping those two questions apart is what stops a refund being mistaken for a ruling on the commercial claim.
WHAT IF — A collection comes back carrying reason code MD01 (no valid mandate)
What happens: The money the creditor had already counted moves back out, and the code is effectively an allegation that the collection should never have happened.
How it is handled: Maya treats an MD01 as a case to review, not an item to silently re-present. A pattern of them points at mandate management that has slipped — stale authorisations, or collections against people who never agreed. Read defensively, R-transaction reason codes are the scheme surfacing bad data and unhappy customers early, which is the control working as intended.
R-transactions as a quality signal
For a collections business, the R-transaction stream is best read as a portfolio-quality dashboard. A high rate of rejects usually means stale or wrong account data. A rise in refusals and refunds means customers who did not expect the collection — a sign pre-notification or mandate management has slipped. Because Core funds can be reclaimed through the eight-week no-questions window, operations teams treat that revenue as provisional: money booked on the due date can walk back out weeks later, so cash forecasting must allow for it. In B2B the balance shifts — the mandate is checked up front and authorised collections are final, so the residual risk moves toward pre-settlement rejects and refusals.
STRICTLY SPEAKING
Strictly speaking, the exact return window in interbank business days, the full reason-code set, and the mechanics of each R-transaction are defined by the European Payments Council's scheme rulebooks and its dedicated reason-code guidance, and they vary by version. The eight-week and thirteen-month refund rights are named here as scheme rights; the finer timings should be checked against the rulebook in force.
FOR NOW, REMEMBER
- Sort every direct-debit failure by one question: had settlement happened yet?
- Before settlement: reject (a bank/clearing) and refusal (the debtor in advance). After: return (debtor's bank), refund (debtor), reversal (creditor).
- Core refunds come in two scheme-right lengths: eight weeks no-questions for authorised collections, up to thirteen months for unauthorised ones.
- A refund answers whether the collection should have been taken, not whether the bill was owed — the underlying debt survives.
- Reason codes like MD01 (no valid mandate) are quality signals to review, not items to re-present blindly.
TRY IT YOURSELF
Asha Traders (as a Core creditor) collects EUR 84.50 from Riya under a valid mandate for a service she genuinely used. Six weeks later Riya asks Bank Alfa for a no-questions refund and the money returns. What is Asha Traders' correct read of the situation?
Direct debits unwind a collection after it has gone wrong. A newer control tries to stop the wrong payment before it leaves at all — by checking the name against the account. Next: Verification of Payee.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
SDD Core lets a debtor request a refund of an authorised collection within eight weeks, with no reason required.
- 02
A collection made without a valid mandate can be refunded for up to thirteen months after the debit date.
- 03
Rejects, returns, refunds, and reversals form the R-transaction family, each carrying a reason code back along the collection path.
Practical use cases / 04
Where you would use this
A creditor's finance team treats collected funds as provisional until the refund window closes, rather than as final revenue.
An operations analyst reviews R-transaction reason codes to find stale account data or missing pre-notifications.
A debtor's bank processes a refund request and applies the value adjustments the scheme rulebook prescribes.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional broadband provider, Cavendish Networks, collects EUR 54.90 from a customer on 10 June. On 2 July — 22 days later, inside the eight-week window — the customer asks their bank for a refund, giving no reason. The bank refunds EUR 54.90 and debits it back from Cavendish Networks. The refund does not settle the underlying dispute: if the invoice was valid the customer still owes it, so Cavendish Networks must pursue that separately. Had the customer instead claimed there was no valid mandate, the claim could be raised for up to thirteen months after 10 June.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01ProcessingAsha Traders confirms the mandateAsha Traders (creditor / biller)
Before pulling any money, the biller checks it holds a valid mandate that Riya signed authorising these collections. The mandate — not the invoice — is what permits the pull; no mandate means no right to debit.
- 05Clearing obligationThe CSM calculates obligationsSTEP2-T (CSM)
On the due date the CSM validates the collection and includes it in a clearing cycle, calculating who owes whom. In a pull this obligation runs from the debtor's bank to the creditor's bank — the reverse of a credit transfer.
Clearing produces obligations only. Nordbank does not have Asha Traders' money yet — that waits for settlement.
- 06SettlementPositions settle in central bank moneyBank Alfa (debtor bank) → Nordbank (creditor bank)
The calculated positions settle across the banks' accounts at the central bank. Money moves from Bank Alfa (debtor side) to Nordbank (creditor side) — funds flowing debtor to creditor even though the instruction came from the creditor.
- DR Bank Alfa settlement account — EUR 480.00
- CR Nordbank settlement account — EUR 480.00
- 07PostingBank Alfa debits RiyaBank Alfa (debtor bank)
Bank Alfa books the debit against Riya's account for the collected amount. This is the customer-facing side of the pull: money leaves the debtor's account because the mandate authorised it.
- DR Riya's current account at Bank Alfa — EUR 480.00
- 10 · EXCEPTION PATHSettlementThe refund settles backNordbank (creditor bank) → Bank Alfa (debtor bank)
The refund is itself cleared and settled — money moves from Nordbank back to Bank Alfa in central bank money, reversing the original pull direction.
- DR Nordbank settlement account — EUR 480.00
- CR Bank Alfa settlement account — EUR 480.00
- 11 · EXCEPTION PATHPostingBank Alfa re-credits RiyaBank Alfa (debtor bank)
Riya gets the full amount back. The eight-week refund is a right, not a favour — the biller must later chase Riya directly if it still believes the invoice is owed.
- CR Riya's current account at Bank Alfa — EUR 480.00
- OUTCOME
- Funds
- Returned to Riya's account after the refund settled.
- Settlement
- Original collection settled, then reversed by a separately settled refund.
- Who acts next
- Riya (debtor / customer) — Asha Traders resolves the disputed invoice with Riya directly; beyond 8 weeks a claim is possible only for unauthorised collections, up to 13 months, and is not automatic.
Evidence & review / 07
Evidence & review
SEPA Direct Debit Core and B2B schemes, euro area; refund rights per scheme rulebook and EU payment-services law.
What this brief simplifies: The eight-week and thirteen-month windows are named as scheme rights; finer return timings in interbank business days are described, not quoted; MD01 used as a representative reason code.
Sources for this brief4
- Scheme-specific rule2025 v1.1 (EPC016-06)
2025 SEPA Direct Debit Core rulebook version 1.1 (EPC016-06) ↗ — European Payments Council · R-transactions; refund windows; reason codes
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority · Unauthorised direct-debit refund right
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Return/refusal reason codes
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.