Automate BACS Payments in an Accountancy Practice: Where AI Fits

To automate BACS payments in an accountancy practice with dual approval, build the payment file from an approved source, run automated checks on it, have a second person approve a one-page summary, submit through your bank or approved software, then reconcile. AI can help with the checks, especially changed payee bank details, but should never approve or submit.

Automation here means removing re-keying and eyeballing, not removing people. Every manual step you strip out is one less chance for a typo, and every automated check you add is a second pair of eyes. But the two decisions that matter, "is this payee right?" and "is this run right?", remain human, and the process has to show who made them.

Follow me on Instagram@sagnikteaches

What a practice actually pays by BACS

Before designing anything, list the kinds of payment the practice makes and who bears the risk. A typical list for a small practice:

Connect on LinkedInSagnik Bhattacharya

• Client payroll runs, where the practice acts as a bureau and pays employees from the client's funds or by instruction.
• Supplier payment runs for clients, where the practice prepares and the client or the practice authorises.
• Refunds and client-money transfers, which usually carry the strictest rules.
• The practice's own suppliers and staff.

The risk and control differ. Client money needs the strongest approval and records, and your professional body and engagement terms may set requirements. Check them, and ask a qualified adviser if the rules are unclear, rather than assuming a general process covers client funds.

Subscribe on YouTube@sagnikteaches

Know your submission route first

Bacs payments reach the scheme in one of a few ways, and the choice shapes what you can automate. The Bacs website describes direct submitters, who connect to the service through Bacstel-IP, and indirect submitters, who send files through a bureau. It also lists approved software and approved bureaux. In practice, most small practices will use one of three routes:

Banks and software vendors change what they offer, so confirm each feature on their own pages before you design around it. In particular, check whether dual approval can be enforced by the bank or software, not just agreed internally, because a control that only exists as a policy depends on people remembering it.

Also look at the scheme's processing calendar, which shows the non-processing days and the Julian dates that payment files use. A run that is approved too late is not a technical failure, but it is a payroll that arrives late for someone.

The run, in seven steps

1. Source: pull the payment list from one controlled place: the payroll software, the approved bills list in the accounting software, or a locked spreadsheet. Never from an email attachment.
2. Build: generate the payment file from that source, using the software's export or the bank's template. The preparer builds it.
3. Check: run the automated checks described below and produce a one-page summary.
4. Approve: a second person, who did not prepare the run, reviews the summary and the exceptions, then approves in the bank or software.
5. Submit: through the chosen route, before the cut-off, with a record of date and time.
6. Reconcile: match the debit and the credits to the run on the day, and note any rejection.
7. Record: save the file, the summary, the approvals and the reconciliation in one folder per run.

The steps are the same whatever the volume. What changes with volume is how much of step 3 is automated.

Step three in detail: the checks that AI does well

Checks fall into rule-based checks, which a spreadsheet or the software can do, and pattern-based ones, where AI helps. Use both.

Rule checks (no AI needed)

• Sort code and account number in the right format, and the sort code able to take the payment: the sort code checker on the Bacs website, built on data updated weekly, shows whether a sort code can receive Bacs Direct Credits.
• No duplicate payee and amount in the same run.
• Run total equals the sum of the lines and matches the approved list total.
• No payee on the list who is not in the approved payee master.

Changed bank details (where AI helps)

Compare this run's payee details with the last approved master list, or last month's run. Any difference in sort code, account number or account name is a flag. A spreadsheet formula finds exact differences; an assistant is useful for the fuzzy ones, such as a name that changed from "Smith Building Supplies Ltd" to "Smith Bldg Supply", and for explaining the pattern in plain words. Feed the assistant a de-identified comparison. Account numbers are sensitive, so mask most digits, and check your tool's data settings and your engagement terms before pasting anything from a client's payment file into one.

