Single Euro Payments Area (SEPA) R-transactions are messages that indicate a direct debit has failed or been cancelled. These messages pose risks that are often underestimated in collections management. Depending on when the transaction occurs, a payment that was considered collected can once again become unpaid, even several months after the due date.

SEPA debits are central to subscription-based models and other models with monthly or recurring billing. Examples include telecommunications, utilities, insurance, software as a service (SaaS), and gym memberships. All requested direct debits can result in an R-transaction. When this happens, the payment is reversed from the business's account, which often incurs bank fees. For businesses, this erodes working capital and has a direct impact on cash flow.

In this article, we explain what businesses need to know about SEPA R-transactions, including how they work, what reason codes mean, and how businesses can reduce and prevent unsuccessful transactions with SEPA Direct Debit (SDD).

Key takeaways

• Single Euro Payments Area (SEPA) R-transactions signify unsuccessful transactions that interrupt or cancel the typical cycle of a direct debit. They are associated with standardised reason codes and can result in the funds being returned to the business's account after settlement.
  
• There are five primary types of unsuccessful transactions: rejections, refusals, returns, refunds, and reversals. They are defined based on when they occur in the payment cycle and who initiates them.
  
• There are a variety of possible reasons for R-transactions, including customer account anomalies, insufficient funds, mandate issues, technical errors, and customer disputes. Each reason is denoted by a unique four-character code.
  
• The risks of R-transactions for businesses are significant and extend beyond simple payment failures. R-transactions can directly impact cash flow and working capital, result in recurring bank and administrative fees, and potentially harm a business's relationship with its bank.
  
• There are several concrete ways to minimise unsuccessful transactions. These include collecting accurate bank details, securing and digitising mandates, setting due dates according to customer profiles, prioritising the B2B scheme for business customers, and requiring backup payment methods so rejected payments can be recovered quickly.
  

What are SEPA R-transactions?

SEPA R-transactions are unsuccessful transactions that stop or reverse the typical payment cycle of direct debits. Notifications about R-transactions are typically issued by either the customer’s bank or business’s bank and are sent in the form of standardised interbank messages that include reason codes. The result is the reversal of funds from the business’s account after settlement.

The term “R-transaction” comes from the European Payments Council (EPC), where all unsuccessful transactions have labels that begin with the letter R. These include rejections, returns, refunds, refusals, and reversals.

SEPA R-transaction rules depend on which direct debit scheme is used: SDD Core or SDD B2B. SDD Core is the standard scheme aimed at both businesses and customers. SDD B2B is an optional scheme reserved for individuals and businesses engaging in business transactions. It has stricter requirements. For instance, the customer’s bank must receive confirmation of mandate details before debiting the account. However, authorised transactions (i.e., direct debits with valid mandates) cannot be refunded.

SEPA R-transactions can occur before (e.g., refusals and rejections) or after (e.g., returns, refunds, and reversals) an SDD:

• Before settlement
  Rejections and refusals occur before funds are transferred. This means transactions are cancelled before they take place. This is the best case scenario for businesses. They are notified of payment failures before funds are collected, so there are no transactions to void.
  
• After settlement
  Returns, refunds, and reversals are paid transactions that are settled in the opposite way. Funds credited to the business are revoked, meaning the payment is reversed. This has a direct, immediate impact on cash flow.
  

What are the different types of SEPA R-transactions?

There are five types of SEPA R-transactions, as defined by the EPC's rulebook. They include rejections, refusals, returns, refunds, and reversals. They are categorised by the initiator of the transaction, when it occurs in the interbank settlement cycle, and whether the funds have already circulated.

Here are the different types of R-transactions:

Rejections

Rejections occur before interbank settlements. The customer's bank – and occasionally the business's bank – stops the transaction for technical or functional reasons, such as an invalid file format or nonexistent International Bank Account Number (IBAN). No funds are transferred, making the incident easier to process from an accounting perspective.

Refusals

Customers initiate refusals by asking their banks to stop upcoming direct debits before they are due. A refusal can apply to a single payment due date, with the authorisation remaining valid for subsequent debits. A refusal can also be accompanied by a general stop-payment order on the account.

Returns

