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.
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.
My air-con can have a temperature set and aim for it. It has a wide range of ± a few degrees which I don't like. It is not setting tempe...
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...