ARUDD code 0 is a failed payment you can try again. ADDACS code 0 is a cancelled mandate you must stop debiting. Both are one character from the same scheme, so a handler that switches on the character alone will eventually collect against an instruction that no longer exists.
Bacs Direct Debit reports trouble through separate report types, each with its own code table and clock, and providers then squash those codes into their own API enums. Below are the full tables, the codes that are safe to re-present, the arithmetic that limits you to about two retries, and how GoCardless and Stripe expose all of it. On sourcing: the Bacs Service User's Guide and DDIC challenge guide are login-only, so some timings come from bureau and participant documentation, and I name those. Confirm them with your sponsor bank.
What Are Bacs ARUDD, ADDACS and AUDDIS Reports?
| Report | Fires when | Typical arrival |
|---|---|---|
| AUDDIS | A new instruction (0N) is rejected |
About 3 working days after submission (GoCardless) |
| ARUDD | A collection goes unpaid | 1 to 2 working days after the collection date |
| ADDACS | The payer's bank cancels or changes a mandate | Early on the working day after the bank's input |
| DDIC | The payer claims under the Direct Debit Guarantee | Any time, with no published limit |
AWACS is the Direct Credit counterpart, so it concerns payroll and supplier payments. You get three working days to act on an AWACS or ADDACS advice, and receiving an AWACS is itself your authority to update the details.
Reports expire. Most stay on the Bacs Payment Services Website for 37 calendar days, ADDACS and AWACS for 60, so an ingestion job that fails quietly for six weeks loses data for good. Bacs's guide to maintaining payment details gives each advice record a sequential A0SN reference, which is the field to watch for gaps. If you normalise to ISO 20022 internally, Bacs's 2017 translation guide maps ARUDD to camt.054, AUDDIS returns to pain.012 and ADDACS to pain.010 and pain.011.
ARUDD Reason Codes: Which Unpaid Direct Debits Can You Retry?
| Code | Meaning | Handling |
|---|---|---|
0 |
Refer to payer | Re-present |
1 |
Instruction cancelled | Stop, new mandate needed |
2 |
Payer deceased | Stop permanently |
3 |
Account transferred | Get new details or a new mandate |
4 |
Advance notice disputed | Stop until resolved |
5 |
No account (or wrong account type) | Fix details or new mandate |
6 |
No instruction | Check your records, new mandate |
7 |
Amount differs | Stop until resolved |
8 |
Amount not yet due | Stop until resolved |
9 |
Presentation overdue | Fresh advance notice |
A |
Service user differs | Fix your submission |
B |
Account closed | Stop, new mandate needed |
Read the full article on tomcn.uk →
About the Author
I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.
Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.
Top comments (1)
the one-character overlap is the sharpest thing here: a handler keyed on the code value alone will treat arudd 0 (refer to payer, safe to re-present) the same as addacs 0 (mandate cancelled, stop debiting immediately) and keep collecting against an instruction that no longer exists. storing the report type alongside the code at ingestion seems like the fix, before any provider squashes both into their own enum, because once they land in one api field you cannot reconstruct the scheme's rules afterwards.