Strip away the national vocabulary and every European e-invoicing arrangement is one of two shapes. Learning to see which one you are looking at is the fastest way to make sense of a market that presents itself as twenty-seven unrelated problems.
Four corners
Four parties. The supplier, the supplier's service provider, the buyer's service provider, and the buyer. Each business has a relationship with its own provider and with nobody else. The providers have a relationship with each other, through a common agreement that binds all of them to the same specifications, the same transport profile and the same addressing.
The elegance is in what it removes. A supplier does not need a connection to each customer, or an agreement with each customer's provider, or knowledge of what software the customer runs. It sends to its own provider, addressed to a participant identifier, and routing is somebody else's problem.
That is a genuine solution to a genuinely hard problem — the alternative, bilateral integration, scales as the square of the number of participants — and it is why the model has become the default across northern Europe.
Five corners
The same path, with the tax administration added as a party.
The fifth corner can be positioned in several ways, and the position is the design.
In the path, before delivery. The document reaches the administration first and is delivered onward only if accepted. This is clearance, and it is what Italy and Poland operate.
Beside the path, in parallel. The document goes to the buyer over the network while a defined data set goes to the administration. Delivery does not depend on the administration's response.
Behind the path, afterwards. The administration receives data on a periodic basis, or asks for it. This is post-audit, which is where most of Europe was until recently and where several Member States remain.
The hybrids, which is what most mandates actually are
Presenting this as two architectures is a simplification that survives about as far as the first real implementation. The arrangements Member States have built are mostly neither, and the departures are where the work is.
The most consequential hybrid inserts an accredited private platform between the parties and gives it a public function. The platform carries the document, as a provider does in a four-corner network, and separately extracts and forwards the data the administration requires. So the transmission is four-corner in shape and the reporting is five-corner in effect, performed by an actor with a licence rather than by the state. The French partner platform model is the fullest expression of it, and it is not adequately described by either label.
A second hybrid runs two obligations side by side over different channels. A structured invoicing obligation moves documents between businesses, and a separate, older ledger reporting regime continues to send book data to the administration on its own clock. Nothing about the invoice architecture tells you the second obligation exists, and a project scoped from the invoicing side alone will miss it entirely — which is what makes Spain's arrangement instructive rather than merely complicated.
A third variation is temporal. Several mandates begin as post-audit, acquire a reporting obligation, and only later route documents through a platform. The architecture in force on the day you scope the project is not the architecture in force when you go live, and the plan has to be written against the direction rather than the snapshot.
The practical lesson is that "which model is this country?" is the wrong question. The useful questions are narrower: does delivery depend on somebody's acceptance, does the administration see the document or a derived data set, and who holds the record of what happened.
What actually differs
Not the format. Not the data. Not the master data work, which is identical, and not the receiving process, which is identical. Three things differ, and each of them is operational.
Who tells you it failed
This is the substantive difference and it is worth stating plainly.
Under clearance, the platform tells you within minutes. The answer is binary, it is authoritative, and there is a reason code. That is unpleasant at volume and it is extremely useful: you always know the state of every document you have issued.
Under a four-corner model, the network tells you that the document was delivered to the buyer's provider. It cannot tell you that the buyer's accounts payable system accepted it, because it does not know. A rejection at that level is a business event, arriving days later, through a channel that may be an email to somebody who has left.
| Failure | Four-corner | Clearance |
|---|---|---|
| Malformed document | At your provider, immediately | At the platform, immediately |
| Profile rule violation | At your provider or the receiver's, minutes to hours | At the platform, immediately |
| Unknown recipient | At addressing lookup, immediately | At the platform, immediately |
| Buyer's own rules | Days later, out of band | Days later, out of band |
| Never actually read | Never | Never |
The bottom row is not a joke. In both architectures a document can be delivered, accepted and ignored, and neither architecture has anything to say about that.
When the invoice legally exists
Under clearance the invoice is issued when the platform accepts it. Your system's own creation event is a draft. Every downstream process that assumed otherwise — revenue recognition timing, numbering, the daily close, the report that says what was billed — needs to be examined.
Under a four-corner model the invoice exists when you issue it, as it always did.
This is the change that catches finance teams rather than technical teams, and it is the reason clearance implementations take longer than their technical scope suggests.
Who you can telephone
Under a four-corner model your provider is your counterparty, with a contract and a service level. Under clearance the platform is a state system, and there is no commercial relationship to escalate through.
That has a real bearing on how you plan for failure, which is why choosing an access point or service provider matters more in a network model than people expect, and why delivery failures and retries matters more in a clearance model.
Who will still hold the evidence in year eight
The third difference is the one nobody asks about during selection and everybody asks about during an audit.
In a four-corner arrangement the record of what happened is distributed and commercial. Your provider holds what it accepted from you and what it passed on. The receiving provider holds what it delivered. Neither is obliged by the network's rules to keep those records for the length of your retention period, because that period is a matter of your national law and their retention is a matter of their contract. The chain of evidence therefore has joins, and the joins are contractual.
Under clearance the record is centralised and public. The platform holds what was submitted, what it validated and what it delivered, and that record is authoritative in a way no commercial log is — it was produced by a third party with no interest in the transaction and no incentive to reconstruct it favourably.
That is a genuine advantage of clearance and it is rarely counted, because the cost of clearance is felt in month one and the benefit is felt, if ever, in year six. It is also the reason that in a network model the retention terms in a provider contract matter as much as the price, a point that runs through both choosing an access point and what an archive actually has to hold.
The corollary is worth stating for network implementations: if your provider will not retain transmission evidence for as long as you must retain the invoice, then you have to capture it yourself, at the time, or accept that part of your assurance of authenticity and integrity rests on a record that will be deleted before you need it.
The parts that are the same
It is worth being equally clear about what does not change, because vendors have a commercial interest in blurring it.
The document. A structured invoice conforming to EN 16931, or to a national schema, is the same artefact regardless of how it travels.
The data. Identifiers with schemes, unit of measure codes, tax categories, complete addresses. Identical requirement, identical effort. See master data for e-invoicing.
The receiving process. Something arrives structured, something validates it, something routes it, somebody handles the exceptions. Architecture-independent, and the largest single piece of work in most implementations. See redesigning accounts payable.
The archive. You keep the instance you sent, with its delivery evidence, for years. See archiving a structured invoice.
That list is most of the project. The architecture decides perhaps a fifth of it.
How to design when you operate in both
Most multinationals do, and will continue to. Three principles hold up.
One internal representation, several outputs. Never model your invoice on a delivery architecture. Model it on the semantic content, and derive the clearance submission and the network document from the same source.
Abstract the acknowledgement. Clearance returns an identifier and a status. A network returns a delivery notification. Your systems should record a normalised "what happened to this document" state, into which both map, so that the daily report reads the same in both countries.
Make the exception queue architecture-independent. One queue, one triage, one set of reason categories. A team that has to learn a different failure vocabulary per country will not learn either properly.
Reading a mandate to find out which model it really is
Legislation does not announce its architecture, and the summaries that do are frequently wrong because they are copying each other. Four questions, asked of the primary text, settle it.
Does delivery depend on an acceptance? If the document is not validly issued until a platform says so, that is clearance, whatever the law calls it. If it is issued when you issue it and the platform is informed afterwards, it is not.
What does the administration receive — the document or a data set? Receiving the whole invoice and receiving a defined extract are materially different obligations, and they have different consequences for what you have to be able to produce later.
Who is permitted to carry the document? Anyone meeting a technical specification, or only an accredited or licensed party? Accreditation is the marker of the hybrid model, and it changes the procurement question from "which provider" to "which licensed provider, and what happens if their licence changes".
Where does the legally significant timestamp come from? Your system, your provider, or the platform. This is the question with the largest downstream footprint, because it decides whether your own issue event means anything.
Answer those four from the legislation and the implementing act, not from a vendor's country page, and the architecture falls out of the answers. It also tells you which of the two operational risks you are carrying: the clearance risk, which is a rejection you must resolve inside a window, or the network risk, which is a delivery that appeared to succeed and did not.
What to watch
The direction of travel is not towards one model winning. It is towards the reporting obligation separating from the delivery mechanism: the administration gets its data through digital reporting, and delivery goes back to being a matter between the parties and their providers.
If that separation completes, the five-corner shape becomes a transitional arrangement and the four-corner shape becomes the norm with a reporting obligation attached. That is a reason to build the reporting interface as its own component rather than as a side effect of invoicing — which is exactly the distinction drawn in e-invoicing and e-reporting are not the same obligation.
