On Monday 13th February 2023, the HM Revenue and Customs Software Developers Support confirmed to the software developer community the end of the BACS hash! A compulsory feature of 10 tax years for many has now been dropped.
Once claimed that RTI BACS is such a powerful validation of RTI compliance HMRC have declared it ‘best practice’. But soon to be no more.
Subject: RTI FPS: Bacs hash not required from 2023-24
HMRC has recently decided to withdraw the requirement for employers to supply an entry in the Bacs hash code field (data item 118) for 2023-24 onwards. Unfortunately this decision was made too late to remove it from the 2023-24 RTI FPS schema; any supplied values will not be processed.
The Data Items Guide on GOV.UK will be updated in due course.
What does that mean and what associated impacts
So for the 2023/2024 (and payment with a contractual payment date from 6th April 2023), there is no need to provide the value in FPS data item 118.
However, HMRC have so far provided no further information on associated impacts:
- Is Regulation 67CA going to be removed?
- Can it be assumed that the adding of the random number alongside the BACS payment instruction is also not needed.
- What is the impact if any for Universal Credit claimants and has the concept of verified payment disappeared?
The announcement for inclusion within some software solutions will be too late, however, HMRC will ignore hash associated values if they are reported.
Origins of the BACS hash
Towards the end of the last Labour government, David Gauke, the then conservative MP for Rickmansworth, met with software developers on a potential proposal for BACS to process the calculation of tax and National Insurance in real time from credits of wages and salaries from employers
After the Conservative and Liberal Democrat coalition government being formed, proposals were explored with a revised implementation of Real Time Information alongside the introduction of the new benefit system Universal Credits.
Following a pilot in the 2012/2013 tax year, through a process of roll-out from smallest to largest, Real Time Information (RTI) Full Payment Submission (FPS) was made compulsory for the majority of employers and pension payers.
Although the original BACS calculation and deduction of tax and NI was dropped after consultation, the concept of verified payments between bank credits and payroll reporting was born in the form of the ‘BACS Hash’ on the FPS and the reporting of a payroll generated random number on the BACS file field 7.
What was it for?
This hash cross reference was claimed to be needed so that HMRC can match the payments individuals receive with the payroll data reported in real time. This was also to provide additional verification about the amount paid into an individual’s bank account to assist DWP’s administration of Universal Credit.
Employers and pension providers who paid their employees or pension recipients via a Bacs direct credit payment using their own Bacs SUN were required by law to include a hash cross reference in their RTI PAYE returns. A SUN is unique and allows a business to be easily identified by the BACS providers.
The same employers or pension providers must also have provided the sub-reference (used to generate the hash) in field 7 of their Bacs (Standard 18) payment instruction, which normally involves software provided by a Bacs Approved Solution Supplier (BASS) or through a Bacs Approved Bureau (BAB).
What legislation covered this?
Regulation 67CA of the Income Tax (Pay As You Earn) Regulations 2003 (S.I. 2003/2682) had effect for relevant payments made on or after 1st September 2012. It was inserted into those Regulations by the Income Tax (Pay As You Earn) (Amendment No. 2) Regulations (S.I. 2012/1895).
Notifications of relevant payments to and by providers of certain electronic payment methods
67CA.—(1) A Real Time Information employer who makes a relevant payment using an approved method of electronic communications which falls to be included in a return under regulation 67B must—
(a)generate a reference under paragraph (3) and include it in that return,
(b)notify the service provider that the payment is a relevant payment, and
(c)generate a sub-reference under paragraph (3) in respect of the relevant payment and notify the service provider of that sub-reference.
So what was the hash?
The first involves the RTI submission and the second involves the Bacs payment instruction.
(a) The hash included in the RTI submission to HMRC (FPS data item 118). The hash should be generated using the Secure Hash Algorithm SHA-256. The data used to generate the hash must be ASCII characters made up from:
- the four character sub-reference inserted, or to be inserted, in the Standard 18 payment file (explained in b below),
- the sort code of the originator’s bank (6 numerical digits),
- the sort code of the recipient’s bank (6 numerical digits),
- the amount of payment in pence (11 numerical digits with leading zeros and no decimal point)
(b) The sub-reference inserted in field 7 of the Bacs payment instruction
This value must be random (not sequential). The sub reference should be the same as that inserted in the hash for the RTI submission.
The value of the field must be a solidus (/) to be inserted in character position 32 followed by a three alpha-numeric character sub-reference generated from the following characters in positions 33-35:
- hyphen (-)
- full stop (.)
- solidus (/) (hexadecimal value 2F)
- zero to 9
- A-Z (as specified for upper case alphabet)
So examples would be: “/123“, “/ABC“, “/..A“ “/9C-“, “/…“ , “/9C/”
The HMRC dropping of the BACS hash indicates a waste of time and effort over the past ten years. What useful purpose did the BACS hash serve. Why were software developers and employers compelled to undertake development for the benefit of taxpayers funding a pointless BACS service?
The BACS hash may continue to be around, although ignored, for the 2023/2024 tax year. Expect it to disappear altogether for future years.
With added flexibility being allowed for salary advances, the concept of on or before is also being challenged as valid. How will DWP know how much ‘earned wages’ have been paid mid period out of the sight of UC and the regulated credit providers.
With RTI now heading into its 11th (12th for those in the pilot) year of operation, is it time for a much deeper review.