How to Guarantee Flawless RTI Reporting for Your Growing UK Team

For the Finance Director who has recently brought payroll in-house, the first encounter with HMRC’s Real Time Information (RTI) system can be unsettling. You understand numbers and financial controls, but RTI operates on a different plane. It’s an automated, unforgiving machine. The threat isn’t a stern letter from an inspector; it’s a silent, automatic penalty notice appearing because a submission was three days and one minute late.

Many guides will offer platitudes: “be accurate,” “submit on time,” “check your data.” This advice is not incorrect, but it is critically insufficient. It fails to address the core nature of the challenge. Managing RTI compliance for a growing UK team isn’t an accounting task; it’s a mission in operational logistics. The system doesn’t care about your reasonable excuses unless they are presented in a specific format, using a specific code, within a specific timeframe.

The true key to flawless reporting lies in shifting your perspective. Instead of seeing RTI as a reporting burden to be managed, you must view it as a deterministic system to be mastered. The solution is not to try harder, but to implement a zero-deviation protocol—a rigid operational sequence where every step is executed with military precision. This guide is built on that principle. We will deconstruct the RTI machine, not just list the rules. We will provide the exact sequence of operations required to ensure every submission is flawless, every allowance is claimed, and every potential penalty is neutralised before it can be triggered.

This article provides a systematic breakdown of the critical RTI processes. The following summary outlines the key operational checkpoints we will cover to build your zero-deviation payroll protocol.

Why Late Full Payment Submissions Automatically Trigger £400 HMRC Penalties?

The fundamental principle to grasp about RTI is that its penalty system is automated. HMRC’s systems are designed to match the payment date recorded in your Full Payment Submission (FPS) against the date it was received. If the submission is late without a valid, coded reason, the penalty process initiates without human intervention. The system’s logic is binary: on time or late. There is no initial consideration for circumstance.

These penalties are tiered based on the number of employees in your PAYE scheme. For a growing business, this can quickly escalate. The fine is not a one-off; it is a monthly charge for each default. A single procedural lapse can therefore result in a cascade of recurring fines until the underlying process is corrected. According to HMRC’s RTI penalty structure, these can range from £100 to £400 per month for businesses with up to 249 employees, making it a significant operational risk.

To navigate this, your protocol must include three critical elements. First, you must aim to submit the FPS on or before the employee’s payday, but be aware that HMRC will usually informally allow a three-day grace period before a late submission is flagged. This is an operational buffer, not a target. Second, if a delay is unavoidable, you must use the ‘Late Reporting Reason’ field in your submission. Valid reasons are limited and must be selected from a specific list of codes (e.g., ‘G’ for ‘Reasonable Excuse’). Third, robust documentation of the “reasonable excuse”—such as evidence of a critical system failure or the serious illness of key staff—is non-negotiable for any subsequent appeal.

Understanding this mechanical, cause-and-effect process is the first step. The system is not malicious; it is simply executing its programmed instructions. Your task is to ensure the inputs you provide never trigger the penalty command.

How to Fix a Submitted FPS File If You Accidentally Overpaid an Employee?

In a disciplined payroll environment, prevention is paramount. However, errors can still occur, and the most common is an overpayment. The critical rule when this happens is: do not panic and do not try to fix it “off-system”. The RTI system requires a clear, auditable trail of corrections. Attempting to claw back the money in the next pay run without correcting the initial submission creates a discrepancy in HMRC’s records that can trigger compliance checks.

The correct protocol involves submitting a corrective FPS. If the error is discovered within the same tax month, you can submit an additional FPS with the corrected year-to-date figures for the affected employee. This new submission will supersede the incorrect data held by HMRC. It is essential to ensure the payment date on the correction aligns with your payroll cycle to maintain data integrity.

This process is demonstrated by a standard payroll correction workflow. An employee is accidentally overpaid in Month 1. The error is discovered before the Month 2 payroll is finalised. The correction is not a simple negative adjustment in Month 2. The proper procedure is to submit a revised FPS for Month 1 with the correct, lower payment figures. This realigns the historical record. Only then is the Month 2 payroll processed. If the overpayment has already been disbursed, the recovery of funds from the employee is a separate, internal HR matter, but the reporting to HMRC must be corrected at its source.

As this workflow shows, the key is to correct the record for the specific period in which the error occurred. If you are correcting a payment in a previous tax month, you must submit a new FPS with the right date and use the ‘Late Reporting Reason’ code H to indicate it is a correction to a prior submission. This tells the HMRC system to replace the old data with the new, ensuring the employee’s tax and National Insurance record for that period is accurate. The integrity of your year-to-date figures is the ultimate objective.

Employer Payment Summary vs FPS: Which Document Claims Your Employment Allowance?

