PAYE RTI BACS madness

This may turn in to a series of blog posts on the matter. At the moment I am a bit behind the game here and only just starting.

It seems that HMRC have decreed (with legislative backing) that we (and indeed, most) employers will have to change the way we do payroll. They list various cases on their web site, such as those with a few employees (who can use HMRC web site), or those using an outside agency or accountant, and those doing payroll in-house. This final option they explain to contact the payroll s/w suppliers. That sounds simple and painless, no?

Now, payroll is not hard. It is something you can do with a pocket calculator, and as a programming exercise it is a piece of cake. So we are in a 4th category - in-house payroll that we wrote.

Sadly this is the worst case. We don't have hundreds of paying customers for our payroll s/w funding new development - yet HMRC want some XML interactions direct with them to submit details of pay in real time (i.e. each payroll run). This changes a handful of sums and a few database summary reports to a task of a hundred times the complexity.

Don't get me wrong - we do this for a living and XML is a piece of cake, but it is massively more complex that just doing payroll normally. I have yet to extract all the specs (which appear to be a moving target) or get on to a test system (assuming they have one).

But it gets worse. It looks like they have "approved" software. I have not got as far as working out what is needed to get approved, but that is never a phrase I like to see.

The reason I say I am a tad behind is that this kicks in for April 2013. Or does it? It turns out there is no penalty in 2013/14 for a late submission, just an inaccurate one. So in fact we have until May 19th 2014 to submit the 2013/14 "real time" submissions without penalty, as long as they are accurate - phew...

But actually, even if we used someone else for payroll, we have loads more work to do at very short notice. We use BACS - we have a service user number. This is because we do Direct Debit. We use Lloydslink Payment BACS service. It is a handy BACS submission bureau used by lots of people for Direct Debits and Direct Credits (e.g. payroll). Works well, easy to use, not too expensive, used it for years.

The files we send include a lot of the BACS fields to allow payments and Direct Debits, but do not actually include all fields. It seems there is an otherwise unused four character sub-reference field (field 7) in the underlying BACS file. We have no way to include that in the submissions. Why would we? It is an unused field as far as we can see.

Sadly, it seems, Lloyds are not prepared to upgrade their BACS system to allow us to include that field. It would cost too much. So they are shutting down their entire BACS bureau service, at only two month's notice to us. This is a nightmare. BACS systems typically take months to set up - they are tightly linked to our billing systems. And to rework it all, finding a new BACS bureau, and getting it set up and tested, in only two month's notice, is scary. I have little doubt we can move fast, but nobody in banking moved at any speed, so this is tricky!

Why is this happening? The answer is that HMRC are to blame. Even if we did not use the BACS files to pay people, the fact that some people do means that they need to populate this magical "field 7" in their BACS payments now, and Lloydslink cannot do that. So we all suffer with the service being withdrawn by Llloyds bank because of HMRC's actions.

The reason is that HMRC want to tie payroll in to BACS in some way. It seems they would actually like real time PAYE reporting to be totally in a BACS file, i.e. detailing the pay and deductions as BACS records. This seems to be partly because it ties actual bank payments to PAYE records, but also because they think the banking system is better placed to handle the data processing for them.

However, they have not quite managed to do that (they still plan to), so they have an interim system which involves BACS/VOCA sending (presumably) HMRC daily SHA256 hashes based on the BACS payment made to the member of staff including this new four character sub-reference field.

This means that to comply with HMRC RTI rules, anyone using BACS directly to pay staff has to be able to include this field in the payments so HMRC can match the BACS/VOCA hashes to the submission.

Oddly they do not include the BACS user number in the hash, so will get duplicates in their files (they acknowledge this). They use sort code (from and to) and amount and 3 random characters, so will get clashes. Why the hell not make it unique - i.e. include BACS user number in the hash and make it a rule that the sub-refrence is unique. Heck, include date as well. That would be easy for s/w providers doing payroll and make sure the hashes are actually unique!

This is an invasive link of payments to HMRC reporting, but more to the point it is creating all sorts of side-effects. We are now having to do two software projects at short notice - one to do a completely new BACS system for Direct Debits, and one to do a new payroll system. The payroll had more notice, had we noticed, but the BACS was a surprise. We had no idea Lloyds would shut down their bureau at short notice.

Well done HMRC costing me money - I'll make sure we account for the time as an R&D project and reclaim extra tax relief for it...