Leaving Your Direct Debit Bureau: The Routes Out

Bureaux are a good start, not a permanent home

A Direct Debit bureau exists to lower the barrier to collecting by Direct Debit. It lets a business collect without its own Service User Number, without a sponsoring bank relationship, and without Bacs-approved software. For a business early in its recurring-revenue journey, that is genuinely useful, and there is no shame in having started there.

The tension appears later. The bureau model is built around a per-transaction fee and a batch-and-deadline operating rhythm that made sense at low volume. At scale, the same features that lowered the barrier to entry become the ceiling on efficiency. This guide is for finance and operations directors who have reached that ceiling and want to understand their options without the jargon.

What are the signs you have outgrown a bureau?

You have outgrown a bureau when its cost and operating model start working against you rather than for you. Four signs come up again and again, and most businesses recognise more than one.

• Per-transaction fees that only scale up. Bureau pricing is usually charged per collection, so the bill grows with every successful payment. Success makes it worse, not better, and the rate rarely improves as volume climbs. You are paying a variable fee on revenue you already own.
• Operations that run on the bureau’s calendar. File preparation, submission windows, and cut-offs dictate when your finance team works. The deadline runs the team rather than the team running the collection, and a missed window pushes revenue to the next cycle.
• Manual file handling between systems. Files move by hand between the bureau, your customer records, and your finance system. Reconciliation happens in spreadsheets, and every handover is a place for error to creep in.
• No real-time visibility. Failures, cancellations, and amendments arrive as reports to be opened and processed, not as events your systems react to. You find out a collection failed when someone reads a file, often days after the fact.

Individually, each is a nuisance. Together, they mean your billing runs on a rhythm and a cost base set by someone else. That is the point at which bringing Direct Debit in-house, in some form, starts to pay for itself.

What are the routes out of a bureau?

There are three broad routes to running Direct Debit without a traditional bureau, and they trade cost, control, and effort against each other. There is no single right answer; the right route depends on your volume, your appetite for setup, and how much control you want over the payment experience.

• Direct sponsorship with your own Service User Number. Your business applies for its own SUN, sponsored by a bank, and submits collections directly to Bacs through Bacs-capable software. This gives the most control and the lowest marginal cost per collection at scale, in exchange for the most setup and the most operational responsibility.
• A managed or facilities-managed arrangement. A provider handles submission for you, often collecting under their SUN or managing yours. You shed most of the operational burden and keep a single relationship, at the cost of some control and a pricing model that sits between a bureau and full independence.
• A modern API-based provider. A provider exposes Direct Debit through an application programming interface (API), with developer-friendly integration and, typically, real-time notifications of failures and amendments. This is often the fastest route to good integration and visibility, with commercial terms that vary by provider and volume.

How the three routes compare

The table below summarises the trade-offs at a category level. Treat it as a way to frame the decision, not as a substitute for quotes and a conversation with your bank.

The common thread is that all three still need a billing system capable of running the Bacs cycle. Even a fully managed route leaves you responsible for what the collections mean inside your business: which member failed, which mandate was cancelled, which amount changed.

What is a Service User Number, and how do you get one?

A Service User Number (SUN) is the six-digit identifier that tells Bacs which organisation is collecting a Direct Debit. Every collection is submitted under a SUN, and the SUN is what a payer’s bank sees on the instruction. If you collect through a bureau today, you are almost certainly collecting under the bureau’s SUN, not your own.

Getting your own SUN means being sponsored. You apply through a sponsoring bank, which assesses your business (its financials, its processes, and its ability to meet scheme rules) before approving you for direct submission. The bank is taking on responsibility for your collections under the scheme, so the assessment is a genuine gate, not a formality.

• Sponsorship is a bank decision. Approval, timelines, and any conditions are set by the sponsoring bank. This is the part of the journey to start early, because it paces everything else.
• Advance notice is agreed at sign-up. When you take out a SUN you confirm how many days’ advance notice you will give payers. The scheme default is a minimum of 10 working days, and a shorter period can sometimes be agreed with the bank if your case supports it.
• Smaller collectors may not need their own SUN. Managed and facilities-managed routes let you collect under a provider’s SUN, which is exactly why they involve less setup. Whether your own SUN is worth the effort is a volume-and-control question.