Customers' banks issue returns after interbank settlements. The most common reason is insufficient funds. In this case, funds credited to the business are revoked. Returns pose the biggest risk related to unpaid direct debits.

Refunds

Customers request refunds after direct debits have been debited from their accounts. With SDD Core, customers are entitled to unconditional refunds for eight weeks after each debit. Refunds are not permitted between eight weeks and 13 months, unless the transaction is unauthorised (i.e., without a valid mandate).

Reversals

Reversals are SEPA R-transactions initiated by customers or their banks after settlement. Reversals refund wrongful direct debits to customers. This might occur because of a duplicate invoice or an internal error.

Revocations and requests for cancellation

Revocations and requests for cancellation allow businesses and banks to stop transactions before they settle. They are governed by bilateral agreements, not the payment scheme:

• Revocations
  This is a request by the business to its payment processor to stop a direct debit order before it enters the interbank circuit, up to an agreed-upon date. Customers can request revocations from businesses.
  
• Requests for cancellation
  A request by the business's bank or payment processor to the compensation or settlement system to stop a transaction. A request for cancellation is an alternative to revocation if the deadline has passed. Requests for cancellation can be made if an error is detected (e.g., duplication).
  

How do SEPA R-transactions work?

SDDs circulate between four parties: the business, business’s bank, exchange system, and customer’s bank. R-transactions follow the same circuit in reverse. The customer’s bank notices an anomaly—such as insufficient funds—and sends a reason code to the business. The business’s account is debited for the amount initially received.

Here’s how SEPA R-transactions happen:

Prenotification and remittance

The business informs the customer of the balance and due date. Next, it sends the direct debit order to the bank with its SEPA creditor identifier (CI number) and the unique mandate reference (UMR) number. If the business’s bank detects an anomaly at this stage—such as an invalid file—the payment will be rejected before it enters the interbank circuit.

Interbank transfer

The business’s bank transmits the transaction to the exchange system, which forwards it to the customer’s bank. Under both schemes, the customer’s bank must receive the transaction no earlier than 14 calendar days and no later than one interbank working day before the due date.

Verification by the customer bank

The customer’s bank verifies that the account exists and is able to receive direct debits and that bank details are accurate. Under the B2B scheme, the bank verifies there is a valid mandate confirmed by the customer. Any failure at this stage triggers a rejection. When customers receive prenotification, they can ask the bank to stop payment, which triggers an R-transaction.

Interbank settlement

On the due date, the customer’s account is debited, and the business’s account is credited. After settlement, any R-transaction will cause funds already transferred to be revoked, immediately affecting the business’s cash flow.

Return, refund, and reversal

After the due date, the customer’s bank can return the payment on its own—typically for insufficient funds—or on behalf of the customer if they are exercising their refund rights. Businesses can also initiate reversals of wrongfully debited funds.

Restitution to the business and resolution of the incident

The business’s bank revokes the payment transferred, typically the same day it receives the R-transaction message. The bank might also charge a failed payment fee and send the reason code to the business. The business can then decide to make a new request, correct the bank details, revise or close the mandate, send the customer a reminder, or send the bill to collections.

Why do SEPA R-transactions occur?

There are six reasons why SEPA R-transactions might occur. They include customer account anomalies, insufficient funds, mandate or authorisation problems, technical or format errors, customer disputes, and legal blocks.

Here are the main reasons for R-transactions:

Customer account anomalies

The customer's account might have been closed, transferred to another institution, or blocked by a legal ruling, third-party attachment, or third-party administrative seizure. Alternatively, the account might not permit payments to be directly debited, as with certain types of savings accounts. In addition, the death of the customer requires the business to terminate the contract and cancel all future payment requests.

Insufficient funds

The customer's account exists, and the mandate is valid. However, the account balance is insufficient to honour the payment on the due date. In this case, the customer's bank issues a return within five interbank working days of the SDD Core debit.

Insufficient funds are also the primary reason for new identical payment requests. If the file is correct and the mandate is valid, typically funds need to be deposited into the account for the next scheduled payment to go through.

Mandate and authorisation problems

