RTI automatic penalties explained
Responding to continuing confusion and frustration on the issue, John Stokdyk attempts to describe how HMRC’s automatic penalty system will function for late RTI filings.
No other subject in recent years has prompted quite the degree of anxiety and outrage as the prospect of automatic penalties for late filing of payroll real time information (RTI) to HMRC.
While HMRC announced this week that it will not automate penalties for late payments for the time being (the regime was due to start in April), the automatic late filing penalty mechanism will kick into action for small companies (50 employees or fewer) from 6 March.
If you have received erroneous penalty warnings in previous periods from HMRC and have not been able to identify the underlying causes yet, now is the time to address the issue. From April these notices will mean fines are totting up for employers on top of their normal tax liabilities.
When AccountingWEB published an article two weeks ago warning of the arrival of automatic penalties, several members raised questions about some of the terminology and processes that were mentioned. This article attempts to describe exactly what is happening with the introduction of the new regime for small companies next month. It’s not an easy job, but somebody has to do it.
The ‘on or before’ rule
“Real time” is the key phrase here - even though we have established that a great bulk of HMRC’s payroll data is not actually passed in real time between its systems. The Department of Work and Pensions (DWP) UC computer polls HMRC’s systems several times a day and can use RTI data submitted by an employer as soon as it is visible. The law stipulates that companies have to submit their payment submissions to HMRC on or before the date on which employees are paid.
In ordinary circumstances, when payday comes around, you need to submit a full payment submission (FPS) to HMRC before the payments reach your employees. HMRC uses the FPS to calculate how much you are due to pay them. If you need to reclaim maternity or sick pay, CIS deductions or contributions under the NI holiday scheme, you’ll need to submit an employer payment summary (EPS) to register the differences in amounts due by the 19th of the month after the tax period.
If there are periods where the business does not pay employees HMRC will expect to see a nil FPS showing no payments by the 6th of the tax month, or an EPS with the either the ‘No Payment for Period’ box ticked or relevant dates entered in the ‘Period of inactivity’ field by the 19th of the following month.
If you have a situation where the individual’s pay is known for the year ahead - for example with a low basic salary with the balance in dividends - you can apply to set up an annual scheme. If the pay date is set for April, you will only need to file the one FPS in April.
How automatic penalties work
HMRC explains that its computers will generate automatic late payment penalties if you didn’t send the expected number of FPSs or if you neglected to submit a nil EPS when you didn’t pay any employees in a tax month. The system is based on the assumption that employees are paid monthly, so the department will expect to see an FPS by the 6th of each month, or an EPS by the 19th of the following month - unless you have taken advantage of the various mechanisms available for less regular payment patterns.
There is an automated system to avoid penalties if the FPS is late. You will be able to do this if you indicate at the time of filing that the reason for the delay meets the following:
- Notional payment: Payment to expat by third party or overseas employer
- Notional payment: Employment related security
- Notional payment: Other - including a “filed within three days” appeal for penalties arising between October 2014 and January 2015.
- Payment subject to Class 1 NICs but P11D/P9D for tax
- No requirement to maintain a Deductions Working Sheet
- Impractical to report work done on the day
- Reasonable excuse
- Correction to earlier submission.
The final point offers a valuable escape route if you are in a situation where you don’t have all the data relating to the HMRC payment data (for example from reclaimed CIS). The EPS is not due until HMRC’s monthly payment deadline on the 19th of the following month and late filing penalties are not imposed for subsequent amendments to original returns which were filed in time. So employers can submit the net amounts paid to employees by the 6th of the month, but overwrite previous returns with amended figures up until the 19th of the next month.
If the amendments cross over the end of the tax year, the employer will need to report adjustments on an earlier year update (EYU), which can be submitted electronically to HMRC up until the 31 January self assessment deadline for that tax year.
What is “hashing” and why is it significant?
A lot of confusion was caused in the previous article about “hashing” and the role of the BACS payment mechanism within the RTI system. But the continuing discrepancies between amounts that payroll service providers are reporting and the amounts HMRC is telling employers raises the question of how the profession is going to be able to defend clients from erroneous automatic penalties.
According to Bacs provider CreDec, the RTI BACS hashcode will give the payroll agent a means to prove the integrity of the RTI data they submitted.
From their inception, the RTI and UC computers were designed to include a 64-digit “hash” code field that linked the records in both systems. This mechanism only works when the payment message arrives via BACS, and does not work if the hashcode is only generated by a payroll program and included as a reference on an FPS. As CreDec put it: “The importance of hashing is that it validates employer PAYE data by referencing the BACS payment network’s corresponding payment to that employee.”
What is best practice?
Another source of confusion is the status of HMRC’s advice to employers in December’s Employer Bulletin 51 that advised under a heading “Best practice” that “using the “BACS hash process is good practice as it enables DWP and HMRC to check PAYE against payment data” and that using the BACS process appropriately would “ensure year to date figures are correct”.
The phrase “best practice” holds particular significance for accountants as complying with such departmental recommendations is a way to demonstrate that a firm has done its utmost to protect its clients’ interests, and so protect itself from negligence claims.
Responding to AccountingWEB’s queries on this point, HMRC said: “Employers do not need to pay their employees by BACS, but where they do, our systems can automatically verify that the payment amount reported is the same as the payment received in the individual's bank account.”
The verification process is not limited to BACS, the department said. “HMRC shares payment information with DWP regardless of how the payment has been made. When someone claims universal credit their identity is validated and checked against DWP and HMRC systems. If these match an indicator appears on our system and any RTI received is sent to DWP within six hours of receipt at HMRC.”
On the “best practice” issue, HMRC said the heading in December’s employer’s bulletin was “simply referring to some practical advice for employers”, and was not intended to infer that those who do not pay by BACS are doing anything wrong.
“There is no obligation for employers to pay by BACS if they don't already and HMRC is not advocating that employers should move to BACS for tax purposes.”
You might also be interested in
AccountingWEB’s interim Editor in Chief has been with the site since 1999 and returned to the editorial hot seat in March 2020 to lead the hunt for a long-term successor... Send a DM if you're interested! When not tending to the needs of AccountingWEB members and geeking out on their technology habits, he devotes much of his time to his oddball...