Maker-Checker Payment Workflow for a UK Finance Team

[aa disclaimer]
Legal Disclaimer: This article is for informational purposes only and does not constitute legal, financial, compliance, or tax advice. Banking eligibility, regulatory requirements, and provider policies vary by jurisdiction. Consult qualified professionals before making decisions.
[/aa]

One failure pattern repeats in small finance teams. Four people share a single banking login, and a supplier payment leaves the account with one wrong digit in the IBAN. Nobody can say who released it. The audit trail names only the shared user.

A maker-checker payment workflow for a UK finance team prevents that sequence. Two named people touch every transfer, and the banking record shows both.

This guide covers the six-step setup and a role matrix for a multi-user business account, then an example threshold table and the control gaps that defeat the process most often. Finance managers and accountants can put a working payment approval workflow in place within a working week.

[aa key-takeaways]

Key Takeaways

1. Six steps build the workflow: roles, limits, routing, deputies, audit trail and a low-value test run.

2. The maker prepares each payment and the checker approves it, so no single person starts and releases the same transfer.

3. A second approver should trigger on amount and on every new recipient. CHAPS has no maximum payment value, so each business sets its own ceiling.

4. A shared login breaks the audit trail and the maker-checker rule at once.

5. A two-person team needs compensating controls, such as owner approval above a fixed amount and a monthly reconciliation by an outside accountant.

6. A quarterly review matches user rights to the people who actually work on the team.

[aa btn]Book a Call[/aa]
[/aa]

Maker-Checker Payment Workflow for a UK Finance Team: Setup in Six Steps

A maker-checker workflow splits each payment between two people. The maker prepares the payment in the banking portal, and the checker reviews and approves it before money leaves the account. Auditors often call the same control the four eyes principle.

Anyone who needs to know how to set up a payment approval workflow can follow a six-step sequence, each ending in one written decision that fits on a single page.

1. Map which person prepares and which person releases each type of payment

2. Set limits for the second approver

3. Route payments by type, with a separate route for payroll and FX

4. Name deputies for absence

5. Switch on the audit trail and export it monthly

6. Test with low-value payments

Step 1: Map Who Prepares and Who Releases Payments

The first task is an inventory of outgoing payment types: supplier invoices, payroll, tax, FX conversions and one-off transfers. Beside each type, the team writes the name of the maker and the name of the checker. In a four-person team the pairing usually rotates, so the person who keys a supplier payment never approves that same payment.

One rule carries the whole step. The maker and the checker for any given payment are two different people. A payment authorisation that one person can start and finish is a single-approver payment, whatever the screen calls it.

Step 2: Set Payment Limits for the Second Approver

The strictest version of the process puts a checker on every payment. Most teams relax that for small recurring transfers, which usually go through Faster Payments, a service that runs around the clock. Those teams require a second approver above a set amount, and for every new recipient or changed bank detail.

Whatever the rail, the ceiling on a single transfer comes from the business's own rules. The threshold table later in this guide shows one way to set those lines.

[aa fast-fact]
Fast Fact: CHAPS, the Bank of England's same-day sterling system, sets no minimum or maximum payment limit.
[/aa]

Step 3: Route Payments by Type

Payroll and supplier runs carry different risks. A payroll file moves many payments at once, so the checker reviews the file total and the headcount, not each line. A supplier payment goes to one recipient, which lets the approver compare the invoice with the name and account details. Marketplace operators with many payouts split routes the same way, as the marketplace payout setup shows.

FX conversions need a route of their own. The checker confirms the currency pair and the rate window before approval, since a correct payment in the wrong currency still costs money. Contractor and payroll runs are the payments most teams send through a second approver first, as the guide to a multi-currency account for contractor pay shows.

Step 4: Name Deputies for Leave and Absence

A workflow with one named checker stalls the day that person takes leave. Teams then share credentials to keep payments moving, and the shared credentials destroy the control the workflow exists to provide.

The fix is a deputy list written into the payment approval process. Each checker has one named substitute with the same permission level, and the administrator records the cover dates.

Step 5: Turn on the Audit Trail

Every action needs a name and a timestamp. Auditors read the log to see who created, edited, approved and released each payment, and whether segregation of duties operated in practice, since a written policy alone proves nothing.

Teams should export the log every month and file it with the month-end close. A log that nobody exports often turns out to be incomplete on the day an auditor asks for it.

Step 6: Test With Low-Value Payments

Before the first real run, the team pushes £1 test payments through the full flow. The maker creates and the checker approves; a third person then confirms the entry in the audit log. One failed test, such as a checker approving their own payment, exposes a permission error that would otherwise surface on a £40,000 supplier run.

Developers who connect accounting software to payments follow the same logic, as the guide to sandbox testing for UK payment APIs explains.

What this means in practice: six decisions, written once, replace an unwritten habit.

Role Matrix for a Multi-User Business Account in the UK

A multi-user business account in the UK assigns each person a role, and the role decides which payment actions that person can take. Four roles cover most finance teams. The administrator manages users and limits but does not release payments.

The administrator role carries the highest risk. A person who can add users and set limits can also give themselves checker rights. The business should therefore name one administrator who never acts as a maker, or add a second administrator who reviews every role change. The four eyes principle applies to permissions as much as to payments.

[aa cta]

Assign Maker and Checker Roles to Every Payment User

EQWIRE is a UK electronic money institution authorised and supervised by the FCA. Its multi-currency business accounts include role-based access controls for finance teams and role-based approvals for batch payments.

[aa btn]Open Business Account[/aa]
[/aa]

Payment Approval Workflow for UK Business: Threshold Table Example

A threshold hands a transfer to a second approver when the amount or the recipient crosses a set line. Banks call this dual authorisation, and portals typically let an administrator set the thresholds.

