Two XML syntaxes may be used to express the European core invoice. Both carry the same semantic model, both are conformant, and they share almost no element names. The choice between them looks like a preference and is actually an architecture decision, because it determines what you maintain for the next decade.
What a syntax binding is
EN 16931 defines meanings. A syntax binding says how each of those meanings is written down: which element carries the seller's legal name, where the VAT breakdown sits in the document tree, how a date is formatted, and which attributes qualify an identifier.
Two bindings are named. One comes from a business document library maintained as an open standard by an international consortium; the other comes from a cross-industry message standard maintained by a United Nations body. Their origins explain almost everything about how they read.
| Library-derived syntax | Cross-industry syntax | |
|---|---|---|
| Origin | A general library of business documents | A cross-industry message framework |
| Element naming | Long, descriptive, close to business vocabulary | Abbreviated, structured around aggregate types |
| Nesting depth | Shallower | Deeper |
| Typical file size | Larger in characters, easier to read | More compact, harder to read unaided |
| Where you meet it | The dominant European network profile, several national profiles | Hybrid PDF invoices, industrial and automotive supply chains |
Neither column is a recommendation. Both express the model completely, and a rejection is almost never caused by the choice between them.
Why both exist
Because the directive that commissioned the standard could not sensibly have picked one.
By the time the European standard was written, both syntaxes had installed bases running real traffic, in different industries and different countries. Naming one would have obsoleted years of investment in the other and guaranteed political failure. Naming both cost something — every receiver has to be able to read two documents instead of one — and bought agreement.
That trade is worth remembering when reading complaints about European standardisation. The two-syntax outcome is not indecision. It is the price of the standard existing at all.
The decision you are actually making
Not "which syntax is better", but "which syntaxes do I have to produce, and how many places will I maintain them".
Three questions settle it.
What do my national profiles require? Several national profiles permit both. Some effectively mandate one by building a hybrid specification on it. If you sell into a country whose profile is built on a particular syntax, you produce that syntax.
What can my counterparties consume? A profile permitting both does not mean your customer's software reads both. In practice the answer is discovered during onboarding, one customer at a time, which is one reason the onboarding phase takes longer than the technical work that precedes it.
Am I producing hybrid files? If you are producing hybrid PDF invoices, the embedded XML is in whichever syntax those specifications use, and the question is settled for you.
Produce one internal representation carrying every business term you need. Derive each syntax from it. Never let two syntaxes be maintained by two teams from two sources of truth — that is how the same invoice comes to say two different things.
Conversion, and where it stops being safe
Because both bind the same model, a core invoice can be converted between them mechanically. Tools exist, they work, and for core content conversion is not a risky operation.
It becomes risky in three specific places.
Extensions. Anything outside the core has no guaranteed counterpart. A converter will either drop it silently or park it somewhere the receiver will not look. Both outcomes are data loss, and only one of them is visible.
Precision and rounding. The two syntaxes express amounts and quantities with different conventions in some places. A conversion that rounds where the source did not has changed the document, and if the document was sealed, it has broken the seal's meaning. This is directly relevant to authenticity and integrity.
The archived instance. If you converted, which version is the invoice? The one you issued. Archiving the converted copy because it was more convenient means archiving something that is not the document your customer received. That distinction is the subject of archiving a structured invoice.
What this means for testing
Two syntaxes means two sets of syntax-level validation rules, on top of the shared business rules of the standard. A test suite that covers one and assumes the other is fine will find that assumption expensive.
The practical minimum is a matrix: each syntax, against each profile you must satisfy, against each of the invoice shapes your business actually produces — a simple domestic invoice, one with allowances and charges, one with more than one VAT rate, one with a credit note reference, one with an attachment. That matrix is small enough to write down and large enough that nobody produces it by accident. The wider argument is in testing against a real validation stack.
The short answer
If you have a free choice and no constraint from a profile, a counterparty or a hybrid requirement, take the syntax your service provider and your customers already use, and stop thinking about it. The choice is almost never where the difficulty is.
Where the difficulty is: whether the data you put into either of them is complete, correctly coded, and consistent with what your ledger says. That is master data, and it is indifferent to syntax.
