In short: it’s worth integrating HR and payroll when a specific operational trigger makes the hand-off between them a genuine risk: a second legal entity, a TUPE transfer (Transfer of Undertakings, Protection of Employment), a new pension scheme, a second pay frequency, an HR system going out of support, or the one person who understands your payroll leaving. Below roughly 200 employees on one PAYE (Pay As You Earn) scheme, integration rarely pays for itself.
Figures verified against HMRC (HM Revenue and Customs) rates and thresholds for employers 2026 to 2027, checked on 20 August 2026.
Almost everything written about integrating HR and payroll argues that you should do it. Very little says when the right time actually is, and our research found that 70% of buyers now say their next software purchase will be a combined HR and payroll solution, so the pressure to move is real. What’s missing from most advice is what the project takes out of your year. So, over this page, we’ll set out the events that actually force the decision (some of which you might recognise), the size and complexity thresholds, and what the work costs in elapsed weeks so you have the full picture.
The three questions that help you decide
Ultimately, your decision comes down to three things, in this order.
- Is there a dated event in the next twelve months that changes the shape of the payroll? A transfer, an acquisition, a new legal entity, a new pension scheme, a change of pay frequency, or a statutory change like mandatory payrolling of benefits in kind from April 2027. A dated event sets a firm deadline. Without one, you’re choosing the date yourself, and the right date is almost always the start of a tax year.
- How much of the risk sits between the two systems rather than inside either of them? If HR data reaches payroll as a spreadsheet emailed on the Wednesday before the run, that’s exactly where your errors live.
- Could you survive the project? An integrated implementation for a mid-market employer runs twelve to twenty-five weeks and takes up twenty to sixty days of your own payroll and HR team’s time, on top of running the payroll as normal. If your payroll manager is already your single point of failure, adding a system change on top is how a risk turns into an incident.
If the answer to the first two questions is no, our honest advice is to wait until the next tax year end before revisiting the integration.
Size and complexity: the thresholds that actually matter
Headcount on its own is a weak signal. Two thousand people on a single monthly payroll in one legal entity is actually a simpler operation than four hundred people spread across three entities on weekly, fortnightly, and monthly cycles. What really drives the case for a single system is the number of hand-offs per pay period, and hand-offs multiply with entities, frequencies, and change volume, not with headcount.
That said, headcount does set a floor. Below roughly 200 employees, the licence and implementation cost of a genuine mid-market integrated system doesn’t recover, and the sensible route is payroll outsourcing alongside whatever HR system you already use. Above 200, here are the thresholds that matter.
Complexity thresholds and what each one does to the case for integrating
| Dimension | Below the threshold | At or above the threshold | Why it changes the case |
|---|---|---|---|
| Employees | Under 200 | 200 or more | Under 200, software licensing and implementation cost more than the errors they prevent. Outsource the payroll instead. |
| Legal entities | One | Two or more | Every entity is a separate PAYE scheme, a separate Accounts Office reference, a separate set of year end submissions, and a separate late filing penalty exposure. Reconciliation across entities in two systems is manual. |
| Pay frequencies | One | Two or more | A second frequency doubles the number of hand-off windows in a month and creates overlapping cut-off dates that a spreadsheet process handles badly. |
| Employee changes per period | Under about 20 | 40 or more | Forty changes a period is 480 hand-offs a year. At that volume, rekeying stops being an inconvenience and starts being a statistical certainty of error. |
| Payroll staff who can run a full cycle | Two or more | One, or none besides the manager | Integration reduces the knowledge held in one person's head, but only if the project happens while that person is still there. |
| Sites, contracts, or terms variants | One or two | Several, or TUPE-protected terms | Transferred terms have to be held somewhere and applied correctly every period. Two systems means holding them twice. |
Cross two or more of those lines, and the case for integrating stops being a preference and becomes an operational argument.
The eight triggers and which ones set a deadline
Below are some of the events that actually start integration projects in UK mid-market organisations. Some impose a date. Most don’t, and that difference matters, because a trigger without a date should be worked into a planned start-of-tax-year cut-over instead of justifying a rushed go-live date.
| Trigger | Sets a date? | What breaks if you do nothing | The suggested action |
|---|---|---|---|
| Headcount crosses 200 | No | Nothing yet. Outsourcing may still be cheaper | Review your process |
| Headcount crosses 500 | No | Manual reconciliation between systems stops being reliable | Plan for the next 6 April |
| Second legal entity | Yes, first payday | Employment Allowance claimed on the wrong scheme, per-scheme filing penalties, split year end | Register the scheme now, integrate at the next tax year boundary |
| TUPE transfer in | Yes, transfer date | Transferred terms held in two places and applied inconsistently | Load into what you have. Integrate the following year |
| Acquisition | No | Nothing immediately. Scoping too early is the risk | Complete, run as-is for a quarter, then scope |
| New pension scheme or provider | Yes, scheme start | Assessment and contribution files reconciled by hand every period | Align the scheme change with the system change if you can |
| Second pay frequency | Yes, frequency start | Overlapping cut-offs, FPS (Full Payment Submission) pay frequency errors, year to date drift | Change frequency and system at the same tax year boundary |
| HR system end of life | Yes, end of support | An unsupported system holding employee personal data | Evaluate integrated options in the same procurement |
| Payroll manager leaving | No | Undocumented rules leave with them | Document first, project second, unless they can stay for the project |
What one missed leaver costs
Now, let’s consider a real scenario. Nothing on this subject is quantified anywhere, so here’s a further factor to consider: what if you miss an employee who has left your company, and they remain on your payroll? A leaver whose termination sits in the HR system but doesn’t reach payroll before the cut-off gets paid one more month.
Here’s what that costs an employer in 2026-27, for someone on £35,000 paid monthly on tax code 1257L, in a qualifying pension scheme at the auto-enrolment minimum, with relief at source so taxable pay isn’t reduced by the employee contribution.
One month overpaid to a leaver, £35,000 salary, 2026-27 rates
| Line | Working | Amount |
|---|---|---|
| Gross overpaid | £35,000 divided by 12 | £2,916.67 |
| Employer National Insurance | 15% of (£2,916.67 less the £417 monthly secondary threshold) | £374.95 |
| Employer pension | 3% of qualifying earnings (£2,916.67 less £520) | £71.90 |
| Total employer outlay | Gross plus employer NI plus employer pension | £3,363.52 |
| PAYE deducted | 20% of (£2,916.67 less the £1,048 monthly personal allowance) | £373.73 |
| Employee National Insurance | 8% of (£2,916.67 less the £1,048 primary threshold) | £149.49 |
| Employee pension | 5% of qualifying earnings | £119.83 |
| Net paid to someone who left | The amount that actually left your bank account and has to be chased | £2,273.62 |
The PAYE and National Insurance are recoverable through a corrected Full Payment Submission (FPS). The £2,273.62 net, though, is a civil debt owed by a former employee who’s already spent it. Two of those a year is roughly £4,500 of write-off risk, plus the admin cost of chasing it, before you even count the employer NI and pension that also have to be unwound. But, with one connected point of truth, every person who leaves your company leaves your payroll system as they leave your HR.
What does integrating actually cost in project time and internal effort?
Now we’ve highlighted when an integrated solution is something to consider and why you might do so, let’s look at what comes once you’ve made the decision to switch. You’ll struggle to find any information about exactly what integration costs you in time and effort.
For full visibility, here is a rough estimate of the planning ranges for a UK mid-market integrated HR and payroll implementation, from signature to a clean first live run. They’re not a quotation by any means, but something to consider.
| Shape of the operation | Elapsed weeks | Your team's days | Parallel runs |
|---|---|---|---|
| 200 to 500 employees, one entity, one frequency | 12 to 17 | 20 to 30 | 2 |
| 500 to 1,500 employees, one or two entities, two frequencies | 16 to 24 | 30 to 45 | 2 to 3 |
| 1,500 to 3,000 employees, several entities, multiple frequencies | 22 to 32 | 45 to 70 | 3 |
| 3,000 or more, four or more PAYE schemes, transferred terms in the population | 28 to 45 | 60 to 110 | 3, sometimes 4 |
| Any of the above with no HR system today, so the HR side is built from scratch | Add 3 to 6 weeks | Add 10 to 20 days | Unchanged |
| Any of the above where HR data currently reaches payroll by rekeying | Add 2 to 4 weeks | Add 8 to 15 days | Unchanged |
While this table may make an integration look like a chunk of time and effort, it does beg the question: instead of hours of reconciling mis-matched data and disconnected systems, are the 100 or so days needed to plan and test your new joined system worth the time you will save in the long run? We’d wager the answer is yes!
Get the latest insights and best practice guides, direct to your inbox.
Why waiting until the 6 April is cost-effective
If nothing external is forcing your hand, go live with the first pay run of a new tax year. The reason is mechanical: a payroll carries year to date figures, and a mid-year cut-over means moving those figures between systems while HMRC’s record stays where it was.
Eleven months of preparation before a 6 April go live
6 April, first run of the new tax yearHere’s what changes if you cut over mid-year instead:
| Item | Go live 6 April | Go live mid year |
|---|---|---|
| Year to date figures | Everyone starts at zero. Nothing to migrate | Every employee's taxable pay, tax, NI by category, student loan, pension and statutory payments to date must be loaded and proved |
| Payroll IDs | Set once, cleanly | If the ID changes you must set the payroll ID changed indicator and report both the old and the new ID. HMRC warns that reusing a previous payroll ID creates a duplicate record and reports payroll incorrectly |
| Cumulative continuity | Not applicable | Year to date financial data must cumulate from the previous submission. A rounding difference of pennies per employee becomes a reconciliation exercise across the whole population |
| Tax codes | Applied fresh from the P9 exercise, with no week 1 or month 1 markers carried over | Codes and their cumulative or non-cumulative basis must be carried across exactly as HMRC holds them |
| P60s | One system produces the whole year | One tax year, two systems. The P60 must reflect the full year, which means the new system must hold the old system's figures correctly |
| Statutory payments in progress | Rare, and start fresh | Maternity, paternity, adoption, shared parental and sick pay in progress carry weeks paid, average weekly earnings, and recovery percentages that all have to move |
| Pension assessment history | Clean start with a known postponement and opt-out position | Opt-outs, postponements, and re-enrolment dates all have to migrate, or people get reassessed and re-enrolled wrongly |
| Parallel running | Runs against the closing tax year, which is stable | Runs against a live year with in-flight changes, so differences are harder to attribute |
None of that makes a mid-year cut-over impossible, of course. Plenty of organisations do it, because a contract ends, an entity’s created, or a system goes out of support, and it works. It’s not something we want to dissuade you from, but it’s something to bear in mind if a new tax year integration would work for you.
One further date is worth putting in the plan now: mandatory payrolling of certain benefits in kind starts from April 2027. Any organisation currently reporting benefits on P11D will be changing how benefits reach payroll anyway. If you’re going to integrate within the next two years, doing it at the same boundary as that change is cheaper than doing it either side.
How to integrate payroll and HR
So, if you’ve got this far and integrating HR and payroll feels like the right move for you, you’re probably wondering how the process actually maps out. The sequence below is where the timing decisions above land in practice. Each step is a place where getting the order wrong adds weeks.
- Write down what your payroll actually does, before you look at any software: Every pay element, every rule, every exception, every protected rate, and where the contractual authority for each one lives. This is the single highest value week in the whole project, and it’s the one most often skipped.
- Decide the architecture before you decide the vendor: One database, or two systems with a feed. That question determines which vendors are even in scope, and it’s worth asking a more fundamental one first: where did this software actually come from? A system built as a payroll engine with HR added over time behaves differently under pressure to one built as an HR platform with payroll bolted on later, and our own analysis of the shift towards combined HR and payroll platforms goes into why that origin question matters more than most buyers realise, particularly if payroll professionals aren’t in the room when the decision gets made.
- Fix the go live date first and work backwards: Not the contract date, but the date of the first live pay run. Everything else is scheduled from it.
- Agree who owns each field: If HR owns the change and payroll owns the calculation, say so in writing, per field. Most integration disputes after go live are ownership disputes, not technical ones.
- Cleanse data in the old system, not during migration: Migrating incorrect data and cleansing it in the new system means proving the same records twice.
- Run parallel for at least two full cycles, and reconcile every line: Not a sample. Two full cycles, every employee, every element, with a written explanation for every difference. The differences you can’t explain are the ones that’ll appear in month three.
- Don’t switch the old system off at go live: Keep it readable until you’ve completed a full year end in the new one, because your record retention obligation doesn’t transfer with the data.
- Plan the first year end in the new system as a project of its own: It’s the first time everything you configured gets tested at once.
This works well when payroll and HR agree the ground rules up front, but be aware that most of what goes wrong after going live traces back to a decision skipped during this sequence, not a limitation in the software itself.
Whatever you buy, ask the same questions of any vendor about their compliance and security position: are they CIPP (Chartered Institute of Payroll Professionals) accredited, do they appear on HMRC’s recognised software list, what independent security certifications do they hold, and what happens to your data if you leave.
It’s worth asking us those questions too. Cintra People runs HR, payroll, and expenses on one genuine database rather than a bolted-together feed, backs that with ISO/IEC 27001:2022, Cyber Essentials Plus, and ISAE 3402 Type II certification, and invests roughly £500,000 a year in cybersecurity on top!
Payroll Legislation Guide
The facts, figures, thresholds and allowances for 2026/27 spanning tax, National Insurance, pensions, statutory payments and more.
Frequently asked questions
Q. When should you integrate HR and payroll?
A. When a dated operational event makes the hand-off between the two systems a risk you can't manage manually. The clearest triggers are a second legal entity or PAYE scheme, a new pension scheme, adding a pay frequency, and an HR system reaching end of support. Without one of those, integrate at the start of a tax year, once you're over roughly 200 employees and crossing at least two of the complexity thresholds: multiple entities, multiple pay frequencies, or forty or more employee changes a period.
Q. How do you integrate HR and payroll?
A. Document what your payroll actually does before looking at software, decide whether you want one database or two systems with a feed, fix the go live date and work backwards from it, agree field by field who owns each piece of data, cleanse the data in the old system rather than during migration, run at least two full parallel cycles reconciling every line, keep the old system readable until you've completed a year end in the new one, and treat that first year end as a project in its own right.
Q. What are the benefits of an integrated system?
A. One record for each employee, so a change made once is applied once. This includes the measurable gains like fewer corrections traced back to HR, no rekeying window between the HR cut-off and the payroll cut-off, consistent handling of transferred and protected terms, reconciliation across multiple PAYE schemes without a spreadsheet, and less operational knowledge held only in one person's head.
Q. Can you integrate HR and payroll part-way through the tax year?
A. Yes, and plenty of organisations do, but it costs roughly 30% to 50% more internal effort. A mid-year cut-over means migrating every employee's year to date taxable pay, tax, National Insurance by category, student loan, pension and statutory payment figures, and proving them. If payroll IDs change you must set the payroll ID changed indicator and report both the old and the new ID, because HMRC warns that reusing a previous payroll ID creates a duplicate record. A 6 April go live avoids all of it, because everyone starts at zero.
Q. How long does an HR and payroll integration project take?
A. For 200 to 500 employees on one PAYE scheme and one pay frequency, roughly 12 to 17 weeks from signature to a clean first live run, using 20 to 30 days of your own team's time. For 1,500 to 3,000 employees across several entities and multiple frequencies, roughly 22 to 32 weeks and 45 to 70 days. Add three to six weeks if there's no HR system today, and two to four weeks if HR data currently reaches payroll by rekeying.
