Common RTI Submission Errors and How to Fix Them Before HMRC Does

HMRC receives approximately 47 million RTI submissions every month. They have systems that check every one of them against a database of 35 million employee records. When something doesn't match, the system flags it. When the same employer's submissions keep flagging, a human gets involved.

RTI errors are not dramatic. They don't arrive with sirens. They arrive as a quiet rejection code from HMRC's gateway, or as an employee calling to ask why their tax is wrong, or as a discrepancy in the year-end reconciliation that takes three hours to trace back to a transposition error someone made in September.

RTI errors occur when the data in a Full Payment Submission doesn't match HMRC's records, contains invalid information, or arrives after the required deadline. Most are correctable. All of them cost time. The ones that aren't caught until year-end cost significantly more.

Error One: The National Insurance Number Mismatch

The most common. The most preventable.

An employee's NI number on the payroll doesn't match HMRC's records. The submission is rejected. The most frequent cause: the employee gave their NI number verbally, someone typed it, and one digit is wrong. A transposition error — 4 where there should be a 7 — that the payroll software has no way to catch because it's a valid-format NI number, just not the right one.

The fix: obtain the NI number in writing from a document that carries it — a P45 from the previous employer, a payslip from another job, a letter from HMRC, a National Insurance card. Do not accept verbal NI numbers. Do not accept it typed into a message. Get the document.

For employees who genuinely don't know their NI number — younger workers getting their first job, workers who have lost the documentation — the submission can run temporarily without the NI number by flagging it as unknown. But the number must be obtained and updated at the earliest opportunity, and the submission corrected.

Error Two: Payroll ID Reuse

Every employee must have a unique payroll ID that is never reassigned to a different employee.

This sounds obvious. It isn't always followed. An employee leaves. Their payroll record is archived. Six months later a new employee joins and someone — trying to keep the numbering sequence clean, or just not thinking about it — gives them the same payroll ID as the person who left.

HMRC's systems then attach every submission for the new employee to the previous employee's tax record. Year-to-date figures accumulate on the wrong person. Tax is allocated incorrectly. The previous employee starts receiving letters about income they didn't earn. The new employee's tax account is a mess.

HMRC has specifically flagged payroll ID reuse as a significant and recurring data quality problem. The fix is permanent: once a payroll ID is used for an employee, it is retired when that employee leaves. Never reassigned. No exceptions.

Error Three: Wrong Tax Code Applied

A new starter joins. Their P45 shows a non-standard code — something from a previous employer's benefits arrangement, or a code carrying forward unpaid tax. The payroll manager looks at it, thinks it seems unusual, and applies the standard 1257L code instead.

This is wrong. The code on the P45 must be applied as issued — it reflects HMRC's calculation of the employee's tax position. Overriding it with a standard code means under-deducting Income Tax. HMRC reconciles this at year end and the employee gets a bill for the underpayment.

Separately: HMRC issues coding notices throughout the year when an employee's tax code changes. These arrive through the payroll software. If the software isn't being checked regularly, or the coding notice is ignored, the payroll continues running on the old code while HMRC's records show a different one. The cumulative divergence grows every month.

Error Four: Late FPS

The FPS must be submitted on or before the date of payment. Not on the same day by close of business if the payment has already cleared at midnight. On or before.

In practice, most payroll software submits the FPS when the pay run is finalised — usually the day before payment. That timing is correct. The problem occurs when the pay run is finalised after the payment date — when someone processes payroll on the 28th for payments that went out on the 25th.

HMRC's late filing penalty for one to nine employees is £100 per month. For ten to forty-nine: £200. For fifty to two hundred and forty-nine: £300. These are per month of late filing, not per late submission. An employer who submits late every month doesn't get one penalty — they get twelve.

HMRC currently operates a risk-based approach to late filing penalties, which means not every late submission triggers an immediate penalty notice. This should not be interpreted as tolerance. The risk-based approach means HMRC is choosing when to issue notices, not choosing not to issue them.

Error Five: Missing or Incorrect Starter Information

A new employee joins. The starter declaration isn't completed. The payroll runs on an emergency code. So far, manageable.

But the FPS for that employee also requires specific starter information: their start date, their statement declaration (A, B, or C), and the reason they don't have a P45 if applicable. If this information is missing or inconsistent, HMRC's systems can't match the new employee to the correct tax record, and the employee's tax position becomes difficult to reconcile.

For employees who are new to the workforce entirely — first job, no NI number yet, no previous PAYE history — the submission requires specific flags that tell HMRC this is a new entrant. Missing those flags means HMRC's systems look for a prior record that doesn't exist and the matching fails.

Error Six: Duplicate Submissions

A pay run is submitted. The software gives a timeout error. The payroll manager submits again. HMRC receives two identical FPS submissions for the same pay period.

Depending on how the software handles the resubmission, HMRC's systems either reject the duplicate automatically or process it as a second payment, doubling the year-to-date figures for every employee in that run. The second scenario creates a reconciliation problem that takes time to unwind.

The correct process when an FPS appears to have failed: check HMRC's employer dashboard before resubmitting. The submission may have been received and processed despite the timeout error. Resubmitting a successful submission creates more problems than the timeout did.

bookd. reconciles every RTI submission against HMRC's records before the payment date. Errors are caught in the payroll review, not discovered three months later when an employee's P800 doesn't match. If your current payroll isn't running a pre-submission reconciliation check, the RTI errors are accumulating — they're just not visible yet.