Rejected direct debits: How can the merchant analyse and optimise R-transactions?

For a merchant, optimising payment processes is essential to maintain operational efficiency and minimise costs.

One of the major concerns in this area relates to failed transactions, in particular rejected direct debits.

Failed transactions are detrimental to the financial health of your company, as they prevent you from achieving the financial results you had hoped for in a timely manner.

Rejected direct debits, whether caused by human error, technical incidents or other factors, can have a significant financial impact on a merchant if they are not proactively managed and optimised.

Today, many companies offer subscription models to provide consumers with products or services on a regular basis.

However, this subscription-based business model involves challenges associated with direct debits, such as rejected payments and processing errors, which can have a significant impact on performance.

Failed direct debit transactions can cause various problems for merchants, in particular:

loss of income when the payment is not successful and the funds are not received,
costly rejection fees,
a negative impact on customer relations due to frustration and dissatisfaction,
the additional time and effort required to resolve problems related to failed transactions,
as well as the risk of fraud and further financial losses.

If collection processes are not automated, merchants lose money and waste time identifying failed transactions and their causes.

This is especially true for companies in the subscription sector, where customer retention is crucial to their business model and their success.

It is thus essential for these companies to keep their customers engaged and satisfied so that they keep on renewing their subscriptions.

To minimise these problems, it is important for merchants to monitor and understand the reason for a rejected direct debit, to use reliable payment systems and to keep their bank details up to date.

In this in-depth article, we explore the different types of rejected direct debit, the associated rejection codes and present various ways of avoiding them.

We also suggest best practice for managing rejected payments when they occur, and look at how they can be used to improve future payment processes.

What is an R-Transaction?

Before solving a problem, it is essential to understand the causes.

“R-transaction” is the term used to describe a payment transaction that has not been authorised or has failed for a given reason.

Failed transactions, or R-transactions, may be the result of various factors such as data entry errors, expired payment cards, technical problems on payment platforms or authorisations refused by the issuing bank.

An in-depth analysis of the specific reasons for failure is the first step towards optimising them.

What are the grounds for rejecting a direct debit?

Whether initiated by the merchant, the consumer or the bank, it is essential to understand the reasons behind rejected direct debits.

→ There are several reasons why consumers and account holders may reject a direct debit:

Suspected fraud: when the account holder has detected actual or probable fraud linked to suspicious movements on their bank account;
Change in payment method: in the event of a change of bank, for example, the account holder may choose to reject a direct debit transaction until the change has been made;
Dispute over the amount debited: if the amount to be debited is changed by the creditor or if the creditor makes a mistake;
Insufficient funds: this is one of the most common grounds for rejection of a direct debit. If debtors do not have the necessary funds for the direct debit and become aware of this beforehand, they can reject it up to 10 days before the due date. This rejection request must be made directly to the debtor’s bank. However, if the due date is reached and there are insufficient funds to cover the amount of the direct debit, it will be rejected directly (see reason AM04).

When the due date has already been reached (and hence the payment has been made), the debtor has 3 days to refuse the direct debit.

→ Rejection can also come from the merchant.

If you put a stop on the direct debit, your bank may reject the transaction.

Note that there can be several reasons for rejections of this type, such as:

poor quality of service,
customer dissatisfaction with the product or service linked to the direct debit,
or customer disagreement over the amount debited.

In this context, and as part of your customer-friendly sales policy, you want to cancel the direct debit to compensate your customer.

Other marginal situations may arise, such as:

Expiry of the mandate: direct debit mandates often have an expiry date in time so that the credit can be made for the creditor’s bank. A direct debit will be rejected on the grounds that the mandate has expired if it has not been renewed or updated with the necessary information;
Disagreement over the invoice or its amount: if the debtor company disputes the validity of an invoice or if there has been a disagreement over the service provided, it may choose to reject the direct debit;
Stoppage for legal or regulatory reasons: in some cases, payment transactions, particularly direct debits, may be stopped under national or European regulations, or in the case of transactions that compromise the regulations on anti-money laundering and combating the financing of terrorism (AML/CFT).

