Handling Bacs Reports Properly: ARUDD, ADDACS, and AWACS

Why report handling is the real test of a billing system

Anyone can submit a Direct Debit collection. Submitting is the easy half. The half that separates a robust billing platform from a fragile one is what it does with the messages that come back, because those messages are where reality intrudes on the plan.

Bacs is a reporting scheme as much as a collection scheme. After you submit, the banks tell you what actually happened: which collections failed, which mandates changed, and which account details were wrong. Those messages arrive as structured reports with coded reasons. Treat them as files for someone to open on a Thursday and you accumulate failed collections, indemnity risk, and finance archaeology. Treat them as events that drive automated workflows and the system runs itself.

This guide covers the three report types that matter, the reason codes inside them, and the correct system response to each. The value here is precision, so verify every code and timescale against current Bacs and Pay.UK documentation before you build, because the scheme evolves.

What are the Bacs reports, and when do they arrive?

There are four inbound signals a Direct Debit billing system has to handle. Three are the reports in the title; the fourth is the rejection of a new instruction. Each answers a different question and arrives at a different point in the cycle.

• AUDDIS rejections. When you lodge a new instruction electronically through the Automated Direct Debit Instruction Service (AUDDIS), the payer’s bank can reject the lodgement. This arrives before you ever collect, and it means the mandate is not active. A system that assumes lodgement succeeded will collect against a mandate that does not exist.
• ARUDD (Automated Return of Unpaid Direct Debits). This reports a collection that was not paid. It arrives the working day after collection, carrying a reason code that tells you why the payment did not clear and, by implication, whether the mandate is still viable.
• ADDACS (Automated Direct Debit Amendment and Cancellation Service). This reports a change to the mandate itself: the payer or their bank has cancelled, amended, or transferred the instruction. It can arrive at any time, independent of any collection, and it is expected to be actioned within three working days.
• AWACS (Advice of Wrong Account for Automated Credits). This applies to money you pay out by Bacs Direct Credit, such as a refund by bank transfer, not to collection. When destination details are wrong or have changed, the receiving bank may apply the payment and advise the correct details, which you should apply within three working days.

The critical distinction is between a payment and a mandate. ARUDD is about a specific collection. ADDACS is about the authority to collect at all. Conflating the two is the most common design mistake, because it leads a system to retry a payment when the mandate underneath it is already gone.

Which ARUDD reason codes matter, and what should the system do?

Every ARUDD return carries a reason code, and the code determines the correct action. Some failures are recoverable and the mandate lives on; others mean the mandate is dead and any further collection is a scheme breach. Hard-coding the right response to each code is the core of good failure handling.

The table below lists the ARUDD reason codes with the appropriate system action. Verify these against current Bacs guidance before relying on them, as codes and their handling can be updated.

Three codes deserve emphasis because getting them wrong is expensive.

• Codes 1, 2, and 6 mean the mandate is dead. Instruction cancelled, payer deceased, and no instruction held all mean there is no authority to collect. Your system must stop, and it must never re-present. Collecting against a cancelled instruction is precisely how indemnity claims under the Direct Debit Guarantee happen.
• Code 0, refer to payer, is the recoverable one. This usually means insufficient funds. The mandate is fine, so contacting the payer and re-presenting at the next opportunity is legitimate, subject to the scheme’s re-presentation rules.
• Suspend codes are not cancel codes. Codes like 4, 7, and 9 signal a process problem (a disputed notice, an amount mismatch, a timing error), not a dead mandate. The right response is to hold collection and fix the process, not to tear down the instruction.

Which ADDACS reason codes matter?

ADDACS reports a change to the mandate, so its codes are about the authority to collect rather than a single payment. The service exists so that you always reflect the bank’s truth about an instruction, and the scheme expects you to act within three working days.

The pattern to notice is that ADDACS codes split cleanly into stop, update, and resume. Cancellations (0, 1, 2, B) stop collection. Amendments and transfers with new details (3, C, E) update the mandate and carry on. Reinstatement (R) resumes a previously stopped instruction. A system that models a mandate as a lifecycle with events applies each of these as a state transition, keeping the reason code and the message it arrived in as evidence.

How should report ingestion be architected?

