Almost every discussion of electronic invoicing evidence starts in the wrong place, with cryptography. The requirement it is trying to satisfy contains no cryptography at all.

What the VAT Directive requires is that the authenticity of the origin of an invoice, the integrity of its content and its legibility are assured from the point of issue until the end of the retention period. It then says something that a great many vendors would prefer their readers skipped: how that assurance is achieved is for the taxable person to determine. A qualified electronic signature is named as one way. An electronic data interchange arrangement is named as another. And any business control creating a reliable audit trail between an invoice and the supply it relates to is expressly sufficient.

So this is not a technology requirement with a legal wrapper. It is an evidential requirement with a technology option, and treating the option as the requirement is how organisations end up paying for cryptographic infrastructure that proves something nobody was going to dispute while leaving the thing that will actually be disputed entirely unaddressed.

Three properties that are routinely confused

The three are not degrees of the same thing. They assert different facts, they are challenged in different circumstances, and evidence that establishes one may say nothing about the others.

Authenticity of origin is an assertion about identity: this invoice came from the supplier it names. The challenge it answers is a claim that the document is not yours, or that somebody else issued it in your name. Note what it does not assert — nothing about whether the content is accurate, and nothing about whether the supply happened.

Integrity of content is an assertion about change: the particulars required on the invoice have not been altered since issue. The challenge it answers is a claim that a figure, a date or a description is not what it was. Note again what it does not assert. Integrity of a wrong invoice is perfectly achievable, and demonstrating it proves only that the error is original.

Legibility is an assertion about access: a human being can read the invoice content, on request, for as long as it must be kept. The challenge it answers is the most mundane and the most likely — an auditor asking to see a document from six years ago, and being handed something nothing in the building can open.

The distinction that saves the most money

Authenticity and integrity are about the document. Legibility is about the environment the document has to survive in. The first two are addressed by a decision made once at implementation. The third is a condition that has to keep being true while the world changes around it, which is why it is the one that fails.

The routes, and what each actually costs

The three properties: what each asserts, what demonstrates it, and how it is challenged
PropertyWhat it assertsEvidence that demonstrates itHow the challenge arrives
Authenticity of originThe named supplier issued this documentA qualified seal, a controlled exchange arrangement, or a trail linking the document to an order and a delivery you can evidenceA denial that the invoice originated with you, or a disputed deduction on the buyer's side
Integrity of contentThe required particulars are unchanged since issueA validated signature or seal, platform-held transmission records, or an unbroken control trail with the original preservedAn assertion that a figure or date differs from what was agreed
LegibilityThe content can be read on request, throughout retentionA demonstrable rendering path, preserved alongside the document and its schemaAn auditor asks to see it and the rendering fails

The route chosen determines which column you are relying on, and the choice is genuinely open.

Sealing takes the assertion out of your hands and puts it in a certificate. That is attractive and it has a cost profile people underestimate: certificates expire, validation has to remain possible for the whole retention period, and a seal that cannot be validated in year seven has consumed budget and proved nothing. The tiers, and what changes between them, are worked through in electronic signatures and seals under eIDAS.

The business control route costs nothing to adopt and a great deal to evidence. It is the route most businesses are already on, usually without having written that down, which is the flaw. A control that is operated diligently and never documented protects the business operationally and not at all when somebody asks it to be demonstrated. What such a trail has to show, and what documenting it involves, is set out in the business control route.

And where a national mandate routes documents through a platform, part of the answer is produced for you. The platform's records establish what was submitted and when, which is a strong piece of both authenticity and integrity evidence — for the transactions it carries, and only for those.

What the network architecture contributes

The route a document takes changes who holds the evidence, which is a separate question from what the evidence proves.

In a four-corner arrangement the evidence is distributed. Your provider holds records of what it accepted from you and passed on; the receiving provider holds records of what it delivered. That is a chain, and chains have joins. The joins are contractual, and whether the records at each end are retained for as long as your retention obligation lasts is a question about a contract rather than about cryptography.