The table below is an illustrative example for a ten-person company that pays about 120 suppliers. Real thresholds depend on the business's risk appetite and on the limits its bank imposes. FCA guidance on segregation of duties names no pound figure, so each business decides.

Bank-detail changes deserve the tightest rule. A common fraud pattern is an email that impersonates a supplier and announces new account details, so the workflow needs a call-back to a phone number already on file.

Confirmation of Payee covers part of the same risk. The service compares the recipient name with the account at the receiving bank, and Finextra reports that it reaches 99% of the organisations that initiate Faster Payments. The check catches name mismatches. It cannot judge whether the payment deserves approval, which is why the checker still matters.

Groups that pay suppliers from several legal entities add an entity-level approver to the table, as the procurement group account setup shows.

Dual Approval for Business Payments: Common Mistakes

The most common failure is a shared login, because the audit trail then names no individual. Two further mistakes follow close behind: self-approval and stale limits.

Shared Logins

Regulation 72 of the Payment Services Regulations 2017 requires payment service users to take all reasonable steps to keep their personalised security credentials safe. Credentials shared across four people sit uneasily with that duty. They also remove the maker-checker control, because the second approver may be the same person under the same login.

An Approver Who Is Also the Maker

A user who holds both the maker and the checker role can approve their own payments unless the portal blocks self-approval. A single test after each update shows whether the block works.

Limits Nobody Reviews

A threshold set when supplier payments averaged £3,000 does not fit a year in which they average £9,000. A limit that is too low produces the opposite failure: the checker faces a queue of 40 requests and approves them in bulk without reading.

Thresholds need an owner and a review date. Both fit into the quarterly review at the end of this guide.

Why the second pair of eyes works: whoever prepared a payment has looked at the same invoice for ten minutes and stops seeing it. A fresh pair of eyes catches what the author no longer notices:

• a transposed digit in an account number

• a duplicate invoice

• a payment in the wrong currency

• bank details that changed since the last payment

Segregation of Duties in a Small Finance Team

Segregation of duties in a finance team means that no single person handles every stage of the same payment, from preparation to reconciliation. Auditors treat separation of duties as a synonym for the same control. Since 1 September 2025, the UK failure to prevent fraud rules have named segregation of duties and sign-off arrangements as financial-control practice for large organisations.

FCA Handbook guidance SYSC 3.2.5G tells regulated firms to segregate duties in a way that reduces opportunities for financial crime when the business is large enough to allow it. Its example is the split between front-office and back-office staff, so that no single person can run a transaction from start to finish. The guidance applies to FCA-regulated firms. For an ordinary UK company it works as a benchmark that auditors and lenders recognise, not as a legal duty.

What to Do When the Team Has Only Two People

A two-person team cannot staff separate maker and checker roles and also an independent reconciler. Compensating controls close the gap:

• The owner or a director approves every payment above a fixed amount, for example £10,000.

• The bookkeeper receives a monthly report of all released payments.

• An outside accountant reconciles the bank statement each month.

• The administrator role sits with the director and never with the maker.

The two people still apply the four eyes principle to the largest payments. The smaller ones rely on review after the fact.

Quarterly Review Checklist

A quarterly review keeps the workflow aligned with the team. The reviewer works through six checks:

1. Compare the user list with current staff and remove leavers within the same week.

2. Confirm that no user holds both maker and checker rights.

3. Compare thresholds with last quarter's average payment size.

4. Test one deputy approval for each checker.

5. Export the audit log and match ten sampled payments to their invoices.

6. Review every bank-detail change and confirm that a call-back was logged.

A payment approval workflow for businesses of any size stays effective only when one person owns it. The review needs a named owner and a calendar date.

FAQ

How does a maker checker workflow reduce payment errors in a finance team?

A maker checker workflow reduces payment errors because a second person reviews every payment before release. People miss their own mistakes after long staring at one document, and a reviewer compares the instruction with the source file. The audit trail also shortens any later investigation, since it records who approved what. The workflow cannot verify the recipient name against the bank's records, which is why Confirmation of Payee and a call-back for changed bank details remain necessary. A finance team that sets a lower threshold for new recipients catches the highest-risk errors first.

What payment limits should trigger a second approver?

No fixed pound figure applies to every business, because FCA guidance on segregation of duties (SYSC 3.2.5G) names none. A practical starting point ties the limit to payment size: for example, a second approver above twice the average supplier payment, and for any new recipient or changed bank detail. CHAPS has no maximum value, so the ceiling sits with the business. The finance manager reviews the figure each quarter.

Can two people approve the same payment in a business account?

Yes, business banking portals typically support two approvers on one payment, and the feature is called dual authorisation or dual approval. Each approver acts under a personal login, and the payment releases only when both approvals are in place. A single person cannot count as two approvers, so a shared login defeats the rule. Many teams set the rule as any two of three named checkers, which avoids a stalled payment when one approver is away.

Why do auditors expect dual authorisation on outgoing payments?

Auditors expect dual authorisation because an outgoing payment is the point where money leaves the business, and a settled payment can rarely be recalled. Segregation of duties is a standard internal control, and the audit trail shows that the control operated during the period under review. The FCA's SYSC 3.2.5G guidance sets a comparable expectation for regulated firms. Lenders and investors often ask for the same evidence. Auditors test the control by sampling payments and confirming that two different users approved each one.

A maker-checker payment workflow for a UK finance team comes down to six decisions: who prepares, who approves, which payments need a second approver, who handles absences, what the log records and how a test run proves it. Giving every user a named login and keeping one threshold sheet leaves auditors a trail they can read. Setting roles first and limits second produces a payment approval workflow that survives staff changes. Teams that want to try the checklist on a live account can start with EQWIRE's business accounts, which carry role-based approvals.