Save content
Have you found this content useful? Use the button above to save it to your profile.

HMRC hashes up RTI compromise

17th Aug 2011
Save content
Have you found this content useful? Use the button above to save it to your profile.

HMRC’s “interim solution” to help administer the Department of Work and Pensions’ Universal Credit has come under fire from the payroll software industry. Jon Wilcox investigates the so-called “RTI hash”.

The forthcoming implementation of Real-Time Information (RTI) by HMRC has been the subject of much debate in recent months, especially here on Having stepped back from relying on the banks’ BACS payment mechanism to run RTI, HMRC recently issued a proposal for a cross-reference between the different systems involved.

Responding to widespread criticism from the payroll industry of its preference for BACS, HMRC announced in May that it would adopt a “revised technical solution” for an interim period. As part of the solution within the RTI submission, HMRC confirmed that it would create a cross-reference field for each employee submission where employees are paid via BACS. This was set out in a technical specification document published on 22 July.

A hash will now be included in the RTI submission to HMRC; [and] a random value inserted in field 7 of the BACS payment instruction, followed by a three alpha-numeric character random string, HMRC explained. Combining this string with other values, including sort code combinations from both the originator’s bank and the recipient’s bank, as well as the amount to be paid, would provide a sufficient degree of uniqueness to allow effective matching to take place, HMRC said.

Yet critics were still unconvinced. member and 12pay managing director Tom McClelland called the latest compromise a “kludge”. HMRC’s decision to go the BACS route suggested the organisation thinks most employers were already paying their employees by BACS - “a key belief so far wide of the mark as to make HMRC's beliefs about every other part of this process utterly suspect”, he added. Not a single user of 12Pay out of around 10,000 companies using the software pays their employees via BACS.

Fellow AccountingWEB member, Peter Tucker, voiced similar concerns. With the contract for BACS due for renewal by the end of 2015, what level of competition or re-tendering process can be expected when HMRC insists on using the platform to support the RTI system as part of the support to Universal Credit, he wondered.

HMRC’s revised technical solution will allow non-BACS users to file RTI data via the Government Gateway without using the tie-in field. However HMRC told payroll developers this would be viewed as a “compliance investigation issue” – even though the overwhelming majority of employers do not pay by BACS, McClelland reported. For those who do use the hash field, all HMRC will get from back from BACS will be a list of correlation codes which it can then link to RTI data.

The RTI system - which will begin trials in 2012 and is due to roll out from April 2013 - is designed to do away with the year-end reconciliations and tax code errors that got HMRC into such trouble in the summer of 2010. But for more 65 years tax codes have given employed taxpayers a means to spread their liability over the course of a year - and the right to have their liability reviewed at the end of every tax year. Some critics question whether the government and banks are planning to sacrifice some of these rights in their enthusiasm to roll out RTI.


Replies (2)

Please login or register to join the discussion.

By DMGbus
19th Aug 2011 14:24

Like iXBRL "here we go again..."

Not the first time that HMRC have imposed a "foreign" software language on small businesses.

First came iXBRL - a software NEVER used by small businesses but imposed on them under the "one size fits all" mentality of HMRC (apparantly multi-national PLCs may have used XBRL reporting for years, so a few uninformed idiots decide that small companies should be forced to use it too).

As a result how many millions of £ costs have been imposed on the software industry and ultimately passed onto small businesses I wonder?

And now with RTI / BACS reporting "here we go again" with those imposing this "foreign language" reporting being demonstrably "out of touch with reality".

I wonder if a proper cost to small business appraisal will be drawn up and published BEFORE implementation and well before legislated as mandatory - this most certainly was NOT done for iXBRL (despite what an apologist or two for HMRC might say).



Thanks (0)
By kevinringer
19th Aug 2011 14:02

RTI - attempting to run before HMRC can crawl

I can appreciate HMRC's desire to have real time information - and the benefits that could flow through to individual employed taxpayers, and the Treasury. So I’ve nothing against HMRC receiving employment information more often than once a year. But HMRC have not learned the lesson from CT. Why or why did HMRC have to insist on iXBRL. I've been efiling CT for several years attaching PDFs - we could easily produce PDFs from any Windows software. The system worked fine. I can understand HMRC wanting increased efiling - so why not simply make it compulsory, but with PDFs instead of iXBRL. By making too large a step, many have had problems. I can see HMRC repeating the same mistake with RTI. So what is my solution?

1.Get rid of the HMRC PAYE Tools download and replace it with an online version. This will have benefits for employers because they won’t have to download and install software and they could access the data from any internet enabled device. And HMRC would have bang up to date information.

2.Require all 3rd party software providers to submit monthly returns – similar to what already happens for CIS. In fact why not have a single filing? But employers will require one key change. Currently most software will not permit you amend a submitted period – it has to be done manually and I know from experience that it can take up to 10 months!!! Instead, HMRC should permit employers to resubmit monthly returns for PAYE/CIS even for the previous tax year.

Thanks (0)