The right architecture is event-driven. Each report is an inbound event that maps to a defined action, applied to the payment or mandate inside a single transaction, with an audit record. That sentence contains the whole design, and the discipline is in refusing to make any of it manual.

A robust ingestion pipeline has a few consistent properties.

• One explicit code-to-action mapping. Every reason code resolves to exactly one defined action: retry, contact, suspend, or cancel. The mapping lives in code, is unit-tested, and has no gaps. An unknown code fails loudly rather than being silently ignored.
• Idempotent processing. Reports can be redelivered, so applying the same message twice must not double-cancel a mandate or create a duplicate event. Processing keys off the message identity, not the moment it arrived.
• Transactional application with an audit event. The status change to the payment or mandate and the audit entry that explains it commit together. Either both happen or neither does, so the record is never half-updated.
• Separation of payment events from mandate events. ARUDD updates a payment; ADDACS updates a mandate. Keeping them distinct prevents the classic bug of retrying a collection whose mandate an ADDACS message has already killed.

The payoff is that the finance team stops processing reports and starts reading outcomes. Instead of a person opening a return file and deciding what each line means, the system has already marked the payment, updated the mandate, and left an audit trail explaining why. Reports become the system’s input, not the team’s workload.

What are the edge cases that earn trust?

The reason codes are the easy part once you have the table. Trust is earned in the timing edge cases, where a message and a collection cross in the post. These are the situations that expose whether a system truly understands the Bacs cycle or merely processes files.

• The payer cancels after a run is submitted. A collection is in the three-working-day cycle when an ADDACS cancellation arrives. The instruction is now cancelled, but the in-flight collection may still complete and then bounce back as an ARUDD return. A good system marks the mandate cancelled immediately, expects the return, and does not re-present the failed collection, because the authority is already gone.
• Amendments arriving mid-cycle. An ADDACS amendment with new account details lands while a collection is in flight against the old details. The system must apply the amendment to future collections without corrupting the one already submitted, and without collecting twice.
• Re-presentation rules. A recoverable failure such as refer to payer can be re-presented, but the scheme constrains how and when, and re-presentations must be marked as such. A system that re-presents blindly, or re-presents a dead mandate, converts a routine failure into a compliance problem. Encode the rules; do not leave them to a person under time pressure.
• The AUDDIS rejection that looks like success. A new mandate is lodged, a collection is scheduled, and then the lodgement is rejected. If the system assumed the mandate was active on submission, it will try to collect against nothing. Lodgement must be confirmed, not assumed, before the first collection is built.

Each of these is a place where a naive system collects when it should not, or fails to react when a mandate has changed underneath it. Handling them correctly is the difference between a low failure rate with short disputes and a steady trickle of indemnity claims.

How does this map to the Billing Engine?

This is exactly the design our Billing Engine accelerator implements. It runs the full Bacs cycle in-house and consumes the scheme’s messages as data, not as printouts. ARUDD returns and ADDACS amendments flow into mandate events and payment status automatically, with the coded reason attached, so member records reflect the bank’s truth without manual keying.

The detail lives in the capability pages. Direct Debit mandates and the Bacs cycle covers AUDDIS lodgement, advance notice, automated submission, and the returns handling described here. Payment runs and batches covers the notice-day and bank-holiday arithmetic that decides when a collection can safely be submitted. Refunds and write-offs covers the guarded, audited handling of money going back out, which is where AWACS corrections and Direct Debit Guarantee refunds are actioned.

The through-line is the accelerator’s core principle: every financial state change is an event with evidence. A failed collection, a cancelled mandate, a corrected account number, and a refund are all recorded with their reason and their audit trail, which is what regulated and multi-site operators need. We have run this in production for membership operators, including the Third Space Atlas platform.

Where to go next

If you are specifying or building a billing system, the reason-code tables above are a good starting checklist, but confirm each against current Bacs and Pay.UK guidance before you rely on them. The scheme’s messages and their handling are authoritative only from the source.

For the demand-side context, our guides on switching from card billing to Direct Debit and leaving your Direct Debit bureau explain why businesses bring collection in-house in the first place, and the card versus Direct Debit savings calculator helps you size the prize. When you want the report handling described here designed into a platform you own, book a consultation and we will walk through the architecture with you.