Questions to ask payroll software suppliers about HMRC RTI filing

What to take away

Why HMRC recognition is the first gate, not the last

Payroll software is not a neutral calculator. In the UK it is the pipe through which PAYE information reaches HM Revenue & Customs (HMRC) under Real Time Information (RTI). If the software is not recognised for RTI, it cannot file on your behalf, and you are left with HMRC's Basic PAYE Tools or a manual workaround.

HMRC's own guidance sets out the baseline duties: register as an employer, run payroll, report to HMRC and pay what you owe. That is the frame every employer works within, whatever their sector or size. You can read the baseline at Running payroll: Overview - GOV.UK.

The practical first check is whether the product appears on HMRC's list of recognised RTI payroll software. Recognition is not a marketing badge. It means the supplier has demonstrated to HMRC that the software can send the required RTI messages in the required format.

A product can be perfectly good at calculating pay and still fail this gate. Some payroll modules sit inside wider HR suites and are not individually recognised. Others are recognised for some RTI message types but not others. Check the exact product name, not the brand.

Recognition also changes over time. A supplier can lose recognition, change its recognition scope, or stop supporting a product line. That is why any shortlist should start from the checks to run before choosing, which include a fresh look at the current list rather than a screenshot from a sales deck.

If you are already running a product, re-check recognition at least once a year. The cost of discovering a problem in a live pay run is far higher than the cost of checking a list.

What RTI actually requires from payroll software each payday

RTI is not a year-end exercise. Every time you pay an employee, you send HMRC a Full Payment Submission (FPS). The FPS carries the pay, tax, National Insurance and student loan figures for each employee, plus the payment date.

The software must produce that FPS from the payroll you have just run, without re-keying. It must also handle starters, leavers, changes to hours, changes to pay and changes to personal details as part of the same submission. If any of those require a separate manual step outside the payroll run, that is a risk.

A compliant product also needs to handle the Employer Payment Summary (EPS). The EPS is how you tell HMRC about things that are not on the FPS, such as statutory maternity pay recoveries, Employment Allowance claims and nil payment periods. Both messages are part of the same RTI service, and both need to be supported.

RTI interacts with other payroll duties. Auto-enrolment under The Pensions Regulator (TPR) requires pension contributions to be assessed and deducted through the same payroll data. National Minimum Wage and National Living Wage rates must be applied correctly. The software has to hold the rules for all of these, not just tax tables.

Data protection matters here too. Payroll data is personal data, and the Information Commissioner's Office (ICO) expects employers to have a lawful basis for processing it. A supplier that cannot explain where payroll data is stored, who can see it and how it is deleted is a supplier with a problem.

Finally, RTI reporting sits alongside Making Tax Digital (MTD) for VAT and income tax. If your finance stack depends on MTD-compatible records, check how the payroll product exports or integrates, rather than assuming it will.

FPS and EPS: submission timing, late reporting and corrections

The FPS submission deadline is the core timing rule. You must send an FPS on or before the day you pay an employee. That is the standard position set out in Full Payment Submission rules and timing.

In practice, most employers run payroll a few days before payday so the FPS can be filed in good time. The software should make that easy: a clear submission step, a timestamped confirmation and a record of what was sent. If the product only lets you submit after the pay run is finalised, plan your pay calendar around it.

EPS reporting has its own rhythm. An EPS is usually sent by the 19th of the month following the tax month it relates to. It is the route for claiming statutory recoveries, Employment Allowance and for reporting a nil payment. The rules are set out in Employer Payment Summary reporting rules.

Corrections are where timing gets harder. If you discover an error after the FPS has been accepted, you do not simply edit the old submission. You send a corrected FPS or an additional FPS, depending on the nature of the error. The software must support that without corrupting the year-to-date figures.

Late reporting is a separate scenario. If you miss payday, you send an FPS after the event, and HMRC treats it as late. The process and consequences are described in sending an FPS after payday. Good software will flag that you are late and help you file the correct message rather than letting you guess.

One more timing trap: a new employer's first FPS. Until the first FPS is filed, HMRC may not have the scheme fully set up for RTI. The software should guide you through the first submission rather than assuming the scheme is live.

A practical way to test all of this is to run a parallel pay run. Use the same data in the new product and your current process, then compare the FPS and EPS outputs.

That is the kind of controlled testing a payroll quality checklist should include, and it exposes timing and correction gaps that a demo will not.

Error handling: what the software must catch before HMRC does

HMRC rejects RTI submissions that fail its validation rules. The software's job is to catch those failures before the message leaves your system, or at least to explain them clearly when HMRC rejects them.

Common failures include missing National Insurance numbers, invalid payment dates, duplicate employee records and figures that do not reconcile to the previous submission. A good product validates these at the point of entry. A weak product lets you submit and then returns an opaque error code.

The distinction matters because rejection is not the same as acceptance. An FPS that HMRC rejects has not been successfully filed. If you do not notice, you can drift into late filing territory without realising it. The software should make acceptance and rejection unmistakable.

Error handling also covers reconciliation. Year-to-date figures on each FPS must line up with the previous submission plus the current pay period. If the software cannot show you that reconciliation, you are relying on hope.

Look for an audit trail. You want to see who ran the payroll, when it was submitted, what was sent and what came back. That record is what you will need if HMRC queries a submission months later.

Finally, test the recovery path. If a submission fails, how do you fix it and resend? Is there a clear correction workflow, or does the product leave you to work it out? The answer tells you a lot about the supplier's understanding of RTI.

Penalty exposure when RTI filing goes wrong

Late filing penalty exposure is real, and it scales with the size of your workforce. HMRC charges penalties for late FPS submissions, with the amount depending on the number of employees. Smaller employers are treated more leniently than larger ones, but the exposure is never zero.

There is also a separate penalty regime for late payment of PAYE, which is distinct from late filing. A product that files on time but pays late still leaves you exposed. Check how the software handles payment scheduling and whether it warns you about upcoming liabilities.

Penalties are not the only cost. Late or incorrect RTI can affect employees' tax codes, Universal Credit claims and National Insurance records. Those problems surface later and are harder to fix than a fine.

HMRC does not always penalise every late filing. There is a measure of tolerance for occasional slips, and genuine errors can sometimes be corrected without a charge. But you should not build a process around that tolerance. Assume the penalty applies and design your pay calendar to avoid it.

Good software reduces exposure in three ways: it warns you before a deadline, it validates submissions before sending, and it gives you a clear record if HMRC later disputes what happened. If a product does none of those, its lower licence fee is a false economy.

When you compare suppliers, put penalty exposure at the centre of the assessment. That is the approach behind a current HMRC status review, which weighs product-level evidence and full costs rather than headline prices.

A verification checklist to run against any supplier demo

Use this list in every demo. Ask the supplier to show each item live, not to describe it.

The table below turns the same points into a scoring frame you can share with colleagues.

Run the demo against your own payroll data, not the supplier's sample file. Use a month with a starter, a leaver and a statutory payment if you can. The gaps show up fastest when the data is messy.

Questions to put to the vendor in writing

Written answers create a record. If a supplier will not commit to these in writing, treat that as a signal.

Common questions