Bacs ARUDD, ADDACS, AUDDIS Codes: Which to Retry

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?

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?

Only 0 is worth retrying automatically. Access Paysuite's auto-represent and GoCardless Success+ act on that code alone. Codes 4 and 7 need a person, because the payer is telling their bank your notice or amount was wrong, and another automated debit turns a billing query into an indemnity claim. A is your own bug.

Advance notice is where 4 usually starts. Bacs's default is at least 10 working days plus postal time unless you have agreed something else with the payer, and providers shorten it: GoCardless works to 3 days, Stripe to 2 working days, and Adyen recommends 8. Whatever you agreed has to match what your emails actually do, because a changed amount sent late produces the same code as no notice at all.

A failure can also turn up late. GoCardless says around 1% of failure notices arrive a day after the rest, and ClearBank's participant docs put the paying bank's deadline at entry day or the next working day before 15:30 UTC. ClearBank also shows returned items swapping transaction codes 01, 17, 18 and 19 for U1, U7, U8 and U9, which matters if you parse the files yourself. Treat a payment as provisional for at least two working days after collection, and check how each provider counts them: GoCardless numbers the cycle Day 0, 1 and 2 where Bacs uses Day 1, 2 and 3. For the wider cycle, see my Faster Payments vs Bacs vs CHAPS guide.

ADDACS Codes List: Mandate Cancellations and Amendments

For C and E, Access Paysuite says to update your records without sending a 0C/0N pair. Current Account Switch Service moves generate these advices, so an amendment can simply mean a customer changed banks.

AUDDIS Rejection Codes: Why a New Direct Debit Mandate Fails

Nuapay notes that 7 and L to Q come only from Bacs validation, so no bank made those decisions. Alert on them as defects in your file generation. F, G and N mean the account cannot take Direct Debits at all, and the fix is asking the customer for a different account.

The AUDDIS service guide sets a minimum of two working days between lodging a 0N and the first 01 collection, and recommends five. GoCardless says AUDDIS responses take about three working days, so if you use the two-day minimum you collect before you have heard back. Use five. Bacs will also stop issuing new non-AUDDIS Service User Numbers from 1 July 2027, though existing ones keep working.

How Long Do You Have to Re-present a Failed Direct Debit in the UK?

Nuapay's documentation states the constraints plainly: re-presentation must happen within one month of the first presentation, for the same amount, with at least five working days' notice to the payer. CIPP describes the notice as recommended. The transaction code is 18, and a re-presentation outside the month comes back as ARUDD 9.

Here is what that leaves you, counted in working days if you move as fast as the rules allow:

A calendar month holds about 21 working days, so a third attempt lands on or past the boundary. That is my arithmetic, and I could not read a scheme-level cap on attempts, but the commercial limits agree with it: Access Paysuite allows two retries, and Stripe makes up to two within 30 days, for insufficient funds only. GoCardless's Success+ FAQ puts the earliest retry after a standard failure at day 4 and recommends a four-week window, and a late insufficient-funds failure remains retryable.

DDIC Reason Codes: How Direct Debit Indemnity Claims Work in 2026

The claim itself has no public time limit, but your response does. Modulr's documentation gives the sequence: advice on working day 1, challenge by the end of day 9, the paying bank responds by day 11, and settlement follows around day 13. An unchallenged claim is accepted automatically at day 9, and evidence is capped at five files of 5 MB each. Nuapay documents the automatic debit on day 14. So you have nine working days to act on something that takes fourteen to reach your bank statement, and a monthly reconciliation will find it too late. Keep the signed or electronic instruction retrievable as well: Bacs expects you to supply a copy of a DDI within 7 working days of a request, and codes 5 and 6 turn on exactly that document.

Code 7 is the one to build for. GoCardless calls a merchant-requested claim "the safest way to refund a payment taken by Direct Debit", because it closes off a later claim on the same payment. Stripe's docs warn of the alternative: since the indemnity period is indefinite, a customer can dispute after a refund and you lose both amounts.

I could not find a published indemnity-claim rate that triggers a review of a service user. Ask your sponsor what theirs is before you need to know.

GoCardless vs Stripe: How Bacs Failure Codes Reach Your API

GoCardless exposes the raw code. Bank-origin events carry details.reason_code and details.scheme alongside details.cause, and its docs tell you to branch on cause:

Stripe hides the scheme. charge.failure_code returns insufficient_funds or generic_could_not_process (both retryable), or account_closed, bank_ownership_changed, debit_not_authorized or invalid_account_number (not retryable). Mandate state lives in network_status (pending, revoked, refused, accepted) with a revocation_reason. A failure after success becomes a dispute, a DDIC arrives as charge.dispute.created, and there is no evidence stage. I found no raw Bacs code documented anywhere in its API.

The trade-off: GoCardless suits a finance team that reconciles to Bacs reports or needs to challenge claims. Stripe is less work if you already run on it and can accept six failure codes and no appeal.

Bacs Reason Codes vs ACH Return Codes and SEPA R-Transactions

What This Means for Developers Integrating Bacs Direct Debit in the UK

1. Key on report and code together. Default every unknown pair to a hold so an unlisted code queues for review. 2. Model mandates with a way back. cancelled has to accept reinstated. 3. Poll reports daily and alert on gaps. Use the A0SN sequence, and remember the 37-day expiry. 4. Run a DDIC clock. Page someone well before working day 9 if you intend to challenge. 5. Refund through the indemnity route where your provider supports it, and keep the original payment reference forever, since the claim window never closes.

type Action = "represent" | "hold" | "update_details"
  | "new_mandate" | "close_mandate" | "fix_submission";
const policy: Record = {
  "ARUDD:0": "represent",
  "ARUDD:4": "hold",
  "ARUDD:B": "new_mandate",
  "ADDACS:0": "close_mandate",
  "ADDACS:E": "update_details",
  "AUDDIS:L": "fix_submission",
};
const actionFor = (report: string, code: string): Action =>
  policy[${report}:${code}] ?? "hold";

My position, and this is opinion: automate one re-presentation, not two. The table above shows two only fit if you fire at the earliest legal moment, which is rarely when the customer has money. I would use the single attempt on a date near the customer's likely payday, then hand off to a human or a different payment method. Every extra debit against a struggling account risks a claim that you cannot contest cheaply and that stays open indefinitely.

If you are working through a Bacs integration, more of my writing on UK payment rails is at Tom Wang.