RTI penalty concession ends

iStock00003633464_Medium
Share this content

Midnight passed on 5 April, the deadline by which HMRC said it would set out its stance on late filing PAYE data via real time information (RTI). We're still waiting to hear back from the tax department what the actual situation is.

“They have 24 hours left to publish their new penalty stance or miss the commitment given last year to publish it by the end of the tax year,” payroll lecturer and writer Kate Upcraft said the day before. “If not we start another tax year with no RTI compliance regime.”

The new tax year will see the end of RTI reporting concessions that were introduced in 2014 to ease the burden on small companies. HMRC’s February Employer bulletin warned that the two-year temporary reporting relaxation will end as planned on 5 April 2016.

The relaxation allowed companies with fewer than nine employes to report monthly information on or before the last payday in the month, rather than on or before each pay run.

A few permanent exceptions to the on or before rule remain in place, for example if employees are paid on a non-banking day or the employee earns less than £112. But for everyone else, the Employer Bulletin advised, “You will need to make sure that from 6 April 2016 your payroll software enables you to report all your PAYE information ‘on or before’ the day you pay your employees.”

As well as the end of the pay month reporting concession, HMRC also decided in February 2015 not to chase full payment submission (FPS) if they were less than three days late (from ANY employer, not just small companies as originally reported. Apologies for the misstatement - Ed). This concession is also due to end today, but there is no word yet from HMRC about what will happen to late SME filers after tomorrow.

AccountingWEB has asked HMRC for an update on the three-day concession and further guidance on RTI penalties.

According to Upcraft, companies and their payroll agents will continue to operate in a twilight zone of RTI compliance and penalties if new guidance does not appear. “They can't police it anyway even if people still file late,” she said. 

About John Stokdyk

John Stokdyk, AccountingWEB head of insight

AccountingWEB’s Head of Insight has been with the site since 1999 and likes to spend his time studying accountants’ technology habits. When not nerding out, you can find him exploring obscure indie music and searching for the perfect organic sourdough loaf from his base in Brighton, UK.

Replies

Please login or register to join the discussion.

avatar
06th Apr 2016 11:16

Process/ submission date

So, we run payroll for many clients, and, of course, we process the payroll on whatever date of the month they request - they will frequently ask us to put the last day of the month even though they may pay them mid-month.  We have no idea when, in practice, they pay their staff.  I guess, in reality, they are rarely going to pay their staff before they get the figures from us, so will they be ok on the basis that, if anything, we are going to put a date after they actually make the payment; rarely before?  We always submit the FPS at the time of processing and file adjustments if the client changes anything.

Obviously this is more or less impossible to police, short of HMRC enquiries.

Thanks (0)
avatar
06th Apr 2016 12:59

But be careful if you pay employees via direct BACS

... because if you do then HMRC will know when the payments were actually made.

I too have clients who (anecdotally) report 'pay date' in the FPS as the final day of the calendar month, even though the payment was actually made on (say) the 25th.  In our case the FPS submission takes place automatically once the processing is confirmed as 'complete' - and only at that point are the 'payment instructions' released, thereby ensuring that at least the 'on or before' rule is enforced.

However, my point is that if your client pays via 'direct BACS' (as opposed to say online banking) then HMRC are automatically notified of the actual payments (including the date) so have the ability to detect when that date differs from what was reported in the FPS.

Thanks (0)
06th Apr 2016 18:38

Why payment dates in FPS matter

Just to chip in here, the reason why FPS 'pay dates' matter so much is because of Universal Credit, which begins its accelerated national roll out this month. RTI is used by HMRC for PAYE but also DWP for UC, potentially the same day it’s reported, in real time!

If there is a mismatch between the actual payment date of earnings and the 'pay date' reported in the FPS then employee claimants - whose personal claim period is not aligned to their employers' payroll period - are at risk of not getting the right UC award.

BACS matters because it’s the only way the employer can get the information to DWP to validate the earnings data on which employees UC claims are based.

