E-invoicing standards: making sense of semantics vs. syntax

If you’ve ever been told an invoice was “valid XML” and then watched it get rejected anyway, we hear you. E-invoicing standards work in layers, and understanding the difference between the semantics and the syntax of e-invoices becomes crucial to maintain control over your processes and transactions.

In this article we’ll unpack each layer in turn, so you can look at any e-invoice format name and know exactly what it’s telling you (and what it isn’t).

TL;DR

• Semantics defines what an e-invoice must contain and what each data field means
• Syntax defines how that content is written as a machine-readable file
• EN 16931 is the European e-invoice standard for semantics, and it works with two syntaxes: UBL and CII
• A CIUS such as XRechnung or Peppol BIS Billing 3.0 tightens the core rules for a specific country or network
• Validation checks both layers, which is why a well-formed XML file can still be rejected
• A managed approach can reduce the complexity of supporting multiple e-invoicing standards across your ERP landscape

Why e-invoicing standards can feel confusing

Ask five people which electronic invoice format their company uses and you might hear five different answers: XML, UBL, Peppol, XRechnung or EN 16931. The surprising part is that they could all be right, as all these terms don’t describe five competing options. They describe different layers of the same invoice.

It’s a bit like asking someone what they’re reading and hearing “English”, “a paperback” and “a crime novel”. Each answer is true, but each one answers a different question.

Knowing how these layers interact becomes non-negotiable as e-invoicing mandates are steadily becoming the norm worldwide. Each of these mandates refers to e-invoicing standards, but rarely in the same way. If you’re absolutely new to the topic of e-invoicing, however, I recommend you check our guide “what an e-invoice is and how e-invoicing works” first before getting into the nitty gritty details of e-invoice structures.

Semantics vs syntax: the difference in plain English

These two words sit at the heart of every e-invoicing standard:

• Semantics is what the invoice says: which information must be included, what each field means, how often it can appear and how the amounts must add up
• Syntax is how that information is written: the element names, the structure and the order of the file

Think of a recipe written in English and the same recipe translated into French. The ingredients, quantities and steps (the semantics) stay identical. Only the language and layout (the syntax) change. As long as the translation is accurate, you’ll end up with the same dish. E-invoices work the same way.

Take the invoice issue date. EN 16931 calls it business term BT-2, “Invoice issue date”. Here’s how it looks in the two main syntaxes:

<cbc:IssueDate>2026-10-29</cbc:IssueDate>

<ram:IssueDateTime>
  <udt:DateTimeString format="102">
    20261029
  </udt:DateTimeString>
</ram:IssueDateTime>

Same meaning, different syntax. This simple example leads to two useful rules of thumb:

• Two files can look completely different and still carry exactly the same invoice
• Two files can use the same syntax and still follow completely different rules

Keep these in mind and most format discussions become much easier to follow.

EN 16931: the European e-invoice standard for meaning

EN 16931 is the European standard for electronic invoicing. The European Committee for Standardisation (CEN) published it in 2017 following Directive 2014/55/EU, which required public authorities across the EU to accept electronic invoices. Since 2020 at the latest, every public contracting authority in the EU has had to receive e-invoices that comply with it.

At its centre is a semantic data model for a “core invoice”. It’s made up of:

• Business terms (BT): individual pieces of information, such as BT-1 invoice number or BT-31 seller VAT identifier
• Business groups (BG): related terms grouped together, such as BG-4 seller or BG-25 invoice line
• Business rules (BR): checks that keep the data consistent, such as BR-CO-10, which says the sum of all invoice line net amounts must match the total at document level

Each business term also has a definition, a data type and a cardinality (how many times it can or must appear).

On the other hand, EN 16931 is made up of several parts. EN 16931-1 defines the semantic model, CEN/TS 16931-2 lists the approved syntaxes and CEN/TS 16931-3 maps each business term to the relevant elements in those syntaxes.

It’s also worth noting that the standard continues to evolve. As ViDA builds on EN 16931 for intra-EU e-invoicing, CEN has been extending the standard to cover more B2B scenarios.

All in all, there are three key takeaways you should leave this article with:

• EN 16931 is syntax-neutral, so it defines meaning and leaves the writing to UBL or CII
• It describes a core invoice, covering what most invoices need rather than every national speciality
• It says nothing about transport, so complying with it doesn’t tell you how the invoice reaches your customer

UBL and CII: the two main e-invoice XML formats

Before we get to the syntaxes, a quick word on XML. Extensible markup language (XML) is a general way of writing structured data. It knows nothing about invoices, tax or VAT, so “we send XML invoices” is a bit like saying “we write in letters”. The obvious follow-up question is: which XML?

For EN 16931, there are two answers:

• UBL (Universal Business Language): developed by OASIS, an international standards consortium, and used in version 2.1 for EN 16931 invoices and credit notes
• CII (Cross Industry Invoice): developed by UN/CEFACT, the United Nations body for trade facilitation, and used in version D16B for EN 16931

