Written evidence from Peter Seymour (UCU0078)
This submission is made in a personal capacity. I was formerly the Head of Government at VocaLink with responsibility for the implementation of HMRC’s validation mechanism for RTI employer reporting by reference to the BACS Direct Credit payment system. As part of my former role I have previously provided evidence to the Work & Pensions Committee and other Government stakeholders.
This submission supplements Lord Freud’s evidence to the Committee of 8 February 2017 and is intended to assist the Committee understand the mechanism the payment system currently provides to ensure the accuracy of UC claimants’ awards.
In particular, it aims to explain the RTI mechanism available to HMRC to support its validation of employer real time earnings data at the point it enters both DWP and HMRC systems and how this mechanism supports HMRC RTI employer compliance activity.
1.1. UC is a real-time data system designed to allow claimants to move seamlessly in and out of work because it adjusts their claim payments automatically according to their employment earnings – UC’s success therefore depends on the accuracy of the earnings data reported by employers to HMRC that feeds DWP’s real-time UC claim calculations.
1.2. The design of UC and its dependency on accurate real time PAYE earnings data requires that employer data is validated at the point it enters HMRC’s and DWP’s systems, because there is no process to correct an award retrospectively.
1.3. HMRC has responsibility for the administration of PAYE and operates the system of Real Time Information earnings reporting by employers. It implemented a data validation mechanism in RTI, known as BACS hashing, which enables HMRC by reference to the BACS payment system to identify late and incorrect reporting by employers of RTI in real time at the point they report PAYE to HMRC and pay their employees.
1.4. This RTI data validation mechanism is universally available, is provided for in legislation and is supported by all commercial payroll software, so employers using the BACS Direct Credit payment network automatically submit RTI data to HMRC capable of validation by HMRC.
1.5. The use of the payment system to validate employer RTI reporting is powerful because actual payments to employees can be cross referenced to the corresponding RTI return made by their employer to HMRC, ensuring the accuracy of the employer’s return can be verified by reference to the relevant payment but also, for the UC in work claimant, the actual date their employer paid them can be verified.
1.6. The payment system provides RTI and HMRC with both the critical data values, pay date and net salary amount, which can be referenced to determine with precision which employers are failing in their RTI reporting obligations and to target compliance action accordingly against only those employers who warrant it. There is no alternative mechanism in UC or RTI’s design which can provide an absolutely verifiable data value against which the timeliness and accuracy of the employer’s RTI returns can be tested.
1.7. It is unclear what use HMRC has made of RTI’s automated data validation mechanism to inform its compliance regime interventions – but understandably it may have been reluctant before now to promote this best practice operation of PAYE (and use of the BACS Direct Credit payment system) to ensure small and medium sized employers avoided additional costs.
1.8. The use of the BACS hash relies on employers’ choice of payment method but as employers are increasingly at risk of challenge from their own employees under HMRC’s digital tax plans it is likely that they may wish to rely on the payment system to prove their compliance to their own employees, and HMRC, that their payroll and tax reporting conform to HMRC best practice.
2.1. Lord Freud’s evidence to the Committee acknowledged there is an employer RTI data error rate of some 5%. While 5% may not sound significant, a small percentage is a large absolute number: ICAEW estimates some 60m recurring RTI records in PAYE, captured by HMRC when payroll is run. Lord Freud explained that in the future the planned convergence of the tax system with the payment system may eliminate RTI data errors. However he did not explain that there is already a payments validation mechanism in RTI already used by DWP and HMRC.
2.2. The Chairman notably commented to Lord Freud at the Committee’s hearing (citing Margaret Thatcher as his authority) that the (first and) absolute principle of any data system is “Garbage in, garbage out”, which underscores the point that the outcomes and success of any data system can only be as good as the data inputs it captures.
2.3. It is a fundamental principle of data systems that they perform data validation therefore at the point data enters the system. This is on the basis that, as UC’s design clearly demonstrates, once data enters the system it is too late to remedy defective award calculations or the suspension of UC payments altogether, which the system will do automatically as a result of late or incorrect RTI data.
2.4. The BACS hash provides a simple validation mechanism by cross referencing salary payments with the corresponding line in the employer’s RTI return that reports their earnings in PAYE to HMRC. Each payment to an employee carries a unique, anonymous code that HMRC captures from the payment system to enable it to cross reference the code with the identical code also inserted by payroll software into the employer’s RTI return submitted to HMRC. Because employers do not and cannot know which of their employees may be directly enrolled in UC (either in their own right, or connected to a complex UC household claim of their partner) BACS hashing works by ensuring that all employee data is hashed by default. This means that validated RTI data is also available to HMRC to ensure the efficient administration of PAYE.
2.5. All UC credit claimants are allocated a personal claim date when they are enrolled in UC which is the date on which they will receive their monthly UC award payment. The claim date is personal to the claimant and is not aligned to their employers’ payroll cycle(s). For this reason the date employers report they have paid their employees in RTI, must for UC be the date the employee’s bank account is actually credited with their employment earnings. Either the late reporting of RTI or the reporting of an incorrect pay date by the employer can result in employment earnings being missed from the claimant’s monthly award calculation, with the result that they receive too much money one month and too little the next, greatly contributing to the difficulties claimants experience trying to manage their income and expenses, risking the build-up for further claimant debt to DWP.
2.6. The BACS hash mechanism implemented by HMRC, in conjunction with the UK payments infrastructure provider and schemes, allows for the real-time operation of hash matching so the timeliness of employer reporting and their obligation to report ‘on or before’ can be established for HMRC and DWP automatically. This ability to cross reference hashes in real time to determine the pay date is provided for as a configurable value in the hash reporting infrastructure available to HMRC.
2.7. HMRC chose the BACS Direct Credit payment network because it is the UK payment scheme that terminates over 90% of UK salary credits (payments).
2.8. Use of BACS Direct Credit to pay employees is not mandatory but the use of the hash is when paying this way. The hash is inserted automatically by payroll software so employers and payroll operators who pay by BACS will always have BACS hashes in their RTI data and payment instructions when they pay by BACS Direct Credit.
2.9. The HMRC data feed for hash cross referencing where an employer’s hashes are matched or not matched provides the basis for HMRC to automate notifications to employers and compliance activity by reference to HMRC’s RTI Generic Notification System (GNS). In effect hash matching activity may be used to generate automatically HMRC electronic communications to employers whose RTI reporting may not be compliant.
2.10. One of the difficulties of operating a digital data system at the scale of PAYE without default real time validation of the data is the challenge of identifying where the responsibility for data errors lies: with the employer or HMRC. The general view of the UK accountancy profession and the PAYE supply chain, as represented by ICAEW, seems to be that HMRC’s management of RTI data contributes to the administrative burden of employers. The significance of the payment system’s validation of RTI data at the point it enters DWP’s systems is that it enforces ownership of the responsibility for accurate data reporting on the employer (because HMRC sends RTI data unchanged to DWP for use in UC claim calculations). However given HMRC’s plans to digitise all personal and business tax administration, validation of PAYE data will undoubtedly benefit all RTI stakeholders including HMRC and employers, not just DWP, as VocaLink’s submission to the Treasury Select Committee of April 2016 made clear.
3.1. Lord Freud’s evidence that employer data error is a material consideration for UC makes clear how UC and the accuracy of claimants’ awards rely on the accuracy and timeliness of real time RTI earnings data.
3.2. The Committee should be aware that the payment system and HMRC’s RTI systems already provide for the validation of RTI data reporting by employers with an effective mechanism that allows employers to demonstrate to their employees and HMRC they are complying with their obligations to ensure the claimant’s UC payments are accurate. It is unclear to what degree employers are aware of or understand these safeguards. HMRC promoted the best practice use of BACS hashing to employers in December 2014, in its Employer Bulletin (Issue 51), although this guidance does not appear to have been repeated since the full national roll out of UC commenced.
3.3. The continued convergence of the payment and tax systems is set to continue (introduction of a new payments standard ISO20022 as one of the new Payments Systems Regulators Market Review remedies) although the payments system is almost certainly unable to offer additional data validation mechanisms before the planned roll out of UC is due to be completed in 2020-21.
3.4. That HMRC, to its credit, provided for an RTI data validation mechanism in the payments system is of real importance to UC. The extent to which HMRC makes use of the BACS validation mechanism in the administration of PAYE and extent to which they promote its use among employers to minimise the impacts and costs for all UC stakeholders of RTI data errors, is not known.
4.1. To ask DWP to explain how they use RTI data validation by the payments system to ensure that UC claims are correctly calculated and paid automatically without error, despite the acknowledged RTI error rate.
4.2. That the Committee may wish to understand what use HMRC currently makes of the BACS hash validation mechanism and the payment system to assist its RTI compliance activity.
4.3. To consider whether employers understand the implications their failure to report timely accurate RTI data may have on their employees, who may be in UC or have a household member in UC, and how they might demonstrate to their employees they are operating RTI to safeguard their employees’ and connected households’ UC entitlements.
4.4. To ask HMRC to explain their use of the hash and any further plans to communicate its importance to employers as UC claimant volumes increase and whether their communication plan is aligned with DWP’s own as the number of UC claimants in work scales up.
4.5. To invite HMRC to explain how employer tax reporting will become further aligned to the payments system in the future as the Payment Systems Regulator implements the adoption of more extensive and sophisticated payments validation of tax data from 2020 onwards.
March 2017
Additional References