The UK Payroll Year-End Lifecycle: What a Payroll Engine Should Handle Automatically

The UK tax year runs from 6 April to 5 April. That boundary creates a concentrated sequence of compliance tasks of closing the year cleanly, reporting everything correctly to HMRC, and opening the new year on the right basis. Done well, the transition is invisible: employees receive their P60s on time, tax codes update automatically, and the first payroll of the new year runs correctly from day one. Done poorly, errors from the closing days of the old year compound into the first payroll of the new one.

Year-end is one of the most problematic areas in UK payroll operations because the process requires a specific sequence of steps that must be followed in the right order at the right time, and the consequences of missing one aren't always immediately visible. The final FPS indicator is the most commonly missed step: employers who don't set it leave HMRC expecting further submissions for a closed year, which eventually surfaces as a mismatch that requires manual resolution. The problem is compounded when multiple payrolls run under the same legal entity (a monthly payroll and a weekly payroll on the same PAYE reference, for example), because the final submission indicator must be set on the last FPS across all frequencies, not just the last run of any single payroll. This step is easy to miss when different payrolls close on different days.

This post covers what a payroll engine should do across four critical areas: submitting the final FPS and EPS, generating P60s, handling the tax code transition into the new year, and reconciling director NIC.

Submit the final FPS and EPS correctly

The final FPS must be submitted on or before the employees' last payday of the tax year. The system must first identify whether a final EPS is actually required. It knows a final EPS is mandatory if the employer needs to report recoverable statutory payments, compensation amounts, apprenticeship levy adjustments, periods of inactivity, Employment Allowance, or CIS (Construction Industry Scheme) deductions. It is equally required if the employer paid no employees in the final pay period, since submitting nothing leaves HMRC expecting an FPS.

If no EPS is required, the engine explicitly marks the final FPS with the indicator. If an EPS is required based on those statutory triggers, the engine should generate it and place the final indicator on the EPS instead. Either way, the marked submission must reach HMRC by the deadline of 19 April. Miss the 19 April EPS deadline, and HMRC calculates the liability without accounting for any claimed reductions, producing an inflated bill that the employer then has to dispute.

Where an employer runs multiple payment frequencies under the same PAYE reference (both a monthly and a weekly payroll, for instance), the engine must identify the absolute last FPS across all frequencies and set the indicator there, rather than on each frequency's last submission independently. This is exactly where manual processing tends to fall down. When administrators have to manually track and coordinate which payroll finishes last, human error easily creeps in: the monthly payroll closes at the end of March, the weekly payroll closes a few days later, and someone accidentally ticks the final submission box on the monthly FPS rather than waiting for the weekly one. A smart engine handles this logic automatically across the whole scheme, or alternatively, bypasses the risk entirely by submitting a single scheme-level final EPS on or before 19 April covering the entire PAYE reference.

Before the final FPS goes out, the engine must reconcile year-to-date figures. The final payslip of the year must clearly show year-to-date gross pay, total tax deducted, and total National Insurance contributions. These numbers feed directly into the P60, so errors at this point propagate forward.

Generate and distribute P60s by 31 May

Every employee on the payroll on 5 April must receive a P60 by 31 May, regardless of when they started in the year or whether they have since handed in notice. Crucially, this includes employees whose final day of employment falls exactly on 5 April.  Employees whose employment ended before 5 April do not receive a P60, they received a P45 when they left.

P60 generation should run automatically from the year-to-date figures the engine has accumulated through the year. It should not require a separate data entry step. The P60 must include gross pay, tax deducted, National Insurance, and where applicable, student loan and postgraduate loan deductions.  It must also clearly break down any statutory payments issued during the year such as maternity, paternity or neonatal care pay.

Two employee types need specific handling. For employees who joined mid-year and provided a P45 resulting in a cumulative tax code, the P60 must accurately combine their previous employment earnings and tax with the pay processed through the current scheme, correctly populating the dedicated 'In previous employment(s)' and 'In this employment' boxes. For directors on the annual NIC method, the P60 must show the reconciled annual NIC figure, not the period-by-period amounts that appeared on payslips through the year.

Employers are required to provide P60s by 31 May. Failure to do so can lead to HMRC compliance action and penalties which accumulate over time until addressed.

Ingest and apply P9X, P9, and P6 tax code notifications

Running the first payroll of the new year on the wrong tax codes is one of the most common year-end errors and one of the most immediately visible, because employees notice a change in take-home pay before HMRC does. The engine must ensure every employee's code is correct before the first April payroll runs.

HMRC uses two mechanisms for this:

The P9X is HMRC's annual instruction that tells employers what to do with tax codes at the start of the new tax year. HMRC does not issue a new code for every employee: for most employees, the existing code carries forward unchanged. The P9X sets out the rules for how to do this correctly.

