Four Corners, Five Corners: The Two Architectures of European E-Invoicing
Every European e-invoicing system is one of two shapes, and the difference decides who tells you an invoice failed, when, and whether you can do anything about it.
Agreeing on a format settles what the document says. It does not settle how it travels, who is allowed to carry it, what happens when delivery fails, or which party holds the legally significant timestamp. Europe has settled on two broad architectures. One is a four-corner network in which accredited providers exchange documents on behalf of their customers under a common agreement. The other inserts the tax administration, or a licensed platform acting for it, into the path of the document before it reaches the buyer. This section covers both: addressing and capability lookup, the transport profile the network runs on, what accreditation actually requires of a provider, how the Italian and French architectures differ from each other, and the failure modes that only appear once real volume is flowing.
Every European e-invoicing system is one of two shapes, and the difference decides who tells you an invoice failed, when, and whether you can do anything about it.
The analysis underneath the anchor piece.
Message-level security, a signed receipt, retry and an envelope that ignores the invoice. Each transport guarantee answers one business question precisely and leaves another wide open.
A procurement piece written by somebody who sells nothing. The questions that bind a provider decision, in the order they bind, and why the per-document price is rarely the one that matters.
An identifier resolves through a chain of lookups before anything is sent, and each link answers a different question. Knowing which link failed tells you who has to fix it.
France routes the invoice through registered platforms that also file data about it. One registration covers both jobs, and the participant directory decides whether anything arrives.
A governed network rather than a product: who is allowed to carry documents, what they agree to, and why that agreement is the thing that actually makes interoperability work.
What happens between submission and delivery in a clearance model, and why the notification the platform returns is the only record of it that anyone else will accept.
A sent invoice and a received invoice are different facts. Five classes of delivery failure, who detects each one, who pays for it, and why retry logic only ever answers the first.