Software body urges HMRC to renew collaboration

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.

Terms of use

The terms of use set down the expectations for developers building software and services that connect to application programming interfaces (APIs) hosted on the HMRC Developer Hub.

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.”

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.”

The terms of use were updated in December to cover the user audit data requirement and the statutory instrument gives developers a lawful basis of processing personal data under GDPR “where the processing is necessary for you to comply with the law”, HMRC explained.

According to BASDA’s chairman Kevin Hart, however, the unilateral switch from a non-binding terms of collaboration document to the more licence-like “terms of use” indicates a break with the partnership culture that the trade body has worked hard to foster. The introduction of a £3,000 penalty for developers that fail to support the data transmission requirement adds to that impression.

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.”

Dictating terms

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?

Other sanctions

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”.

TaxCalc chief operating officer Simon Guest commented: “Luckily we have the capacity to handle it but maybe some smaller suppliers could struggle.” The shift to the new terms of use might indicate a more uncompromising approach at policy level, but has had no impact as yet.

“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.

“In the current circumstances, the statutory instrument outlining the terms of use was the best place to do that. They’ve been very explicit and provided a dedicated page to explain it,” Prince said.

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.

About John Stokdyk

AccountingWEB’s Head of Insight has been with the site since 1999 and likes to spend his time studying accountants’ technology habits. When not nerding out, you can find him exploring obscure indie music and searching for the perfect organic sourdough loaf from his base in Brighton, UK.

The software houses should just say "We won't play as you have changed the rules of the game." Where does HMRC go then?

Perhaps they would just say " Sugar! Oh well we can always stay as we are." Or they could stamp their feet and complain to the PM who would dash to Brussells to get instruction and then do nothing. Actually it would be nice to watch but I suppose it is too much to hope for.

There must be a subtle way to make HMRC squirm but they seem to be so immune to reason that I don't suppose they would notice. Just like the government which is run by Civil Servants these days it seems. Don't know why we bother with Politicians.

I honestly think HMRC are heading for a melt down. Software companies should now collaborate with Accountants who are left holding the baby on this one.
When I rang HMRC yesterday an announcement said - MTD if only for VAT registered business entities with T/o above £85000 and goes on to infer you should call the Software company not HMRC. If we all are aware of MTD why put the announcement on ! Coffee break .

What a load of whiny sanctimonious hogwash you lot are spouting. If 10 software developers rebelled and put no MTD support into their software, you'd all flock to use them instead of the ones that did? Well, no of course not. Don't be dumb. They do it, as they do everything, because they have no choice. HMRC is a closed shop monopoly. If software houses could develop software for a different UK tax collector then I'm sure they'd love to. They can't, so they are stuck picking up the mess and trying to make it smell as nice as possible before exposing us to it.

As a developer of MTD for VAT bridging software, I'm wondering what all the fuss is about. HMRC laid out its requirements and rules and provided an API and test environment for developers to use.

Sure, there have been issues along the development path, but no more than you would encounter during the development of any software product.

HMRC were the client for us. They stipulated what they wanted and we did the graft to produce what they wanted. And despite rules and requirements being changed by HMRC along the way (which is no different to what we get from any client), we came up with the goods.
Compared to many software projects I have been involved in, producing our solution was a breeze.

In the article, John Whelan asks: “Why force us to code a security feature that will be redundant in six months?”
Here's the answer: Because HMRC are the client and if they want you to code a security feature then you code that security feature - even if it will be redundant in six months. If you don't like or agree with what the "client" wants then don't get involved in developing a solution for them. Leave it to the developers who will.

As for the comment: "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?".

Wait! What? The implementation of security headers is well documented by HMRC and implementation for us took a matter of hours. If a developer struggled to implement them in "such a short space of time", then they need to reevaluate their career choice.

I hope this reply isn't seen as a stab at the competition, but I feel Making Tax Digital has been been wrongly perceived as complicated by developers and end-users alike. Remember, what HMRC asked for was a mechanism to get 9 VAT figures from a client's machine to their system (with a few bells and whistles chucked in for good measure). A task, that, in my opinion, doesn't warrant the panic and concerns we are witnessing today.