Semantics, Syntaxes, and Standards: An e-Invoicing Glossary

Q: What is a semantic data model?

A **semantic data model** defines **what** data belongs in an invoice - the buyer, the seller, line items, amounts, tax breakdowns, payment terms - without saying anything about how that data is encoded in a file. It is a blueprint of meaning, not a file format. In the EU, **EN 16931** defines the core semantic model for e-invoicing. It lists every business term (over 160 of them) that a compliant invoice can carry, along with rules about which terms are mandatory and which are optional. If you think of an invoice as a form, the semantic model is the list of fields on that form. Because the semantic model is independent of any particular file format, the same set of business terms can be expressed in different technical syntaxes - UBL XML, CII XML, or others - and still be semantically identical. That separation is what makes cross-border interoperability possible. For a deep dive into the EU core model, see [EN 16931 explained](/blog/en-16931-explained).

Q: What is an invoice syntax?

An **invoice syntax** defines **how** semantic data is encoded into a file that can be transmitted between systems. It specifies the rules for data placement, tag names, nesting, formatting, and structure. If the semantic model is the list of fields, the syntax is the envelope they go into. Several syntaxes are in active use worldwide. **EDIFACT INVOIC** (specifically the D16B subset) is long established in European industry supply chains. **ANSI X12 810** is the dominant EDI invoice format in the United States. **Peppol BIS Billing 3.0**, built on UBL 2.1 XML, is the default for cross-border public-sector invoicing across the EU and beyond. The same invoice data can be encoded in multiple syntaxes and remain valid against the same semantic model. That is the whole point of separating semantics from syntax: a German manufacturer and an Italian public authority can use different XML schemas and still agree on what the invoice means.

Q: What are e-invoicing standards?

An **e-invoicing standard** is an agreed-upon set of rules published by a recognised standards body. A single standard may encompass multiple syntaxes, validation rules, and document types. Standards exist so that trading partners, governments, and software vendors work from the same rulebook. **EN 16931** is the European norm for e-invoicing. It maps its semantic model to two official syntaxes - UBL and CII - and is the basis for EU Directive 2014/55/EU, which requires all public administrations in member states to accept EN 16931-compliant invoices for B2G transactions. **EDIFACT** and **X12** are older standards maintained by UN/CEFACT and ANSI respectively, each covering a wide range of business documents beyond invoicing. Standards also define validation artefacts - Schematron rules, XSD schemas, code lists - that software uses to check whether an invoice is technically correct before sending it. Without those artefacts, a "standard" would just be a document sitting on a shelf.

Q: What is a CIUS?

