Direct Debit mandates and the Bacs cycle: collected on time, every time

What does the capability do?

It treats the mandate, the authority to collect, as a first-class financial record and automates the scheme traffic around it.

• Complete capture. A mandate holds the payer’s name, contact details, and billing address alongside the bank account number, sort code, agreed amount, and collection day of month, with a dedicated encrypted field for sensitive data. Capture happens during member signup, so the billing relationship starts complete.
• A real lifecycle. Mandate status is one of pending, submitted, active, failed, cancelled, or expired, and every status change is recorded as a mandate event with its originator code and reason. The history answers “why did this mandate stop collecting?” from data.
• Automated submission and rejection handling. Instruction lodgements and collections are submitted in batches each cycle, and rejections come back the same way: a refused lodgement or a failed collection updates the mandate and payment records automatically, with the coded reason attached.
• Scheme messages processed, not printed. ARUDD returns and ADDACS amendment and cancellation notices are consumed as data. A cancelled instruction moves the mandate to cancelled and stops future collection; an unpaid collection marks the payment failed with its reason; nothing waits for someone to read a report.
• Notice-aware collection. Payment runs define mandate notice days and payment lead days (weekend and bank-holiday aware), and each billing batch computes its cut-offs from them. A mandate or amount change that misses the cut-off waits for the next cycle rather than breaching Bacs notice rules.

How the Bacs cycle actually works

Bacs Direct Debit is a scheduled scheme with fixed rhythms, and a billing platform either encodes them or leaves staff counting days on a calendar.

• Lodgement (AUDDIS). A new instruction is lodged electronically with the payer’s bank ahead of first collection. A rejected lodgement comes back with a reason code and the mandate never silently pretends to be active.
• Advance notice. Before collecting a new or changed amount, the payer must be told the amount and date. The notice period is configurable to match your scheme agreement, and the platform counts it in working days.
• Submission and processing. A collection is submitted to Bacs and processed over three working days: submitted on day one, processed on day two, debited on day three. The submission date, not the collection date, is the real deadline, and the platform works backwards from it.
• Returns (ARUDD). Unpaid collections come back the working day after collection with a coded reason, such as refer to payer, instruction cancelled, or account closed. Each return updates the payment and, where the reason demands it, the mandate.
• Amendments (ADDACS). When a payer cancels at their bank, switches account, or their bank amends the instruction, the bank sends an ADDACS message. The platform applies it to the mandate promptly, because collecting against a cancelled instruction is how indemnity claims happen.

Two cut-offs, not one

A detail most billing systems flatten: a new mandate and an amount change have different deadlines, so each batch carries two cut-offs.

• The mandate cut-off governs new joiners. A new instruction needs AUDDIS lodgement plus first-collection notice, so it needs the most lead time. A mandate created after this date collects from the following cycle.
• The amount cut-off governs existing payers. Collecting a changed amount against an active mandate needs only advance notice of the new amount plus the submission lead, so this date falls later. Price changes, plan upgrades, and freeze fees agreed after the mandate cut-off can still make this cycle.

Both dates are computed per batch from the payment run’s configured notice days, counted in working days and adjusted for bank holidays. “Will this member be collected this cycle, at the new amount?” is a question the system answers deterministically, not a judgement call at the front desk.

Why late cut-offs are worth real money

Cut-off dates sound like plumbing; they are actually revenue timing. Every day a cut-off moves later:

• Joiners start paying sooner. A member who signs up this week is collected this month rather than next, across every site, every cycle.
• Changes land a cycle earlier. A price rise or upgrade agreed just before submission takes effect now, not after another month at the old amount.
• Less correction work. Fewer pro-rata adjustments, fewer stale amounts collected, fewer of the ARUDD returns and disputes that stale amounts cause.

Operators using manual calendar maths defend themselves with padding: cut-offs set days earlier than necessary because nobody trusts the arithmetic near a bank holiday. Because the platform computes the exact latest safe date for each batch, that padding, and the revenue it delays, is recovered.

Why it matters

Recurring revenue is only as reliable as the mandates underneath it and the scheme discipline around them. A platform that lodges, notices, submits, and reconciles automatically, processes ARUDD and ADDACS as data, and pushes cut-offs as late as the rules allow keeps failure rates down, disputes short, and cash arriving a cycle earlier. It is the same audit-first design the Billing Engine applies to payment runs and refunds and write-offs.