In a clearance arrangement the evidence is centralised. The administration's platform holds a record of what was submitted, what it validated and what it delivered, and that record is authoritative in a way that no commercial provider's log is. The difference between the two architectures is usually discussed as a question about transmission. It is at least as much a question about who will still hold the proof in year eight.

The chain of evidence that has to hold from issue to production on request, across a retention period measured in years.
The chain of evidence that has to hold from issue to production on request, across a retention period measured in years.

Legibility is a preservation problem

Here is where the field's collective attention runs out, and it is the part that will cost the most.

An invoice that is a structured file is legible only if something can render its content in a human-readable form. That capability is not a property of the file. It is a property of an environment: a stylesheet, a viewer, an application that understands the syntax version the file was written in.

Retention periods across Europe run into years — long enough for a syntax version to fall out of general use, for an application to be discontinued, and for the people who knew how it worked to leave. A file that is perfectly valid against a schema nobody still implements is not legible in any sense an auditor cares about. The obligation is not that the bytes survive. It is that the invoice can be read.

There are two honest responses to that, and both need deciding early rather than discovered late.

The first is to preserve the rendering capability alongside the document — the schema, the stylesheet or the rendering route, treated as part of the archive rather than as infrastructure. That is why what has to be kept alongside the file is a longer list than most projects assume.

The second is to keep a rendered representation as well as the structured one, which is exactly the argument behind hybrid formats that carry both a readable document and the structured data. It is not an elegant answer. It is a durable one, and durability is the requirement.

The migration nobody documents

An archive migration — a change of provider, a move to new storage, a format conversion — is an integrity event. Content passes through a process that could alter it, and afterwards the only assurance that it did not is whatever record was kept of the migration. Businesses that document the migration are fine. Businesses that treat it as routine infrastructure work have a gap in the chain precisely where the chain is weakest.

The structured document does not settle it

There is a comfortable assumption that a structured invoice, validated against the European semantic model, is somehow self-evidencing. It is not, and the reason is worth stating plainly: validation is a statement about conformance to a model, not about origin, not about subsequent alteration, and not about whether the file can still be read.

What structure does contribute is different and genuinely useful. It makes the audit trail machine-checkable. When the invoice, the order, the delivery record and the ledger entry all carry the same identifiers in known fields, linking them is a query rather than a filing exercise. That strengthens the business control route considerably — but it strengthens it by making the control easier to operate and to demonstrate, not by removing the need for one.

How the mandates change the calculation

National mandates rarely restate these obligations. They sit on top of them and quietly remove options.

Where every domestic business-to-business invoice must pass through a platform, the platform's record becomes the primary evidence for those transactions whether or not you chose it. Where a national rule requires a particular sealing arrangement, the choice the directive left you is gone for that jurisdiction. And where a mandate applies to some of your transactions and not others — which is the normal case during a phased rollout — you are operating two evidential regimes at once, and the one that will fail is the one nobody assigned an owner to. Which mandate catches which transaction, and from when, is the subject of the national mandates and their dates.

Data protection pulls the other way

One last complication, because it is the one that surprises finance teams most.

The tax rule sets a floor: keep the invoice, with its assurance, for the retention period. Data protection law sets a ceiling: do not keep personal data longer than the purpose requires. An invoice contains personal data — always, if the customer is a sole trader, and usually anyway through contact names and transmission metadata.

Those two obligations are reconcilable, and reconciling them is a documentation exercise rather than a dilemma: the legal retention obligation is the purpose, and it justifies keeping the data for exactly as long as it lasts and no longer. What it does not justify is keeping everything adjacent to the invoice for the same period simply because it was convenient to store it together. Where the boundary falls is worked through in invoice data as personal data, and how long the floor actually is depends on rules that vary by Member State and by document, examined in retention periods across Europe.

What to actually do

Decide the route deliberately, per jurisdiction, and write the decision down. Then write down how it is operated, and by whom, and how you would demonstrate it to somebody who was not there.

That last document is the whole thing. Not the certificate, not the platform, not the archive vendor's compliance statement. A page that says: this is how we assure these three properties, this is the evidence, this is who checks it and how often. Businesses that have that page find audits dull. Businesses that do not find that their evidence was real all along and entirely unprovable, which in an assessment is the same as not having had it.