It is essential for merchants to ensure that bank details are correct, that the required authorisations are obtained and that direct debit mandates are up to date to avoid rejected direct debits and maintain smooth commercial relations with their customers.

Failed direct debit transactions and error codes: what you need to know

In summary, the SEPA Direct Debit can be partially or completely cancelled via R-transactions, which may be:

→ At the initiative of the debtor or the debtor’s bank:

“Reject” (Code REJ) means that the debtor’s bank has rejected the direct debit. This can happen before execution by the bank, between D-1 and D (“D” being the execution date).
“Return” (Code RET) means that the debtor’s bank has returned a direct debit due to a problem during its execution. This can happen after execution by the bank, between D and D+5.
“Refund”: between D and D+8 weeks, the debtor can request a refund without giving a reason. Between D+8 weeks and D+13 months, debtors may only request a refund they claim never to have signed a direct debit mandate.

→ At the initiative of the creditor or the creditor’s bank:

Request for cancellation (RFC) before the direct debit due date;
Reversal: up to two days following the direct debit due date.

Below is a summary of R-transactions by initiator and payment date:

Initiator of the rejected direct debit	Before payment of the direct debit	After payment of the direct debit
Creditor	Revocation	Reversal
Creditor’s bank	Request for cancellationReject	Reversal
Debtor’s bank	Reject	Return
Debtor	Refusal	Refund

R-transaction codes are used to indicate why a direct debit transaction has failed.

There are currently around a hundred codes in use in France, all governed by the ISO standard, the current standard (ISO 20022) is for 4 characters, with two letters followed by two digits.

The most commonly used codes are:

AC04: Account closed. The customer must be asked to provide new account details.
AC06: Account blocked, the debtor has blocked SEPA Direct Debits on this account.
AG01: Transaction forbidden, direct debits are prohibited on this account for regulatory reasons.
AM04: Insufficient funds. The transaction must be re-submitted once the account has been replenished.
AM05: Duplication, the direct debit transaction must be re-submitted using different data.
RC01: BIC incorrect. The customer must be asked to provide the correct BIC.
MS02: Refused by the debtor. The customer must be contacted to find out the grounds for refusal.
MD01: Invalid mandate or no mandate on the account.
MD07: Debtor deceased. The contract with the debtor must be terminated to avoid further rejected direct debits.

An exhaustive list of error codes is available in our Help centre.

These rejection codes can help companies understand why direct debit transactions have failed, enabling them to take preventive action and avoid future rejects.

What are the risks of ignoring failed transactions?

Merchants that implement automated management of failed transactions and automate their collection processes limit the risk of rejection, and hence of non-payment and the associated costs.

This is especially true now that there are dedicated solutions to help manage failed direct debits.

Note that there are costly rejection fees to consider, as well as the extra effort required to recover failed transactions.

Under these circumstances, the costs associated with rejection can be considerable.

→ Fees for a failed transaction may include:

additional processing fees,
customer service fees for dealing with complaints,
fees for the refund of rejected direct debits,
and additional fees when processing future transactions.

If unjustified and/or unidentified, failed transactions can lead to frustration among customers and may encourage them to make complaints that are detrimental to the company, with social networks playing a predominant role in the world today.

Finally, failed transactions can lead to a potential loss of customers, with a negative impact on the merchant’s financial results.

How can you solve the problem of rejected SEPA Direct Debits?

While there is no magic formula and everything depends on the grounds for rejection, you can limit the number of rejected direct debits by taking the following steps.

Re-submit the transaction

A further attempt will then be made to recover the rejected/refused payment.

This can be automated using our Automatic Retry function.

As a result, as soon as a transaction is refused, it is automatically represented according to certain predefined management rules.

This option can be customised based on a prior study of all rejected transactions. Each company can choose which codes will result in Automatic Retry.

Offer an alternative payment method

If the first direct debit payment is refused, you can offer another payment method. In particular, the new payment can be made via an email sent to your customer.

On receipt of this email, the customer can click on the payment link and will be redirected to the checkout to make an online payment for the outstanding amount.

Be sure to collect the correct bank details on sign-up