Mandate and authorisation problems trigger direct debit rejections or returns. These problems include missing mandates, revoked mandates, inconsistent UMRs, and erroneous direct debit request sequences (e.g., requests for recurring direct debits with no prior direct debit history).

Technical and format errors

Errors likely to trigger R-transactions include invalid IBANs, non-compliant transaction codes, incorrectly formatted extensible markup language (XML) files, or missing required information.

These errors are the responsibility of the business or their payment processor and are the easiest to permanently correct.

Customer disputes

Customer disputes include two legally distinct scenarios. The first scenario concerns disputes of authorised transactions. Article L133-25-1 of the Monetary and Financial Code entitles customers to unconditional refunds for eight weeks after payments made by SDD. No justification is required. The bank has 10 working days to refund the payment or justify refusal.

The second scenario involves disputes of unauthorised transactions. This refers to transactions made without valid consent (e.g., non-existent, revoked, or lapsed mandates). Customers have 13 months from the debit date to dispute the transaction.

Legal reasons

SDDs can be blocked from an account for legal reasons. Transactions can also be blocked due to required information that is missing. In either case, businesses cannot correct the issue on their own. It is the responsibility of the customer and their bank to remove the block. Any new direct debit requests made before the block is resolved will trigger a new incident.

What R-transaction codes do banks use?

R-transaction reason codes have four characters. They signify the cause of the incident and its resolution (e.g., re-requesting payment, correcting inaccurate information, or suspending payment).

The primary R-transaction codes are as follows:

• AC01 (incorrect bank details): The IBAN format is incorrect or does not exist in the customer bank's records. The business must obtain new bank details before making another payment request.
  
• AC06 (blocked account): The customer has blocked all direct debits from their account, or the account has been blocked by a legal ruling, attachment, or embargo. The business must contact the customer.
  
• AC13 (consumer account): This code is used only for B2B direct debits, which cannot be requested from consumer accounts. The business must switch the customer to an SDD Core mandate.
  
• AG01 (transaction forbidden): This code can apply in three cases. The first case involves an account that is not eligible for direct debit withdrawal due to the type of account (e.g., a Livret A savings account or home savings plan [plan épargne logement, or PEL]). The other two cases involve transactions that are prohibited for legal reasons and direct debit requests that fall outside permitted time windows.
  
• AM04 (insufficient funds): Even if the account contains funds to make a partial payment, the entire amount will be rejected. SDDs do not allow partial payments.
  
• AM05 (duplication): The customer's bank has previously processed the same transaction. The business must verify its payment requests before issuing new ones.
  
• BE05 (unrecognised initiator): The CI number is missing or in the wrong format, or it doesn't appear in the national database of identifiers. The error must be corrected with the business's bank.
  
• ED05 (failed settlement): Settlement of the direct debit failed, and the customer's bank or the exchange system must report a settlement failure.
  
• FF01 (invalid file format): The file has been completed incorrectly (e.g., syntax error, missing required information, forbidden character). The business or their payment processor must correct the issue.
  
• MD01 (no mandate): The mandate is nonexistent, unsigned, cancelled, revoked, or lapsed after 36 months of inactivity. In B2B transactions, this code also signifies that the customer's bank was not able to confirm the mandate.
  
• MD06 (customer dispute): The customer is exercising their right to a refund of an authorised transaction within eight weeks of settlement. This code is reserved for standard direct debits. The customer's bank cannot issue B2B refunds because the B2B scheme does not allow refunds of authorised transactions.
  
• MD07 (customer deceased): The date of death must precede the payment due date. The business must terminate the contract and suspend direct debit requests.
  
• MS02 (customer refusal): The customer asks their bank to stop payment on a transaction without specifying a reason or has blocked payment on a specific CI number and UMR. The customer must be contacted.
  
• RR01 to RR04 (legal reasons): Legally required information is missing, such as the customer's account number or ID (RR01), the customer's name or address (RR02), the business's name (RR03), or other legal requirements (RR04).
  

