How to Correct Payroll Errors: The Employer Guide
Late Real Time Information submissions carry monthly penalties of between £100 and £400 depending on payroll size, and the employer rate of National Insurance now stands at 15% on earnings above £5,000, so a miscalculated payrun can cost more than it used to [1]. Most payroll errors are small, human, and completely fixable, but the method for correcting each type differs, and choosing the wrong one can duplicate an employee record or leave a bill unresolved [2].
This article is written for UK employers and payroll administrators who have spotted a mistake after running a payrun and need to know exactly what to do next. The stakes are practical: an uncorrected error can distort an employee's tax position, trigger an unexpected HMRC bill, or breach National Minimum Wage rules.
The guide covers the four situations HMRC itself separates: a mistake in a Full Payment Submission or Employer Payment Summary, an employee paid the wrong amount, a wrong tax code, and the wrong amount paid to HMRC. Each has its own fix, and each is set out below with the relevant deadlines and limits.
Key takeaways
- Most current-year errors are corrected simply by updating the year-to-date figures in the next regular Full Payment Submission (FPS) [2].
- A corrected FPS for an earlier period should reach HMRC by the 19th of the tax month after the original was sent [2].
- An employer cannot recover more National Insurance from an employee in a month than the contribution due that month, and can only recover it in the tax year of the error and the following year [3].
- Recovering an overpayment of wages must not drag an employee's pay below the National Minimum Wage in that period [4].
- RTI late-filing penalties run from £100 to £400 per month by employer size, with the first default in a tax year usually excused [1].
Why payroll errors happen and why they matter
Payroll sits at the junction of three moving parts: an employee's contract, HMRC's real-time reporting rules, and a monthly or weekly deadline that never slips. When any one of those changes without the payroll record catching up, an error appears. The correction is rarely difficult, but the reporting mechanism is unforgiving, because HMRC treats the FPS as the definitive record of what an employee earned and what was deducted [5].
Real Time Information, live since 2013, means every payrun is reported to HMRC on or before the day employees are paid [6]. There is no quiet period at year end to reconcile before the figures reach the tax authority. That immediacy is why a clear correction process matters: the wrong number is already with HMRC by the time most employers notice it.
The most common sources of error
Errors cluster around a small number of predictable triggers. Gaps in records, an unrecorded pay rise, inaccurate time tracking, and late notification of a leaver are the usual culprits behind a discrepancy [7]. Directors are a category of their own, because their National Insurance is assessed on an annual basis even when they are paid monthly, and an SME paying a director a low salary plus dividends often gets the NI timing wrong [8].
A second cluster comes from tax codes. When HMRC issues a new code and the payroll record is not updated before the next payrun, the employee is taxed on the old basis, and the difference has to be unwound [9]. Incorrect National Insurance category letters, especially after the rate moved to 15%, are another frequent source of miscalculation that only surfaces when the year-to-date figures are checked [3].
What HMRC penalties actually cost
The financial exposure from an uncorrected error is not abstract. HMRC charges a monthly penalty for late or missing FPS submissions, scaled by the number of employees on the scheme. The table below sets out the current bands.
| Employees on scheme | Monthly late-filing penalty |
|---|---|
| 1 to 9 | £100 |
| 10 to 49 | £200 |
| 50 to 249 | £300 |
| 250 or more | £400 |
Source: HMRC guidance on payroll penalties [1].
There is measured leniency built into the system. The first late-filing default in a tax year is normally not penalised, unless the scheme is an annual one, and HMRC usually allows an informal three-day grace period after the statutory filing date [1]. Late payment of the PAYE and National Insurance itself attracts a separate penalty of between 1% and 4% of the amount, rising with the number of defaults in the year [10]. The lesson is not to panic but to correct promptly, because prompt correction is what keeps most of these charges from ever applying.
Correcting a mistake in your FPS or EPS
The FPS and the Employer Payment Summary (EPS) are the two returns HMRC receives. The FPS reports what each employee was paid and what was deducted. The EPS reports adjustments at the scheme level, such as statutory pay reclaimed or an Apprenticeship Levy allowance. When the mistake lives in one of these returns, the fix is a corrected submission rather than a phone call [2].
Payroll software that holds the HMRC Recognised badge submits the FPS automatically at the end of each payrun and carries the corrected figures forward without manual reconfiguration, which removes a large part of the risk of a second error creeping into the correction itself. Employers running payroll by hand or on the free HMRC tool have to compose the corrected return themselves.
Fixing an error in the current tax year
For a mistake made in the current tax year, the standard fix is to update the year-to-date figures to the correct amount in the next regular FPS [2]. Because the FPS always carries cumulative year-to-date totals, a single corrected submission brings the record back into line without needing to unpick the individual payrun that went wrong.
If the correction cannot wait for the next scheduled payrun, an additional FPS can be sent before the next regular one is due, showing the adjustment for the affected employees [2]. Where the corrected FPS relates to an earlier period, it should reach HMRC by the 19th of the tax month following the month the original was sent, so that HMRC applies the correction to the right month [2]. The methods are compared below.
| Correction method | When to use it | Effect |
|---|---|---|
| Update year-to-date figures in next regular FPS | The correction can wait until the next scheduled payrun | Cumulative totals self-correct in one submission |
| Send an additional FPS | The correction is urgent and cannot wait | Adjusts the specific pay period for affected employees |
| Send an Earlier Year Update (EYU) | The error is in a tax year before 2020 to 2021 | Reports only the difference for that closed year |
Sources: HMRC payroll error guidance [2][7].
Correcting a previous tax year
Errors in a closed tax year follow a different route. For tax years from 2020 to 2021 onwards, the correction is made by sending an FPS carrying the correct year-to-date figures for the year in which the mistake occurred [2]. For older years, before 2020 to 2021, the Earlier Year Update remains the mechanism, and it reports only the difference between what was submitted and what should have been submitted [2].
Getting this distinction right matters because using an EYU for a recent year, or a full FPS for a very old one, will not be processed as intended. Accountants and bureaux handling this across dozens of client schemes typically rely on a multi-client payroll dashboard that selects the correct return type automatically based on the tax year being corrected, rather than leaving the judgment to memory under deadline pressure.
The payment after leaving trap
One specific trap catches employers correcting a payment to someone who has already left. If the FPS being corrected relates to a previous payment and the "payment after leaving" box is ticked, the same amounts must not be entered again in both the "pay in period" and "pay in year-to-date" fields [2]. Doing so creates a duplicate record for the employee, which then has to be corrected in turn.
This is a good example of why the mechanics of RTI reward care over speed. The correction is straightforward, but the reporting fields interact in ways that are not obvious, and a rushed entry can turn one error into two [5].
Correcting an employee's pay or deductions
When the underlying problem is the amount an employee actually received, rather than only the figure reported, two things have to happen: the money has to be put right with the employee, and the record has to be corrected with HMRC. The reporting fix is the FPS route above. The money fix depends on whether the employee was paid too much or too little [3].
When too much was paid
An overpayment of wages is one of the few situations where an employer may recover money from an employee's pay without falling foul of the unlawful-deductions rules, because the Employment Rights Act 1996 protection does not apply to the recovery of an overpayment of wages [4]. That does not make recovery unlimited. Where the employer recovers an accidental overpayment from a worker, the recovery must not reduce the worker's pay below the National Minimum Wage for the period in question [4].
In practice this means a large overpayment is often recovered over several pay periods by agreement, rather than clawed back in a single deduction that would breach the minimum wage. The year-to-date figures are then corrected through the next FPS so that the employee's tax and National Insurance position reflects what they were actually entitled to [2].
When too little was paid
Underpaying an employee is corrected by paying the shortfall and updating the record. The additional payment is put through payroll in the normal way, and the year-to-date figures are brought up to the correct total in the next FPS or an additional one [3]. Because tax and National Insurance are calculated on the corrected cumulative figures, the deductions self-adjust once the right totals are reported.
Employers producing the occasional corrected payslip outside a full scheme, such as a sole trader settling a one-off shortfall, can generate a compliant document through an instant payslip generator rather than reopening a full payroll run. The important discipline is that the corrected figure reaches HMRC through the FPS, not only the employee through the payslip [6].
National Insurance recovery rules
National Insurance carries its own recovery limits that catch employers out. If too little National Insurance was deducted, the employer must pay HMRC the underpayment straight away, and can then recover it from the employee through deductions from pay [3]. The recovery cannot exceed the amount of National Insurance the employee owes in that month, so a large shortfall is spread across several months up to that monthly ceiling [3].
There is also a time limit. Recovery of under-deducted National Insurance from an employee is only permitted in the tax year in which the mistake was made and the year after [3]. Beyond that window the employer bears the cost. Because National Insurance interacts with statutory pay, student loans and pension deductions, most employers rely on HMRC-recognised payroll software to recalculate the whole stack from the corrected gross figure rather than adjusting one line in isolation.
Correcting a wrong tax code
A wrong tax code is corrected by applying the right code and letting the cumulative PAYE calculation do the rest. When HMRC issues a revised code, the employer applies it from the next payday, and because most codes operate on a cumulative basis, the next payrun automatically refunds or collects the tax difference built up under the wrong code [9]. The corrected figures then flow to HMRC through the next FPS in the usual way [2].
HMRC operates a safety net that limits how much tax can be collected at once. No single PAYE deduction may exceed 50% of an employee's gross pay in a period, regardless of the tax code or the back-tax owed [11]. This regulatory limiter means that even a large tax correction cannot wipe out a pay packet, and any excess is carried into later periods. Employers should not attempt to manually override a code issued by HMRC, because only HMRC can change an official code, and an employer-invented adjustment risks a further error [9].
Correcting what was paid to HMRC
The final category is a mismatch between the PAYE bill and what was actually paid over to HMRC. This is distinct from an error in the FPS, and HMRC handles the two differently depending on where the mistake originated [12].
Underpaying HMRC
If the underpayment was caused by an error in the FPS or EPS, correcting that report is enough, and HMRC adds the underpayment to the next PAYE bill [12]. If instead the wrong amount was entered when making the payment, the balance should be paid as soon as possible, using the Accounts Office reference, to avoid interest or a penalty [12]. The distinction matters because a reporting error self-resolves through the next bill, whereas a payment error needs an active top-up [7].
Overpaying HMRC
Overpayments work in the mirror image. Where the overpayment stems from a report, the correction in the next FPS or EPS causes HMRC to take the overpayment off the next PAYE bill [12]. Where too much was simply paid over, the account can be balanced by paying less in the next PAYE bill, or a refund can be claimed [12]. For platforms and finance teams that need this reconciliation to happen programmatically across many schemes, an HMRC-recognised payroll API can surface the expected bill against the amount paid and flag the variance automatically.
How modern payroll software reduces and corrects errors
The pattern across all four correction routes is the same: the FPS is the source of truth, corrections are cumulative, and the reporting mechanics reward accuracy over speed. Software that holds the HMRC Recognised badge closes most of the gap by recalculating the entire payrun from the corrected input and resubmitting the FPS without manual field entry, which is where duplicate records and payment-after-leaving errors tend to originate [6].
An API-first payroll engine takes this a step further for platforms that embed payroll into their own products. Rather than an administrator retyping year-to-date figures, the corrected gross pay is passed once and the engine derives the tax, National Insurance, student loan and pension consequences, then files the corrected FPS. For accountants juggling corrections across many clients, a payroll bureau platform that applies these rules per scheme removes the need to remember which return type each tax year requires. Readers who want the fuller picture on the National Insurance side of corrections can follow the Moonworkers guide to understanding employer National Insurance.
Conclusion
Correcting a payroll error is less about the mistake itself and more about matching the fix to the right mechanism. A current-year miscalculation self-corrects through cumulative year-to-date figures on the next FPS. A closed-year error needs an FPS or an Earlier Year Update depending on how old it is. An overpayment to an employee is recoverable but bounded by the minimum wage, and an under-deduction of National Insurance is recoverable only within a monthly ceiling and a two-year window. A payment mismatch with HMRC resolves through the next bill or an active top-up.
The direction of travel is towards payroll systems that make most of these corrections invisible, because they recalculate the full stack from a single corrected input and file the amended return automatically. As Real Time Information reporting tightens and the employer National Insurance rate sits at its highest level in over a decade, the margin for an uncorrected error narrows, and the employers who cope best are those whose payroll engine treats correction as a routine recalculation rather than a manual unpicking.
Frequently asked questions
How do I correct a payroll mistake from a previous tax year?
For a tax year from 2020 to 2021 onwards, send a Full Payment Submission carrying the correct year-to-date figures for the year the mistake was made [2]. For a year before 2020 to 2021, use an Earlier Year Update, which reports only the difference between what was submitted and what should have been. Sending the wrong return type for the year will not be processed as intended, so the year of the error determines the method.
Can an employer take back an overpayment of wages from an employee?
Yes. The Employment Rights Act 1996 protection against unlawful deductions does not apply to the recovery of an overpayment of wages, so an employer may deduct the overpaid amount [4]. The recovery must not reduce the employee's pay below the National Minimum Wage for that period, which is why larger overpayments are often recovered by agreement over several pay periods rather than in one deduction.
What is the deadline for sending a corrected FPS?
A corrected FPS that relates to an earlier period should reach HMRC by the 19th of the tax month following the month in which the original FPS was sent, so that HMRC applies the correction to the correct month [2]. Where the correction can wait, updating the year-to-date figures in the next regular FPS is enough, because those figures are cumulative and self-correct.
What happens if too little National Insurance was deducted from an employee?
The employer must pay HMRC the underpayment immediately, then recover it from the employee through deductions from pay [3]. The recovery in any month cannot exceed the National Insurance the employee owes that month, so a large shortfall is spread across months, and recovery is only permitted in the tax year of the error and the following year. After that window, the employer bears the cost.
Image prompt for Imagen (also in frontmatter)
A wide landscape photograph of a tidy UK small business back office in soft morning light, a payroll administrator at a desk reviewing figures on a laptop next to a printed spreadsheet and a calculator, warm natural window light, muted greens and greys, shallow depth of field, realistic documentary style, no text, no logos, 16:9



