OK, this may take a little explaining, but I think that all the huge hassle we have had to sort new BACS systems may have been totally and utterly pointless crap.
How it works
We do have to send HMRC details of payroll each month (well, on or before each payment made under PAYE). That is the new system. Previously we did this once at the end of the year.
It uses XML and stuff to send the data, and on its own this is not too bad. We have to do all the work for PAYE and make pay slips and so on - the extra work to effectively make an XML payslip and send that to HMRC is not big. Indeed, I got most of it sorted in a few hours at the start of the week. As ever I have spent a lot of time polishing up the old code for PAYE (see other blog post of code wearing out).
But yes, on its own, simply sending an XML copy of payslips as we make them to HMRC is not a huge task.
What is hard work is that every BACS submission software package and BACS bureau has also had to change to allow "BACS field 7" to be populated. A previously unused 4 character sub-reference. This even led to Lloydslink shutting down their BACS bureau. It has taken a lot of time and money for us to do this all.
The reason is that, when we send the data to HMRC, we can prove we paid the employee. This is done using a hash.
The way it works is that a one-way hash is made of some data in the BACS payment we make. BACS do this, when they get the payments, and they send the hashes to HMRC. The theory is that HMRC do not get the whole of the bank details (privacy issues?) just the hash. We do the same calculation and send the same hash in the submission to HMRC. HMRC can match them up, proving we paid the employee.
The hash is made from fields in the BACS payment. These include our sort code, the recipient sort code, and the amount we are paying. They also include this sub-reference, which has to have a "/" at the start (so BACS know it is for HMRC to get the hash) and there random characters. The random characters mean the same person paid the same amount each month does not get the same hash. They could, of course, have simply included the date to avoid that, but maybe that was too risky as BACS could be run early or late for lots of reasons.
Clever stuff, you may think. Including the amount in the hash means HMRC know we paid the right amount to someone for payroll, doesn't it? The theory is that if they cannot match the hashes then they consider that more of a risk in their risk management.
The problem
There is, of course, a huge hole in this. All the hash actually proves is that we made a payment. It is not likely we could make a matching hash for some payment we did not make. It could be any payment to anybody and any amount, as long as we made it, and and therefore we can work out the hash for the payment. There is no way for HMRC to check the hash we send them is right as we don't tell them sort codes, or the sub-reference. All they can check is that it matches some payment that went through BACS.
Wouldn't BACS tell them the amount? Well maybe, but if that is the case why include the amount in the hash?
Wouldn't BACS tell them all the details, sort code, account, amount, etc? Well maybe, but in that case why have a hash at all - why not make the submission to HMRC include the sort code and account of the employee? That would have meant we would not have had to change BACS at all.
In fact, HMRC state that they will not have any access to the source information from BACS (such as bank account details). But to check I have FoI'd them. I'll FoI how much all of this has cost later!
Basically, when making the submission to HMRC, as long as we have a means to make a payment of some sort via BACS, even if it is 1p (or indeed, the correct amount) that is paid back in to the same account it left, and we can work out a hash and include that in the submission, it will match up on HMRC's side. The actual payments to staff could be completely separate, different amounts and times and anything else. The very issue one assumes they are trying to address by matching up payments.
Basically: It is trivial to fake the BACS payments with matching hash, independent of actual payroll payments.
So why the hell did they bother?
That is the real question. Why make a half hearted system that has caused a lot of people a lot of work for no real gain?
Either don't try and check payments, or check them properly by requiring the actual payment details in the submission (sort code and account). This faffing with hashes is a total waste of time.
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
It seems to me that it's not 100% secure but if they have any doubts about the accuracy of your data that they would have the legal powers to obtain the actual payment data and at that point it would become clear that the payments didn't match the purpose. The hashes give them a clear trail of evidence to follow that you've deliberately mislead them thus aiding any investigations or prosecutions while remaining relatively anonymous in the general case.
ReplyDeleteCan't see that the hashes help with that - if the RTI report does not match payments, then that is evidence we are sending wrong reports. The difference between the two is evidence enough.
DeleteAlso, saying "not 100% secure" is misleading - it implies some slim theoretical chance of being thwarted. No, it is not "secure" at all - they have no way to check the hash is correct, all they can do is check it matches a BACS payment but no details of the payment itself. So it is 100% possible to fool it, i.e. it is 0% secure. But it adds hassle, and makes mistakes possible, as well as making legitimate corrections and changes difficult or impossible. It causes potential problems for all legitimate users, but anyone actually trying to game the system has no problem and looks queeky clean to HMRC. We are all paying to make this happen.
DeleteI'm assuming they are treating the hash as a kind of unique transaction ID, so if there are questions they can easily identify the offending transactions at the bank and obtain full details more easily. It does seem a lot of effort for little value though, particularly as the most obvious way to cheat is to pay people off the books somehow and then there would neither be a submission to bacs or a record send to PAYE.
ReplyDeleteEven if you supplied HMRC with the destination sort code and account number and the value of the transaction, how would they know that that account belongs to the employee?
ReplyDeleteI see they've responded to your FoI request, looks like they do get the amount as well as the hash, so you couldn't just make 1p payments.
ReplyDeleteHaving said that, I would assume the 'threat' to HMRC here is not you claiming you've paid an employee but not actually doing so (which wouldn't be in your interest, as you'd still owe HMRC the associated amount of tax and NI contributions and have to pay it), but that you report to HMRC you've paid the employee less than you actually have (so as to reduce the amount you owe HMRC).
In that situation, all it requires you to do is therefore pay the employee twice, once at the amount you've told HMRC about, and then again separately. I guess the counter argument here is that the employee would then potentially notice something amiss, but as suggested above you could always pay yourself the appropriate amount (though that would likely make the bank suspicious in the long run)...
Basically, all the hash does is confirm the submitter has access to BACS. It does no more. It does not check payments at all. As long as a payment matches the hash and amount, even if back you yourself (which the banks really would not care about, honest, we do it), HMRC cannot tell anything.
DeleteSo one has to wonder what the hash is meant to check. If all it checks if the sender has means to send BACS, then they could just ask for your SUN. The hassle and technology involved creates lots of problems and proves nothing.