Payroll software strategy and planning 2027: a framework

This payroll software strategy and planning 2027 framework treats selection as a buyer's task, not a vendor's. It helps UK employers, finance teams and their advisers review, select and plan the roll-out of payroll software for the tax year beginning 6 April 2027. It covers the official rule boundary, HMRC recognition, pension data, payroll forms, data protection, security, migration, support and a 90-day evaluation plan. It does not rank products or provide a price comparison or complete tax-year rate table. Instead, it gives a framework and names common options to test, so you can build a plan you can evidence before you commit.

Start with the 2027 tax-year boundary

The 2027 to 2028 tax year runs from 6 April 2027 to 5 April 2028. Before you compare payroll software, write down the official figures and rules that your payroll must apply in that year. The personal allowance is set at £12,570 up to and including 2027 to 2028, and the basic rate limit is set at £37,700 up to and including 2027 to 2028, according to GOV.UK's policy paper on maintaining the Personal Allowance and basic rate limit. Use this as a fixed reference for planning, not as a prediction of every rate or threshold.

Payroll software must calculate PAYE, National Insurance, statutory payments, student loan deductions and other deductions according to HMRC rules. HMRC operates Real Time Information (RTI), which requires employers to report payroll data to HMRC on or before each payment. The main RTI submission is the Full Payment Submission (FPS). Employers also use an Employer Payment Summary (EPS) to claim reductions or report nil payments. Other standard payroll forms include P45, P60, P11D and P32.

Mandatory real-time reporting of Income Tax and Class 1A National Insurance contributions for certain benefits in kind and taxable expenses is phased in from 6 April 2027. This change sits alongside the existing P11D and P11D(b) year-end reporting route for benefits that fall outside the phased scope.

HMRC does not approve or recommend payroll software. It recognises software that can report PAYE online. The official term is 'recognised'. Use that word precisely. Do not treat recognition as an endorsement of pensions, data protection, support or service quality. Check the current HMRC recognised software list and the latest specifications for the tax year you are planning.

Review the market by category, not by marketing claim

The UK payroll software market includes desktop and cloud products, payroll-only systems and combined HR and payroll systems, and employer editions and bureau editions. Common options include Sage 50 Payroll, Xero Payroll, BrightPay and QuickBooks Payroll. This is not a ranking. Each product suits different employers, and features change. Your job is to test the product against your payroll profile, not to choose from a slogan.

A desktop payroll product may suit an employer that wants local data storage and a familiar annual upgrade cycle. A cloud payroll product may suit an employer that needs remote access, automatic updates and integration with accounting records. A bureau edition may suit an accountancy practice or payroll bureau that processes multiple clients. A combined HR and payroll product may suit an employer that wants one employee record for absence, benefits, onboarding and pay.

Use a supplier comparison guide to structure the review. Compare the same criteria for every supplier: HMRC recognition, tax-year maintenance, pension outputs, data import, approval workflow, reporting, access control, support, migration and exit. Ask for a written response to each criterion, and test the response in a sandbox or trial.

Write the payroll profile before you test

A payroll software review fails when it starts with a feature list. Start with a payroll profile. Record the number of employees, pay frequencies, pay elements, pension schemes, worker types, starters and leavers, statutory payments, expenses, benefits and off-cycle runs. Include multiple PAYE schemes, multiple pension providers and any bureau or multi-client work. Note who approves pay and who authorises payment.

Turn the profile into a test pack. The test pack should include ordinary payroll, a starter, a leaver, a change of tax code, a change of bank details, a statutory payment, a pension opt-in, a pension opt-out, a postponement and a re-enrolment. Add boundary cases, invalid inputs, corrections and an off-cycle payment. If your organisation uses a bureau model, add a multi-client scenario with different pay frequencies and pension schemes.

The test pack is the core of a fair comparison. It lets you see how each product handles the work you actually do. It also gives you evidence for the decision. Do not accept a demonstration that only shows a clean monthly payroll for a single employee.

Check HMRC recognition and current specifications

HMRC recognition is necessary for a product that reports PAYE online, but it is not sufficient for your payroll. Check the current HMRC recognised software list, officially titled 'Find payroll software that is recognised by HMRC', and the specifications for the tax year. Confirm that the product supports the forms and data structures you need, including FPS, EPS, P45, P60, P11D and P32 where applicable. Confirm how the supplier handles tax-year changes, emergency tax codes, National Insurance categories and student loan plan types.

Ask the supplier for a release note and a test record for the current tax year. Check the date of the last payroll update and the process for urgent changes. A product that is recognised today can still fail your test pack tomorrow. The recognition status is a starting point, not a verdict.

For each tax-year update, record:

Put pensions and payroll data in the same plan

Payroll software and workplace pensions are connected. The Pensions Act 2008 and the Pensions Regulator set out auto-enrolment duties for employers. These duties include assessing workers, enrolling eligible jobholders, handling opt-ins and opt-outs, calculating contributions and keeping records. Your payroll software may support some of these tasks, but the employer remains responsible for compliance.

