How to automate payroll approvals across multiple UK entities without losing control
Copied! A practical guide for UK finance leads on controlling payroll approvals across several entities: what breaks first, what a controlled approval chain looks like, and what automation should and should not do.
TL;DR
- Each UK company in a group is its own employer with its own PAYE scheme, so a single group-wide approval chain rarely fits.
- Only one company in a connected group can claim the Employment Allowance in a tax year.
- A controlled chain needs four things: segregation of duties, dual approval thresholds, a named delegate for every entity, and an audit trail.
- Automation should assemble the data, validate the run against last month, surface exceptions and route to the right named person.
- A named human should still judge the exceptions, approve each entity on their own authority and release the payment.
- HMRC expects the Full Payment Submission on or before payday, and payroll records must generally be kept for at least three years.
See how Round supports finance operations across multiple entities
Why does payroll approval break down across multiple UK entities?
Each UK company in the group is its own employer. HMRC treats connected companies as separate entities for PAYE purposes, most visibly in the rule that only one company in a connected group can claim the Employment Allowance in a tax year, even though every company still runs its own PAYE scheme (gov.uk, Connected companies and Employment Allowance guidance).
Each new entity also has to register separately with HMRC and get its own PAYE reference before its first payday (gov.uk, Register as an employer). Practically, that means a separate bank mandate, a separate authorised signatory list, and usually a separate person who holds the login for each entity's payment portal.
From there, the failure points are predictable:
- Approver lists get set up when the group has one entity and never get revisited when a third or fourth is added.
- Intercompany recharges sit between two entities' payroll costs, so the number a finance lead is approving depends on a journal that has not landed yet.
- The approver who is on leave means the payment file waits, or worse, someone shares a login to get it through anyway.
- And the audit trail lives in an email thread or a message that says "approved, go ahead" rather than anywhere a reviewer can actually find it a year later.
None of this is really a payroll problem. It is a control problem that payroll happens to expose every single month, on a fixed deadline, because HMRC expects the Full Payment Submission on or before payday (gov.uk, Running payroll: reporting to HMRC), not whenever the last signatory gets back from holiday.
What does a controlled approval chain actually look like?
A controlled chain has four parts, and none of them are exotic.
Segregation of duties. The person who prepares the payment file is not the person who approves it. That should hold within one entity, and it should hold across entities too. A payroll or finance ops person assembles the run; a director or finance lead for that specific entity approves it.
Dual approval thresholds. Above a set amount, or for any off-cycle or unusual payment, a second named approver signs off before release. The threshold can differ by entity if the entities differ in size, but it should never be a courtesy step that gets waved through without being looked at.
Delegated authority for absence. Every entity needs a named backup approver, agreed and logged in advance, not chosen in the moment the primary approver goes quiet. This is the single most common failure in multi-entity groups and the cheapest one to fix, because it is a decision you can make once, on a day when nothing is urgent.
An evidence trail that survives an audit. Who approved what, for which entity, against which payment file, and when. Payroll records generally need to be kept for at least three years from the end of the tax year they relate to, and HMRC can charge a penalty of up to £3,000 if your records do not show you have reported accurately (gov.uk, PAYE for employers: keeping records). An approval history buried in a shared inbox does not meet that bar reliably. A logged, timestamped chain does.
Written down in a treasury or approval policy, this is a page, not a project. The difficulty is not defining the chain, it is running it the same way every month across four different logins.
What should automation actually do, and what has to stay human?
Multi-entity groups tend to go wrong in one of two directions. Either they automate nothing, and the finance lead spends a day a month doing the same repetitive checks across separate logins, or they automate the approval itself, and the control disappears along with the manual effort.
The useful split is narrower than either extreme.
Automation should:
- Assemble the data. Pull each entity's payroll run, headcount changes and totals into one place instead of four separate exports, in the same way accounts payable automation pulls invoice data together rather than leaving it in separate inboxes.
- Validate against what came before. Flag when a run is materially different from last month's, when a new starter or leaver has not been reflected, or when an intercompany recharge has not been booked yet. A two-way sync with Xero keeps that comparison current instead of relying on a monthly export.
- Surface exceptions. A large one-off payment, a change to an approver's own pay, a payment date that has drifted from the usual cycle. These get raised before anyone approves anything, not discovered after.
- Route to the right named person. If the primary approver for an entity is marked as away, route to the agreed delegate automatically, with the reason logged, not the login shared.
A named human should still:
- Look at flagged exceptions and decide what they mean.
- Make the actual approval decision for each entity, on their own authority.
- Release the payment.
That split is close to how Round is built to work day to day: automation prepares, reads and surfaces exceptions, while named humans retain consequential approval.
It is a reasonable test to apply to any tool, not just Round's.
If a tool claims to make the approval decision for you, or does not leave a clear record of who signed off, that is a step away from control, not towards it.
The goal is fewer manual checks, not fewer named approvers, and it is worth being specific with any vendor about which of the two you are actually being sold.
How do manual, partly automated and orchestrated approaches actually compare?
Set side by side, the difference between the three approaches is less about effort and more about where the risk sits.
The real tradeoff is time. Fully manual costs less to set up and more to run, every single month, for as long as the group exists. An orchestrated approach costs more to configure once, mapping entities, approvers, thresholds and delegation rules, and considerably less to run afterwards, because exceptions get flagged before anyone has to go hunting for them.
What is the practical sequence for setting this up?
- Map every entity, its bank mandate and its current authorised signatories. Most groups have not done this since the last entity was added, and it usually surfaces at least one name that should no longer be on a mandate.
- Write down the approver and delegate for each entity, by name, not by role. "Whoever is around" is not a control, and it is the thing that breaks first when someone is on leave.
- Set dual approval thresholds per entity, based on typical run size for that entity rather than a single group-wide number that is either too loose for the largest entity or too tight for the smallest.
- Agree what counts as an exception, such as a new starter, a leaver, a one-off payment or a recharge mismatch, and who reviews it before approval, not after the file has already gone out.
- Centralise the data feed so the finance lead is checking one consolidated view across entities and banks, not four separate logins each showing a different slice of the same group.
- Pilot on one entity for one payroll cycle before rolling the rest of the group onto the same chain, and treat the pilot's exceptions as the baseline for tuning thresholds.
- Review the audit trail after the first quarter and tighten thresholds or delegation rules based on what actually got flagged, not on what you expected to get flagged.
None of this requires giving up oversight for speed. It is the opposite: a documented chain, once it exists across a multi-entity structure, is easier to defend in an audit than a habit that lives in one person's inbox.
Sources
Frequently Asked Questions
They can hold the mandate for more than one entity, but each approval should still be a separate, logged decision against that entity's own payment file. Treating a multi-entity run as a single approval defeats the point of segregating duties entity by entity.
Generally yes. Each UK company is treated as its own employer for PAYE, and HMRC does not merge schemes across connected companies just because they share ownership. That is also why only one company in a connected group can claim the Employment Allowance in a tax year.
HMRC requires payroll records to be kept for at least three years from the end of the tax year they relate to, and can charge a penalty of up to £3,000 if your records do not show accurate reporting. Keep the approval trail, meaning who approved what, when, and for which entity, alongside the payroll data itself, not in a separate email thread.
If a delegate has been agreed and logged in advance, the run routes to them and the file still goes out on or before payday, which is what HMRC expects for the Full Payment Submission. Without a named delegate, the file waits, or someone improvises with a shared login, which is exactly the gap that breaks the audit trail.
No. Automation should assemble the run, check it against what came before, and flag anything unusual, but the decision to release money should stay with a named human for each entity. That is the difference between automating the admin and automating the control away.
