Agreeing a format settles what a document says. It does not settle how it gets there, who is allowed to carry it, which party holds the timestamp that counts, or what happens when nothing arrives. This section is about that layer, and it is written for the person who has been told an invoice was sent and is trying to establish whether it was delivered.
Europe has settled on two architectures and a number of hybrids. In one, accredited providers exchange documents for their customers under a common agreement, and an address is a lookup rather than an entry in an address book. In the other, a tax administration, or a platform licensed by it, stands in the path of the document and decides whether it exists at all. The pieces here cover addressing and capability lookup, the transport profile underneath, what accreditation actually obliges a provider to do, how the Italian and French designs differ from each other, and the failure modes that only appear once real volume is flowing. Which countries impose which architecture is in mandates and deadlines; what the document has to contain is in standards and formats. The library lists everything.
The four-corner and five-corner models are the two architectures of European e-invoicing. How each routes an invoice, who sees it first, and where each one fails.
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.
The buyer's answer to a delivered invoice on Peppol: the seven status codes, what each commits the buyer to, and why the message is optional on the network.
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.
What the Peppol network is: a governance framework for exchanging e-invoices through access points under common agreements, with no central operator in the path.
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.
