Protect yourself from automatic RTI penalties

468153617.jpg

tadamichi/Thinkstock
Editor
AccountingWEB.co.uk
Share this content
Tags
31

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.”

Replies

Please login or register to join the discussion.

What does this mean?

John Stokdyk wrote:

The impact of automatic will be lessened ...

Thanks (0)

Hashing???

Please can you explain precisely what you mean by "hashing".

Thanks (0)

Hashing

as with Twitter - you can search on a hash tag 

Thanks (0)

confused!

am I being thick!  what does this mean?

 

 

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.

Thanks (0)

Hashing

Does "hashing" mean we can emulate the Revenue and make a hash of our submissions? 

I too would like an explanation of "Hashing" please.

 

Geoff (a non Twitter person)

Thanks (0)

HMRC ignore agents again

"Agents will not be sent copies of penalty notices" 

It's typical of HMRC's myopia not to understand that agents need to see the notices and that clients may not pass them on immediately. We can only help HMRC and our clients if HMRC keep us in the loop.

Thanks (8)

Hashing

I believe that this is to link directly to the BACS system, which provides the ability for two way data traffic. Lots of people do online banking and, mistakenly, call it BACS, whereas this is not the case at all.

My suspicion is that to do #BACS will be an extra cost! However, I would be happy to be proved wrong!

Thanks (0)

More confused than ever

Having read this article I'm more confused than I was before...

I run a number of client payrolls, all less than 50 employees.  Will the automatic penalties apply to them from 5th March?

Many of them use online banking but I doubt any use BACS.  Will they have to set up BACS just for this?  Or will we have endless grief from HMRC (and additional penalties) because they can't reconcile the payments they have received to the RTI submissions sent - even when they are the same?  I've noticed this year that if a client has paid SSP then reclaimed it, it throws HMRC into complete confusion.

 

Thanks (0)

mushrooms


This all reminds me of the description of how and where mushrooms are grown and HMRC are doing this with accountants

"Keep them in the dark and feed them on bull***t"

We have had the recent farce of stopping sending out reminders for those who have not filed their tax returns and not sending out payslips and now this.

How on earth do they expect us to act for clients when they keep us out of he loopk.

We are been treated like the mushroom but expected to know everything anyway.

 

 

Thanks (0)

Bacs and penalties


Bacs submissions are not in any way linked to RTI penalties for late (non) filing of FPS returns.

 

Whether this changes in the future remains to be seen.

 

Thanks (0)

as confused as everyone else

“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,”

Does this mean that HMRC/DWP have access to the BACS system and can find out how much  has actually been paid into a person's bank account?

A step too far or am I a bit paranoid?

And what has this got to do with Avoiding RTI Penalties? I wish I had got on with my work and not taken the time out to read the article!!

Thanks (1)

BACS

I don't have any clients who use BACS, all pay using internet banking, or yes, even by cheque, so this just seems irrelevant. Nice to know larger companies have a way of providing more detailed data to HMRC I suppose, will leave support staff free to sort out my clients!

The problems I have had have stemmed from reconciliation problems from prior years leading to a mis-allocation of current year payments. If these are going to kick off penalties it will truly be a nightmare. I have found it very difficult to get problems like this resolved, with the people who chase payments not seeming to have access to the same data as the PAYE people. Systems don't seem to communicate, nor do the support staff. Is that just my experience?

Thanks (0)

PAYE

No it's not just your experience. I have two clients at the moment who HMRC keep sending arrears letters to, I have been through the reconciliation process (which means they agree to your RTI submissions, but not payments received) We can show HMRC that the payments made reconcile to the RTI submissions yet they still keep sending letters. We have asked if the alleged underpayments relate to previous years and have been told they do not. Don't know what else to do!!

Thanks (0)

I've had that experience too - client has paid all the PAYE on time yet HMRC keep sending arrears letters; have sent them documentation proving that the payments are correct (significant additional work for which I cant charge the client) but still the letters keep coming....

Thanks (0)

Just charge them!

ger57 wrote:

We can show HMRC that the payments made reconcile to the RTI submissions yet they still keep sending letters. We have asked if the alleged underpayments relate to previous years and have been told they do not. Don't know what else to do!!

Can't you just mark your letters "Complaint" and charge them £100 + VAT for the extra work caused by their erroneous letters? Do an invoice to the client, send them a copy and tell them it's all their fault. They generally cough up.

Every threat is an opportunity. If they start issuing thousands of automatic penalties when submissions/payments have been made correctly and on time, that sounds like a good little income stream to me.

Thanks (0)

I'm with Charlie on this on this one.....

