If you exchange structured invoices in Europe outside Italy and a few national systems, there is a good chance you are exchanging them under one profile. It is the most widely implemented restriction of the European standard, and its practical importance now exceeds its formal status: for large parts of the market, it is what "a valid electronic invoice" means.
What it is
A business interoperability specification: a document that says exactly how the European standard is to be used for a defined purpose, in this case invoicing over a shared four-corner network.
It does three things.
It restricts the standard. Optional elements become mandatory, code lists are narrowed, and some elements are excluded. That is the ordinary work of a core invoice usage specification.
It fixes the identifier schemes. This is the part unique to a network profile and the part that matters most. On a shared network, a receiver has to be found before a document can be delivered, and finding requires an identifier that both ends interpret identically. The specification says which schemes may be used and how they are written.
It binds itself to a syntax. The specification is expressed against one of the two permitted syntaxes, which removes a decision and removes an ambiguity at the same time.
Why a network profile is stricter than a national one
A national profile has one authority behind it, and every participant is subject to that authority. A network profile has neither. It has to work between parties who have no relationship with one another, in different countries, under different laws, connected through providers who have never spoken.
That produces a specific kind of strictness. Where a national profile can say "the tax administration will interpret this field", a network profile must say what the field means with no interpreter available. Ambiguity that a national system resolves by asking somebody has to be legislated out in advance.
The visible consequence is a set of rules that look pedantic and are not:
- Identifier schemes are mandatory, not optional. An identifier without a scheme is unusable, and the specification refuses to accept one. This is the point made in an electronic address is two things.
- A buyer reference is required in most contexts, because the receiving system needs a routing hook that the buyer, not the seller, controls.
- Code lists are narrowed hard. Fewer permitted values means fewer ways for two implementations to disagree.
What it does not solve
Three things, and each is a source of surprise.
It does not make the buyer's rules go away. The specification is a floor for interoperability. Above it sits whatever the buying organisation requires — a purchase order reference, a valid cost centre, a supplier who is not blocked — and those rules reject documents that are perfectly valid under the specification. This is the fourth gate in the validation stack.
It does not satisfy every national mandate. Where a Member State has adopted it — Belgium is the clearest example — building to the specification is building to the mandate. Where a Member State has its own format, it is not.
It does not stand still. The specification is versioned. Versions overlap for a period and then the old one stops being accepted. A business that treated the first implementation as finished discovers this the hard way, usually through a wave of rejections with no obvious cause.
Not "do you support the specification" but "which versions do you support today, what is your process when a new one is published, and how much notice will I get". The second question predicts your operational load; the first predicts nothing.
The parts most often got wrong
The buyer reference. Suppliers treat it as a free-text field and populate it with their own reference, which defeats the purpose: it exists so the buyer's system knows where to route the document. If your customer gave you a value, use it exactly. If they did not, ask, because guessing produces a document that is valid and unroutable.
Allowances and charges at the wrong level. A document-level discount and a line-level discount are different structures with different arithmetic consequences, and putting one where the other belongs produces totals that do not reconcile. The business rules catch this, which is fortunate, because it would otherwise be an invoice for the wrong amount.
VAT breakdown completeness. Every combination of tax category and rate present in the lines must appear in the breakdown, with an exemption reason where the category requires one. Systems that were built to print a single VAT total on a paper invoice do not have this data in a usable shape. It is one of the more common reasons a first test fails, and it is examined in exemption and reverse charge reason codes.
The specification identifier. As always. Declaring the wrong profile produces a validation report that describes a document nobody built.
Where it fits in an architecture
The pattern that works is the one described in EN 16931 explained: one internal representation of an invoice, carrying everything, from which each target is derived. The network specification becomes one target among several rather than the shape of your data model.
The temptation to do the opposite — to model your invoice on the network profile because it is the one you implemented first — is strong and expensive. The profile is narrower than the standard. Anything it excludes, your data model then cannot carry, and the second country that needs it becomes a rebuild rather than a mapping.