Below are two lists of payees for a payment run: last month's approved master (A) and this month's file (B). Account numbers are masked to the last 3 digits.
1. List every payee whose sort code, masked account number or account name differs between A and B.
2. List every payee in B who is not in A (new payees).
3. List every payee in A who is missing from B.
4. List any amount more than 30% above or below that payee's amount in A.
5. For each flag, write one plain-English line for an approver.
Do not say whether a flag is fraudulent. Do not suggest ignoring any flag.
LIST A: [paste]
LIST B: [paste]

The last two instructions matter. The assistant produces a report; deciding what a flag means is for the approver and a call to the payee.

A worked run: twelve clients' payroll and one supplier batch

Illustrative case: a practice runs monthly payroll for twelve small clients, 64 employees in total, and pays a supplier batch for the car repair garage client. Pay day is the 28th. Because the money must land on the 28th, the file has to go in two processing days earlier, on the 26th, assuming no weekend or bank holiday falls in between. The preparer pulls the payroll file from the software on the 24th and the supplier list from the garage's approved bills.

The check report from the assistant, trimmed and illustrative:

Flags: 3.
1. Employee at the furniture maker: account number differs from last month (ends 482 vs 119). Sort code unchanged.
2. Supplier at the garage: new payee not in last month's list, amount 4,860.00, the largest line in the batch.
3. Employee at the online clothing store: amount 2,140.00 against 1,430.00 last month, 50% higher.
No duplicates found. Total of lines matches the source total.

The preparer does not clear any of them alone. For flag 1, the preparer phones the employee on the number held on the client's file, not a number in any message, and asks for the change to be confirmed. The employee confirms; the change is recorded with the date and the person who took the call. For flag 2, the preparer asks the garage owner to confirm the new supplier and that the invoice is genuine; the owner says the supplier replaces a previous one and forwards the invoice, which the preparer checks against the purchase order. For flag 3, the client confirms a bonus. All three are noted on the summary.

The approver, a manager who did not prepare the run, sees a one-page summary: run totals by client (payroll total, supplier total), count of payments (64 + 18), three flagged items with the resolution of each and who confirmed it, and the submission cut-off. The approval happens in the bank or software, not by email. The file goes in on the 26th, and the preparer reconciles on the 28th, when the payees are credited and the practice's account is debited. Total time: about 90 minutes for the whole practice, most of it the three phone calls.

Why the changed-details check matters so much

Payment fraud against practices often takes the form of a request, apparently from a client, supplier or employee, to change bank details just before a run. The request may come from a hijacked email account or a convincing copy. The control has two parts: never accept a change by email alone, and always verify through a channel you already trusted. The AI comparison makes sure no change slips into a file unnoticed, and the call makes sure the change is genuine.

Some banks also offer Confirmation of Payee, the account name-checking service that compares the payee's name with the account before a payment is made. Ask your bank whether it applies that check to payments in a bulk file, and treat a name mismatch as one more flag for the approver rather than a verdict.

Write the rule where staff will see it: "No bank-detail change is made or paid without a call-back to a number already on file, recorded by the person who made the call, and checked by a second person before the run." Include supplier changes, employee changes and your own staff. Catching duplicate invoices and payment fraud with AI covers related checks on the invoices that feed the payment file.

Dual approval that people can actually follow

Dual approval fails in two ways: it becomes slow, so people find workarounds; or it becomes a rubber stamp, so approvers click without reading. Design against both.

• Separate roles. The preparer cannot approve their own run. If the bank or software can enforce that, use it. If not, write it in the procedure and spot-check.
• A summary, not a file. The approver sees totals, counts, new payees, changed details and exceptions on one page. They can ask to see the underlying lines, but the summary is the start.
• Approve in the system. Approval by email or chat leaves no reliable record. Use the bank's or software's approval, and save the confirmation.
• A cover. Name a deputy approver for when the first is away, so a missing approver does not tempt someone to share credentials.
• Limits. Agree a threshold above which a third person, such as a partner, must also approve. For client money transfers, a partner always approves.

