Skip to content
SEPA.tr

SEPA R-Transactions: Reject, Return, Recall and Refund

In SEPA a payment is not always completed successfully; it can be rejected, returned or recalled. This guide explains the four basic R-transactions — Reject, Return, Recall and Refund — who initiates them, when and with what time windows they work, with sources.

Updated:

Quick answer

R-transactions are the four ways a SEPA payment is processed in reverse.

Reject = rejection before settlement · Return = a return by the recipient's bank after settlement · Recall = the sending bank's recall request (e.g. wrong/fraud) · Refund = the debtor's refund right in SDD direct debit (authorised 8 weeks, unauthorised up to 13 months). Each is carried together with a reason code (AC01, AM04, MD01…).

In SEPA the vast majority of payments are completed smoothly, but not always. A wrong IBAN, a closed account, insufficient funds, a duplicate instruction or a suspicion of fraud can cause a payment to be reversed. The European Payments Council (EPC) gathers these "reverse" transactions under a common name: R-transactions. This page explains the four main R-transactions — Reject, Return, Recall and Refund — separately, showing which is initiated by whom, when and with what result. Note: the main source is the EPC rulebook and the time windows can vary by the relevant rulebook version; in a critical situation, always confirm with your bank.

What does R-transaction mean?

Every message that prevents a SEPA payment from being completed or reverses it after it has been initiated is technically an R-transaction. The letter "R" comes from the common first letter of the English names of these transactions (Reject, Return, Recall, Refund, Reversal, Request for Recall by the Originator). Each R-transaction is not a money movement in itself; most, in ISO 20022 messages (for example the pacs.004 return message), carry a reason code explaining what was returned and why. These codes (AC01, AM04, MD01, RR04, RC01…) travel with the transaction and are the source of the explanation your bank shows you. To decode the exact meaning of the code, you can use our SEPA reject/error code decoder tool.

The most critical distinction in understanding R-transactions is timing: the transaction falls into a different category depending on whether or not the settlement of the amount between banks has taken place. This is the determinant of both the process and of who can ask what from whom.

1. Reject — rejection before settlement

A Reject is the rejection of the payment before clearing and settlement are completed. That is, the money has not yet passed to the recipient bank; the transaction is stopped for a technical or formal reason while still in the flow stage. A Reject is usually initiated by the sending bank, the payment infrastructure (clearing) or the recipient bank before the settlement of the transaction.

Typical reasons for a Reject: a malformed IBAN, an invalid BIC, a missing mandatory field, or a message not complying with the scheme rules. As a result of a Reject, the amount that left the payer's account (if it did) is quickly reflected back, because settlement never took place. From the user's perspective, a Reject is the "cleanest" scenario: because the money did not change hands, getting it back is clear.

2. Return — a return by the recipient's bank after settlement

A Return is the sending back of the payment by the recipient's bank after the amount has reached the recipient's bank (after settlement). Here the money has actually passed to the counterparty bank; but the recipient bank cannot credit it to the account, or there is a situation where it should not credit it, and it returns the amount to the sending bank.

Typical reasons for a Return: the recipient's account is closed, the IBAN cannot be found at the recipient bank, the account is blocked, or the recipient refuses the payment. A Return is done within a specific time window defined in the rulebook and again returns with a reason code (e.g. AC04 closed account, AC01 wrong account). For the user, a Return is the "I sent it but it came back" scenario; whether the banks apply a return transaction fee on the incoming amount varies by bank — for exact information consult your bank. If your transfer was returned, our My SEPA transfer was returned tool can guide you.

3. Recall — a recall by the sending bank

A Recall is the request of the sending bank to recall a payment that has already been processed. Its difference from a Return is that the one initiating the request is not the recipient side but the sending side. A Recall is usually used in these situations: a duplicate (double) payment, an instruction wrongly processed as a result of a technical error, or a suspicion of fraud.

There is a very important point here: a Recall is a request, not a right. The sending bank sends a Recall message, but whether the amount actually comes back depends on the response of the recipient and the recipient's bank. The recipient bank can return the money (positive response) or refuse (for example if the amount has already been withdrawn). A special variant initiated by the sender themselves is called "Request for Recall by the Originator": the customer formally asks their bank to recall the payment, and the bank passes this to the recipient bank as a Recall. Again, the result is not guaranteed. Therefore, the honest answer to the question "can I cancel a SEPA transfer?" is: "you can try, but there is no guarantee."

4. Refund — the debtor's refund right in SDD

A Refund, unlike the three above, is specific only to the SEPA Direct Debit (SDD) scheme and expresses the legal refund right of the debtor (the party from whose account the payment was drawn). On the SCT (credit transfer) side there is no Refund; the Refund is the core of consumer protection in direct debit.

Two basic periods are defined in the EPC rulebook, and these are scheme-based, definite values:

  • Authorised (permitted) collection: Even if the mandate (authorisation) is valid, the debtor can request an unconditional refund (a no-questions-asked refund) within 8 weeks from the collection date; the bank refunds the amount.
  • Unauthorised (unpermitted) collection: If there is no valid authorisation (an unpermitted or mandate-less collection), the refund-request period can extend up to 13 months.