"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 clients we do regular bookkeeping for tend to not look at correspondence from HMRC, they always say "That's why we appoint you as our agent".

Thanks (0)

More old tat
So we get a system that nobody (except HMRC) wanted and then foisted a half-arsed error ridden version of upon us. After finally realising how error ridden it was HMRC almost got their act together and then typically awoke the cash cow instinct in them and decided to implement a fining system as soon as possible. Even though in sections it still doesn't work properly. What with the pension auto enrolment for small companies that again no one, not even my financial advisor colleague, really understands Its no wonder that people think twice before employing anybody. Whatever happened to government support for small business? Can't see much of that here...

Thanks (0)

just dont offer payroll services

just give  client chargeable support when they get  in  a pickle

 

I know quite a few who just cant be bothered with payroll ( or CIS) anymore

Thanks (0)

Reading the above

Just reading the above, I am confused, mind you the above have worded their concerns better than I can, so i am not going to comment further.  

 

Needless to say we are all going to receive some un-welcome calls from our clients.  In the meantime lets start working on our responses.    

Thanks (0)

What worries me....

..is that I still get these generic notices. I receive several late submission notices for FPS which I know have been submitted on time, and I have the receipts. So I decided to follow one up and what worries me is:

1. HMRC agreed that the FPS had been received when due but could not see why a notice had been issued.

2. I have not called HMRC about the others and I wonder how many other people ignore them knowing the FPS was submitted on time. So are HMRC thinking all is fine and dandy because many of the errors are not being reported, and they still don't realise the system is not working?

With payments since RTI the system allocates receipts to the oldest amount showing overdue (in the current year), and you cannot get a list of payments by date/amount. If a payment disappears into suspense (might be a typo in the bank payment reference) it can takes hours or days to resolve.

I dread the day penalties start, and the time it will take to get them cancelled.

Thanks (1)

Yep - I share everyone's concerns...

I can identify with a lot of what I've just read, including the individual that said he/she wishes they hadn't read this thread at all!

I find the PAYE arm of HMRC the worst to deal with. They have no information to offer pre-RTI. I have one case that HMRC say relates to 2013-14, but I swear it's because they have allocated 2013-14 monies paid (and clearly labelled as per their own system) to a previous year. I have sent my figures in, and now we wait....And wait... 50% of the time I find I hear nothing & phone lines are all too often overloaded. And that's before the penalties kick in.

I dread to think what lies ahead, and yet again wonder just how this country manages to stagger form one year into another year of increased inefficiency & ever deepening bureaucracy.

I will give it all a fair go, but it won't take much for me to run for the hills & drop payroll services if this creates half the head ache I fear it might.

 

 

 

Thanks (2)

Not always Revenue's fault

Client was getting threatening letters from HMRC because of unpaid PAYE. Client knew that he had paid, sent copies of bank statements to HMRC who insisted that cheque was not received. Client got copies of cheque from bank, only to find that it had been intercepted and fraudulently paid into another account.

Client sent a replacement cheque to HMRC and recovered recompense from bank for fraudulent banking. The moral of this story is to always pay online, which client now does.

Thanks (0)

Linking bacs and FPS records


Just read an article by Credec on this site about the potential linkage between the FPS and the bacs records. Well worth a read.

But, as I cannot seem to post a reply/comment there, I am adding my comments here. There are several potential scenarios…

(1) The Bacs record and the FPS link by virtue of the ‘hash’ and the four-character length random string. The bacs date and the FPS payment date match.

(2) The Bacs record is missing the four-character length random string – no match. How will HMRC identify the PAYE scheme and the employee to which this refers? Pretty unlikely in my view.

(3) The FPS record is missing the ‘hash’ which is a 64-character length string generated at point of FPS creation using certain data (eg account details which are not reported in the FPS) and Secure Hash Algorithm SHA-256. Unlikely there will be a match with a bacs record.

(4) The Bacs record has the 4ch string but there is no matching FPS. How will HMRC identify the PAYE scheme and the employee to which this refers? Pretty unlikely in my view. Furthermore, it is quite feasible that the employer cancelled / recalled the bacs payment and stopped the FPS record being submitted.

(5) The Bacs record and a FPS record are matched by the 64ch/4ch strings, but the payment dates are different. If the FPS record has a valid late filing excuse code, I understand HMRC take no action. If there is no code, and the FPS is not filed on or before a late filing default will occur anyway.

So, I do not see how HMRC can use the Bacs data to support late filing notice/penalties. But perhaps I'm wrong?

Thanks (1)

Thanks Mike for your comments above.
What you describe broadly covers a successful hash match i.e. your scenario (1). And (2), (3) & (4) are examples are examples of failed matching and (5) would be covered under 'on or before' if the FPS hashed record had an earlier date than the date of matching, where matching is taking place on actual pay date (when funds credit the employee).

