Your mandates move one of two ways. Under the Bacs Direct Debit Bulk Change Process the existing instructions transfer and your customers sign nothing again, and under the other route each customer signs a new mandate with your new provider. The mechanics underneath the first one are more interesting than the reassurance usually given for it.
In this article
The short version
- Bacs defines the Bulk Change Process as the rules for "applying bulk amendments to Direct Debit Instructions (DDIs), already held with paying PSP's", where a service user's name, legal status, service user number or reference changes. Changing provider counts, because it changes your service user number.
- Your customers don't sign anything again under any of the scheme's three switching options. Saying your mandates aren't cancelled says something else, and under one option it's wrong: the instructions are cancelled at the paying bank with AUDDIS 0C transactions and re-created with 0N.
- The documents containing the bulk change rules are behind a Bacs login. Only the glossary, the November 2018 switching guide, the Facilities Management guide v5.0 and the deed are public, and "approximately four to six weeks" is the only timescale the scheme publishes.
- No scheme document, and no provider page we read, publishes a minimum number of mandates for a bulk change. Any minimum you're given is that provider's own policy.
- "No gap in collections" is a provider claim, not a scheme fact. London & Zurich requires "a 10 day clear window of no Direct Debit activity" before your first collection with them, and GoCardless's own timeline leaves five working days in which nothing gets submitted.
- What happens to a mandate that fails to transfer, and how you find out, is the least documented part of the process, ours included.
What a bulk change is for
A bulk change isn't a migration product. It's the scheme's mechanism for amending instructions that already exist at your customers' banks, and Bacs lists four things it exists to change: your name, your legal status, your service user number and your service user reference.
Changing provider triggers it because of the third one. When you collect through a provider's facilities-management service, your collections run under a service user number belonging to that provider, so moving changes the number and the instruction at your customer's bank has to be amended to point at the new one. The customer's authorisation doesn't have to be redone, which is why the scheme built the process. You're not asking anyone to rebuild your mandates, only asking two providers and their sponsor banks to update an identifier.
The three options, and what each does to the instruction
Bacs's switching guide of November 2018 names three options and no others, and says anything outside them "needs to be agreed by the acquiring FM provider with its sponsoring PSP before the switch takes place".
| Option | When it applies | What happens to the instruction | What your payer does |
|---|---|---|---|
| Transfer of SUN | "when all DDIs are being switched", the simplest of the three | "It doesn't require the cancellation of DDIs and the creation of new ones, reducing the risk of problems occurring" | Nothing |
| Transfer of all DDIs | when all instructions move from one provider to another | The ceding provider generates "AUDDIS 0C transactions to cancel existing DDIs with paying PSPs" and the acquiring provider generates "0N transactions to create new DDIs" | Nothing. It "avoids asking payers to complete new DDIs" |
| Transfer of some DDIs | when you only want to move part of your book | As above, on the subset. "it is of paramount importance that all stakeholders are clear how many and which DDIs will be included" | Nothing |
Read the middle row carefully, because published reassurance tends to flatten it. Under transfer of all DDIs the existing instructions really are cancelled at the paying bank and new ones really are created, and GoCardless's own support material describes the change date as involving cancellation and re-creation of the mandates. So "your mandates won't be cancelled" isn't quite what the scheme documents describe, whereas "your customers don't have to sign anything again" is, and that applies to all three of the options above.
What you can verify, and what's behind a login
You can't read the rules that govern your own mandates. The two Bacs documents containing the bulk change rules, the Bulk Change Process v4.6 and the FM version v1.5, both redirect to a login page, and so does the Service User's Guide and Rules. The Bacs resources page says as much: "Some areas and assets are password protected and only available to eligible registered users".
Four scheme documents are public, and they're the only ones anything here rests on: the glossary, for the definitions; the Little Bacs Guide to Switching Facilities Management Provider, reference LBGSFMP/GH/1118/K of November 2018, for the three options and the timescale; Direct Debit Facilities Management v5.0 of February 2025, for the co-operation duty and the indemnity transfer; and the bulk change deed itself, for what you sign.
One timescale in the whole subject is scheme-published: Bacs "anticipated the basic procedures for the switch will take approximately four to six weeks". Every other number you'll be quoted belongs to a provider. GoCardless publishes 4 to 6 weeks inbound and 3 to 5 weeks outbound, Stripe publishes about 6 weeks inbound and 6 to 8 weeks outbound, and nobody explains why leaving takes longer than arriving.
Which route you get, and who decides
Your provider decides, not the scheme.
We looked for a published mandate threshold in every scheme and regulator document available, and in the migration pages of GoCardless, Stripe, London & Zurich and Access PaySuite. Not one names a number, including the glossary definition, the November 2018 guide, FM v5.0, the deed and both PSR consultation papers. Stripe asks how many mandates you're migrating and sets no floor.
Why a provider would still set one is easy to explain without inventing a rule. A bulk change involves two sponsor banks, a wet-signed deed, a notification of change form and several weeks of co-ordination, and below some number of mandates all of that is more work than asking your customers to sign again. Every provider draws that line differently, so ask a prospective provider what their own minimum is and what they'll do with your book if you fall under it.
The trade-off is real either way. A bulk change asks nothing of your customers and takes weeks, while re-signing starts immediately and asks every customer for something. The PSR heard in 2017 that customers who had already signed a mandate found being asked again confusing (evidence submitted by one provider, describing the position before the January 2018 rule change).
Whether your collections keep running
"No gap in collections" is a provider claim. The scheme's version is narrower: the bulk change routes avoid "uncertainty over whether a valid DDI will be in place enabling collections to continue when the collection date falls".
Look at what providers publish about the days either side of a change date and the claim gets more honest.
- London & Zurich: "When you are migrating, there must be a 10 day clear window of no Direct Debit activity before the first collection date with your new Direct Debit provider."
- GoCardless: final payments go in 2 working days before the change date, and payments "can be submitted using the new SUN" from 3 working days after. On their own timeline that's a five-working-day window with nothing submitted, and their outbound article advises stopping collections 5 to 7 days beforehand.
- Stripe: once your old processor cancels the mandates, "You can't charge your customers using your current processor", and the first payment goes in at T+3.
- Adfin: collections continue with the old provider until one working day before the change date and resume from the mandate activation date, three working days afterwards.
So no invoice has to go uncollected, and the collection dates around the change date do move. Published quiet windows run from about four working days to ten days, and the practical consequence is one billing cycle where the dates aren't the dates your customers are used to.
The mandates that don't arrive
Some mandates don't make it across, usually because the underlying details were wrong or stale, and this is where the published record thins out to nothing.
Of the providers whose migration pages we read, only two address it. Stripe says it "identifies any problems with the import", works with your current processor to correct them, and shares "a summary of the import for your final review and approval". Adfin says plainly that not every mandate always makes it across, and its answer to how you find out is that you compare the arrival list against your old provider's records and flag what's missing to your Adfin contact. That's a manual reconciliation, done by you, and a weaker answer than Stripe's. We'd rather set that out here than leave you to discover it during the migration.
GoCardless, London & Zurich and Access PaySuite publish nothing on it across the pages we fetched, and neither does the Bacs switching guide.
What the mechanism implies, and this is our reading and not a quotation: under transfer of all DDIs the new provider submits AUDDIS 0N transactions, and the paying bank rejects any it can't create, with reason codes for a closed account, incorrect account details, a reference that isn't unique or a missing payer name. So a failed transfer surfaces as an AUDDIS rejection, and you learn about it only if somebody reads the AUDDIS report. Ask your incoming provider who reads it and what they send you.
Common questions
Do my customers have to sign a new direct debit mandate? Not under any of the scheme's three bulk change options, where their original authorisation carries over. Under the alternative route, where new instructions are created instead of transferred, each customer signs a new mandate. Your provider decides which route you get, since no scheme rule sets a mandate count.
Are my mandates cancelled during a bulk change? Under transfer of SUN, no: Bacs says it "doesn't require the cancellation of DDIs and the creation of new ones". Under transfer of all DDIs, yes, at the paying bank, with AUDDIS 0C transactions to cancel and 0N transactions to create the replacements. In both cases your customers sign nothing again.
How long does a mandate migration take? Bacs anticipates the basic switching procedures taking "approximately four to six weeks". Provider timetables run from three to eight weeks and depend on two sponsor banks, so treat any specific promise as that provider's own estimate, not a scheme timescale.
Is there a minimum number of mandates for a bulk change? No scheme document publishes one, and neither do the migration pages of GoCardless, Stripe, London & Zurich or Access PaySuite. Providers set their own minimums, so ask what theirs is and what happens if your book is smaller.
Will my collections stop during the switch? No invoice has to go uncollected, but the dates around the change date move, because every provider builds in a few days when nothing is submitted. Published windows run from about four working days to a ten-day clear window.
How will I know if a mandate didn't transfer? Ask before you sign anything, because most providers don't publish an answer. Stripe reviews the import and shares a summary for your approval, and Adfin asks you to compare the arrival list against your old provider's records. A failed transfer shows up as an AUDDIS rejection from the paying bank, so what matters is who reads those messages and what they send you.
Sources
- Bacs — glossary (accurate as of August 2026)
- Bacs — little guide to switching FM providers (accurate as of August 2026)
- Bacs — resources (accurate as of August 2026)
- Payment Systems Regulator — CP17/1, direct debit facilities management (accurate as of August 2026)
This article describes the Bacs Direct Debit Bulk Change Process as published by Bacs, the Payment Systems Regulator and named providers, and is not legal or financial advice. The documents containing the bulk change rules are behind a Bacs login, so every process detail not quoted from a public scheme page is described as what a provider publishes. Last updated August 2026.