So which is better? Neither. Both carry the same EN 16931 semantics, so what matters is which syntax your customer, network or mandate accepts. Germany, for example, accepts XRechnung in both UBL and CII.

However, you shouldn’t assume the two are interchangeable in your code. Element names, nesting and tax structures differ, so a parser built for UBL won’t read CII. Because the meaning is shared, though, a well-built mapping can convert core invoice content from one to the other without losing information.

CIUS and extensions: how countries and networks adapt the core

EN 16931 gives everyone the same foundation, but countries, networks and industries often need a little more. That’s where CIUS and extensions come in.

A core invoice usage specification (CIUS) tightens the rules of the core. Think of EN 16931 as a dress code that says “smart casual” and a CIUS as an event that adds “jackets required”. A CIUS can…

• make optional business terms mandatory
• restrict which code list values are allowed
• add extra validation rules

What a CIUS can’t do is add new information. Any invoice that meets a CIUS automatically meets EN 16931 as well, so receivers that only support the core can still process it.

Common examples include:

– Peppol BIS Billing 3.0: the CIUS used on the Peppol network, based on UBL
– XRechnung: Germany’s CIUS, which makes the buyer reference (BT-10) mandatory and is available in UBL and CII
– NLCIUS: the Dutch CIUS used for invoices to the Dutch public sector

Hybrid formats such as Factur-X and ZUGFeRD sit on the same foundation. They embed CII XML inside a PDF/A-3 file, so people and software can both read the invoice. Their EN 16931 profile follows the core, while the EXTENDED profile goes further, which brings us to extensions.

An extension does the opposite of a CIUS. It adds information the core doesn’t include, usually because a national requirement or industry process needs it. Extensions solve local problems, but both sides need to support them, so they reduce interoperability. That’s why specifications use them sparingly.

Finally, every invoice tells the receiver which rules it follows. The specification identifier (BT-24, CustomizationID in UBL) names the CIUS or extension, and the business process type (BT-23, ProfileID in UBL) names the process. If these values are wrong, a perfectly good invoice can be checked against the wrong rules and fail.

How the layers fit together

Here’s the full stack, from the most generic layer to the most specific:

Peppol is a good example of why the layers matter. People often call it a format, but it’s really a network with its own specifications. You can see how those specifications build on EN 16931 in the official Peppol BIS Billing 3.0 documentation.

When you come across a new e-invoice format name, these four steps will help you decode it:

1. Identify the syntax (UBL, CII or something else)
2. Check which semantic model it follows (EN 16931 or a national model)
3. Find the CIUS or extension and its current version
4. Confirm how the invoice must be delivered

Why the difference matters for your e-invoicing project

When an invoice is validated, both layers are checked:

• Schema validation (XSD) checks the syntax, confirming the XML is well formed and uses the right elements
• Schematron validation checks the semantics, applying the EN 16931 business rules plus any CIUS rules on top

Passing the schema check only proves that the file is readable. Acceptance depends on the business rules.

Imagine you sell to customers in two countries and send the same ERP output to both. In the first country, generic Peppol BIS Billing 3.0 is enough, so your invoices go straight through. In Germany, your public-sector customer expects XRechnung, which makes the buyer reference mandatory. Your invoice is still valid EN 16931, yet it’s rejected because that field is empty. The data didn’t change, but the rules did. If you want to dive a bit deeper into e-invoice validation, feel free to check out our article on how to validate an XRechnung.

Now, multiply this situation by 15 countries, each updating its specifications and code lists on its own schedule. That’s the real work behind e-invoicing compliance: keeping up the ever-increasing, ever-moving international e-invoicing standards.

How ecosio makes multiple e-invoicing standards manageable

Managing e-invoicing across countries gets more complex when different entities use different ERP systems. Each system must provide the right invoice data, while formats, validation rules and delivery requirements vary by market.

ecosio’s Global E-invoicing Compliance solution helps reduce integration complexity across your existing ERP landscape. ecosio converts invoice data into the required formats, validates it against applicable rules and delivers invoices through the relevant network, government platform or agreed channel.

For your team, this means:

• Support for multiple e-invoicing formats, including Peppol BIS Billing 3.0, XRechnung and Factur-X
• Less internal effort maintaining country-specific mappings and adapting to changing requirements
• Visibility into invoice processing and validation results
• Support from ecosio’s experts with regulatory and technical updates in supported countries

As your business expands or requirements change, this managed approach helps your teams maintain e-invoicing processes across markets without building a patchwork of local solutions. Find out more about upcoming changes, and to prepare for them, in our article on Vat in the Digital Age (ViDA).

Making sense of e-invoicing standards

Once you separate semantics from syntax, e-invoicing standards become far less intimidating. EN 16931 tells you what an invoice must say, UBL and CII decide how it’s written, and a CIUS adds local rules on top. Transport is a separate question again.

Get these layers clear in your own systems and every new mandate becomes a matter of applying the right rules, rather than starting from scratch.

Want to see how your invoices measure up? Run a file through our free Peppol, e-invoice and XML validator, or talk to our experts about how Global E-invoicing Compliance can support your rollout.