--- title: "How to scale BACS payments: bureaus, SUNs and the volume trap" description: "Scaling BACS for accountants, investment firms and platforms: how bureaus and Service User Numbers work, the operational traps at volume, and how to run large BACS runs without month-end chaos." url: "/blog/scaling-bacs-payments-bureau-sun/" date: "2026-08-05" updated: "2026-09-07" author: "Valeria Vahorovska" tags: ["Guides","Payouts"] --- Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “How to scale BACS payments: bureaus, SUNs and the volume trap”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks. # How to scale BACS payments: bureaus, SUNs and the volume trap BACS is boring in exactly the right ways — cheap, predictable, built for volume — right up until you're running it at real scale. Then the boredom turns into a month-end operation: files to prepare three days ahead, cut-offs to hit, returns to chase, and client money to keep separate and correct. For accountancy practices, investment firms and platforms pushing regular payouts, "scaling BACS" isn't about the rail's speed; it's about the machinery around it. Here's how that machinery actually works. ## Why hand-keyed BACS stops working A few BACS payments a month, you can submit by hand. A few hundred across a dozen client entities, and manual submission becomes the bottleneck: someone assembling files days in advance, re-keying payee details, watching cut-off windows, and reconciling what came back. [BACS](/glossary/bacs/) runs on a **three-business-day cycle** — submit day one, process day two, credit day three — so every error is expensive precisely because you find out about it late. The scheme operator's own pages set the mechanics out plainly. On [input day](https://www.bacs.co.uk/bacs-schemes/getting-started/bacs-direct-credit/) the file must reach Bacs between 07:00 and 22:30; on processing day it is passed to the receiving banks; on entry day the recipients are credited and your account is debited at the same moment. The cycle counts English bank working days only. Scaling BACS means industrialising three things: **how files get submitted**, **whose money is whose**, and **how returns get reconciled**. ## Bureaus and SUNs: how submission actually happens To submit to the BACS scheme you need a **Service User Number (SUN)** — the unique six-digit number Bacs allocates to an authorised service user — and an approved route in. There are two ways to get one: - **Your own SUN.** Sponsored by your bank (the *sponsoring PSP*, in Bacs' terms), with the scheme's requirements to meet. You appear on payees' statements under your own identity and keep full control — worth it at high volume or where statement branding matters. You submit as a **direct submitter**, through Bacstel-IP software or the Bacs payment services website. - **A bureau's SUN.** A **Bacs Approved Bureau (BAB)** is a commercial bureau awarded approved status by Bacs and inspected against its standards, permitted to submit files on behalf of others. Submitting as an **indirect submitter** under its SUN is faster to start and offloads much of the compliance overhead. Bacs reports that over half of organisations using the service submit this way. Most operations begin on a provider's or bureau's SUN and only pursue their own once volume, control or branding justify the setup effort. ## The accountancy case: many entities, one operation For an **accountancy or bookkeeping practice**, the hard part isn't one payroll — it's *many*. Client A's payroll, Client B's supplier run, Client C's expenses, each a separate entity whose funds must never mix, all on the same three-day cadence. Scaling here is about **multi-entity segregation** and clean per-client reconciliation: every run attributable to the right client, every return matched back, no commingling. Do it on spreadsheets and it's a standing month-end fire; do it on a platform that holds and separates client funds and reconciles returns automatically, and it's a scheduled, boring job again — which is what you want. ## The investment-firm case: regular distributions, tight controls **Investment firms** push scheduled distributions and redemptions to many recipients, and the pressure is control and audit as much as volume. Validated payee details (a failed distribution is a three-day round trip and an unhappy investor), a clean audit trail on every run, and reconciliation that flags failures the moment they return rather than at period close. ## The regulated-platform case: Faster Payments *and* BACS Platforms — including in regulated sectors like iGaming — usually need **both rails**: BACS Direct Credit for cheap scheduled runs, Faster Payments for anything instant or ad hoc. But at that level the harder questions are upstream of the rails: **KYC/AML** on payees, **safeguarding** of client funds, and holding money on behalf of others compliantly. Processing Faster Payments and BACS at scale in a regulated vertical is a licensing-and-controls problem wearing a payments-rail costume. (For the rail mechanics themselves, see [Faster Payments vs BACS vs CHAPS](/blog/faster-payments-vs-bacs-vs-chaps/).) ## How to scale BACS payments, by sector The three-day cycle, the SUN and the bureau are the same for everyone. What changes by sector is which constraint bites first: volume, timing, client-money rules, the number of SUNs, or whether to submit direct or through a bureau. Below, one answer per sector — the constraint it hits, and the fix. ### Accountants and bookkeeping practices The constraint is entity count. An accountancy practice runs BACS for dozens of clients, each a separate legal entity with its own payday, its own suppliers and its own bank account. Client money rules forbid mixing those funds, and a return has to land against the right client, not the practice. The fix is a bureau-style operation: one submission point, one SUN per client (or the practice's bureau SUN with per-client sub-accounts), and per-entity reconciliation of every run and every return. The practice stops keying files and starts approving them. A platform that holds each client's funds apart and matches returns automatically turns a month-end fire into a scheduled task. ### Payroll providers The constraint is timing at volume. A payroll provider's BACS runs are pinned to hundreds of clients' paydays, and every one of them has to be on input day three working days ahead — later and the wages are late. Missed cut-offs, not bad files, are the scaling failure. The fix is a submission calendar that works backwards from each payday, files assembled and validated automatically the moment payroll is signed off, and a Faster Payments lane for the inevitable late starter or correction. Most payroll providers hold Bacs Approved Bureau status themselves; the operational win is letting the software own the calendar so a person never watches a 22:30 deadline. ### Investment firms and wealth managers The constraint is client-money rules and audit. Investment firms and wealth managers push distributions, redemptions and fee rebates to many investors, and every pound is client money under the FCA's CASS regime until it lands. The BACS run must reconcile to the penny against the ledger, and a bounced distribution is a three-day gap in someone's account. The fix is validation before input day (modulus and account-name checks on every payee), a segregated client-money account per scheme or mandate, and automatic matching of BACS returns to the originating instruction. Direct submission under the firm's own SUN suits the audit trail; the bureau route suits smaller managers. ### Lending platforms The constraint is two-directional flow. A lending platform pays out loans on Bacs Direct Credit and collects repayments on Direct Debit, so it runs both halves of BACS under the same SUN, with AUDDIS handling the electronic Direct Debit Instructions. The volume trap is the collections side: one returned Direct Debit is a missed repayment, and at scale unpaid returns arrive in bulk on entry day. The fix is Faster Payments for the disbursement (the borrower wants the money today), BACS for the scheduled collections, and returns reconciled straight into the loan ledger so an unpaid item triggers a retry or a contact, not a month-end review. ### Fintech startups The constraint is that you have no SUN yet. Bank sponsorship for a direct SUN takes time and scrutiny a young company rarely has, so the scaling question is really a starting question. The fix is to begin as an indirect submitter through a Bacs-approved bureau or a payments platform that already holds one, and to design the operation as if you will one day submit direct: clean payee data, per-entity segregation, automated reconciliation. Add Faster Payments from day one for anything instant. When volume and statement branding justify it, migrate to your own SUN without rebuilding the process. ### Merchants and marketplaces The constraint is payee data quality. A merchant or marketplace paying sellers, suppliers and partners has thousands of sort codes and account numbers it did not type itself, and each wrong one is a bounced payout that surfaces three days later. Volume makes the error rate visible. The fix is validation at onboarding — modulus checks and Confirmation of Payee before the first payout, not after the first bounce — plus a routing rule: the weekly settlement run goes on BACS at per-item pricing, and the on-demand payout goes on Faster Payments. Returns are matched back to the seller balance automatically, so a failed payout is a corrected bank detail, not a support ticket. ### Travel agencies The constraint is calendar-driven supplier payments. A travel agency pays hotels, airlines and ground operators against departure dates, often from trust or client-account arrangements that keep customer money separate until the trip is delivered. The three-day cycle is fine for the supplier run booked weeks ahead; it fails for the late booking, the reissued ticket and the refund promised today. The fix is a split by urgency — scheduled supplier payments on BACS, time-critical ones on Faster Payments, the occasional large deposit on CHAPS — with every payment reconciled to the booking so the trust account balances by trip, not by month. ## The failure mode nobody plans for: returns The single biggest source of BACS pain at scale is **bad bank details**. A wrong sort code or account number doesn't fail loudly at submission — it bounces on the three-day cycle, so you learn about it days later, after you thought the run was done. Reduce it with **validation on the way in** (modulus checks, account verification), disciplined payee-data hygiene, and **automatic reconciliation of returns** so a failed item surfaces immediately and gets re-issued, instead of surviving as an unexplained gap in someone's account. ## Where Fynex fits Scaling BACS is a money-operations problem, which is the layer Fynex runs. Rather than treating submission, segregation and reconciliation as three manual jobs, Fynex keeps funds safeguarded with Fondy Ltd, an FCA-authorised EMI (FRN 900705), keeps each client's or entity's money cleanly separated, validates payee details before a run rather than after it bounces, and reconciles BACS returns back to the originating payment automatically — while [routing anything time-sensitive over Faster Payments instead](/features/payouts/) when the three-day cycle won't do. Fynex is the layer above the rails, not a rail: it pays UK payees by Faster Payments and books the result. A large BACS run behaves like the boring, scheduled thing it's supposed to be, across as many entities as you serve. This is the BACS chapter of [Fynex for UK businesses](/uk/). Related: [ISO 20022 structured addresses](/blog/iso-20022-structured-address-deadline/) is the SWIFT deadline — delayed from November 2026 — that reaches the payout file itself, and [instant means irrevocable](/blog/instant-means-irrevocable/) covers what changes when you move part of the run off BACS onto a faster rail. BACS scales fine. It's the operation around BACS that either scales with it or becomes the job.