Complete payroll year end and start the new tax year

UK payroll year-end checklist

Start before the final payroll cut-off. Build a year-end snapshot for each PAYE scheme using the expected employee population, employee YTD values, accepted FPS and EPS history, annual employee-payment control, annual HMRC-liability control, annual pension control and every correction case.

Annual means the whole closing year. A reference to March’s bank file does not prove earlier payments reconciled. The final pension schedule does not prove contributions across the year were acknowledged. Use consolidated annual controls or an evidenced set of periodic controls.

Reconcile population and YTD values

Confirm starters, leavers, directors, irregular workers, duplicate employments and payroll-ID changes. Compare each employment’s maintained taxable pay, tax, NI, loans and other reportable YTD values to accepted RTI. Investigate unexplained negative, missing or inconsistent figures through Lesson 11 rather than editing the final snapshot.

Reconcile accepted reporting separately from employee payments, HMRC liabilities and pensions. A known timing difference stays visible with an owner and review date. A blocked correction stops the relevant close. A specialist handoff can allow the main workflow to progress only when its evidence and owner are retained.

Review correction cases before deciding readiness

List every correction opened during the year and confirm its outcome across payroll records, employee payments, FPS or EPS, employer liabilities, pensions and employee communication. A correction marked complete in payroll but still awaiting an employee refund is not fully closed. A historic specialist case can remain under investigation only when its owner, evidence and effect on closing values are known.

Compare the closing snapshot with the evidence used for the last routine payroll. This catches employees who were added or removed after calculation, payroll IDs that changed unexpectedly and year-to-date values that moved after a correction. Preserve both snapshots rather than replacing the earlier one.

Final FPS or final EPS?

For employees paid in the final period, send the scheme’s final FPS on or before its last payday and use the supported “Final submission for year” indicator. If several payrolls share one PAYE scheme, the last report for that scheme carries the year-end information. Another PAYE scheme needs its own decision.

Send a final EPS instead when HMRC’s current conditions apply: the final FPS omitted the indicator, software lacks the field, nobody was paid in the final pay period, or an early final FPS was followed by complete no-pay tax months. A final EPS is due by 19 April, not the final FPS payday deadline. Use HMRC’s final-report guidance.

Scheme cessation is a separate decision

Closing the tax year does not mean the PAYE scheme ceases. A ceasing employer still chooses the applicable final FPS or EPS, then separately evidences the ceased indicator and cessation date. Never use “ceased scheme” as a substitute final-report route.

Preserve decision, preparation, submission, acceptance, rejection and correction states. Retain response warnings. If a report is rejected or corrected, the later attempt references rather than overwrites the original.

For every decision, retain the PAYE scheme, payrolls covered, last report, final payday, route rationale and response. This prevents the last payroll in a multi-company group from accidentally being treated as the last report for unrelated schemes. Where payroll frequencies differ, identify the final report using the actual scheme calendar rather than assuming the monthly payroll always closes last.

If the scheme continues next year, record that separately. If it ceases, verify the legal employer decision, cessation date and supported ceased-scheme fields. A normal annual close must never switch a live scheme to ceased simply because no April payroll has yet been prepared.

Week 53, 54 or 56

Weekly, fortnightly and four-weekly calendars can create an additional payment period. Maintained software determines the applicable calculation and the FPS tax-week field uses 53, 54 or 56. Investigate unexpected results, but do not recreate the statutory tax calculation manually.

Build the P60 population at 5 April

Give a P60 by 31 May for each supported payroll employment belonging to an employee working for the employer on 5 April. A genuine earlier leaver is not eligible merely because they received a payment after leaving. Uncertain status blocks population approval.

Use employee, employment, payroll ID and PAYE scheme together. One person can have multiple payroll employments; do not silently consolidate them into one artifact. Grouping for secure delivery is different from merging payroll records.

Reconcile every required P60 field to the applicable payroll record, YTD values and maintained P60 specification. Separately verify the wider payroll record remains consistent. Do not imply every internal statutory-payment or deduction category appears as its own P60 line.

Issue and correct without overwriting

Provide a printed or secure electronic P60 and retain delivery evidence. The original issued artifact remains immutable. If correction is needed, issue either a replacement P60 marked accordingly or a written correction. Both reference the original; a replacement also references its new artifact.