A common point of confusion in RTI is the distinct roles of the Full Payment Submission (FPS) and the Employer Payment Summary (EPS). Misunderstanding their functions leads to missed opportunities for claiming allowances and can result in overpayment of PAYE tax to HMRC. The FPS is your primary reporting tool; the EPS is your tool for adjustments and claims.

The FPS reports what you have paid your employees. It is sent on or before each payday and contains the gross pay, tax, NI, and other deductions for every individual on your payroll. It is a statement of fact about payments made. Conversely, the EPS is used to report adjustments to the total amount you owe HMRC. This includes reclaiming statutory payments (like maternity or paternity pay) and, crucially, claiming the Employment Allowance.

You do not claim the Employment Allowance on an FPS. The claim is made once per tax year via an EPS. Once claimed, you then reduce your employer’s Class 1 National Insurance contributions each month until the allowance is exhausted or the tax year ends. For growing businesses, this is a critical cash flow consideration. The allowance must be actively claimed; it is not automatic. The table below clarifies the distinct functions and deadlines, which must be treated as absolute.

As a Finance Director, you must ensure your process includes a specific checkpoint at the start of each tax year to submit an EPS to claim the allowance. Failing to do so means you will overpay your Class 1 NI contributions, and while this can be rectified later, it negatively impacts your company’s short-term liquidity. With the Employment Allowance providing significant relief, failing to claim it via the correct EPS submission is a costly procedural error.

The New Starter Checklist Mistake That Places Staff on Emergency Tax Codes

The onboarding of a new employee is the first point of data entry into your payroll system and, therefore, one of the most significant points of potential failure. A single mistake here can incorrectly place a new hire on an emergency tax code, leading to them overpaying tax and creating a frustrating experience for the employee and an administrative burden for you to correct. The most common failure is not a complex technical error, but a simple breakdown in process: failing to obtain and correctly process the starter declaration *before* the first payroll calculation.

A new employee should provide a P45 from their previous employer. If they do not have one, they must complete a “starter checklist” (the replacement for the old P46 form). This checklist asks them to select one of three statements (A, B, or C) that determines their initial tax code. The critical mistake is processing the payroll without this information. In the absence of a valid P45 or a completed starter checklist, your payroll software’s only option is to apply the default emergency tax code (0T) on a ‘Week 1/Month 1’ basis. This is a non-cumulative code that often results in higher tax deductions.

To prevent this, your onboarding process must be integrated with your payroll data freeze. The collection and verification of starter information cannot be an afterthought; it must be a mandatory prerequisite for creating the employee’s record in the payroll system. This ensures the correct tax code is used from the very first payment, safeguarding both the employee’s net pay and the accuracy of your first FPS for that individual.

Executing this checklist flawlessly ensures data integrity from day one. It transforms onboarding from a simple administrative task into a critical risk-mitigation step in your payroll operation.

Exactly How Many Hours Before Payday Must Your RTI Submission Be Acknowledged?

The official HMRC guideline is unequivocal: the Full Payment Submission (FPS) must be sent “on or before” an employee’s payday. However, for a Finance Director managing cash flow and banking cut-off times, this definition requires a more precise, operational interpretation. The process is not complete when you click “submit.” It is complete when HMRC acknowledges receipt. This distinction is critical.

A submission can be rejected for a variety of reasons, such as formatting errors or invalid data. If you submit at 4:59 PM on payday and your Bacs payment file has already been processed, a rejection from HMRC creates a serious compliance issue. You have paid the employee, but HMRC has no valid record of that payment for that day. This is technically a late submission.

Therefore, the best practice is to build a buffer. While HMRC provides a 3-day administrative grace period for FPS submissions, relying on this is poor practice. It is designed to cater for unforeseen issues, not to be a part of the standard process. A more robust protocol is to ensure your FPS is submitted and, crucially, acknowledged by HMRC at least 72 hours before the payment date. This “72-Hour Buffer” serves two purposes. First, it provides ample time to diagnose and correct any submission rejections from HMRC without jeopardizing the ‘on or before’ rule. Second, it decouples the HMRC reporting process from the bank payment process, reducing the risk of a single point of failure on payday itself.

For instance, if payday is a Friday, the FPS should be submitted and acknowledged by the close of business on Tuesday. This allows all of Wednesday and Thursday to resolve any unexpected issues with HMRC’s gateway, ensuring complete compliance long before funds are disbursed. This operational discipline transforms the deadline from a source of stress into a manageable checkpoint.

In What Sequence Should You Process Monthly Pay Runs to Guarantee RTI Compliance?

RTI compliance is not the result of a single action but the outcome of a rigid, sequential process. For a Finance Director, establishing this “unbreakable sequence” is the single most effective way to eliminate errors and guarantee compliance. Ad-hoc changes and last-minute adjustments are the primary causes of failure. The process must be treated as a production line: each step must be completed and signed off before the next can begin.

