Real Time Information payroll submissions

Real Time Information payroll reporting normally requires a Full Payment Submission on or before payday. Check the reporting date and any applicable exception, and distinguish the FPS from an Employer Payment Summary and the separate payment due to HMRC.

Use the appropriate payroll identifiers and review year-to-date totals before submission. Keep acknowledgements and investigate rejected reports promptly.

Identify the report that matches the task

A Full Payment Submission reports employee pay and deductions. An Employer Payment Summary serves different purposes, including relevant employer adjustments or reporting circumstances. Neither report is the bank payment to employees or the settlement of the employer's HMRC liability. Keep these tasks separate in the payroll checklist so completing one does not create the false impression that the whole payroll cycle is finished.

The normal FPS deadline is on or before payday, with specific rules and exceptions that need checking where relevant. Use the correct payment date under HMRC's guidance, particularly where a regular payday falls on a non-banking day or another unusual arrangement applies. Do not change the date merely to make a late submission appear timely. Preserve the facts and use the appropriate reporting process. ^[1]

Review the data before submission

Compare the report preview with the approved payroll, focusing on gross pay, deductions, employee identifiers and year-to-date figures. Check starters, leavers and employees whose circumstances changed during the period. A report can be technically accepted while containing inaccurate input, so software validation does not replace a business review. The approver should understand the material changes from the previous run rather than signing off solely on the total net payment.

Pay particular attention to identifier changes and records imported from another system. A new payroll number can be harmless internally but cause problems if the reporting process does not preserve continuity correctly. Follow the software and HMRC requirements for the situation. Keep a mapping of old and new identifiers during migration so a later discrepancy can be traced without creating a second employment record as an improvised fix.

Record successful acceptance

After sending the report, save the acknowledgement and confirm that the submission was accepted for the intended employer and period. A queued file, generated XML document or screenshot of the payroll calculation is not the same as acceptance evidence. If the report is rejected, capture the error message and assign someone to resolve it promptly. The status should remain visibly outstanding until the correct report has been accepted.

Avoid repeatedly resending a report simply because the response is unclear. Check the submission history and provider guidance before taking another action. Duplicate reporting can create additional reconciliation work and confusion over employee totals. Keep a dated note of attempts, responses and the eventual resolution, especially when a connection problem occurs close to the deadline and several people are involved in troubleshooting.

Reconcile reporting with the employer account

Compare the accepted payroll figures with the amount expected to become payable to HMRC, allowing for any separate adjustments reported through the appropriate route. Record the employer's payment reference and settlement date independently. A correctly filed FPS does not prove that the tax payment has been made or allocated properly. Finance and payroll should agree who checks the employer account and follows up unexplained differences.

If the account does not match expectations, identify the precise period and component in dispute. Review accepted reports, corrections, EPS information and bank evidence before concluding that HMRC has made an error. A clear reconciliation gives the adviser or HMRC contact a defined question to investigate. Repeatedly altering employee figures to force the account total to match can obscure the original cause of the discrepancy.

Manage exceptions and corrections deliberately

Keep a separate log for off-cycle payments, late information and corrections. Establish which tax year and report type are affected before choosing the correction method. A change to an employee's details may require a different approach from an error in pay or a wrongly allocated employer payment. Preserve the original report and document the reason for the amendment so the year-to-date position remains explainable.

Use Correcting a payroll reporting error for the correction workflow and Payroll administration to discuss RTI reporting controls. Provide the payroll frequency, software and the type of problem encountered, without sending the whole employee dataset in an initial enquiry. A practical review should identify the approval point, submission owner, acceptance check and account reconciliation, giving each task a clear place in the payroll timetable.

Plan cover for the person who normally submits reports and test that the authorised replacement can access the necessary system. Keep permissions proportionate, but do not wait until the usual payroll operator is absent on payday to discover that nobody else can complete an accepted submission.

Illustrative scenario

A business pays staff early because the usual payday falls on a bank holiday. Payroll checks HMRC’s rules for the reported payment date and preserves the approved calculation and submission receipt.

Preparation checklist

• Confirm the reporting date
• Review employee identifiers
• Check FPS and EPS needs
• Retain acknowledgements