Submitted, or so we thought
The payroll is run, the FPS is sent from the software, and the administrator moves on. Usually it goes through. Occasionally it is rejected because of a mismatch, the wrong PAYE reference, an authentication problem or a gateway hiccup, and the error message sits in the payroll software's submission log for that client.
Nobody opens that log unless they have a reason. Weeks later the client receives a notice from HMRC about a missing submission, or an employee's tax record looks wrong, and the bureau has to explain.
Why failures stay hidden
Each client's RTI history lives inside that client's payroll file. There is no bureau-level list of 'what should have been submitted this week and what was accepted'. EPS submissions, which are needed in some periods and not others, are even easier to miss because they are not tied to every run.
Busy administrators also assume success. The send button was pressed, the screen moved on, and the next client is waiting.
Bureaus running more than one payroll package have it worse, because each package logs submissions differently. An administrator who covers a colleague's clients on an unfamiliar package may not even know where to look for the response.
What a missed rejection costs
A rejected or missing submission can lead to penalties or notices for the client, and to incorrect records at HMRC for employees. Fixing it later is slower than fixing it the same day. Clients who get HMRC letters about something the bureau was paid to do lose confidence quickly, and those letters tend to arrive at the worst time.
| Submission | When it is expected | Common way it goes wrong |
|---|---|---|
| FPS | On or before each pay day | Rejected and not noticed |
| EPS | Periods with reclaims, no pay, or other adjustments | Not sent when it should be |
| Late FPS | After the pay day | Late reason code missing |
| Year-end final submission | Last period of the tax year | Final indicator missed |
How we build RTI monitoring across clients
- From each client's pay run calendar, we generate the expected submissions: an FPS for every run, and an EPS where your rules or the client's situation call for one.
- We read submission status from your payroll software, through its API, reports or submission logs, depending on what it offers.
- Each expected submission is matched to an actual one: accepted, rejected, pending or missing.
- Rejections and missing submissions create an alert to the client's administrator the same day, with the error text from the software.
- A bureau-wide screen shows every submission for the week and its status, so a manager can see at a glance that everything went through.
- At tax year end, the view includes the final submission checks for every client, so none is left open.
When an EPS is needed depends on the client's circumstances and HMRC's rules, which your team applies. The view tracks what your team has decided should be sent.
We also keep the history. Over a year, the view shows which clients have had repeated rejections and why, which often points to a setup problem in that client's payroll file, such as a reference entered wrongly years ago, that is worth fixing once rather than working around every period.
Knowing everything went through
Rejections are fixed the same day, while the run is still fresh. Missing EPS submissions are caught before HMRC notices. Managers stop relying on the assumption that the send button worked. And clients stop being the ones who tell you something went wrong.
Signs your RTI checking has gaps
- You have learned of a rejected FPS from a client's HMRC letter.
- Nobody reviews submission logs across all clients.
- EPS submissions are sent from memory.
- Year-end final submissions need a manual check of every client.
- Administrators assume a submission worked if no error popped up.