Illustrative threshold: any single payment above 5,000.00 or any run above 50,000.00 needs the partner's approval as well. These numbers are the practice's own choice; set them from your risk and your clients' terms.

The payee master: where most control is won

Every later check compares against a list, so the list itself needs care. Keep one approved payee master per client, with these fields: payee name as on the bank record, sort code, account number, date added, date of the last verified change, who verified it and how (call-back, signed form, or in person). Only two people can edit it, and every edit is logged. Ask the assistant, once a quarter, to review the master for oddities: payees with no payment in twelve months, two payees sharing an account number, accounts held in an individual's name for what looks like a company supplier, and entries with no verification date. Illustratively, for the garage client with 46 suppliers, such a review might turn up six dormant payees and one shared account number. Dormant payees are removed so they cannot be targeted by a change request, and the shared number is checked with the client in case two suppliers really are one business.

Not every change arrives as a request. If the practice submits through Bacs and collects its reports, a payee's bank can notify it of new account details through the Advice of Wrong Account for Credit Service (AWACS). The Bacs website says those advices must be acted on within three working days of becoming available and recommends applying them straight away. Record "AWACS advice" as the source of that change in the master, which keeps it distinct from a change someone asked for by email, and still have the second person check the edit.

What the approver's one-page summary looks like

The summary is worth designing carefully because it is the thing the approver reads. A filled-in, illustrative version for the run above:

The point is that the approver can approve or query in five minutes without opening the file, and the record shows what she saw. If a flag has no resolution written beside it, she sends the run back.

Who does what in a three-person practice

A small practice cannot always separate every role neatly. A workable split for three people, the partner, a manager and a bookkeeper: the bookkeeper prepares the source list and builds the file; the manager runs the checks and approves; the partner approves anything above the agreed thresholds and any client-money transfer, and keeps the master list edit rights with the manager. When the manager is the preparer for a run, the partner is the sole approver. The rule that nobody approves their own work holds in each case. For a sole practitioner there is no second person in the firm, so use an outside approver, such as the client for their own supplier run, with the practitioner's checks documented. That is not perfect segregation, but it is a real second control, and better than a single pair of hands.

Submission, timing and what rejection looks like

Bacs Direct Credit runs on a three-day cycle, which the Bacs website sets out as day 1, input (the latest day a file can be submitted for that cycle), day 2, processing (the files go to the receiving banks), and day 3, entry (payees are credited and your account is debited at the same time). So the date you submit is not the date the money lands. Use the scheme's processing calendar, which marks the non-processing days, and if a bank or bureau submits for you, ask for its own cut-off time on input day and plan to that. Put the practice's cut-offs in the shared diary. Work backwards: for a payroll due on the 28th, set an internal deadline several working days earlier for the source data, a day for checks, a day for approval and a buffer. Illustratively, a practice that builds a pay day plan with a two-day buffer finds that the one time the bank's portal is down, it still pays on time.

Plan for rejection. A file may be rejected for format errors, or individual credits may come back later: when a receiving bank cannot apply a payment, for example because the account has been transferred, the Automated Return of Unapplied Credits Service (ARUCS) returns it and sends a report giving a reason for each item. If the preparer spots after submission that many payments in a file are wrong, the Bacs FAQs say the bank can be asked to withdraw the whole file, but the request must be made before 10.30pm on input day. Write down who collects the reports after submission (the Bacs guidance says to access and act on advices promptly, and most reports stay available for 37 calendar days), and who contacts the payee. A returned payment found three days later is a worse conversation than one found the same morning.

Reconcile and keep the evidence

On the day, match the debit in the bank to the run total, and tick off the credits where the bank statement lists them. Any difference is investigated that day. Then file, in one folder per run: the source list, the payment file, the check report with each flag's resolution, the approver's confirmation and the reconciliation. If a client, bank or professional body asks how a payment was authorised, the folder answers in a minute. Ask the assistant to draft the cover sheet for the folder from your notes, so every run's record looks the same.