Map every pension task to a role: employer, payroll operator, software, pension provider or adviser. A flow helps you see where data is created, checked and reconciled. If the software exports a pension file, specify the provider, format, version and rejection route. A generated file is not the same as a file accepted and reconciled by the pension provider.

Test representative pension events in your test pack. Check how the product handles joiners, opt-ins, opt-outs, postponement, re-enrolment and contribution changes. Check how it treats different tax-relief methods. Record what the software cannot decide and where the employer must seek guidance. Track rejected files and reconciliation failures, not just successful exports.

Test data protection, access and security

Payroll data is personal data. UK GDPR and the Data Protection Act 2018 apply. The employer or payroll provider must have a lawful basis for processing, keep data accurate, retain it only as long as necessary and support individual rights. A payroll software review should cover data storage location, encryption, backup, retention, deletion and subject access requests.

Access control matters. Use role-based permissions and least privilege. A payroll administrator should not automatically see every client or every employee record. A bureau user should have access only to the clients they serve. Record who can approve a payroll, who can export data, who can change bank details and who can submit to HMRC. Test how access is removed when a person leaves or changes role.

Do not share Government Gateway sign-in details. HMRC's access rules for agents and software require each user or organisation to authenticate properly. Use the official access route for the product and the service. Record which authority is granted, what the software can do with it and how it is withdrawn.

Plan migration, parallel run and deadline recovery

Migration is where many payroll software projects fail. Map the data you need to move: employee records, year-to-date figures, tax codes, National Insurance categories, pension records, student loan plans, attached earnings and historical payments. Reconcile the opening position against the final payroll from the old system. Check P45 data for starters and leavers. Check pension records for contribution history and opt-in status.

Run a parallel payroll for at least one full pay cycle. Compare gross pay, deductions, employer National Insurance, pension contributions, net pay, payslips, reports and HMRC submission totals. Investigate every difference. A difference in one employee's tax code can reveal a wider data problem.

Build recovery tests around the payroll deadline. Test what happens when an input is missing, a calculation changes, a submission is rejected, a submission is interrupted, a critical service is unavailable, a backup is restored, a pension file is rejected and a deadline incident is escalated. The support route must reach someone who can resolve the issue before payday.

Build a 90-day review plan

A 90-day plan gives the review a shape. In the first 30 days, define the payroll profile, gather official evidence, check HMRC recognition and shortlist suppliers. In days 31 to 50, run demonstrations with your test pack and check pension outputs. In days 51 to 70, run a sandbox or parallel payroll, test support and review security. In the final 20 days, reconcile results, review the contract, confirm total cost and agree an implementation plan.

Use the 90-day payroll software plan as a base, but adapt it to your payroll calendar. Set stop conditions before you start. Examples include unexplained calculation differences, a required worker case the product cannot handle, a pension file that cannot be reconciled, an access model that does not meet your policy, or support that cannot answer a deadline question. If a stop condition is met, pause the review and fix the issue.

Gather supplier quotations and commercial evidence

A payroll software decision has more cost lines than the licence fee. Ask for a full breakdown covering implementation, data migration, configuration, training, support, pension module, HR module, extra payroll runs, off-cycle payments, additional employer accounts, integrations and exit. Ask how the price changes when headcount, clients or pay frequency changes. Ask what happens if you need an urgent correction or a parallel run.

Compare product evidence and commercial evidence. Product evidence includes test-pack results, reconciliations, pension files accepted, submission acknowledgements, correction records and recovery times. Commercial evidence includes implementation effort, support response, contract terms, price changes, customer references and exit arrangements. Keep the two sets of evidence separate so a good demonstration does not hide a weak contract.

Keep these closing commercial checks separate from the go-live decision gates below:

Review the supplier as well as the software. Check the legal entity, the product roadmap, the support model, the security posture and the exit route. Use a payroll software review methodology to score the evidence consistently. Use payroll software pricing models to understand what you are being charged for. A supplier that cannot explain its pricing model may also struggle to explain its support model.

Review HR and payroll together where they connect

Many employers need both HR and payroll software. They are not the same product. HR software manages employee records, absence, holidays, performance, recruitment, benefits and onboarding. Payroll software calculates pay, deductions, pensions and HMRC submissions. A combined system can join the two, but the integration is only as good as the data flow.

Use HR versus payroll software to decide what each system must do. If an HR system feeds payroll, test how a new starter, a leaver, a pay change, an absence record and a benefit change reach payroll. Test who approves the change and what happens when the change is corrected. If the integration fails, payroll must still be able to run and the correction must be traceable.

Set decision gates and stop conditions

A good payroll software plan has gates. Each gate needs an owner and evidence. A gate owner must be able to stop the project. Useful gates include:

Do not treat an open risk as accepted by leaving it out of the meeting. Record each risk with severity, owner, workaround and target date. If a stop condition is met, the gate stays closed until the issue is resolved.

Common questions

Before you commit

Payroll software strategy and planning for 2027 should end with a decision you can defend. The right product is the one that passes your tests, meets your pension and data duties, fits your support model and gives you a clean exit. Start with the official boundary, build the evidence and keep the plan narrow enough to test.