Because these two periods are defined in the EPC SDD rulebook, they are definite as a rule, not "according to indications"; still, the application detail and the assessment of exceptions can vary by bank and the relevant rulebook version. In a collection you are unsure about, confirm the refund process with your bank.

The difference between SCT R-transactions and SDD R-transactions

Which scheme an R-transaction belongs to matters. Roughly:

  • SCT (SEPA Credit Transfer): Reject, Return and Recall apply. The debtor's unconditional refund right (Refund) does not exist — because you are already the one who sent the money; getting it back is a matter of request.
  • SDD (SEPA Direct Debit): In addition to Reject and Return, there is also the Refund right (8 weeks / 13 months) not found in SCT. Furthermore, a pre-settlement concept of Reversal is also defined for the creditor side to reverse an erroneous collection.

In addition, in both schemes there is a "claim of non-receipt" / inquiry process used in cases where the recipient claims not to have received the money at all. This is not a money movement but an investigation/request flow between two banks; as a result, a Return or a correction can be triggered if needed.

Comparison table

Transaction Who initiates When Period Result
Reject Sending bank / clearing / recipient bank Before settlement Within the transaction flow, immediately The payment is never completed; the amount is reflected back
Return Recipient's bank After settlement A window defined in the rulebook The amount is returned to the sending bank
Recall Sending bank (can be at the customer's request) After the payment has been processed A window defined in the rulebook A request; the refund is not guaranteed (depends on recipient approval)
Refund (SDD) Debtor (the party whose payment is drawn) After the collection Authorised 8 weeks · unauthorised up to 13 months Refund to the debtor (unconditional in an authorised transaction)

The table is a general framework. The exact periods and exceptions can vary by the EPC rulebook version; in a critical transaction, get confirmation from your bank.

Reason codes come together with R-transactions

An R-transaction never returns "empty"; alongside it, it carries an ISO 20022 reason code explaining why it was returned. Frequently seen examples:

  • AC01 — the account number / IBAN is wrong or formally invalid.
  • AC04 — the account is closed.
  • AM04 — insufficient funds.
  • MD01 — there is no valid mandate (authorisation) (frequently seen in SDD).
  • RR04 — rejection for regulatory reasons.

Behind the "transaction returned" explanation your bank shows you there is usually one of these codes. To enter the code you have and see its meaning and what you need to do, use our SEPA reject/error code decoder tool.

What should you do in practice?

If your SEPA payment has been returned or has gone wrong, recognising the correct R-transaction saves time: if you entered a wrong IBAN and the amount came back, you probably experienced a Return; if you sent the money to the wrong person and want to cancel it, you can request a Recall from your bank — but the result is not guaranteed; if an unauthorised direct debit was drawn from your account, you can use your SDD Refund right (authorised 8 weeks / unauthorised up to 13 months).

In every case, the first step is to contact your bank and learn the reason code that came with the transaction. The information on this page is for informational purposes; the binding rules of SEPA R-transactions are defined in the European Payments Council's rulebooks in force and are updated over time. Do not assume any uncertain period on your own; confirm with your bank.

Frequently asked questions

What is the difference between Reject and Return in SEPA?

Both are a reversal of the transaction, but their timing differs. A Reject is a rejection before clearing and settlement is completed; the money never changes hands. A Return, on the other hand, is a return by the recipient's bank after settlement, after the amount has reached the recipient bank. Both come with a reason code such as AC01, AM04 or MD01.

How long does my refund (Refund) right last in SDD direct debit?

In the SEPA Direct Debit (SDD) scheme the debtor's refund-request right is defined in the EPC rulebook: for an authorised (permitted) collection, an unconditional refund can be requested within 8 weeks from the collection date. For an unauthorised (unpermitted) collection, the period can extend up to 13 months. The exact application can vary by your bank and the relevant rulebook version; confirm with your bank.

Can I get back a SEPA transfer I sent?

Once a SEPA Credit Transfer (SCT) has been processed, getting it back is not guaranteed. The sending bank can initiate a Recall request — for example in a wrong account, a duplicate payment or a suspicion of fraud — but the return of the amount depends on the approval of the recipient and the recipient's bank. This is a request, not a right.

What do codes such as AC01 or AM04 that come with R-transactions mean?

These are ISO 20022 reason codes: AC01 means the account number/IBAN is wrong, AM04 means insufficient funds, MD01 means there is no valid mandate (authorisation). Every R-transaction returns with one of these codes. To see the exact meaning of the code you can use our SEPA reject/error code decoder tool.

Sources

Confidence is graded from A (official document) to E (unverified).

SEPA scheme rulebooks & geographical scope

European Payments Council (EPC)

A
Document date:
2025
Last checked:
2026-07-16

ISO 20022 message standards (pain / camt)

ISO 20022 Registration Authority

A
Document date:
2025
Last checked:
2026-07-16

Register of Participants — official list of payment service providers that actually participate in the SEPA schemes (SCT, SCT Inst, SDD Core/B2B, VoP) (downloadable CSV/PDF/XML; SDD B2B register current as of 12 Jun 2026)

European Payments Council (EPC)

A
Document date:
2026-06-12
Last checked:
2026-07-16

Related content