HMRC’s decision to abandon a collaborative agreement with tax software developers on the eve of Making Tax Digital prompted industry association BASDA to question the department’s commitment to consultation and co-operation.
While the terms “do not create a legal relationship between HMRC and any software developer”, HMRC said, “We reserve the right to remove your access to the Developer Hub and its APIs temporarily or permanently.”
New fraud prevention requirements to submit audit data headers were added as part of the document to help the department protect confidential user data. These were enacted from 1 April 2019 in the Delivery of Tax Information through Software (Ancillary Metadata) Regulations 2019 statutory instrument.
An HMRC spokesperson explained: “We are legally required to keep taxpayer data safe and secure. HMRC has requirements and systems in place so we can detect fraud and protect customer data for all those using MTD. The new regulations provide a secure lawful basis for developers to process customer data.”
AccountingWEB contributor and AAT Making Tax Digital adviser Brian Palmer explained that tax rules generally carry penalties, which necessitated the secondary statue. Since it was enacted, HMRC has been promoting a “trust us” message and promising that it won’t be so bad.
“Industry and professional bodies are looking for clarity – just as they are with the MTD for VAT soft landing period,” Palmer said.
BASDA worked extensively with HMRC on the original collaboration document, published in July 2017. “The BASDA agenda is, ‘Put yourselves in the eyes of the customer. They need to have absolute confidence that systems are fully fit for purpose,’” said Hart.
“We worked really hard to ensure that HMRC is making the best-informed decisions it can by staying triangulated with accountancy bodies and software houses. This [MTD penalties] initiative is counter to that tendency.”
Given HMRC’s dependence on the industry, the software trade body is concerned the department is dictating terms that put the onus on developers, but few commitments on HMRC aside from notification of API changes and a guaranteed testing environment.
“We’re sad to see this unexplained change brought in without consultation. The partnership approach was working as far as the software side could see. We are keen to see HMRC engage with the wider industry and not just certain developers,” said Hart.
Some developers are confused about why HMRC brought in penalties when the department’s systems are being programmed to reject messages without headers. “Why force us to code a security feature that will be redundant in six months?” asked John Whelan from MyDigitalAccounts and chair of BASDA’s MTD special interest group.
“There must be a reason why this was rushed in at the last minute, but we haven’t been given a context.”
The header guidance in HMRC’s Developer Hub explains that blank header fields will be accepted, but these have been rejected when test sample headers have been sent to HMRC for approval. If HMRC is not clear about what the security requirements are, how can any developer comply, Whelan asked.
This raises questions as to how so many new software providers have been able to meet these new requirements in such a short space of time: have all of the 290+ programs on HMRC’s MTD for VAT software list met the requirements?
Executives at other software houses, including IRIS, said things like this were part and parcel of doing business with HMRC.
TaxCalc reported that it has complied with the header requirements, but viewed them as an unwelcome addition to the workload at a very late stage, “especially as a lot of the detail was still changing as the deadline approached”.
“The teams we interact with at the coal face remain collaborative and constructive in helping us,” Guest said.
In his view, the sheer volume of developers pitching in with new MTD bridging solutions may have put a strain on HMRC’s resources and prompted the new approach. “HMRC may be struggling to interact individually with so many and want some sanctions available as a last resort,” Guest suggested.
Like other tax software developers, Sage’s vice president of product management, compliance and Brexit Adam Prince would have preferred more time to implement the transmission header changes, but could see the reasons for HMRC’s approach. “Sage completely supports HMRC’s need to fairly tax people and combat fraud, and all our MTD for VAT products now include the required metadata,” he said.
Metadata showing the user’s IP address, operating system and similar details are classified as personal information under GDPR, so HMRC needed legislation to collect the anti-fraud information, Prince explained.
Recommendations about the anti-fraud headers were published on HMRC’s Developer Hub in 2017 and the requirements were finalised at the end of 2018. According to Prince, HMRC needed to strike a balance between keeping its tools below the radar and publicising the enabling legislation.
There were other more significant risks for developers than HMRC’s penalty, he added. The statutory instrument makes developers that build MTD for VAT filing software the data controller, putting them under the GDPR enforcement regime overseen by the Information Commissioner’s Office.
“That moves many of the penalties for personal data breaches to developers. The potential loss of API access or penalties under GDPR are much bigger than £3,000,” said Prince.