Thanks (0)

Linking bacs and FPS records

Credec

It seems to me that in none of scenarios 2 to 4 does it make any difference whether or not the FPS and bacs records are matched. It is a non late filing of the FPS which will determine whether a notice / penalty is issued.

So, going forward, what exactly can HMRC do which is different?

 

Thanks (0)

Mike,
Where HMRC's RTI systems are functioning correctly (FPS received/recorded properly and correct amounts allocated to employer PAYE accounts) then HMRC does not need to do anything differently going forward, as the system will not issue a penalty where it isn't supposed to.
However, where an employer and their payroll agent have done everything right but there are still issues with their PAYE account, using RTI BACS to pay employees provides an independent means for the employer/agent to demonstrate that they paid what they reported and when they paid it.
 

Thanks (0)

bacs and fps returns

CreDec "...independent means for the employer/agent to demonstrate that they paid what they reported and when they paid it"

Have any of your clients used bacs data in this way?

My own view is that it's the FPS return which is crucial.

And of course there are many employers who do not use Bacs to deliver net pay.

From the start of RTI I have been sceptical about what value the hash etc add to the process. I have also yet to see recent figures published by HMRC about matching accuracy but I recall in the early days of RTI there was a high percentage of mismatches (for whatever reasons).

Personally the hash requirement is pointless and a waste of resources.

Surely, the data from the FPS returns HMRC supply to DWP is sufficient for UC purposes?

 

 

 

 

Thanks (0)

Actually no..

Hi Mike,
"Surely, the data from the FPS returns HMRC supply to DWP is sufficient for UC purposes?"
Actually no. HMRC and DWP have confirmed that the only way for DWP to receive net earnings values, as paid, in their own systems so as to manage claimant queries is if their employer is hashing. We published an article in December: Payroll - The Key to Universal Credit, that explains this.
See: http://www.accountingweb.co.uk/press/payroll-key-universal-credit
Private Message us if you'd like us to make contact so we can go through these points with you in person - we're keen not to dominate this comment thread.
KR, CreDec

Thanks (1)

mess!

I have 41 payroll clients if you include those where I have sub-contracted payroll to my book-keeper.  The total number of staff across those for 14-15 is about 150.

The number of those staff being paid via BACS is zero.  Has this whole RTI rigmarole been work for the cat?

Thanks (0)

A definition of RTI BACS / "BACS"

By way of a quick guide to the RTI BACS, HMRC 'best practice', payment channel for employee salary credits, CreDec has posted this article today on AccountingWEB.

http://www.accountingweb.co.uk/press/abcs-bacs
 

Thanks (0)

A definition of RTI BACS / "BACS"
CreDec, I notice in the article you refer to here, you again imply that using Bacs can prevent an HMRC automatic penalty for late filing. There is no linkage (currently) between Bacs submissions and RTI penalties for non- or late filing, that I am aware of. It is the non or late filing of the FPS which will lead to a penalty, so irrespective of whether a Bacs record with the random string has been submitted and received by HMRC, the onus will still it seems to me to be on the employer to demonstrate the FPS has been sent 'on or before'. If you know differently please advise.
Indeed, if we take this a step further, HMRC has issued guidance that where a pay day falls on a non-banking day (e.g. 6 April 2015) the normal pay date is to be shown in the FPS even though the payment may be delivered on a preceding bank working day (e.g. Thursday 2 April). Inevitably in these cases the Bacs records and the FPS records will bear different dates, but this is ok for HMRC as it is the FPS which they will use for late filing penalty purposes.

In your reply above you say "HMRC and DWP have confirmed that the only way for DWP to receive net earnings values, as paid, in their own systems so as to manage claimant queries is if their employer is hashing."

This is surely incorrect, as there are many employees who are paid other than by Bacs. There must therefore exist a channel by which HMRC supply data to DWP which meets requirements for UC. Indeed, a Bacs record is not of itself an indicator of an employee's (or pension recipient's) net pay as the employee may have their net pay split with different pay methods used for each. Moreover, the employee may have savings or other 'non-allowable' deductions made, with the residue of earnings paid as net pay. Another issue is that the employer might in some circumstances make a payment outside of the payroll and simply adjust the year to date figures for tax and NICs etc in the next FPS. Unless HMRC's system picks this up by checking the YTD movements and includes it in the data supplied to DWP, the latter will not know about it at all from Bacs records as these will not exist.
I'm sure you're also aware that there is a HMRC specification for the FPS data which is in part intended to identify an employee's 'real' net pay.

Thanks (0)