Digital infrastructure: building shared foundations, not separate initiatives

The diagnosis

Four separate systems for one import

Imagine a lorry bringing food from Calais to a UK importer. Before it arrives, the haulier and the importer’s customs agent must between them deal with four separate UK government systems for this one consignment: 

• a safety and security declaration; 
• a customs declaration; 
• a goods movement reference that allows the lorry to board the ferry/shuttle; and 
• a pre-notification of the food to the Department for Environment, Food & Rural Affairs (Defra) on yet another system, largely re-keying data already on the customs declaration. 

If the load is selected for inspection, the lorry is sent to the Sevington Inland Border Facility near Ashford. There, HMRC deals with the declaration and Border Force with the goods, at adjacent desks, on systems that do not talk to each other, and the agent cannot see where the consignment has got to without emailing both and waiting for a reply. One ICAEW member, a customs agent, recently had a single consignment held under customs control for 36 hours. When the facility is crowded, a lorry can be released without its load, and the agent must then provide details of whichever vehicle is coming to collect the goods once they are cleared. 

None of this is a story about one facility having a bad day. It is what happens when four systems holding overlapping information about the same consignment are each built, funded and maintained separately, with no shared layer beneath them and no one responsible for making them work together. The same pattern recurs wherever the tax system meets another part of government, another organisation or a taxpayer’s own systems: build first, connect later and hope the joins hold.

This chapter argues that the joins are now the main problem. The UK is digitalising its tax system initiative by initiative – identity, filing, e-invoicing, artificial intelligence (AI) – without a published blueprint for how any of it fits together. That is primarily a failure of governance rather than of technology: no one is accountable for the space between the digital systems. 

The chapter makes three connected arguments:

• First, the tax system needs a common architecture for its data and identity, published and applied to every future initiative. It should set out who holds what data and how it should move, so that taxpayers provide data only once, third-party data can be challenged, and everyone who needs particular data can access it. 
• Second, that architecture cannot stop at HMRC’s boundary, because much of the data the tax system depends on is held elsewhere. 
• Third, when government requires taxpayers to interact with it digitally, it takes on obligations of its own: to the users of software it has in effect mandated, to agents acting on behalf of taxpayers and to those who cannot easily go digital.

This chapter is primarily concerned with the third area and its effect on taxpayers and their agents. HMRC’s internal systems are the subject of the earlier administration pillar in this series, which covers how HMRC governs and uses the data it holds. 

HMRC remains the most important single actor in the tax system’s digital infrastructure, and much of this chapter is about it, but it is not the only one. Taxpayers and their agents also have to deal with Companies House, HM Land Registry, the Department for Work and Pensions, Defra, Border Force, the devolved tax authorities and others, often crossing between several systems in a single transaction. A chapter confined to HMRC would therefore miss much of the friction taxpayers actually experience.

Why this cannot wait

Several major changes now under way rely on the same foundations: how taxpayers are identified, how they access services securely, how agents act on their behalf and how data moves between systems. They include:

• Making Tax Digital (MTD) for income tax became mandatory from 6 April 2026 for sole traders and landlords with qualifying income of more than £50,000, with lower thresholds following in April 2027 and April 2028.
• GOV.UK One Login began replacing Government Gateway for new HMRC users in February 2026, with existing users to be moved across gradually and arrangements for agents and organisations still to be settled.
• Mandatory e-invoicing for business-to-business and business-to-government VAT invoices takes effect from April 2029, with a detailed implementation roadmap published at budget 2026. 
• And AI is arriving on both sides at once: HMRC is beginning to use it to review what taxpayers provide, while taxpayers, agents and software providers are beginning to use it to prepare what they submit.

All of these developments may make sense on their own terms. The risk is that each is designed and delivered as though it were the only thing happening. If the question of which identifier is authoritative for which purpose is settled only after One Login has replaced Government Gateway as the way into HMRC’s services, today’s inconsistencies will be locked in for years; if e-invoicing standards are set without reference to the data HMRC already collects through MTD and VAT returns, businesses will build the same plumbing twice. AI sharpens the risk: an AI tool is only as good as the data it is given, so what data the tax system holds, where it comes from and how reliably it can be linked to the right taxpayer now matter more, not less. 

