Refer to Payer & other common Direct Debit ARUDD failures
Direct Debit is a convenient and cost-effective way to manage regular collections of money. It can be frustrating though when Direct Debit Collections fail. As well as disrupting cash flow, failures require administrative time and effort to address. Luckily Service Users are told about Direct Debit failures via the Bacs Automated Return of Unpaid Direct Debits Service – or ARUDD. This means Service Users can work to resolve issues quickly after they arise. But – do you know what error codes such as ‘Refer to Payer’ or ‘Instruction cancelled’ mean?
What is a Direct Debit?
A Direct Debit is an automated bank-to-bank payment that is governed by Bacs (now part of Pay.UK). It is a payment method used by organisations such as utility providers, membership bodies, charities, not-for-profits and corporates of all sizes. These organisations need to be approved to use Direct Debits in order to collect their income. Once approved, they are known as ‘Service Users’. The Service User will initiate the request for payment and money is received on a known date into the Service Users bank account.
The ARUDD Report
When a Direct Debit fails, Service Users receive an ARUDD Report. This is generated by Bacs on Day 4 (sometimes Day 5) of the Bacs cycle. The Report tells Service Users why the Direct Debit collection has failed.
Accessing and understanding this report can help Service Users take the most appropriate next course of action.
Reasons for Direct Debit Failures
There are 12 different error codes used on the ARUDD report to provide information about why a direct debit has been returned unpaid. They are:
- 0. Refer to payer
- 1. Instruction cancelled
- 2. Payer deceased
- 3. Account transferred
- 4. Advance notice disputed
- 5. No account or wrong account type
- 6. No instruction
- 7. Amount differs
- 8. Amount not yet due
- 9. Presentation overdue
- A. Service user number differs
- B. Account closed.
Reason Code 0 – Refer to Payer
Refer to Payer is the most common error code used to explain why a Direct Debit payment has failed. It simply means that a specific collection has been returned unpaid and the Service User should liaise with the payer to find out why. It is often interpreted to mean that the payer has insufficient funds in their account – and it may often mean this. There are other reasons why this code is used however and so insufficient funds should not be assumed.
If you receive failures with ‘Refer to Payer’, you may decide to contact your payer and ask why. It might appear to your payer as if the payment has been taken from their account, although it would show as being returned later the same day. You might ask if they would like you to try to collect the Direct Debit again. If you do, Bacs recommended you give Payers at least 5 working days’ notice of a new collection date. If you can reasonably assume that conditions for collection could be met upon a second attempt however, you can choose not to contact the payer. Instead you could automatically represent the Direct Debit. You can do this up to one month from the original processing date.
Other Common Error Codes for failures
Reason Code 1 – Instruction cancelled
If a customer cancels a Direct Debit Instruction (DDI) via their bank, you will receive an ADDACs report notifying you of the cancellation. If you do not update your database with ADDACS reports regularly, you may miss these notifications. You could then attempt a collection when the underlying authority (DDI) has been cancelled. If so, this would prompt a failure on ARUDD for reason code 1 – Instruction cancelled. On an ARUDD report you can’t tell whether the DDI has been cancelled by the Payer or the bank – and this could affect the action you take next. Best advice is to review ADDACS reports and check if you have already been notified about this cancellation.
Reason Code 6 – No instruction
If you receive a failure due to reason code 6 – No Instruction, it can be tempting to simply send the AUDDIS instruction again and try to lodge the Direct Debit Authority on the Payers account. And this might be the correct action to take, for example if you have missed sending a file of new AUDDIS instructions. It might not be the correct action though so it’s important to run some checks first. You could consider the following before deciding upon next steps:
- Has the AUDDIS instruction been sent? If not, send it.
- If it has been sent, did you allow enough time for the instruction to lodge before you tried to collect? If you didn’t allow enough time it might now be live and you don’t need to resend. If you did allow enough time…
- Did the lodgement of the AUDDIS instruction fail? Were you advised of this on an AUDDIS report that you may have missed? If so, sending the Instruction again will not necessarily change the outcome. Instead you could review your AUDDIS reports and processes to ensure you don’t miss future advices.
- Has the Instruction been cancelled (or expired) and you have missed the notification of this that you should have received via an ADDACS report?
- Have you used a different reference in your Direct Debit collection vs the reference that was lodged with the AUDDIS instruction? If so, you correct the reference submitted and try again.
Dealing with Failed Direct Debits
When considering the appropriate actions to take in response to failed Direct Debits there are 2 key questions it can be helpful to ask:
- Is this a temporary failure related to one collection or a more permanent failure that impacts the underlying authority?
If temporary – for example you receive reason code 0 – refer to payer, then you may decide to represent the Direct Debit. If it is a more permanent failure, i.e. reason code 1 – Instruction cancelled, then you will need to resolve the underlying authority (and ensure one is live on the account) before attempting to collect again. - Is this within your control or outside of your control?
For example, if you receive a failure due to reason code 2 – Payer deceased, this is outside of your control and a permanent instruction to the bank to allow no further Direct Debits. If however, you receive a failure due to reason code 4 – Advance notice disputed, you should consider whether it is within your control to prevent future occurrences of this failure code. You may wish to check that Advance Notice is always being sent – and that it is being sent to the correct person (Payer) – and in a format they can understand.
Preventing Direct Debit Failures
It will not be possible to prevent all Direct Debit failures, especially those such as 0 – refer to payer and 2 – payer deceased. Ensuring you have an efficient and compliant Direct Debit Scheme in place however, will help keep possible failures to a minimum – and limit them to those outside of your control. Remember to:
- Regularly check and action your Bacs reports – including both ADDACS and AUDDIS reports. This will ensure that you have the cleanest possible dataset and therefore the highest change of success.
- Consider automatic re-presentation of Direct Debits for those returned as reason code 0 – refer to payer.
- Where possible, allow customers to choose a Direct Debit collection date (e.g.: to coincide with their pay day). This can help them ensure funds are available in their account.
- Make sure you give your Direct Debit customers sufficient advance notice taking into account delivery time (e.g.: post)
- Make sure your processes ensure you allow enough time between submitting Direct Debit Instructions and requesting collections to allow time for the DDI to lodge. This will be helped if you ensure your team fully understand the 3-day Bacs Cycle.
In conclusion, while direct debit failures can be inconvenient, understanding the common reasons behind the failures and implementing proactive measures can significantly reduce the likelihood of such occurrences.
Still have questions?
You can read more about Bacs reports on our website; you can contact us for information on our Accredited Direct Debit training options or you can simply call or email us (info@movimo.co.uk) for advice at any time.