The one thing the engine must not carry forward is a week 1 or month 1 or X non-cumulative suffix. These markers are applied temporarily when HMRC cannot confirm an employee's full-year tax position — for example, for a new starter whose previous pay history is unknown. While the marker is in place, tax is calculated on each pay period in isolation rather than taking into account what has been deducted earlier in the year. This prevents the employee from receiving a large tax refund before their full position is known, but it is not meant to be permanent. At the start of the new tax year, the marker must be removed for any employee who has not received a new code from HMRC. Leaving it in place means the employee continues to be taxed on an isolated-period basis throughout the new year, which will result in either over- or under-deduction of tax depending on their circumstances.

In years where the personal allowance (the amount an employee can earn before income tax applies) increases, the P9X instructs employers to uplift the numeric portion of every employee's code to reflect the new allowance. For 2026/27, the personal allowance is frozen at £12,570, so the P9X carries no general uplift instruction this year. The standard code for employees entitled to the full personal allowance remains 1257L, and the engine simply carries existing codes forward unchanged for employees who have not received an individual notice.

P9 and P6 notices are individual code changes for specific employees. P9 notices arrive before the new tax year begins and must be applied from 6 April. P6 notices arrive in-year when an employee's circumstances change, such as a new benefit in kind reported, a change in allowances, or an underpayment being collected. HMRC issues both electronically via the RTI system, and the engine must apply P6 notices on the next available payroll run following their arrival.

The engine should ingest P9 and P6 notices automatically via the RTI connection and apply them to the correct employee record.

New starters without a P45 should be taxed according to the HMRC Starter Checklist rules. In many cases, this results in code 1257L on a Week 1/Month 1 basis until HMRC issues an updated code. Once the permanent code arrives, the engine must apply it immediately and switch to the cumulative basis as instructed.

Reconcile director NIC against annual thresholds

For most employees, NIC is calculated per pay period and the year-end total is simply the sum. Directors are different: they use an annual NIC basis, meaning NIC is assessed against annual thresholds across all payments in the year rather than against prorated period thresholds.  The payroll engine needs to support both permitted in-year calculation routes: the Cumulative (Annual) Method and the Alternative Method. While the Cumulative method tracks the true annual liability accurately in every pay period, the Alternative method assesses NICs like a standard employee throughout the year. For directors on this Alternative method, the NIC collected will likely not match the true annual liability until the mandatory final pay period reconciliation runs.

The engine must run this reconciliation automatically as part of year-end close. It must compare total NIC collected across all payment events against the NIC due on total annual earnings, calculate any shortfall, and collect it in the final payment of the year.

This matters most for directors with irregular pay patterns — nothing in early months, a large payment mid-year, regular amounts towards year-end. The period-by-period NIC figures on individual payslips will not reflect the true annual liability until the reconciliation runs. The P60 and final FPS must both carry the reconciled figures, not the sum of period amounts.

From April 2027, phase1 of the mandating of payrolled common benefits in kind (car/fuel/vans/medical) means these values must be processed through payroll for Income Tax purposes. However, a compliant engine must correctly exclude these benefit values from the Director's Class 1 NIC year-end reconciliation, as they remain strictly subject to Class 1A employer-only NICs.

What this means for a platform built on Intermezzo

The final FPS indicator is set automatically on the last pay period across all payment frequencies running under the same PAYE reference. The engine identifies the correct FPS regardless of when different frequency payrolls close. The year-end EPS is generated where statutory payment claims require it and where no employees were paid in the final period, submitted before the 19 April deadline.

P60s are generated automatically from year-to-date figures for all employees active on 5 April. Director P60s carry reconciled annual NIC figures. Electronic P60s meet HMRC's formatting requirements. Generation completes within the 31 May deadline without a separate data entry step.

P9 and P6 notices are ingested automatically via the RTI connection and applied to employee records immediately. Week 1, Month 1 and X non-cumulative suffixes are stripped at the year-end transition per the P9X instruction and do not carry forward unless a new HMRC notice explicitly reinstates them. Where a notice arrives after the first April payroll has run, the discrepancy is flagged and the correction calculated for the next run.

Director NIC reconciliation runs automatically as part of year-end close, comparing cumulative NIC collected against the annual liability and producing the reconciled figures for the P60 and final FPS. From April 2027, the engine will handle the mandating of payrolled benefits seamlessly, ensuring they are taxed correctly without improperly inflating the Class 1 NIC annual earnings total.

‍Rates, thresholds, and codes update in configuration with effective dating, applying from 6 April without a deployment. All required codes, including standard non-cumulative emergency bases are in place from the first payroll run of the new year. Subsequent increases and updates flow through automatically, so it’s not a burden on the employer.

Intermezzo is an AI-powered global payroll API used by payroll software providers to power calculation, compliance, and filing across multiple countries. To discuss UK year-end payroll handling or explore the API, book a demo with us below.

‍