A **CIUS** (Core Invoice Usage Specification) is a restricted profile of the EN 16931 core model, tailored for a specific country, industry, or network. The key rule: a CIUS can only tighten requirements - making optional fields mandatory, narrowing allowed code values, adding validation rules - but it can never add new data elements or relax existing constraints. Because a CIUS only restricts, any invoice that conforms to a CIUS is automatically fully compliant with the EN 16931 core. Examples include **Peppol BIS 3.0** (the most widely adopted CIUS, used across 40+ countries), **CIUS-PT** (Portugal's national specification), and **XRechnung** (Germany's B2G specification). Each one takes the same core model and applies local business rules on top. The practical benefit is interoperability with guardrails. A German public authority receiving an XRechnung invoice knows it can also be processed by any system that understands EN 16931, because XRechnung is a strict subset. For more on [Peppol's](/blog/what-is-peppol) role in this ecosystem, see the linked guide.

Q: What is an Extension?

An **Extension** expands the EN 16931 core model by adding data elements that the core does not include. Unlike a CIUS, which only restricts, an Extension introduces new fields - making the invoice **conformant** to the core (it still contains the core) but not **strictly compliant** (it carries data beyond what the core defines). The best-known examples are **ZuGFeRD** (Germany) and **Factur-X** (France), which are essentially the same specification under two names. Both embed a CII XML data stream inside a PDF/A-3 file, and both add optional fields for things like payment card details and buyer-specific account references that the EN 16931 core does not cover. The catch with Extensions is that the extra data only works if both parties agree to use it. A receiving system that only understands the EN 16931 core can safely ignore the extension fields and still process the invoice - the core data is always present. But the additional information will be lost unless the receiver's software explicitly supports that Extension.

What is a semantic data model?

A semantic model defines what data belongs in an invoice. A syntax defines how that data is encoded in a file.

A semantic data model defines what data belongs in an invoice - the buyer, the seller, line items, amounts, tax breakdowns, payment terms - without saying anything about how that data is encoded in a file. It is a blueprint of meaning, not a file format.

In the EU, EN 16931 defines the core semantic model for e-invoicing. It lists every business term (over 160 of them) that a compliant invoice can carry, along with rules about which terms are mandatory and which are optional. If you think of an invoice as a form, the semantic model is the list of fields on that form.

Because the semantic model is independent of any particular file format, the same set of business terms can be expressed in different technical syntaxes - UBL XML, CII XML, or others - and still be semantically identical. That separation is what makes cross-border interoperability possible. For a deep dive into the EU core model, see EN 16931 explained.

What is an invoice syntax?

An invoice syntax defines how semantic data is encoded into a file that can be transmitted between systems. It specifies the rules for data placement, tag names, nesting, formatting, and structure. If the semantic model is the list of fields, the syntax is the envelope they go into.

Several syntaxes are in active use worldwide. EDIFACT INVOIC (specifically the D16B subset) is long established in European industry supply chains. ANSI X12 810 is the dominant EDI invoice format in the United States. Peppol BIS Billing 3.0, built on UBL 2.1 XML, is the default for cross-border public-sector invoicing across the EU and beyond.

The same invoice data can be encoded in multiple syntaxes and remain valid against the same semantic model. That is the whole point of separating semantics from syntax: a German manufacturer and an Italian public authority can use different XML schemas and still agree on what the invoice means.

What are e-invoicing standards?

An e-invoicing standard is an agreed-upon set of rules published by a recognised standards body. A single standard may encompass multiple syntaxes, validation rules, and document types. Standards exist so that trading partners, governments, and software vendors work from the same rulebook.

EN 16931 is the European norm for e-invoicing. It maps its semantic model to two official syntaxes - UBL and CII - and is the basis for EU Directive 2014/55/EU, which requires all public administrations in member states to accept EN 16931-compliant invoices for B2G transactions. EDIFACT and X12 are older standards maintained by UN/CEFACT and ANSI respectively, each covering a wide range of business documents beyond invoicing.

Standards also define validation artefacts - Schematron rules, XSD schemas, code lists - that software uses to check whether an invoice is technically correct before sending it. Without those artefacts, a "standard" would just be a document sitting on a shelf.

What is a CIUS?

A CIUS can tighten EN 16931 requirements but can never relax them or add new data elements.

A CIUS (Core Invoice Usage Specification) is a restricted profile of the EN 16931 core model, tailored for a specific country, industry, or network. The key rule: a CIUS can only tighten requirements - making optional fields mandatory, narrowing allowed code values, adding validation rules - but it can never add new data elements or relax existing constraints.

Because a CIUS only restricts, any invoice that conforms to a CIUS is automatically fully compliant with the EN 16931 core. Examples include Peppol BIS 3.0 (the most widely adopted CIUS, used across 40+ countries), CIUS-PT (Portugal's national specification), and XRechnung (Germany's B2G specification). Each one takes the same core model and applies local business rules on top.

The practical benefit is interoperability with guardrails. A German public authority receiving an XRechnung invoice knows it can also be processed by any system that understands EN 16931, because XRechnung is a strict subset. For more on Peppol's role in this ecosystem, see the linked guide.

What is an Extension?

An Extension expands the EN 16931 core model by adding data elements that the core does not include. Unlike a CIUS, which only restricts, an Extension introduces new fields - making the invoice conformant to the core (it still contains the core) but not strictly compliant (it carries data beyond what the core defines).

The best-known examples are ZuGFeRD (Germany) and Factur-X (France), which are essentially the same specification under two names. Both embed a CII XML data stream inside a PDF/A-3 file, and both add optional fields for things like payment card details and buyer-specific account references that the EN 16931 core does not cover.

The catch with Extensions is that the extra data only works if both parties agree to use it. A receiving system that only understands the EN 16931 core can safely ignore the extension fields and still process the invoice - the core data is always present. But the additional information will be lost unless the receiver's software explicitly supports that Extension.

Why does everyone use the word "format" differently?

If you have ever been confused by someone saying "EN 16931 format" and someone else saying "EDIFACT format" as though those are the same kind of thing, you are not alone. The word "format" is the most overloaded term in e-invoicing. It gets applied to semantic models, syntaxes, standards, CIUS profiles, and Extensions - all of which are technically distinct concepts.

In casual conversation, "format" usually means "the thing my system needs to produce or consume." That might be a UBL XML file, a ZuGFeRD PDF, an EDIFACT message, or a Peppol BIS document. The speaker rarely distinguishes between the semantic layer and the syntax layer because, for their purposes, it does not matter - they just need the file to validate and transmit.

When precision matters - in a procurement specification, a regulatory text, or a vendor evaluation - it pays to be specific. Say "syntax" when you mean the file encoding, "semantic model" when you mean the data content, "standard" when you mean the published norm, and "CIUS" or "Extension" when you mean a profile built on top of EN 16931. The overview page groups countries by their required specifications if you want to see how these layers play out in practice.