How UK employers can check payroll software meets HMRC RTI filing rules

What to take away

• Payroll software must appear on HMRC's recognised list before it can file RTI returns at all.
• Each payday needs an FPS on or before the payment date, with an EPS for any month where statutory recoveries or nil payments apply.
• Late FPS filings can trigger penalties, so error handling and submission timing are the features to test hardest.
• A demo should be checked against a written list covering recognition, timing, corrections, penalties and data protection.
• Vendor answers about HMRC recognition, FPS deadlines and EPS reporting should be confirmed in writing before you sign.

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 exact product name appears on HMRC's recognised payroll software list today.
• The product can produce and submit an FPS on or before payday.
• The product can produce and submit an EPS, including nil payment periods.
• Starters, leavers and changes to pay are handled in the same submission flow.
• The software validates common RTI errors before submission, not after rejection.
• A rejected submission has a clear correction and resend path.
• The audit trail shows who submitted what, and when.
• The supplier can explain where payroll data is stored and how it is protected.
• The product handles auto-enrolment assessment and pension deductions.
• The product applies current National Minimum Wage and National Living Wage rates.
• The supplier provides a written statement of RTI support and update policy.
• The contract sets out what happens if HMRC recognition changes.

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

Check area	What good looks like	Evidence to request
HMRC recognition	Exact product listed for RTI	Link to current list entry
FPS timing	Submit on or before payday	Live demo of submission step
EPS reporting	Recoveries, Employment Allowance, nil periods	Sample EPS output
Error handling	Pre-submission validation and clear rejection codes	Test with deliberate error
Corrections	Corrected or additional FPS without breaking YTD	Worked correction example
Penalty awareness	Deadline warnings and submission records	Screenshot of alert and log
Data protection	Clear storage, access and deletion rules	Data processing agreement
Support	Named route for RTI queries and updates	Support terms in writing

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.

Is this exact product on HMRC's recognised payroll software list today? Ask for the product name as it appears on the list, not the brand or suite name.

How does the product handle an FPS that must be sent after payday? The answer should describe the late reporting route and any warnings the software gives.

What happens if HMRC rejects a submission? You want a described workflow: how the error is surfaced, how it is corrected and how the resend is logged.

How are EPS claims for statutory recoveries and Employment Allowance handled? Confirm the product supports them and show where the figures come from.

What is the update policy when HMRC changes RTI rules or tax tables? Ask how quickly updates ship and whether they are included in the licence fee.

What happens to our data and our RTI access if we leave? You need a clear exit route, including a final FPS and a data export.

Who is liable if the software causes a late or incorrect filing? Read the contract carefully. Most suppliers limit liability, so your own checks remain essential.

Common questions

Do I need HMRC-recognised payroll software to file RTI? Yes, if you want to file RTI electronically. HMRC's Basic PAYE Tools are an option for very small employers, but most businesses use recognised commercial software.

What is the FPS submission deadline? You must send an FPS on or before the day you pay an employee. If you pay early, the FPS goes early too.

When do I need to send an EPS? Usually by the 19th of the month after the tax month it relates to. You also send one for a nil payment period or to claim statutory recoveries.

Can I correct a mistake after submitting an FPS? Yes. You send a corrected or additional FPS rather than editing the original. The software should support this without breaking year-to-date figures.

What penalties apply for late RTI filing? HMRC charges late filing penalties that scale with employee numbers. Late payment of PAYE is a separate penalty regime.

How often should I re-check HMRC recognition? At least once a year, and before any contract renewal. Recognition can change, and a product can be withdrawn from the list.