E-invoicing, and why the UK is moving

A PDF invoice is a picture of an invoice. Somebody has to read it and type its contents into something else, and every year a percentage of those retypings are wrong. An e-invoice is the opposite: structured data, in a format the receiving system can act on without a human in the middle, checked against published rules before it is sent.

That distinction is the whole subject. Not “electronic” as in emailed. Not “digital” as in scanned. A document that a machine has to accept, and that can be rejected for reasons written down in advance.

What it means for the code you write

If you build invoicing into software, three things change.

The invoice becomes a document with a specification. Today you decide what an invoice looks like. Under a mandate, a published standard decides: which fields exist, what they mean, which ones are required, and how the arithmetic has to add up. Your data model still belongs to you, but what leaves your system has to satisfy someone else’s rules.

You find out before you send. Validation stops being something the recipient does by complaining. The rules are public and machine-readable, so a document can be checked in CI, on save, or at the moment a user clicks send — and a document that fails is a bug you can fix, not an email thread.

Sending becomes addressing. An e-invoice does not go to an email address. It goes to a participant identifier on a network, and the network has to be asked where that participant is and what they accept. That is the four-corner model, and it is the next chapter.

Where the UK actually stands

The UK’s mandate is real and the details are not published yet. That combination generates a lot of confident writing that is worth being careful about, so here is what is actually confirmed, in an official source:

• E-invoicing becomes mandatory for all VAT invoices from 2029. It covers B2B and B2G. B2C is excluded, and businesses that are not VAT-registered are outside it. No thresholds have been published.
• The model is decentralised, and real-time reporting to HMRC will not be implemented in 2029. A five-corner model, where a copy goes to the tax authority as it is sent, could follow later.
• Peppol is the core interoperability network for UK e-invoicing, named in the Tax Update of 23 June 2026.
• The roadmap is published at the Budget on 28 October 2026.

What is not published yet: the UK data standard, whether service providers will need accreditation, the phasing, and how any of it will be enforced. You will read that the start date is 1 April 2029, or that large businesses go first and smaller ones follow in 2030. Both are plausible and neither is official — they come from vendors, not from HMRC.

This guide keeps that distinction everywhere, and chapter 8 is nothing but the claims and their sources. It is updated on Budget day.

Why it is not a 2029 problem

Three years is long enough to ignore something. Two things make that a mistake.

Your neighbours are already live. Belgium’s B2B mandate started on 1 January 2026 and has been issuing fines since April. Germany has required businesses to receive e-invoices since 2025, with sending phased in from 2027. France went live in September 2026 on its own approved-platform model. Ireland starts with large companies in late 2028. The EU’s ViDA package brings intra-EU digital reporting from July 2030. If your software has customers trading into any of those markets, the deadline already passed.

The work is not the deadline. Producing a document that satisfies around eleven hundred validation rules is not a switch you flip in the last quarter. It touches your data model — tax categories, party identifiers, payment terms, line-level detail — and those are exactly the places where software accumulates shortcuts. Finding out in 2028 which of your shortcuts are illegal is worse than finding out now.

What is worth doing now

Not much, and that is the point. You do not need an Access Point contract, a compliance programme or a rewrite. You need three things:

1. Know what identifies your customers on the network. For a UK business that is usually its VAT number, under a scheme code. That is chapter 3.
2. Be able to produce a valid document from your own data. Not send it, just produce it and prove it passes. If your data cannot express what the standard requires, that is the finding that matters, and it is cheaper to learn today.
3. Put validation somewhere automatic. A test that fails when an invoice would be rejected is worth more than any amount of reading about the standard.

The rest — Access Points, AS4, the network’s plumbing — is someone else’s job, and the next chapter explains why.