The prize for getting this right is considerable. With the right data, in the right format, reliably linked to the right taxpayer, HMRC could help taxpayers get things right first time by pre-populating returns and flagging likely errors before filing. It could also target its enquiries more precisely, asking specific questions of those who need to answer them and leaving compliant taxpayers alone.

Infrastructure beyond HMRC

Much of the data the tax system depends on is produced by bodies HMRC does not control – the Office for National Statistics (ONS), Companies House, HM Land Registry, banks, online platforms and overseas tax authorities – and a tax authority can be no more accurate than the data it is given. Better information at Companies House about who owns and controls UK businesses would also help HMRC’s compliance work, particularly in matching entities across platforms to establish whether an online seller should be registered for VAT.

Digitalisation does not fix poor data; it moves it faster. High-quality data matters all the more as HMRC moves towards pre-populating returns. A published architecture should therefore include data quality standards for the core records the tax system depends on, covering accuracy, timeliness, transparency about the source of data, and a named owner responsible for correcting errors. It should also set out how taxpayers, agents and their software can securely access, use and challenge that data. 

The solution: five design principles

Our recommendation has two parts. First, government should adopt a set of design principles for the tax system’s digital infrastructure, meaning every system through which taxpayers and agents deal with the tax system, whichever body runs it. Second, it should establish a mechanism for holding future initiatives to those principles. The five principles below are tests any new digital initiative should be able to pass.

1. One identity

The tax system has no consistent way to identify businesses. One UK company may be known to the state by its Companies House registration number, its Unique Taxpayer Reference (UTR), its VAT registration number, its PAYE reference or its Economic Operators Registration and Identification (EORI) number, while an unincorporated business has no Companies House number, and which of the other identifiers it holds depends on what it does. Banks and online platforms hold their own records, with no reliable way to link them to the records held by the state.

A single business identifier, or a robust cross-government framework linking existing ones, used consistently by HMRC, Companies House, banks and online platforms, could do more to resolve some of today’s hardest compliance problems – businesses split artificially, or trading across several platforms, to stay below the VAT threshold or to retain small business rate relief; records that cannot be matched to the right entity; opaque ownership – than any new enforcement power aimed at taxpayers. It would also simplify life for the great majority of businesses that are trying to comply. No single department can build this alone, which is why it, like the quality of the data the tax system relies on more generally, needs to be treated as shared infrastructure even though most of the bodies involved sit outside HMRC’s remit.

The business identifier problem has a counterpart for individuals. The tax system has no single, authoritative answer to a basic question: who is this? A taxpayer may be identified by a UTR, a National Insurance number or both, each created for a different purpose, and may reach HMRC’s services through Government Gateway or, increasingly, GOV.UK One Login. There is no published rule for how any of these relate to one another. Signing a client up for MTD, for example, requires their National Insurance number and date of birth, while accessing their MTD record requires agents to identify the same client by their UTR.

Someone new to the UK tax system, including many non-residents who may have neither a National Insurance number nor a UTR, faces a chicken-and-egg problem: they cannot easily be registered without an identifier, an agent cannot be authorised to act for them until they are registered, and registration is precisely what the agent is trying to help with. 

This does not necessarily require a new national identity scheme, but it does require three things: 

• First, every person and business the tax system deals with, including non-residents and new businesses, should be able to obtain an authoritative identifier promptly and digitally, directly or through an agent. 
• Second, government should settle and publish which identifier is authoritative for which purpose, for individuals, agents and businesses. 
• Third, it should settle and modernise how agents and others are authorised to act on someone else’s behalf so that a taxpayer who chooses to use an agent can put that in place safely and efficiently.   

2. Once, and only what is needed

Estonia has written the once-only principle into law: its Public Information Act requires data in state databases to be collected on a once-only basis and prohibits separate databases collecting the same data. In effect, the state should not ask a citizen for information it already holds. Applied to UK tax and customs, it would rule out, for example, the re-keying customs agents currently face across separate systems for customs declarations, vehicle movements and food and plant notifications.

