Owner Kate Upcraft Consultancy Ltd
Share this content

RTI penalties: Crucial to accurately record payment dates

An employer relied on its payroll software to insert the correct payment dates in the full payment submission and ended up with £300 of RTI late filing penalties. Kate Upcraft explains what went wrong.

15th Oct 2019
Owner Kate Upcraft Consultancy Ltd
Share this content
alarm clock on office desk

For three tax months (October 2018 to December 2018) Essk Design Consultants Ltd (TC07368) failed to file its full payment submission (FPS) on or before the date of payment of salary to its employees.

As I explained in April, reg 67b of the PAYE regulations requires the FPS to be received by HMRC at the latest by midnight on the actual date of payment. As HMRC is unaware when payment to the employees is actually made, it bases the decision as to whether the FPS is late on the ‘payment date’ contained in field 43 of the FPS.

Some payroll software will default this date to the actual date of payment, having asked the employer to input this at the start of the particular pay period or even the start of the tax year. The software may also be designed to insert other dates that the employer/software user may be unaware of, such as:

  • Payroll processing date
  • End of the tax month
  • End of the pay period

What HMRC knows

The Essk Design case is a timely reminder of what data is visible to HMRC in the electronic world and the importance of understanding that the payment date is used for:

  • deciding if compliance with the “on or before” requirement has been met; and
  • passing earnings data to DWP for the calculation of universal credit.

In order for HMRC to raise a late filing penalty, the FPS must have been populated with a payment date of the 30th of the month for October, November and December.

In fact, the employer could not possibly have actually paid the employees on 30 December 2018 as it was a Sunday, so payment must have either been made on the 28th or the 31st. We can surmise that the employer’s payroll software held a contractual payment date of the 30th of the month that populated field 43  of the FPS automatically each month.

Employees’ UC claims

If any of the employees were universal credit recipients, recording the payment date as 30th of the month at least ensured that the December 2018 payment of earnings fell in the correct UC award period. This wouldn’t have been the case if the employer had moved the payment date in the file forward to the actual payment date of Friday 28th December.

A very similar situation occurred in the Johnson case, which DWP lost, when the four employers incorrectly moved the payment date forward in their FPS.

What the software told HMRC

Essk Design appeared to be totally unaware that having filed the FPS returns on 5 November 2018, 7 December 2018 and 6 January 2019, which are date stamped on arrival, that HMRC’s systems compare the filing date and the payment date held in the FPS. The HMRC system thus came to the appropriate conclusion that all three months FPS were late.

Essk Design had already filed the FPS late in June 2017 and April 2018 and HMRC had accepted those appeals, cancelling the penalties. HMRC also sent Essk Design its very clear education letter that informs the employer about the ‘on or before’ rule. Despite this Essk Design appealed the next three penalties and unsurprisingly failed to get those appeals accepted by the first tier tribunal. The judge agreed that HMRC had acted perfectly reasonably.

No reasonable excuse

Judge Popplewell also dryly observed, “the Appellant has no excuse, let alone a reasonable one”. Essk Design simply asserted that the FPS had been sent on the 30th of each month which it clearly hadn’t and that wasn’t even the actual date of payment in December 2018!

As far as ‘special circumstances’ are concerned, the Judge felt that neither HMRC (nor a tribunal where appropriate) need to be constrained by a narrow interpretation of ‘special’ relating only to an individual taxpayer’s situation. As long as HMRC has taken the right matters into account in reaching their decision on special circumstances, and the outcome of that decision is reasonable, the penalty decision is not deemed to be flawed.

In this case, HMRC had considered the employer’s assertion that they had filed on the date of payment and had decided that this did not amount to special circumstances, as clearly, they had evidence to the contrary.

Learning points

The Essk Design case illustrates that employers need to understand that the world of electronic filing gives them less wriggle room than they might have had previously because:

  • HMRC knows when the FPS was received.
  • HMRC’s systems compare the receipt date to the date in the field 43 held against every record in the file to determine whether the FPS is late.
  • The date in field 43 should be the contractual rather the actual payment date as this is vital to Universal Credit. In fact, this is the only thing that this employer got right and that was because the payroll software did it for them!

Replies (4)

Please login or register to join the discussion.

By Ian McTernan CTA
16th Oct 2019 12:34

Stupid system, just a revenue collection exercise by HMRC. Did the Treasury suffer any loss? Was the PAYE paid on time? But because some paperwork didn't have the exact date on it (which didn't affect anything) HMRC gain more fines.

And you wonder why many firms won't do payrolls any more and farm them out....

Thanks (1)
Replying to Ian McTernan CTA:
By peterdell
16th Oct 2019 14:54

The current system assumes that you can work 365 days per year and that as an external provider you can telepathically know when your client decides to make a bank transfer.

A fair system would have been filing by 5th of each month with a three day grace period and tax payments by 19th. This would have no effect on universal credit.

It is just the continuing direct attack on small accountancy practices and the wider small business community. Its obvious the Revenue/Government much prefers work to be dealt with by bigger organisations.

The current attack is MTD. Expect more to follow.

Thanks (0)
Pile of Stones
By Beach Accountancy
16th Oct 2019 14:53

Also, if the payroll payments had been made individually by Faster Payments, they technically could have gone through on the Sunday 30th. You can't automatically assume the payment went through on a weekday any more - you need to find out from the client when they actually made the payment!

Thanks (0)
By Nigel Hughes
16th Oct 2019 15:25

It would be helpful to know the software being used. I know that QB online tries to be helpful and insert dates and if you happen to prepare the payroll a couple of days later than the usual date it can appear as though you have made a late submission, even though payments have not actually been made yet.

Thanks (1)