HMRC e-invoices need original-message reconstruction

Define the original message before choosing an archive

HMRC's VAT Notice 700/63 says a business using electronic VAT invoices must ensure authenticity of origin, integrity of content, and legibility. In section 5.2, the notice calls for invoice data to be recreated as at its original transmission or receipt and presented in a readable form. That is a more specific review question than whether a vendor can open a current PDF or display a current ERP invoice row. The taxpayer should be able to distinguish the message sent or received at the time from later conversions, enrichment, corrections, and accounting interpretations. This article interprets the public HMRC guidance; it does not determine a taxpayer's compliance.

A reconstruction record should retain the original message or faithful preserved representation, invoice identifier and version, sender and recipient identities, transmission or receipt timestamp and channel, message format and schema version where relevant, content hash or equivalent integrity evidence if used, validation response, attachments, and the route to readable presentation. Record any transformation into an ERP, network, PDF, or reporting format as a separate event with its mapping version, date, source object, target object, and exception. The control is to retrieve both the original and the derived record without mistaking the latter for the former.

Test origin and integrity across the whole exchange

The notice describes multiple ways to support authenticity and integrity: an electronic signature, an EDI arrangement, business controls that connect invoice and supply, or other satisfactory controls. It does not say an HTTPS connection, XML file, signature badge, or network acceptance alone completes every obligation. A buyer should map which control supports sender identity, which protects data during transfer, which detects alteration, and which independent business record connects the invoice to the supply. HMRC's examples include orders, delivery documents, invoices, remittances, and trading-partner data; the right chain depends on the taxpayer's transaction and operating method.

At the system boundary, test whether the issuer's original content matches what the recipient stored, including line data, tax values, currency, customer details, issue date, tax point, and credit-note references where material. Separate message transport acknowledgment from recipient receipt, tax-content validation, accounting posting, and any later authority interaction. If a supplier and customer both retain the message, compare identifiers and revisions rather than assuming a shared filename means shared content. A duplicate, partial batch, failed conversion, or replaced attachment should surface as an exception with a named owner and retained history.

Recreate a historical invoice after a change

An archive demonstration should start with one electronic invoice and its linked order or supply evidence. Retrieve the exact version as originally transmitted, show a readable rendering, and expose the metadata and control evidence that support origin and integrity. Then change a customer master record, invoice display template, mapping, software version, or storage location and run the retrieval again. The historical representation should not silently inherit today's address, template, exchange rule, or data correction. HMRC's notice requires history files so appropriate past details can be found; a current-screen replay is therefore an incomplete test if it cannot show the dated source state.

Next, test a credit note, a duplicate message, a batch header with shared details, an inbound paper invoice scanned into electronic storage, and an outage-recovery scenario. HMRC separately discusses credit-note linkage, batched invoices, scanned paper records, and recovery plans. Each case should retain its own source and transformation path. Do not infer that one successful example proves every jurisdiction, entity, message type, or retention period. A vendor's archive feature may support this review, but actual control design and retained records remain the taxpayer's responsibility.

Keep the UK guidance and its limits explicit

VAT Notice 700/63 is HMRC's UK guidance, last updated May 26, 2022. It does not itself settle the future UK 2029 e-invoicing policy, another country's clearance model, or an EU recipient's local requirements. Nor does it establish a specific company's invoice population, storage configuration, security control, authenticity result, retention exception, tax treatment, or audit outcome. The operational claim here is narrower: a UK e-invoice archive decision should be evaluated against original-message reconstruction and the evidence of origin, integrity, and legibility described in the notice.

The next editorial recheck should watch HMRC's current notice and any subsequent implementation rules for a material change in scope, acceptable control, format, or record duty. Until such a change is verified, the old publication and update dates remain the authority's dates and September 21, 2026 is only this article's review date. Tax and finance owners should involve qualified advisers for their own facts instead of using this analysis as a filing, retention, or system-conformance opinion.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Indirect Tax Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.