Bacs Reason Codes
Overview
This guide will provide a comprehensive overview on Direct Debit Bacs statuses:
- ARUDD: Automated Return of Unpaid Direct Debit
- ADDACS: Automated Direct Debit Amendment and Cancellation Service
- AUDDIS: Automated Direct Debit Instruction Service
- DDIC: Direct Debit Instruction Confirmation
Understanding these statuses is pivotal for merchants utilising Direct Debit transactions. Each status represents a specific stage or notification within the Bacs system, influencing the processing and management of Direct Debit payments.
In this guide wherever the term 'service user', this relates to 'merchant' in Acquired terms.
Direct Debit Instruction notifications
AUDDIS and ADDACS messages relate to any notifications about your Direct Debit Instructions.
Acquired will send out a mandate_update webhook notification on day 3 confirming whether the mandate was successful or not (or on day 4 depending on the time at which the mandate request was created).
AUDDIS messages
AUDDIS messages relate to the Direct Debit Instruction process, also referred to as Direct Debit Mandates. They are received when there has been a problem with the setup or the payer has cancelled the setup.
reason_code | reason_description | Description | Handling the response |
|---|---|---|---|
| 1 | Instruction cancelled | The payer has instructed the paying bank to cancel the DDI. In rare circumstances, this may be sent when a customer cancels their DDI shortly after setup instead of the correct ADDACS message. | If there are any outstanding funds, the service user must liaise with the payer to agree on a payment method. |
| 2 | Payer deceased | An attempt has been made to create DDI on an account belonging to a deceased individual. | This is an extremely rare circumstance. |
| 3 | Account transferred | The account has been transferred to a new bank. | If you have not received the new bank details, obtain a new DDI from the payer. |
| 5 | No account | The account number is not recognised at the paying bank. | The service user should check the DDI information and/or liaise with the payer. |
| 6 | No instruction | The instruction does not exist on the paying bank's database. | The service user should check the DDI information and/or liaise with the payer. |
| 7 | DDI amount not zero | The amount indicated in any DDI submission must be zero, as all DDIs are intended for an unlimited amount. | The service user should correct the record and re-submit. |
| B | Account closed | The DDI has been attempted on a closed account. | The service user should obtain a new DDI for a different account. |
| C | Account transferred to a different branch of the bank/building society | The account has been transferred and new account details provided. | The service user needs to update the data file and proceed with Direct Debit collections. However, upon receiving this message, refrain from sending a 0C/0N pair. |
| F | Invalid account type | The account is of a category that doesn't allow setting up DDIs. | The service user should obtain new account details from the payer. |
| G | Bank will not accept Direct Debits on account | The paying bank does not allow Direct Debits on this type of account. | The service user should obtain a new DDI for a different account. |
| H | Instruction has expired | The DDI that you instructed to cancel has already expired. | To reactivate this DDI for collections to resume, a 0N DDI will be necessary. The service user must possess the payer’s authorisation to collect funds under an expired Instruction. |
| I | Payer reference is not unique | The paying bank has matched the DDI to an existing DDI with a similar reference. | The service user should allocate a different reference and assign a DDI again using 0N. |
| K | Instruction cancelled by paying bank | The paying bank has cancelled the DDI (similar to 1) | The service user cannot collect via DD for this account. They must obtain a DDI for a new account if Direct Debit is to continue. |
| L | Incorrect payer's account details | The sort code and account number provided by your customer did not pass a publicly available "modulus check" designed to verify their potential validity. | We advise implementing sort code validation and modulus checking prior to sending DDI transactions to the Bacs service to avoid these reason codes. |
| M | Transaction code / user status incompatible | Transaction codes which are not allowed whilst in this status have been sent. (This is only an issue when converting from Standing Orders to DD.) | The service user submitted 0S DDI transactions after obtaining 'LIVE' status on the Bacs service master files. They should resubmit the transactions with 0N as transaction code. |
| N | Transaction disallowed at payer's branch | Collections via Direct Debit cannot be processed from this specific sort code. | The service user should obtain a new DDI for a different account. |
| O | Invalid reference | The reference field on the DDI does not comply with the AUDDIS rules. | The service user should ensure that references meet the AUDDIS service rules. |
| P | Payer's name not present | The payer's name field was blank, this is a required field. | The service user should correct the record and re-submit. |
| Q | Service user's name blank | The service user's name field was blank, this is a required field. | The service user should correct the record and re-submit. |
ADDACS messages
Automated Direct Debit Amendment and Cancellation Service (ADDACS) messages relate to specifically to any alterations or terminations of Direct Debit Instructions (DDIs) initiated by your customers.
reason_code | reason_description | Description | Handling the response |
|---|---|---|---|
| 0 | Instruction cancelled - Refer to payer | The paying bank has cancelled the DDI. | If Direct Debit is to continue, the service user must obtain a new DDI for a new account. |
| 1 | Instruction cancelled by payer | The payer has instructed the paying bank to cancel the DDI. | If there are any outstanding funds, the service user must liaise with the payer to agree on a payment method. |
| 2 | Payer deceased | An attempt has been made to create DDI on an account belonging to a deceased individual. | This is an extremely rare circumstance. |
| 3 | Account transferred | The account has been transferred to a new bank. | If you have not received the new bank details, obtain a new DDI from the payer. |
| B | Account closed | The DDI has been attempted on a closed account. | The service user should obtain a new DDI for a different account. |
| C | Account transferred to a different branch of bank | The account has been transferred and new account details provided. | The service user needs to update the data file and proceed with Direct Debit collections. However, upon receiving this message, refrain from sending a 0C/0N pair. |
| D | Advance notice disputed | The payer has disputed the time, amount or frequency of the advance notice. | The service user should not collect further Direct Debits until the dispute has been resolved with the payer. |
| E | Instruction amended | Your customer has changed the name or other details on their DDI and the paying bank has advised. | The service user should collect Direct Debits using the new details. AUDDIS service users only – A 0C/0N pair must not be sent on receipt of this message |
| R | Instruction reinstated | A cancelled DDI has been re-instated by your customer's bank. | The service user may resume Direct Debit under reinstated instruction. A new DDI must be obtained and lodged |
Payment request notifications
Messages regarding the payment requests that you've made are received as Automated Return of Unpaid Direct Debit (ARUDD) or Direct Debit Indemnity Claim (DDIC) notifications.
ARUDD messages
Automated Return of Unpaid Direct Debit. are notifications sent by the paying bank to inform the collecting bank about unsuccessful Direct Debit payments. These messages provide details regarding the reasons for payment failures, such as insufficient funds or closed accounts, allowing the collecting bank to take appropriate actions. Understanding ARUDD messages is crucial for managing and resolving issues related to unsuccessful Direct Debit payments.
reason_code | reason_description | Description | Handling the response |
|---|---|---|---|
| 0 | Refer to payer | The payer's bank was unable to process the Direct Debit, typically due to insufficient funds. | It is recommended to reach out to your customer and coordinate a retry for processing the payment. |
| 1 | Instruction cancelled | The payer has instructed the paying bank to cancel the DDI. | If there are any outstanding funds, the service user must liaise with the payer to agree on a payment method. |
| 2 | Payer deceased | An attempt has been made to create DDI on an account belonging to a deceased individual. | This is an extremely rare circumstance. |
| 3 | Account transferred | The account has been transferred to a new bank. | If you have not received the new bank details, obtain a new DDI from the payer. |
| 4 | Advance notice disputed | The payer has disputed the time, amount or frequency of the advance notice. | The service user should not collect further Direct Debits until the dispute has been resolved with the payer. |
| 5 | No account (OR wrong account type) | The account number is not recognised at the paying bank. | The service user should check the DDI information and/or liaise with the payer. |
| 6 | No instruction | The customer does not have a DDI set up with you. | The service user should check the DDI information and liaise with the payer to obtain a new instruction. |
| 7 | Amount differs | The customer has disputed the amount that you have taken, stating that it differs from the amount in the advance notice. | The service user should not collect further Direct Debits until they have resolved the dispute with the payer. |
| 8 | Amount not yet due | This may occur due a submission of a payment before a DDI is fully set up or if you try to take a payment before the date that your customer was notified of. | The service user should not collect further Direct Debits until they have resolved the dispute with the payer. |
| 9 | Presentation overdue | You have attempted to collect a payment more than 3 working days after the date that you notified your customer. | The service user must give further advance notice before the Direct Debit is collected. |
| A | Service user differs | The identity of the service user differs from the DDI. | N/A |
| B | Account closed | The payer has closed their account for an unknown reason. | service user must obtain a DDI for a new account if Direct Debit is to continue. |
DDIC messages
A Direct Debit Indemnity Claim (DDIC) refers to a process allowing bank customers to request refunds for unauthorised or incorrectly executed Direct Debit payments. It provides a mechanism for customers to dispute payments made via Direct Debit, typically due to errors, unauthorised transactions, or instances where the payment amount or timing does not align with the agreed terms.
reason_code | reason_description | Circumstances | Challenge Reasons |
|---|---|---|---|
| 1 | Amount and/or date of Direct Debit differ from Advance Notice | Where possible provide the payer with proof of the Advance Notice or a copy of the contract. | |
| 2 | No advanced noticed received by payer. | The payer did not receive a pre-notification of the Direct Debit. | Where possible provide the payer with proof of the Advance Notice or a copy of the contract or any emails/texts sent to the payer that include the Advance Notice. |
| 3 | DDI cancelled by paying bank. | This occurs when the Payment Service Provider (PSP) fails to send a cancellation notice to the service user before the DD is due or the service user doesn't include the cancellation date from the form. | |
| 4 | Payer has cancelled DDI directly with Service User. | N/A | |
| 5 | No instruction held (AUDDIS service users only) | The payer disputes giving authority. | See below. |
| 6 | Signature on DDI is fraudulent or not in accordance with account authorised signature(s) (AUDDIS service users only). | Provide a copy of the DDI in situations where no request has previously been received from the PSP. | |
| 7 | Claim raised at Service User's request after Direct Debit applied to payer's account. | The paying PSP will not accept the request until the payment has been deducted from the payer's account. No action will occur regarding any request until written confirmation is provided to the paying PSP, such as via fax or email. The specifics of this confirmation will be included with the indemnity claim. | Where the indemnity claim is disputed, the paying PSP is required to uphold the challenge if the email provided by the service user cannot be produced. |
| 8 | Service User Name Disputed | The payer does not recognise the service user who is collecting the Direct Debit. | See below |
Reason Code: 5 - challenge reasons
AUDDIS service users can submit various forms of evidence, including:
- An authorised instruction adhering to AUDDIS requirements, retained by the service user.
- Documentation of a signed contract by the payer explicitly mentioning Direct Debit payment.
- Documentation of a contract referencing Direct Debit, not necessarily signed by the payer if they don't dispute the contract's existence but only the payment method.
- Proof of the payer confirming receipt of a nominal amount in their account with a corresponding reference to the service user.
- Evidence demonstrating completion of previously agreed-upon payer verification measures between the service user and their sponsor.
For non-AUDDIS service users, challenges can be raised if:
- The paying PSP has issued a claim citing reason code 5 against a non-AUDDIS service user.
- The paying PSP has returned a Direct Debit transaction with a 'refer to payer' code 01 and subsequently raised an indemnity claim due to the reason 'payer disputes having given authority' for a representation with an 18 transaction code.
Reason Code: 8 - challenge reasons
AUDDIS service users have the option to present one or multiple pieces of evidence:
- An authenticated instruction, such as one kept by the service user in line with AUDDIS requirements.
- A contract signed by the payer explicitly mentioning payment via Direct Debit.
- A contract specifically referencing Direct Debit as the payment method. If the payer doesn't dispute the contract's existence but only the payment method, their signature might not be necessary.
- Proof indicating that the payer has acknowledged receiving a specific amount in their account, accompanied by a relevant reference to the service user.
- Correspondence directed to the payer regarding the Direct Debit, like advance notices, from a service user sharing the same name as the entity collecting the Direct Debit.
- Records demonstrating the completion of payer verification measures previously agreed upon by the service user and their sponsor.
Updated 11 months ago