The reconciliation step is also where the bank feed matters, and open banking automation for accountants covers how consents and feeds keep those transactions arriving.

Three more cases that test the process

The urgent request. A client emails at 3pm asking for an extra payment to a new supplier before the cut-off, with the details attached. The process says: new payee, so the call-back rule applies. The preparer cannot reach the client on the file number before the cut-off. The payment waits for the next run, and the client is told why. The cost is a day; the cost of the alternative could be the payment itself.

The false alarm. The assistant flags 14 payees as having changed names because the new file uses "Limited" where the old one used "Ltd". The preparer adds a normalisation step: standardise "Ltd" and "Limited" before comparing. Noisy flags train approvers to ignore flags, so tuning the check to reduce them is part of the job, as long as sort codes and account numbers are never normalised.

The missed check. The assistant reports no flags, and a payment goes to an old account. The investigation shows the preparer pasted the wrong version of last month's list. The fix is procedural: the comparison list is always the approved master in a locked place, not a pasted copy, and the check report states which file versions it compared.

How to tell it is working

1. Every run has a folder with the five records above, and any run can be reconstructed from it.
2. No run was approved by its preparer, and no approval came by email.
3. Every bank-detail change in the quarter has a recorded call-back and a second person's check.
4. The check report's flag count is stable: not zero every time (it is probably not checking) and not dozens (people will ignore it).
5. Submission was on time for every run, with the calendar's cut-off visible in the diary.

Run this review quarterly. If the practice also uses AI to look at client books before payments, how accountants use AI to spot errors in client books shows how to add that check upstream, and the approval design here connects naturally to AI accounts payable: approvals and payment runs without chaos. Whatever route you pick, confirm the bank's and software vendor's current features on their own pages first.

Questions about automating BACS runs in a practice

Can AI approve or submit a payment run?

It should not. AI can compare, flag and summarise, but approval and submission are decisions with legal and financial consequences, so a named person makes them. Design the process so the AI step produces a report for the approver and has no access to the bank or the submission channel.

What is the biggest fraud risk in a BACS run?

A changed bank account detail that nobody verified. Fraudsters impersonate a supplier or an employee and ask for new details. Verify every change by calling a known number, not one from the request, and have an independent person check the change before the run.

Is dual approval slower?

Slightly, but it can be quick if the approver gets a one-page summary with totals, new payees, changed details and exceptions rather than a raw file. Build that summary into the run and approval takes minutes.

How do I find out which submission route my practice has?

Check how your bank offers bulk payments, whether your accounting or payroll software is on the scheme's approved software list, and whether a bureau submits on your behalf. The Bacs website lists approved software and bureaux and has a processing calendar.

Further reads

• Dext Pricing for Accountants: Essentials, Advanced and AI Assist — Capture bills upstream so payment files start clean.
• 7 AI Mistakes That Put an Accounting Firm's Client Trust at Risk — How errors with client money damage trust.
• Accounting Firm Standard Operating Procedures With AI: Record to Publish — Write the payment-run procedure down and give it an owner.
• Best AI Tools for Chartered Accountants: Seven for a Small Practice — Other AI tools a small practice can add safely.
• AI for Chartered Accountants: What to Tell Clients About Your AI Use — What to tell clients about AI in checks on their payments.
• How to Automate Client Onboarding in a Small Accounting Practice — Collect verified bank details at onboarding, not at the run.
• ICAEW AI Guidance for Small Practices: A Client Notice and Staff Checklist — ICAEW's generative AI guide turned into a client notice, terms-of-business wording and a one-page staff checklist for a small accountancy practice.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Bacs website (bacs.co.uk: Bacs Direct Credit getting-started page for the input, processing and entry cycle; FAQs on file withdrawal, AWACS and report availability; ARUCS and AWACS service pages; direct and indirect submitter pages; sort code checker; processing calendar) and the scheme operator's Confirmation of Payee page, all checked 4 November 2026. Bank and software dual-approval features are not stated; check each vendor's own page. The practice, files and figures are illustrative.