Before the First New Pay Run: Assembling a Payroll Transfer File

A change of payroll provider is usually described as a service decision. In practice it is a records transfer with a statutory deadline attached. The risks are rarely dramatic: an FPS for the last pay period that is never filed, a pension contribution file rejected because the payroll reference changed, or an employee's year-to-date figures arriving in a spreadsheet that does not reconcile. Each of those is recoverable, but each consumes time that a small finance team does not have.

For a UK employer changing provider part-way through the 2026/27 tax year, the handover has to be built around pay periods rather than calendar convenience. The following file is a practical way to organise it.

Fix the cut-over at the edge of a pay run

The safest point of transfer is immediately after a completed pay run and its associated filing, not between calculation and payment. The outgoing provider should confirm in writing which pay period it will process last, the date it will submit the FPS for that period, and the date it will release the payroll records.

Avoid a cut-over that leaves the new provider calculating a period for which the old provider has already taken a part-payment or made a deduction. If the payroll is weekly or fortnightly, allow an additional pay cycle of contingency; the margin for error is thinner than with a monthly run.

Set the first live run with the new provider at least one full pay cycle after the data arrives. That gap is for a test calculation and a reconciliation, not for a rushed parallel run.

The core record set

Ask for the records in a structured export, not a PDF report. As a minimum, the file should contain, per employee:

• year-to-date taxable pay, tax deducted and National Insurance contributions for 2026/27;
• pensionable pay and employee and employer contributions, including any salary sacrifice arrangement;
• statutory payments made or due — statutory sick pay, maternity, paternity, shared parental and adoption pay;
• student loan and postgraduate loan deductions, and any attachment of earnings or court order;
• benefits in kind being payrolled, and deductions such as childcare vouchers or cycle-to-work repayments;
• bank details, tax code, NI number, and starter declaration or P45 information;
• leaver records for anyone who left during 2026/27, with the P45 data that was issued;
• the payroll ID mapping, because internal references rarely survive a software change.

Also collect the employer-level items: the PAYE reference and accounts office reference, the employment allowance position, any EPS claims already made in the year, the last FPS acceptance receipt, and the most recent P60 and P11D submissions for reference. These are the audit trail if HMRC queries a period.

Authorisations that must move

A payroll provider can hold data without holding authority. Before the first new run, confirm who is authorised to act for the PAYE scheme, who can submit an FPS, and who can approve a BACS payment file.

If the employer is keeping the same PAYE scheme and simply changing agent, the new provider needs agent authorisation through HMRC's online agent services, and the old agent should be removed to prevent conflicting submissions. If the change involves a new PAYE scheme — less common, and usually tied to a change of legal entity — the opening position must carry the year-to-date figures and the correct starter information for each employee.

For payments, check the BACS service user number, the bureau arrangement and the approval hierarchy. A new provider that cannot submit a payment file on the first payday creates a different kind of payroll failure.

Pensions are a separate handover

Auto-enrolment duties stay with the employer, not the provider. The pension scheme may be unchanged, but the payroll-to-pension data feed is not. Collect the scheme's payroll reference, the contribution schedule format, the assessment and postponement rules in use, and the records of opt-outs and re-enrolment dates.

If contributions are made through salary sacrifice, confirm that the contractual arrangement is documented and that the new payroll will apply the same sacrifice amount. A pension file rejected after the first run is not merely an administration issue; it can affect contribution deadlines and the scheme's reconciliation.

Sequence the first two pay periods

A workable sequence for a monthly payroll paid on the 25th, with a handover after the November run, looks like this. The outgoing provider processes November, files the FPS on or before 25 November, and releases the export by the end of that week. The employer checks the export against the last payslips and the pension contribution schedule. The new provider imports the data and produces a test calculation for December, which the employer checks against expected gross-to-net figures. The December run is processed live, the FPS is filed on or before the payday, and the pension file is submitted within the scheme's deadline.

If any step slips, the cut-over moves to the following month rather than compressing the checks.

Employee communication and data protection

Employees do not usually need to consent to a provider change, but they do need notice of who will process their data and when payslips will change format. Check the staff privacy notice and update it if the processor changes. Under UK GDPR, the employer remains the controller and should have a written processor contract with the new provider covering security, sub-processors, retention and deletion.

The outgoing provider should confirm when it will delete or return the payroll data, and the employer should retain its own statutory records for the required period.

The first-run reconciliation

Before the first new payslip is issued, reconcile three things: the opening year-to-date balances per employee, the gross-to-net calculation for the period, and the FPS acceptance from HMRC. After the run, check the pension file acceptance and the BACS payment total against the payroll summary.

A clean handover is not one where nothing goes wrong. It is one where the errors are found in a test run rather than in an employee's bank account.