Expenses, benefits, P11D and P11D(b) tasks have their own rules and the 6 July signpost. They remain specialist work rather than being folded into P60 production.

Before issue, reconcile the employment’s required fields to the accepted year-end record and inspect identity details that affect the document. A P60 can reconcile arithmetically while still belonging to the wrong payroll employment or carrying an unresolved identifier. Keep validation, delivery and correction as separate states.

When an employee requests a correction, investigate the payroll record first. A replacement document cannot repair incorrect RTI by itself. Correct the underlying payroll and reporting through the maintained route, then issue the replacement P60 or written correction linked to the original artifact. Retain delivery evidence for both.

Validate parameter provenance

Record the opening tax year, software version, tax parameters, NI parameters, statutory-pay parameters, student-loan parameters and pension parameters. Every rules family needs an effective date, source and validation date. Do not accept one generic “rates updated” checkbox.

Apply tax codes in the correct order

For each continuing employee:

1. Read the closing code and basis.
2. Check for the latest valid individual HMRC instruction.
3. Apply the current P9X general instruction only when the code is eligible.
4. Remove W1 or M1 markers where the current instruction requires it.
5. Never invent or manually uplift an ineligible code.
6. Retain the code used for the first new-year payment.

HMRC sends individual P9T notices and publishes P9X general instructions. An individual valid instruction takes priority over a general assumption. Review HMRC’s employee-record guidance.

Reset and carry deliberately

Through maintained software, reset applicable tax-year taxable pay, PAYE, NI, statutory-payment, loan and annually maintained pension totals. Do not execute a blanket database reset.

Review and carry continuing payroll and employment IDs, employment history, pension membership, attachment orders, overpayment-recovery balances, authorised continuing deductions, correction cases and unresolved employee balances. A new tax year does not erase a debt, order or unresolved case.

Prepare an opening employee snapshot for those working on 6 April. Validate a first new-year draft against population, parameter set, tax-code instructions and continuing balances before approval. Preserve stable payroll IDs unless a supported employment event requires change.

Compare the first draft with a controlled expectation rather than expecting every value to match March. Tax thresholds, NI treatment, statutory settings, tax codes and pension thresholds can legitimately change. The reviewer should explain expected movements and investigate unexpected ones. Record the software calculation-rules version used so a later correction can reconstruct the opening decision.

Do not copy closing YTD values into new-year current fields as a migration shortcut. Equally, do not erase balances whose authority continues. The opening snapshot should explain which values reset under the maintained tax-year process and which records were carried because the employment, order, membership or recovery remains active.

Review Riverside’s closing board

The fictional board allows the final report to be accepted while P60 issue and HMRC settlement remain pending. It does not call the full year complete. Each later state needs evidence or a specialist handoff.

Derive reusable deadlines

For tax year 2026/27, derive rather than type:

• tax-year end: 5 April 2027;
• final EPS deadline: 19 April 2027;
• P60 deadline: 31 May 2027;
• expenses and benefits signpost: 6 July 2027.

The final FPS deadline derives from each PAYE scheme’s last payday. Future years use the same date rules with the relevant ending year.

Build an accessible archive

Retain closing snapshots, final-report decisions and responses, P60 population and artifacts, P60 corrections, annual employee/HMRC/pension controls, correction cases, new-year parameters, opening snapshot and first-draft validation. Confirm another authorised person can retrieve it without a departed employee’s login or obsolete software.

Test the archive by retrieving one employee’s year-to-date evidence, the scheme’s final response, a P60 delivery record and the new-year parameter set. Record who performed the retrieval and whether any file depended on an expired link or unsupported proprietary format. Correct access problems before supplier changes or staff departures make them harder to solve.

The extension-track handoff should reflect real learning gaps. Learners dealing with directors, no-pay schemes, complex corrections, care travel time or provider migrations should continue into those tracks. Completion of the core course means the learner has followed the educational sequence; it does not replace HMRC guidance, professional advice or the employer’s operational approval.

The core Academy is complete

This summary is a device-local learning record. It is not a professional credential and does not prove a real payroll year end is complete. Reset requires explicit confirmation and deletes only local Academy lesson, knowledge-check, checkpoint, capstone and checklist progress.