The unbreakable 5-step payroll sequence is as follows:

1. Data Freeze: A hard cut-off date and time is communicated across the business (e.g., 5 PM on the 15th of the month). After this point, no further changes to pay (e.g., overtime, bonuses) or employee data (e.g., bank details) are accepted for the current pay run. This creates a stable dataset.
2. Gross-to-Net Processing: The payroll team calculates all pay and deductions for every employee based on the frozen data. This is a firewalled, technical processing stage.
3. Pre-Submission Audit & Management Approval: A draft payroll report is generated. This report is audited for variances against the previous month and reviewed by management (e.g., the Finance Director). This is the crucial approval gate. No submission can occur without this sign-off.
4. FPS Submission & HMRC Acknowledgment: Following approval, the FPS is generated and submitted to HMRC. The process is not complete until a successful acknowledgment receipt is returned from the government gateway. This step should occur at least 72 hours before payday.
5. Payment Disbursement & Payslip Distribution: Only after successful HMRC acknowledgment are the Bacs payment files uploaded to the bank and payslips distributed to employees. This ensures you never pay employees based on data that HMRC has not successfully received.

To enforce this sequence, roles and responsibilities must be explicitly defined. A RACI (Responsible, Accountable, Consulted, Informed) matrix is the ideal tool for this, ensuring there is no ambiguity about who performs and who approves each step. For a Finance Director, being ‘Accountable’ for approval is a critical control point.

Final FPS vs EPS: Which Document Actually Closes Your Payroll Year?

The end of the tax year (5th April) brings a final, critical set of RTI procedures. A common misconception is that the tax year simply “ends.” In the world of RTI, you must formally tell HMRC that your payroll for the year is complete. Failing to do so can leave your scheme’s record open and create reconciliation problems for the new tax year. The document that performs this crucial function is your final Full Payment Submission (FPS).

Each time you pay your employees, you send an FPS. The final FPS of the tax year—the one for the last pay period on or before 5th April—is special. Your payroll software should have a “Final Submission” indicator. This is typically a checkbox that must be ticked on this last report. Ticking this box inserts a flag in the data sent to HMRC, formally signalling that this is the last submission for the tax year and that all payments have been reported. This action officially closes the payroll year from a reporting perspective.

An Employer Payment Summary (EPS) can also be marked as the final submission if you have not paid any employees in the final tax month. However, for any active payroll, the final FPS is the definitive closing document. After this final submission, you must provide each employee with their P60 form (summary of pay and tax for the year) by 31st May. The data on the P60 must exactly match the year-to-date figures sent in that final FPS. Post-year-end reconciliation is a critical audit step to ensure this alignment.

A robust post-year-end checklist ensures no steps are missed:

• Cross-reference all generated P60s against the final FPS data to ensure 100% alignment.
• Submit any necessary P11D and P11D(b) forms for reporting benefits in kind by the 6th July deadline.
• Archive all payroll records for the closed tax year. The statutory retention period is 3 years after the end of the tax year they relate to.
• Upload new tax codes for all employees (from P9 forms) into your payroll software for the new tax year.
• Update your payroll software with the new tax and National Insurance thresholds for the upcoming year before processing the first payroll.

How to Streamline Your UK Payroll System to Eliminate Costly Administrative Errors?

Having established the non-negotiable sequences and procedures for RTI compliance, the final strategic objective for a Finance Director is to engineer a system where adherence to these rules is the path of least resistance. The goal is to move from manual discipline to systemic resilience. This is achieved through process integration and the strategic use of automation within your payroll software.

An effective payroll system is not a standalone silo. It must be integrated with your existing HR and accounting workflows. For instance, the new starter process should be owned by HR, but the data must flow seamlessly and in a validated format into the payroll system *before* the data freeze. The output of the payroll—the costs of employment—must then flow automatically into your accounting software’s general ledger. This integration reduces manual data entry, which is the primary source of administrative errors.

Your payroll software itself should be configured to enforce the process. This includes setting up user roles that mirror your RACI matrix, creating automated alerts for key deadlines like the data freeze, and building custom reports for the pre-submission audit. The system should work for you, making it difficult to deviate from the established sequence. Payroll data should be reviewed to reduce submission errors and discrepancies, ensuring smooth operations.

By embedding the five-step sequence into an integrated and properly configured system, you transform RTI compliance from a stressful monthly scramble into a predictable, auditable, and ultimately boring administrative function. This is the hallmark of a truly streamlined and resilient payroll operation. The focus shifts from fire-fighting errors to strategic analysis of labour costs, which is where a Finance Director adds the most value.

To put these principles into practice, the next logical step is to conduct a full audit of your current payroll process against the zero-deviation framework outlined here. Begin by mapping your existing workflow and identifying every point of manual intervention or potential ambiguity, and then systematically redesign it to build a truly resilient system.