The SlimCollect Verify solution makes it possible to logon to a customer’s bank account, with their consent, to collect specific data such as the IBAN or the name of the account holder.

This data can be used on its own to check the validity of an IBAN, or combined with a payment method.

Analyse and continuously optimise data

Data analysis is the key to continuous optimisation.

Regularly monitor trends in failed transactions, identify patterns and adjust your strategies accordingly.

It may be that certain times of day have a higher failure rate, or certain types of product are more prone to error.

By adjusting your systems and processes in line with this data, you can significantly reduce the number of failed transactions over the long term.

Automate the direct debit management process using a dedicated solution

As we have seen in this article, there are many reasons why direct debits may be rejected.

To overcome this, it is essential to have a responsive management process in place in the event of a rejected direct debit.

Good management of direct debit flows includes proactive monitoring of failed transactions, alerts via dedicated notifications and automated re-submission of rejected direct debits to quickly resolve disputes between the parties and issue a refund where appropriate.

The end-to-end process can be delegated to companies specialising in direct debit management, using solutions such as those offered by SlimPay.

Automatic Retry: a SlimPay solution to limit your loss of earnings

Automatic Retry is a solution that enables merchants to easily reduce the number of failed transactions through an automated process, thus increasing turnover and maximising the value of each customer.

Failed transaction (or R-transactions) cannot be avoided 100%, they are a fact of business life.

But most of these failed transactions can be recovered simply and automatically using Automatic Retry.

→ The rate of successful transactions is thus preserved for the merchant and loss of customers is avoided.

The Automatic Retry solution from SlimPay has a 24% success rate in terms of volume (total recovery of initially failed direct debits), resulting in an average increase in our merchants’ revenues of 2%.

The “Retry” process is automated, transparent and secure for both the merchant and the customer.

Automatic Retry: how it works

We can set up an alert, which SlimPay sends by SMS or email, to inform the customer that a new attempt will be made to make the direct debit.

SlimPay is then able to make several further direct debit attempts if the transaction continues to fail.

These attempts are configured after an analysis of the data to find the best dates for further direct debits and increase the chances of a successful transaction.

The creditor can, of course, decide whether or not they wish to inform their customer of each of these attempts.

Automatic Retry: available options

Automatic Retry can be configured to suit your specific needs.

There are a number of configurations to choose from. Here are 5 examples:

1. Number of automatic retries

Configure the number of attempts to maximise the chances of recovering failed payments.

→ Example: Payments can fail for a variety of reasons, but Automatic Retry can help to increase your turnover, especially if large amounts are involved. It is recommended to carry out at least two Automatic Retries.

2. Time before execution

Define the appropriate timeframe for executing Automatic Retries, once the R-Transaction has been received.

→ Example: if payments tend to fail at the end of the month, you can set up a 3 to 5 day lead time to increase the chance of recovering payments, as debtors will generally have received their salary.

3. Working day of execution

Choose the working day on which you wish to execute your Automatic Retries.

→ Example: if payments tend to fail less frequently at the beginning of the month, it makes sense to carry out the Automatic Retry between the 1st and 5th working day of the month.

4. Amount of transactions to re-submit

Define the range of transaction amounts that you want to re-submit.

→ Example: some low-value transactions will have little impact on your income. You can thus choose only to re-submit transactions worth more than €100.

5. Codes of R-transactions to re-submit

From the list of R-Transaction codes that can be re-submitted by SlimPay, select only the most relevant.

→ Example: only authorise Automatic Retry on R-Transaction code AM04 (insufficient funds, the limit of available funds has been reached), as these are the most frequent and the situation is usually temporary.

An exhaustive list of options is available in our Help centre.

Conclusion

At the end of the day, transaction failures can cause significant financial damage to a company, including loss of revenue, additional costs and a poor brand image.

By understanding the different types of failed transactions and the associated error codes, merchants can minimise processing errors and refused payments.

By effectively managing refused payments when they occur, companies can also learn lessons to improve their future payment processes.

Hence, it is important for them to take account of failed transactions and implement effective strategies, such as Automatic Retry.