Payroll Director Armstrong Watson
Share this content

RTI: Employer fights back against software errors

12th Feb 2019
Payroll Director Armstrong Watson
Share this content
Red error message on order binary code background

Confusion over the payment dates reported by payroll software resulted in HMRC issuing late filing penalties. Karen Thomson investigates what went wrong.

Facts of the case

Cunis Ltd (TC06954) received four RTI late filing penalties: two in 2016, which HMRC cancelled on the grounds of reasonable excuse due to a software problem. A further two penalties were issued on 9 February 2018, which arose due to the same software problem, but those penalties were not cancelled.

The software problem stated was that the processing date was uploaded in the Full Payment Submission (FPS) rather than the actual payment date, which would have followed the processing date. If paying by Bacs, for example, it would be impossible to pay on the same day as processing the payroll, as three working days are required for Bacs payments.

Grounds for appeal

Cunis appealed against the February 2018 penalties and included these points:

  • As HMRC cancelled the previous penalties, it should have cancelled the latest penalties.
  • The fault lay within the software, which was HMRC approved, so HMRC should have known it wasn’t fit for purpose and should not have accredited it.
  • No financial loss to the Treasury was incurred and Cunis didn’t gain any financial advantage.
  • Their payroll processes hadn’t changed; they did not update their payroll to try and avoid paying late.

HMRC’s arguments

HMRC said the RTI legislation states the FPS submission should be sent on or before payment day ie the date the employees are actually paid. HMRC’s guidance on this point is not as clear as it could be, as Kate Upcraft has pointed out.

Cunis did not comply with the RTI regulations and submitted their FPS after the payment date on four separate occasions in respect of the latest penalties. Cunis submitted the data and HMRC cannot amend or update this information.

HMRC took a lenient approach in 2016 when it accepted reasonable excuse due to a software problem, which Cunis should have fixed. Despite the leniency previously shown, RTI submissions were late again in 2018 and therefore Cunis had not exercised reasonable foresight or due diligence. HMRC pointed out that the previous reasonable excuse ended when Cunis received HMRC’s letter of 6 January 2016 and do not accept responsibility for any software error.

HMRC only tests software to ensure RTI submissions can be made. It is the responsibility of the employer to choose compliant software (editor’s note: this testing process by HMRC also applies to MTD software).


This case was a paper-based hearing, so the arguments were not given in person and Judge Fairpo was not able to question the parties.

The judge stated it was clear from the documents provided that the payment dates were prior to the submission of the RTI report. Also, that Cunis had told HMRC there was a software problem as their employees were paid weekly in arrears. The process date being used for the appeal appeared to be the date at the end of the relevant work week, with Cunis arguing the information was submitted during the following week, and that payment was made at the end of the following week.

The judge noted that no evidence was provided by Cunis to support when the payments to employees were actually made. There was also no evidence to show whether Cunis had been in communication with their software provider to resolve the problem between January 2016 and February 2018, when the disputed penalties were issued.

The judge concluded that any other taxpayer who was intending to comply with their obligations would have either changed their software or would have been communicating with their software provider. Based on this, and following the test of reasonable excuse set out in The Clean Car Company case (see EM5152), Judge Fairpo dismissed the appeal as the case did not demonstrate Cunis had a reasonable excuse.

Judge Fairpo noted that even if Cunis had supplied evidence that HMRC had specifically tested the software, as Cunis was aware of the problems it had plenty of time to sort it out with their software provider.

My thoughts

This was an unusual case, as the employer challenged HMRC in respect of late filed RTI penalties generated by a software error. Whilst I sympathise with the employer, I am puzzled why this apparent software problem only happened a few times and not for every payroll run. However, software can sometimes develop problems without rhyme or reason.

The RTI legislation is very clear: you must submit your RTI returns on or before the payment day. Here at Armstrong Watson, for example, our payroll software allows for a schedule of paydays, which we can override if needed. Before we start processing any payroll we check when the actual payment will be made and ensure our submission shows this.

There are genuine occasions where HMRC’s systems would record that a return is late, such as when a supplementary payroll run is undertaken, but there should be options within software to advise HMRC why an RTI report is late. In this scenario, we would state it was a correction to a previous return. This ensures HMRC is told there is a genuine reason for submitting another file and after the original payment date.

I wonder whether Cunis ticked the box stating “reasonable excuse”, and if HMRC flagged it as used before, or if was no box ticked and that’s why HMRC investigated?

If Cunis had supplied the evidence the judge stated was lacking, or even appeared in person, would there have been a different outcome to this case?

Replies (4)

Please login or register to join the discussion.

By SteLacca
12th Feb 2019 16:10

The judge concluded that any other taxpayer who was intending to comply with their obligations would have either changed their software or would have been communicating with their software provider.

There is no evidence one way or the other regarding whether or not the software supplier was approached. However, the suggestion that the employer should have changed their software is an odd one, particularly given that, unless very carefully handled, a mid year change of software can cause problems with RTI and AE which are almost impossible to put right.

Thanks (2)
By SXGuy
13th Feb 2019 10:39

I also don't get, that given employees were paid weekly, employer couldn't have just ran a batch of 4 or 5 week FPS submissions in advance.

If the pay changed during that time for whatever reason, the proceeding FPS would have corrected it anyway.

Nothing stops an employer submitting an FPS early.

Thanks (0)
By indomitable
13th Feb 2019 16:03

I am interested in what software they were using?

Thanks (1)
By Mike Towle
13th Feb 2019 17:50

I note one of the defense points was:

"The fault lay within the software, which was HMRC approved, so HMRC should have known it wasn’t fit for purpose and should not have accredited it."

But HMRC do not approve or accredit software. They simply acknowledge the software appears to do the minimum necessary to make a submission. Which includes software that's compliant with MTD.

I know, as my software Adminsoft Accounts has been 'acknowledged' by HMRC for several types of data submission. The testing required is very basic. They do not go into any real detail.

My point, is not to be taken in by any software vendors claiming their software has HMRC 'approval' or similar. It doesn't! Even if it's listed on HMRC's web site.

Thanks (3)