The principle has a less comfortable second half, to which we give equal weight: government should not ask for data it does not need. The tax system is increasingly used to collect information with no direct bearing on anyone’s tax liability. Collecting data that is not needed adds cost and burden for HMRC as well as taxpayers, and sits uneasily with the data minimisation principle in data protection law. The data fields originally proposed for the payrolling of benefits in kind were reduced after challenge by employers and stakeholders. A proposal to require employers to report employees’ hours worked through PAYE real time information returns, intended in part to improve labour market statistics, was withdrawn in January 2025 after representations, including ours, highlighted the burden and questioned whether it was a proper use of PAYE powers as it had no bearing on the calculation of tax.

We do not argue that HMRC should be prevented from collecting data that supports legitimate compliance work. But every new data requirement should be published with a clear statement of its purpose and why it cannot be met from data that government already holds. Government should recognise that pushing data collection onto businesses transfers the cost of compliance work from the state to the taxpayer. There is a fair bargain here: a government that asks only for what it needs, and explains why, is in a much stronger position to ask for the data it does need and to expect it to be provided promptly and accurately.

3. Agent parity by design

Digital services are typically designed around what an individual taxpayer needs, with agent access added later, if at all. The result is a system with gates an individual can walk through and information they can see, that their agent cannot, and the gaps are often greatest in routine compliance tasks agents carry out every day. Many individuals and most smaller businesses choose to deal with HMRC through an agent, so a service that works for the taxpayer but not the agent does not, in practice, work. 

The principle we propose is simple: if a client can do or see something digitally, their agent must be able to do or see it too, from the day the service launches. That does not mean every agent sees everything: a taxpayer with more than one agent, such as one for payroll and another for VAT, should be able to give each access to what it needs for its work, and no more. An earlier pillar of this series calls for agent parity in HMRC’s own digital services; this chapter extends it to every government body whose services taxpayers and their agents rely on.

4. Digital obligations require digital accountability

Once government requires taxpayers to interact through software, the quality of that software becomes part of the tax system’s own infrastructure. HMRC’s API-first approach, which opens its systems to commercial software rather than HMRC building every product itself, is generally well regarded, at least for new services.

However, the API-first approach has a consequence. For some services, including MTD, HMRC has chosen not to provide its own free tool, leaving taxpayers reliant on commercial software. Where HMRC itself provides a service, there is no case for it to intervene in the commercial software market. But where it has deliberately withdrawn from providing a tool, it acquires a responsibility to set and assure standards for the products taxpayers are, in effect, required to use. At present, the checks a product must pass to be recognised by HMRC establish that it can connect and submit correctly formatted data, not whether the figures it submits are right. Members have described products from both large and small providers that have submitted incorrect figures, in one case because a legislative change had been missed entirely, with nothing to catch the error before it reached HMRC.

HMRC has begun this work: its strategic approach to third party software, published in March 2026, is to be followed by enhanced software standards and a delivery roadmap. In our view, those standards should cover the accuracy and security of what a product submits as well as its connectivity, supported by a practical registration process and a test environment, with realistic test data, that mirrors live systems closely enough for developers to rely on it. The aim is not to deliver an HMRC guarantee of commercial software but a common standard everyone can work to and hold products to account against. Where responsibility lies when software gets it wrong, between HMRC, providers, agents and taxpayers, needs a fresh look as part of this work.

An API-first approach also needs to go further. As more of the data HMRC needs already exists in accounting platforms, payroll software, bank feeds and, increasingly, invoices exchanged directly between businesses, the question becomes how that data is best exchanged. The answer should be agreed with those who hold the data, rather than HMRC imposing a bespoke format or each provider going its own way. Where HMRC defines its own format in isolation, it recreates the duplication of processes that this chapter describes. The aim should be to allow innovation and efficiency while maintaining the security of taxpayer data, providing secure routes for what agents and software providers legitimately need so that they do not have to work around the system.

Mandating digital also carries a vital obligation: workable exemptions for those who are digitally excluded and genuine investment in digital capability for those who lack it. A digital-by-default tax system without that support is not more efficient; it simply works less well for the people who most need it.

5. Trust in an automated system

