With automatic penalties for late PAYE filing due to come into force for small companies from 5 March - the first notices will arrive just over a month later - HMRC has alerted employers to new procedures and guidance for preventing penalties.
December’s Employer Bulletin 51 explained that filing penalties began on 6 October for employers with schemes of 50 or more employees. Employers who incurred penalties will start to receive quarterly penalty notices from the beginning of this month (February 2015).
The impact of automatic penalties will be lessened by amendments to legislation which mean final returns made from 6 March 2015 just have to reflect the final year to date figures for 2014-15, with a final full payment submission (FPS) or employment payment summary (EPS).
Employers can submit additional final returns to overwrite previous versions if they need to make amendments and in this situation automated penalties will be levied on returns made after 19 April.
Agents will not be sent copies of penalty notices, but they will include prominent messages telling recipients who use third party payroll agents to show them the notice immediately. The bulletin also sets out the process for appealing against automated penalties.
Even with these precautions, April’s crop of penalties is likely to dwarf the initial volumes seen by larger employers this month.
AccountingWEB has regularly featured news and posts about RTI reconciliation errors going back to the scheme’s pilot phase and as we have seen with generic alerts issued last year, data discrepancies between the records on HMRC’s computers are likely to trigger penalties - potentially in their thousands.
In an interesting coda at the end of the Employer’s Bulletin regarding RTI “data quality”, HMRC and the DWP published 'best practice' advice advising that while it was not mandatory for most employers: “using the BACS hash process is good practice as it enables DWP and HMRC to check PAYE against payment data”.
In an oddly worded and ambiguous bullet point, the guide adds that it is best practice to “ensure year to date figures are correct; and use the BACS process appropriately”.
This suggestion has been floating in the background for the past year or two, but the public comment in the employment guide goes part of the way - subject to the qualifying adverb “appropriately” - to installing BACS as the preferred payment method to ensure a flow of clean data from HMRC to the pensions department.
ACCA head of tax Chas Roy-Chowdhury explained the significance of this statement. “They are recognising that they have data that’s not as clean as they need to work properly with universal credit,” he said.
“It’s going to be an ongoing problem. Because they went for real time data along with tax credits and universal credit, which are paid in arrears, there will always be inaccuracies as incremental data comes in. It’s a fundamental problem in the philosophy behind RTI.”
Roy-Chowdhury advised that using the BACS should be “good rather than best” as a one-size approach doesn’t really work for payroll.
Bacs payments specialist CreDec responded to the guidance with a press release explaining that the hashcode link has been built into the RTI system for years for the express purpose of matching the reported payment data with the actual sums paid.
“The importance of hashing is that it validates employer PAYE data by referencing the BACS payment network’s corresponding payment to that employee, helping DWP to eliminate errors (and fraud) in the benefits system,” CreDec explained.
“Hashing is directly connected with the operation of universal credit which starts an accelerated national roll out from February 2015.
“The use of the hash by employers gives the DWP direct visibility of the net payments each UC claimant has received from their employment, allowing the DWP to answer the claimant’s query as to why their UC payment has changed. In the absence of hashed data, DWP can only refer the employee query back to their employer to answer: DWP has no visibility of an employees’ net earnings payments without hashing.”