EU e-invoicing rules distinguish structured data from document images

An invoice image and a structured invoice are different records

The direct answer in Directive 2014/55/EU is that an electronic invoice is issued, transmitted, and received in a structured electronic format that allows automatic and electronic processing. The recitals reinforce the boundary: only machine-readable invoices that can be processed automatically and digitally should count as compliant with the European standard, and a mere image file should not be treated as an electronic invoice for the Directive's purpose.

A procurement or accounts-payable system should therefore preserve the structured invoice payload as the transaction record, not only a rendered PDF or scan. Human-readable rendering can support review, but the original data, syntax, identifiers, validation result, sender, recipient, receipt time, transformations, and version must remain traceable. Optical character recognition can create data from an image; it does not retroactively make the supplier's original document a compliant structured message.

Semantic interoperability is the common core

The Directive describes a European standard for the semantic data model of the core elements of an electronic invoice. It explains that semantic interoperability preserves the precise meaning of required information across systems even when the information is represented differently. That is the business-data layer: buyer and seller references, invoice lines, amounts, tax information, payment data, and other core concepts must be interpretable consistently.

A robust implementation maps local fields to the applicable semantic model with explicit code lists, cardinalities, transformations, and exceptions. It retains the source value and mapping version so a rejected or disputed invoice can be reconstructed. A populated field is not automatically correct; contract, order, receipt, tax, supplier, and accounting evidence still determine whether the business statement is accurate and whether the invoice can advance.

Syntax and transport are separate choices

The recitals distinguish semantic interoperability from syntax—the format or language in which data elements are represented—and from the method of transmission. They recognize that syntactic interoperability can use a common syntax or mapping between syntaxes. Article 7 connects the obligation to invoices compliant with the European standard and a syntax identified under the Directive. This layered model prevents a network connection from being mistaken for content conformance.

Systems should record the semantic profile, syntax, customization, validator and rule version, access point or other transport, addressing identifiers, security context, acknowledgments, and delivery errors independently. Peppol can govern a document-and-network stack used in implementations, but this Directive does not make every network message valid, every compliant payload delivered, or every delivered invoice payable.

Receipt and processing do not equal approval

Article 7 requires covered contracting authorities and entities to receive and process electronic invoices that comply with the European standard and an identified syntax. The operational workflow still has to connect the invoice to the relevant procurement, contract, purchase order, receipt or service evidence, tax treatment, exception policy, approval authority, and payment controls. Technical acceptance is one state in that sequence.

A defensible ledger distinguishes transport receipt, syntax validation, semantic conformance, business validation, exception, approval, rejection, posting, and payment. It should expose which party or system made each determination and preserve the evidence and message returned to the supplier. This analysis does not determine a Member State's transposition, procurement scope, tax treatment, contractual right, or payment outcome; those require the applicable current law and transaction facts.

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

Procurement Technology Current 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.