Because sponsorship and the regulatory questions around it sit with your bank, treat this as a conversation to have with your sponsoring bank or a qualified advisor. Talk Think Do builds the billing platform that operates once the sponsorship is in place; we are not a bank, a bureau, or a regulated advisor.

Can you migrate existing mandates to a new provider?

Yes, and this is the anxiety that most often stalls a decision, usually needlessly. Your existing payers have already authorised collection, and a well-planned migration preserves that authority rather than asking everyone to sign up again.

How much moves depends on whether your SUN changes.

• Same SUN, new tooling. If you already collect under your own SUN and are only changing software or provider, your mandates do not move at all. They stay attached to the SUN, and you point new tooling at the same collections.
• New SUN, transferred mandates. If you are moving from a bureau’s SUN to your own, or between SUNs, your existing mandates are transferred to the new SUN through an established bulk process coordinated with the sponsoring banks. Payers keep their authority and, in most cases, do not need to re-authorise.

The mechanics of a bulk transfer, including any requirement to notify payers and the exact sequencing, depend on the route and are set by the scheme and the sponsoring banks. Confirm the current process with your sponsor before you commit to a date, and verify the latest bulk-change guidance rather than relying on how it worked in the past. Planned properly, the transfer happens without a gap in collection, which is the outcome that matters.

The practical risk in a migration is rarely the scheme mechanics. It is data quality and coordination: making sure every live mandate is accounted for, every collection day is preserved, and nothing falls between the old system and the new one. That is a project management and systems problem, and it is very solvable.

What must your billing platform do once the bureau is gone?

This is the question that decides whether leaving a bureau is a saving or a headache. A bureau does not just submit files; it quietly absorbs a lot of scheme work on your behalf. Bring collection in-house and that work has to live somewhere, which means your billing platform has to be genuinely Bacs-capable, not just able to generate a file.

A platform ready to run without a bureau handles the whole cycle as data.

• The mandate lifecycle. It lodges new instructions electronically through the Automated Direct Debit Instruction Service (AUDDIS), tracks each mandate through its states, and records every change with its reason. A mandate is a financial record with a history, not a row in a spreadsheet.
• Notice-aware, deadline-correct submission. It counts advance notice in working days, adjusts for weekends and bank holidays, and submits each collection to the right Bacs deadline. It works back from the submission date, not the debit date.
• Automated report ingestion. It consumes the scheme’s return and amendment messages as events. A failed collection updates the payment; a cancelled instruction stops future collection; a changed bank detail is applied. Nobody opens a file on a Thursday to find out what happened.
• A complete audit trail. Every financial state change is an event with evidence, which regulated and multi-site operators need and which a pile of processed files can never provide.

This is precisely what we build. The Billing Engine accelerator runs the full Bacs cycle in-house: see Direct Debit mandates and the Bacs cycle for lodgement, notice, and returns handling, and payment runs and batches for scheduled collection you can audit. The technical detail of ingesting returns and amendments correctly is covered in our guide to handling Bacs reports properly.

We have run this at scale for membership operators. The Third Space Atlas platform carries recurring Direct Debit billing for a large, multi-site membership base on an owned system. That is exactly the position a business reaches when it decides a bureau is no longer the right fit.

How should you approach the decision?

Start with the commercial case, then the systems case, then the migration. In that order, each stage informs the next, and you avoid committing to a route before you know it pays.

First, estimate the saving. Use the card versus Direct Debit savings calculator in bureau mode to compare your per-transaction bureau fees against direct submission across your real volume. That tells you whether the effort is worth it at all. If you are still on card payments rather than a bureau, our guide on switching from card billing to Direct Debit covers that step first.

Second, decide the route (own SUN, managed, or API-based) against your priorities on cost, control, and effort. Third, plan the migration around your billing platform’s readiness to run the full cycle. If you want help sizing the saving or designing the system that replaces the bureau’s tooling, book a consultation and we will work through it with you.