As returns come to be prepared, checked or filed with the help of software and, increasingly, AI, a taxpayer’s ability to stand behind what has been submitted in their name depends on being able to see and understand what was done. Members report that some AI tools can now turn bank statements into a set of accounts with no easily understandable audit trail showing how each transaction was treated, so neither the taxpayer nor their agent can meaningfully check the output, let alone reconstruct it if HMRC later asks a question. A taxpayer who cannot check a figure is not well placed to declare that it is correct. Pre-population raises similar issues: as more figures arrive already filled in, the taxpayer and agent’s role shifts from compiling a return to checking it, which requires transparency about where each figure came from and an ability to challenge it.

HMRC is already grappling with this. Its guidelines for developers using generative AI, published in January 2026, expect products to be transparent about their source data and to support human oversight, while reminding users that responsibility for the return stays with them. Members have also described cases where HMRC asked a business to retain the inputs to and outputs from an AI tool and any subsequent human amendments, so that an audit trail exists if figures are later questioned. Both requests are sensible, but they are expectations and case-by-case requests rather than standards that developers must build to and taxpayers can rely on.

We recommend that HMRC, working with developers, agents and taxpayers, and building on its software standards work, publish a framework for the assurance it expects around AI-assisted preparation and filing. It should set clear standards for developers, including the audit trail a product must be able to produce; what a taxpayer or agent must be able to verify before signing a return; and how responsibility is allocated between taxpayer, agent and software or AI provider when something goes wrong. In practice, an adequate trail would show which source records produced which figure, what treatment the tool applied and which entries a human subsequently changed, retained for as long as HMRC may enquire into the return.

From diagnosis to delivery

A single conversation, then a single map

ICAEW’s central recommendation is that government publish a common architecture for the tax system’s data and identity and hold every new initiative to it. That architecture has three parts: a set of principles, a named owner responsible for it, and a map of what data exists, who holds it and how it flows. Without that, the other recommendations in this chapter risk being pursued as separate projects, in exactly the way MTD, One Login and e-invoicing have been to date.

The principles should be agreed by convening a roundtable of the accounting and tax profession, the software industry, business representatives and groups representing taxpayers and citizens. The roundtable should build on the five principles set out above and on the premise that government, not the taxpayer, is responsible for making the system work. The same process should decide who owns the architecture and holds future initiatives to it. We do not prescribe which body that should be, but a blueprint with no owner leaves no-one accountable and risks going the way of earlier roadmaps.

The map would not be another transformation roadmap, but a specification of every party in the system (taxpayer, agent, employer, software provider, HMRC, banks and other public bodies), how they interact and what data passes between them. It would need to be comprehensive, covering data that has nothing to do with money: the weights, emissions and material compositions that increasingly determine environmental tax liabilities, and the property data on which any council tax revaluation would depend (England still uses 1991 values). Future reforms of how incomes, transactions or property are taxed will be built on data infrastructure that may not yet exist, so the map should be a living document, updated as that infrastructure develops.

Government is not starting from nothing. HMRC already holds data on tens of millions of individuals and businesses – the first pillar of this series calls for it to build a comprehensive catalogue of that data – and cross-government API and data standards have existed for several years. What has not yet been published is a model others can design against, covering the relationships that cause the most friction, such as agent to client, business to individual and importer to declaration, and applied to new and legacy systems alike.

Where this fits

Some practitioners argue for a more radical starting point: a moratorium on the current rules, an agreed opening position for every taxpayer and a clean slate from which to build a digital tax system. While a clean slate is a laudable idea, we do not think that it is realistic given the questions of fairness and transition it would raise. But the frustration behind it is real: digital transformation built on rules designed for a paper-based system will always be constrained by those rules, however good the technology on top. Our answer is to map what exists, publish the map and require what comes next to fit it, while treating each reform of the underlying rules as an opportunity to design them for a digital system.

The pillar papers in this series ask, one institution at a time, whether the foundations exist to deliver the kind of tax system the revised ten tenets describe. For digital infrastructure, the foundations are being laid, but initiative by initiative and without an agreed plan for how they fit together. We are not calling on government to build yet more infrastructure. We are calling on it to publish how what it is building fits together, to connect it and to make someone accountable for reviewing, improving and adapting it as technology advances. The alternative is to keep digitalising the tax system one initiative at a time, leaving gaps that are rarely fixed because the time and money needed to join them have run out.