So any mismatch between the actual payment date and the reported ‘pay date’ in RTI which affects their claim – when payment is not made via RTI BACS – means the employee claimant will be referred back to the employer.

DWP’s guidance actually says this. (“If RTI data is submitted late this could mean that your employees receive too much or too little Universal Credit, and a possible increase in contact for you.” This is how UC has been designed. See “DWP UC & employers: frequently asked questions” https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/418186/uc-and-employers-faq.pdf

However, paying by RTI BACS / direct BACS means DWP has the information to be able to resolve the employees’ queries about their UC award without recourse to the employer. This automated protection isn’t available via online banking. This is why HMRC says RTI BACS hashing is PAYE ‘best practice’ and why DWP’s guidance says “Best practice advice includes using the BACS process appropriately.”

Effectively, employers that don’t choose to pay by RTI BACS face having to deal with the challenges and queries of employees in UC. Only they won’t know when or which employees have been enrolled into UC.

It’s had many false starts but UC is finally on: HM Treasury have £12bn riding on it and Stephen Crabb, DWP's new Secretary of State, is set to announce government’s “absolute commitment” to delivering UC in his first major speech next week on 12th April. (Yesterday’s Times, 5 April 2016: if you believe what you read in the papers, of course.)

Thanks (1)
06th Apr 2016 18:13

Some would argue that definitive proof is no bad thing

If you're more concerned about filing after rather than "on or before" the pay date, then your advice holds, Hugo.

But from what I have seen, most payroll software will prepare a monthly pay run and then either print checks or output a payment data file. With the "soft landing" concessions slipping away, continuing with a laissez faire attitude to on or before could come back to haunt people later.

And because of the concessions, late reporting penalties are a long way behind duplicated records, payment reconciliation errors and unexplained PAYE code calculations in the list of RTI concerns being reported by AccountingWEB members.

The BACS mechanism will feed HMRC accurate data about your pay run, but if you've ever had to confront HMRC over some of the discrepancies we've heard of, having a definitive record of what was paid, when isn't such a bad thing.

BACS specialist CreDec makes this argument extensively on its AccountingWEB Supplier page.

Thanks (1)
avatar
07th Apr 2016 10:59

Facts vs Recommendations

Just to be clear, I wasn't giving any advice (let alone recommending avoidance of paying via direct BACS) ... merely pointing out (in response to an earlier post in this thread) that IF you put a 'pay date' in your FPS that is AFTER the date when you actually paid staff then HMRC can automatically detect this IF you pay by direct BACS (and therefore 'BACS hashing' values are included in your FPS file).

CreDec is quite correct about the potential impact on UC claimants ... although not strictly so correct when saying "any mismatch .. means the employee claimant will be referred back to the employer".  In the first instance, when a mismatch is found (not just of dates but of reported vs claimed earnings) DWP refer the anomaly back to HMRC - who may (not will) refer back to the employer for clarification.

None of this has anything to do with failing to report 'on or before' the pay date (or late reporting penalties).  Indeed the closest I meant to come in terms of advice was:

* Don't put an incorrect 'pay date' value in your FPS if you pay staff via direct BACS, because HMRC can detect this automatically (without any human 'policing').

The pros and cons of using direct BACS - let alone whose fault it is that there is only a partial solution within RTI for tracking actual payments - are entirely different stories!

Thanks (1)
avatar
By ringi
11th Apr 2016 14:31

Any issue may result in your employees benefits being stopped…

With UC claimants, it is very possible that any errors in your RTI submissions will result in all the benefits of one of your employees being stopped.   Your employee’s landlord may then decide to evict them, even if they do pay the late rent once the benefits are sorted out.

The benefit department will explain to your employee that their benefits where stopped due to you not running PAYE correctly.    That employee will talk to other employees of you…..

For example if the benefit department see from the employees bank statement a payment that looks like a second wage coming in, as it does not match 100% with your RTI return, they will stop the benefit then spend many weeks (months even) on the investigation.

Just think what happens when the benefit department gets a real time feed on all transactions from the banks for everyone on benefits, and question any payment that happens before the RTI return….

Thanks (0)