The complete list of codes – including those specific to each scheme – can be found in this brochure from the French Committee for Banking Organisation and Standardisation (Comité français d'organisation et de normalisation bancaires, or CFONB).

How do SEPA R-transactions affect businesses?

SEPA R-transactions create a gap between Revenue invoiced and Revenue collected. The results are reversed payments, bank fees, slowed cash flows, and increased administrative burdens. Conversely, when monitored and analysed appropriately, R-transactions can act as advanced indicators of Customer database quality and the robustness of the Collection Process.

Direct impacts on cash flow

Direct debits returned after Settlement create a debit Transaction in the Business’s Account, sometimes weeks after Payment was collected. For businesses with fixed expenses that depend on recurring Revenue, returned payments disrupt the cash flow cycle and create unanticipated cash flow issues.

This discrepancy automatically increases the need for working capital because the Business must use its own resources to finance receivables it expected to have already collected.

Direct and indirect bank costs

The Business’s bank typically charges a Fee for each rejection and return. Added to that is the Business’s administrative costs, including investigating the reason for the incident, contacting the Customer, revising the mandate, resending the Payment Request, sending a reminder, and possibly sending the bill to collections.

Lower Collection rates

Failed payments that are not resolved quickly might never be paid. The longer the delay between the R-transaction and contact with the Customer, the more likely that the Payment will never be collected. This is especially true if there are many invoices for small amounts.

Customer database quality indicators

A high rate of technical codes (e.g., AC01, FF01) can indicate a poor database of bank details or a flawed data Collection Process. A high rate of dispute codes (e.g., MD01, MD06, MS02) can indicate an issue with authorisations or clarity in Business dealings or communications.

Less advantageous banking terms

Banks and payment providers track R-transaction rates of their Business customers. A consistently high rate can result in a demand for more guarantees, higher fees, or revocation of a Business’s Direct debit Authorisation.

Compliance and security issues

Rigorous management of mandates and R-transactions directly helps lower the risk of fraudulent direct debits. In France, there was €16.3 million in Direct debit Fraud in the first half of 2024, a 31% increase from the previous year. The most common cases involved fraudulent direct debits sent without a mandate or using a stolen CI number.

Business success indicators

If tracked by Customer category, product, acquisition channel, and reason code, SEPA R-transaction rates can serve as independent indicators of operational performance. They can help businesses make objective decisions about commercial policies. For instance, a Business might choose not to allow direct debits as a Payment method for certain risky segments.

What are the time limits for SEPA R-transactions?

Time limits depend on when the incident occurs. Rejections and refusals occur before settlement. Returns can occur up to five interbank working days after the due date, in the case of standard SDDs. For B2B SDDs, returns can occur up to three days after the due date.

Refunds are allowed for up to eight weeks. They are allowed for up to 13 months for unauthorised transactions.

The time limits for R-transactions include the following:

• Rejections and refusals: Before settlement
  Customer banks must receive direct debits no earlier than 14 calendar days and no later than one interbank working day before due dates. Rejections can be made within this window for technical or functional reasons, and customers can exercise their right of refusal up to and including the due date.
  
• Returns of standard SDDs: Five interbank working days
  Customer banks can issue returns after settlements—such as those due to insufficient funds—within five interbank working days following the settlement date.
  
• Returns of B2B SDDs: Three interbank working days
  The period for settling returns is three interbank working days after a transaction’s settlement date. This is a shorter period than for the standard scheme. It reduces but does not eliminate the business’s period of uncertainty for B2B direct debits.
  
• Refunds of authorised transactions: Eight weeks
  For standard SDDs, a customer can ask their bank to refund an authorised debit within eight weeks of the direct debit date without justification.
  
• Refunds of unauthorised transactions: 13 months
  Customers typically have 13 months from the debit date to claim a transaction was unauthorised. Claims cannot be made after that time. This rule applies to both SDD Core and SDD B2B direct debits. However, if the customer is acting as a business, the contract with the customer’s payment processor can stipulate a different time limit.
  
• Business-initiated reversals: Five interbank working days after the due date
  If the business notices an issuance error—such as a duplicate or incorrect amount—it can ask its bank to reverse the funds to the customer within five interbank working days of the original payment due date. The customer’s bank does not verify the reversed transaction.
  
• Lapsed mandate: 36 months
  If a direct debit request has not been made on a given mandate for 36 months from the due date of the last debit—even if the direct debit was rejected, returned, or refunded—it is considered to have lapsed and must be replaced with a new mandate and a new UMR. A series of rejected payments does not interrupt the countdown.
  

How to minimize SEPA R-transactions

It’s impossible to completely avoid R-transactions. Nevertheless, there are three ways to minimise technical incidents and certain disputes: ensure accuracy of data and mandates, choose smart due dates, and track incidents by reason code.

Here are more ways to minimize R-transactions:

Ensure accurate Collection of bank details

Real-time verification of the IBAN format, check code, and associated Bank Identifier Code (BIC) at the time they are entered can eliminate many rejections for technical reasons. An Account holder verification department can also help ensure data collected is accurate and reduce subsequent disputes due to lack of Authorisation.

Secure and digitise mandates

Businesses must secure Customer consent at the time of enrollment. They can electronically obtain Authorisation, verify the Customer’s identity, maintain a record for evidentiary purposes, and immediately send the Customer a confirmation that includes the IC number, UMR, and a description that will appear on the Customer’s Account statement.

This reduces the risk of disputes over unauthorised transactions and enables a prompt response to a Request from the Customer’s bank for the Authorisation form.

Create clear Direct debit descriptions

Transaction descriptions that include a business name are easily recognisable by customers. This can eliminate many good-faith disputes made under codes MD06 and MS02. Customers rarely dispute transactions they recognise.

Send clear prenotifications

Businesses need to inform customers of the amount and date of each Direct debit. A clear notification sent with sufficient notice can preempt problems due to insufficient Funds and good-faith refusals.

Choose smart due dates

Scheduling direct debits for the start of the month and after typical paydays can help reduce returns from Individual customers resulting from insufficient Funds. For Business customers, syncing with Customer Payment cycles can have the same effect.

Keep mandate records up to date

This can help businesses avoid transactions that are likely to fail. Make sure to clear out mandates that have lapsed after 36 months, update new Customer IBANs, and deactivate mandates for closed accounts or deceased customers.

Use B2B SDDs for Business customers

The B2B SDD scheme does not allow refunds on authorised transactions and requires the Customer’s bank to receive confirmation of mandate data before debiting the Account. These two steps eliminate the main source of uncertainty under the standard scheme: unconditional refunds for eight weeks.

Evaluate segment risk and use mandatory backup Payment methods

Tracking SEPA R-transaction rates by Customer segment, offer, and acquisition channel allows businesses to adjust their Payment Terms. For example, businesses can require risky segments to make first payments by bank Card or Bank transfer before the mandate is activated.

Saved Card information and online Payment links also help businesses quickly Collect payments rejected for insufficient Funds, without waiting for the Payment Request cycle.

Anticipate regulatory changes

SEPA documentation changes regularly. The CFONB has announced that unstructured addresses will no longer be accepted in SEPA messages beginning 15 November 2026. Only structured and hybrid formats will be accepted. Anticipating these technical changes is an important part of preventing R-transactions.

Document and track Collection chains

High-volume businesses benefit from test environments where they can simulate primary R-transaction scenarios and verify that each reason code triggers the correct action in the management system.

How Stripe Payments can help

Stripe Payments provides a unified, global payments solution that helps any business – from scaling startups to global enterprises – accept payments online, in person and around the world.

Stripe Payments can help you:

• Optimise your checkout experience: Create a frictionless customer experience and save engineering time with prebuilt payment UIs, access to 125+ payment methods, and Link, a wallet built by Stripe.
  
• Expand to new markets faster: Reach customers worldwide and reduce the complexity and cost of multicurrency management with cross-border payment options, available in 195 countries across 135+ currencies.
  
• Unify payments in person and online: Build a unified commerce experience across online and in-person channels to personalise interactions, reward loyalty and grow revenue.
  
• Improve payments performance: Increase revenue with a range of customisable, easy-to-configure payment tools, including no-code fraud protection and advanced capabilities to improve authorisation rates.
  
• Move faster with a flexible, reliable platform for growth: Build on a platform designed to scale with you, with 99.999% historical uptime and industry-leading reliability.
  

Learn more about how Stripe Payments can power your online and in-person payments or get started today.

FAQs about SEPA R-transactions in France