The short answer: The PAYE calculation is the same whether you pay 15 people or 2,000. What changes at scale is the operating model around it: parallel running when you switch software, separate reporting for every PAYE scheme, TUPE transfers, controlled off-cycle runs, Bacs submission deadlines and segregation of duties.
When you’re paying a few dozen people, payroll is mostly about getting the calculation right. When you’re paying thousands across several entities, with a finance team that needs the numbers to reconcile first time, it’s just as much about process, controls and timing.
The good news? The mechanics don’t change. Income tax codes, National Insurance, and Real Time Information (RTI) submissions work exactly the same way. What changes is everything around them—how you move between systems, how you manage risk, and who’s allowed to do what. To make things easier, we’ve broken down the six areas that matter most once your payroll gets big.
Parallel running when you change software
When a project’s running late, it’s tempting to switch straight over to new payroll software, but you shouldn’t. Going live without a parallel run is the single biggest risk in any payroll migration.
Instead, run your old and new systems side by side for two full pay cycles, then reconcile the results at employee level. That last part matters. Totals can match perfectly while individual employees are wrong in offsetting directions (one person overpaid by £40, another underpaid by the same amount), and a top-level check will never catch it.
When you reconcile, compare:
- Gross-to-net for every employee: gross pay, each deduction and net pay should match line by line.
- Year-to-date figures: these feed every cumulative tax calculation from here on, so any error carries forward.
- Tax codes and NI category letters: migrations are a common point where codes and letters get dropped or defaulted.
- Pension and other deductions: check the contribution basis has carried over, not just the percentage.
Parallel running works well when you plan it into the timeline from day one, but be aware that it roughly doubles the processing effort for those two cycles. A lot of organisations don’t budget for that, so it’s worth agreeing extra resource (or a quieter point in the year, well away from year end) before you start.
Multiple PAYE schemes and entities
Each PAYE reference is a separate reporting entity in HMRC’s eyes. That means every scheme has its own:
- Full Payment Submission (FPS) and Employer Payment Summary (EPS)
- Accounts Office reference and monthly payment
- Employment Allowance position
That last point catches groups out. The Employment Allowance is shared across connected companies, so only one claim is allowed for the whole group. Claiming it on each entity’s EPS isn’t a clever saving—it’s an error, and HMRC will claim it back.
Here’s how that tends to play out in practice. A group with three trading companies sets each one up as its own PAYE scheme, and a different person manages each payroll. Each claims the allowance on its first EPS of the year, nobody has a view across all three, and the overclaim only surfaces when HMRC writes to the group.
Separate schemes work well when entities genuinely need their own reporting, but be aware that every extra scheme adds another set of deadlines, payments and reconciliations. If you run several, keep a single schedule showing every scheme, its references and who owns it.
TUPE transfers mid-year
The Transfer of Undertakings (Protection of Employment) Regulations 2006 (TUPE) protect employees when the business or service they work in moves to a new employer. Their contracts, terms and continuity of employment all transfer with them.
Their PAYE history is a different story. Year-to-date pay and tax figures generally don’t transfer unless HMRC accepts that a succession has taken place [ADD SOURCE: confirm HMRC conditions for PAYE succession on a business transfer]. Without that, transferring employees join your payroll as new starters, so you’ll need their P45s or starter checklists before the first pay date.
The risk is timing. Leave the PAYE treatment until the week of the transfer, and hundreds of people can land on emergency codes on day one, with overtaxed pay and a flood of queries to follow.
To keep things smooth:
- Agree the PAYE treatment early: decide with the outgoing employer, well before the transfer date, whether succession applies or whether you’ll treat everyone as new starters.
- Get the data in a usable format: bank details, NI numbers, student loan status, pension membership and year-to-date figures where relevant.
- Run a test payroll: a dry run for the transferring group catches missing data while there’s still time to fix it.
Good news if you’ve done this before: the process is very repeatable. But stay vigilant, because no two transfers come with the same data quality.
Off-cycle and supplementary runs
At scale, off-cycle payments are a fact of life: a missed overtime claim, a leaver’s final pay, a correction that can’t wait until next month. Each supplementary run is its own FPS, and it has to reconcile back to the main run for that period.
Where organisations come unstuck is when their payroll can’t handle a controlled off-cycle run. Under pressure, someone pays the employee directly from the business account instead, outside payroll. That’s where reconciliation breaks, because the payment never reaches the employee’s tax and NI record, or HMRC’s.
A few practical tips:
- Set clear triggers: agree what qualifies for an off-cycle run and what waits for the next scheduled payroll.
- Use the same approval route: an off-cycle run should go through the same checks as a main run, even if it’s for one person.
- Reconcile every period: check that main and supplementary runs together match what you’ve reported and paid to HMRC.
Off-cycle runs work well as an exception, but be aware that if they’re becoming weekly, it usually points to a data or cut-off problem upstream.
BACs cycles and internal deadlines
BACs Direct Credit runs on a three-day cycle. So for a Friday payday, the file needs to go in on Wednesday, which means approval needs to happen on Tuesday.
That sounds simple, but it shapes your entire payroll calendar. Every internal deadline (timesheets, overtime, new starters, leavers, changes from HR) really works back from that Bacs submission date, not from payday itself. Bank holidays push it back further, so the run before Christmas or Easter can need inputs almost a week early.
Here’s a pattern a lot of large payrolls follow. They publish an annual calendar showing the input cut-off, approval date and Bacs submission date for every pay period, and share it with HR and line managers at the start of the tax year. Late changes still happen, but everyone knows where the line is.
For genuine emergencies, Faster Payments can get an individual correction to an employee the same day. It’s a useful safety net, but it isn’t a substitute for a calendar people actually stick to.
Segregation of duties
The person who adds an employee to payroll shouldn’t be the person who approves the bank file. It’s the control your auditors will ask about, and it’s the one payroll fraud exploits when it’s missing.
The classic examples are a “ghost” employee added to the payroll, or an existing employee’s bank details quietly changed to a different account. Both are much harder to pull off when no single person can make a change and approve the payment that follows.
In practice, that usually means:
- Split set-up from approval: one person keys new starters and changes, someone else reviews and signs off.
- Treat bank detail changes as high risk: verify them independently, not just by replying to the email that asked for them.
- Review exception reports every run: new starters, leavers, bank changes and large variances against last period.
This works well in a team of five or more, but be aware that smaller payroll teams often can’t fully separate roles. If that’s you, a documented second review by someone outside payroll (finance, for example) is a sensible compromise.
In-house software or a managed service?
Once you’re running payroll at this scale, the choice between in-house software and a fully managed, outsourced service is a real decision worth taking time over.
In-house software tends to win on control and cost for larger organisations, particularly with multiple PAYE schemes or several entities. A managed service shifts more of the operational load (cover for absence, rate updates, year-end processing, for example) to a team that already has the people and the controls in place. Neither is automatically right, and headcount alone won’t decide it. Complexity, the size of your team, and how much risk you want to hold in-house all matter just as much.
Whatever your needs, Cintra has the solution to support your company at this size and beyond. If you’d like to talk through which approach fits your organisation, book a demo and we’ll walk you through how Cintra handles payroll at scale.
Payroll Software
Find out more about Cintra's payroll software, built to handle whatever your workforce needs—no matter how complex. Packed with deep functionality, intuitive workflows, and expert support for in-house payroll teams.
Frequently asked questions
Q. Does the PAYE calculation change for large employers?
A. No. Tax codes, National Insurance and student loan deductions work the same way for every employer. What changes at scale is the operating model: controls, reporting across multiple schemes, and how you manage migrations and transfers.
Q. How long should you parallel run new payroll software?
A. Two full pay cycles is a sensible minimum, with every employee reconciled line by line, not just the totals.
Q. Can a group claim the Employment Allowance for each company?
A. No. The Employment Allowance is shared across connected companies, so a group can only make one claim between them.
Q. Do year-to-date figures transfer under TUPE?
A. Generally not, unless HMRC accepts that a succession has taken place. Otherwise, transferring employees join your payroll as new starters, so plan the PAYE treatment well before the transfer date.
