Understanding EU E-Invoicing: EN 16931, UBL, CII, and National Syntaxes

See also E‑Invoicing Explained – Syntax Reality: UBL vs CII and the Impact on Mapping and Validation – VATupdate

---

Understanding EU E-Invoicing: EN 16931, UBL, CII, and National Syntaxes

Electronic Invoicing in the EU: The European Union’s e-invoicing landscape is built on a common semantic standard (EN 16931) but allows multiple technical formats (syntaxes). This approach is intentional, not accidental – it reflects a policy of technology neutrality and flexibility, accommodating existing systems while ensuring a shared understanding of invoice content across borders. Under Directive 2014/55/EU, all contracting authorities must accept an e-invoice that conforms to EN 16931. However, the European Standard defines what data an invoice must contain (the semantic model), but not a single how. Instead, two official XML syntaxes – OASIS UBL 2.1 and UN/CEFACT Cross-Industry Invoice (CII D16B) – are approved to encode that content. Beyond these, several national and industry-specific formats (some predating EN 16931) remain in use, either aligned with the EU standard or requiring conversion for interoperability. This overview provides a detailed taxonomy of the key e-invoicing syntaxes in the EU, covering their origins, usage, and legal status, and explains how they coexist in practice. [invoice-co…verter.com], [invoicenavigator.eu] [invoice-co…verter.com] [invoicenavigator.eu], [invoicenavigator.eu]

EN 16931 – A Semantic Standard, Not a Single Format

EN 16931 (the European e-invoicing standard) is fundamentally a semantic data model – a structured set of Business Terms and rules describing the content of an invoice. It ensures that any compliant invoice carries all required information (buyer, seller, tax details, totals, etc.) in a consistent way, regardless of the technical file format used. Notably, EN 16931 is syntax-neutral: it does not mandate one specific format for all invoices. Instead, it defines the core data elements and meaning, which can then be implemented in different syntaxes. [invoice-co…verter.com] [invoice-co…verter.com], [invoicenavigator.eu]

This approach was intentional – by separating content (semantics) from format (syntax), the EU enabled technology neutrality and easier adoption. At the standard’s inception, two mature XML invoice formats existed (UBL and CII), each with its own community and use cases. Rather than force a “winner” and disrupt existing e-invoicing ecosystems, the standard incorporated both as valid. Thus, Directive 2014/55/EU explicitly recognizes that a compliant invoice can be delivered using any syntax listed by the standard. This means Member States must accept invoices in UBL or in CII (the two official syntaxes) for public procurement, even if they have local preferences. [invoicenavigator.eu], [invoicenavigator.eu] [invoicenavigator.eu]

Beyond legal compliance, in practice the dual-syntax model acknowledges that no single format could immediately satisfy all business contexts. It also leaves room for future formats or evolutions. For instance, as e-invoicing expands into B2B transactions under ViDA (VAT in the Digital Age), the EN 16931 model remains central, but the EU hasn’t signaled a shift to a single syntax. Instead, emphasis is on interoperability – ensuring different systems can exchange invoices seamlessly – rather than imposing uniformity.

UBL 2.1 (OASIS Universal Business Language)

UBL 2.1 is one of the two official syntaxes for EN 16931 invoices. Developed by OASIS, UBL is a widely adopted XML-based business document format that includes a standard schema for invoices. UBL was chosen because it was already a mature, open standard (ISO/IEC 19845) available for free, and it had proven adoption especially in northern and western Europe. Peppol BIS Billing 3.0 – the invoice specification used on the Peppol network for cross-border and B2G e-invoicing – is based on UBL 2.1 with a set of additional rules (in effect, a profile of UBL aligned with EN 16931). Many countries that implemented e-invoicing mandates, especially in public procurement (B2G), opted for UBL via Peppol or similar frameworks. For example, Belgium, the Netherlands, the Nordics, and much of Central Europe rely on UBL as the primary format for receiving or exchanging e-invoices. [invoicenavigator.eu] [invoicenavigator.eu], [invoicenavigator.eu]

From a technical perspective, UBL is known for being implementation-friendly and relatively lightweight. It uses simple, descriptive XML tags such as <Invoice>, <Party>, <TaxTotal>, etc., with a typically flat hierarchy for invoice data (most elements nested only a few levels deep). This tends to result in smaller file sizes and easier mapping from typical ERP data models. Tooling support for UBL is extensive: many ERP systems and e-invoicing services can generate or parse UBL out-of-the-box. Moreover, Peppol’s international network (active in over 30 countries) amplifies UBL’s reach, making it a de facto cross-border standard in Europe. If a business must choose one format to cover the broadest set of EU scenarios, UBL is often the safest bet. [invoice-co…verter.com], [invoice-co…verter.com] [invoicenavigator.eu], [invoicenavigator.eu]

From a regulatory standpoint, UBL 2.1 is directly referenced by EN 16931 as a conforming syntax. Thus, any invoice built in UBL 2.1 that follows the EN 16931 content rules must be accepted by all EU public bodies. UBL is also being adopted in emerging national real-time reporting or continuous transaction control systems (for example, the Belgian B2B e-invoicing mandate from 2026 uses UBL via Peppol).

UN/CEFACT Cross-Industry Invoice (CII D16B)

The UN/CEFACT Cross-Industry Invoice (CII), version D16B, is the other official XML syntax under EN 16931. UN/CEFACT developed CII as part of a broader family of electronic business standards, aiming to modernize classic EDI (Electronic Data Interchange) in an XML form. Unlike UBL’s document-centric design, CII stems from an EDI heritage, resulting in an invoice structure that is more granular and deeply nested, reflecting detailed trade transaction semantics. [invoicenavigator.eu]

Use cases and adoption: In the EU context, CII’s biggest role is in hybrid invoice formats like Factur-X (France) and ZUGFeRD (Germany). These hybrid approaches embed a machine-readable CII XML inside a human-readable PDF/A-3 file, offering the benefit of a single file that satisfies both electronic data requirements and human legibility. This has made CII appealing in countries or industries where businesses still heavily rely on PDFs – for example, in France’s forthcoming B2B mandate, the Factur-X (PDF+CII) format plays a key role. Germany’s XRechnung (its national e-invoice spec) also allows CII as an alternative to UBL, and CII is accepted by certain EU public platforms (like some in Austria or the Netherlands, for example, which technically support both syntaxes even if UBL is more common). [invoicenavigator.eu], [invoicenavigator.eu]

From a legal perspective, CII D16B is equally recognized by EN 16931 and Directive 2014/55/EU. Contracting authorities must accept a compliant invoice in CII just as they would in UBL. Some Member States explicitly built their e-invoicing frameworks on CII (or on both syntaxes). For instance, Germany’s XRechnung specification supports both UBL and CII encodings of the EN 16931 model, and many German federal entities can receive either. France’s Chorus Pro platform similarly can ingest pure CII XML invoices, although business usage often leans toward the PDF hybrid. [invoicenavigator.eu]

Technical characteristics: CII’s invoice schema uses more layers of XML elements (e.g., wrappers for document context, trade transactions, line trade details, etc.), which can make files larger and mapping more complex. Dates and codes in CII often use separate data type declarations (like a date value plus a format code, reminiscent of EDIFACT standards), whereas UBL directly uses standardized strings. These differences mean a solution must implement distinct mapping and validation rules for CII to ensure the same information is correctly represented. [invoicenavigator.eu] [invoice-co…verter.com]

Hybrid Formats: Factur‑X / ZUGFeRD (PDF + XML)

Factur-X (France) and ZUGFeRD (Germany) are twin hybrid e-invoicing formats that bridge the gap between PDF-based invoicing and fully structured XML. They follow the principle of a PDF/A-3 file (which humans and existing workflows can handle easily) containing an embedded CII XML for machine processing. Technically, Factur-X and ZUGFeRD use the same CII D16B structure internally and differ only in their documentation language and local profiles, so they’re often mentioned together. [invoicenavigator.eu]

• Factur-X was introduced in France (co-developed with Germany) as part of the push to modernize B2B invoicing while minimizing friction for SMEs that prefer PDFs. It’s essentially a PDF invoice that includes a visible invoice and an attached EN 16931-compliant CII file. France’s upcoming B2B e-invoicing mandate (2024–2026 rollout) explicitly supports Factur-X as one of the formats on its central platform. [invoicenavigator.eu]
• ZUGFeRD (short for “Zentraler User Guide für elektronische Fakturen in Deutschland”) is the German name for the same concept. It has been used in Germany’s business community as a voluntary standard and complements the official XRechnung (which is XML-only) by offering a solution for businesses and sectors that still want a PDF copy of invoices.

These hybrid formats come with multiple profiles (e.g., Basic, Comfort, Extended in ZUGFeRD) that vary the data content from minimal to full EN 16931 detail. Hybrid invoices are particularly helpful during transition periods – they allow companies to maintain familiar PDF processes for recipients (ensuring readability and easy printing if needed), while still fulfilling digital reporting and archiving requirements with the attached XML. One key challenge is ensuring that the PDF’s human-readable content matches the XML’s data, as mismatches can cause confusion or compliance issues. Nonetheless, Factur-X/ZUGFeRD provide a pragmatic stepping stone for businesses moving from unstructured to structured invoicing. [invoicenavigator.eu]

National E-Invoice Formats (Non‑EN / Domestic Standards)

Several EU countries have homegrown e‑invoice formats – some predate EN 16931, others run in parallel to it. Here we summarize the major ones:

• Italy – FatturaPA: FatturaPA is Italy’s proprietary XML invoice format, introduced in 2014 when Italy pioneered a national e-invoicing mandate. It became mandatory for B2G in 2015 and then for all domestic B2B and B2C invoices in 2019 via the SDI (Sistema di Interscambio) clearance platform. Legally, FatturaPA is not an EN 16931 syntax, as it was developed independently by Italy. However, Italy has aligned FatturaPA’s content closely with EN 16931 (e.g. including all required data fields). When EU suppliers send an EN 16931-compliant invoice to Italian public bodies, the SDI platform converts it automatically into FatturaPA format for processing. Thus, the Italian system ensures compliance with the EU standard by mapping EN 16931 invoices to its national schema behind the scenes. For cross-border exchanges, businesses may need to convert between FatturaPA and UBL/CII to interoperate with counterparties outside Italy. Italy’s case highlights how legacy e-invoice systems can coexist with the EU standard through mapping and CIUS (Core Invoice Usage Specifications) that align national rules with EN 16931. [invoicenavigator.eu], [invoicenavigator.eu] [ec.europa.eu] [invoicenavigator.eu]
• Spain – Facturae: Facturae (sometimes styled FacturaE) is Spain’s national XML invoice format, mandatory since 2015 for B2G invoices above €5,000. Facturae is used to send invoices to public administrations via the FACe portal, and it requires an XAdES digital signature for authenticity. B2B e-invoicing in Spain is currently voluntary (except for certain large companies), but legislation (“Crea y Crece” law) plans to make B2B e-invoicing mandatory from 2027–2028, and to align Spanish practices with EN 16931 and ViDA. Spain’s approach appears to allow multiple formats for B2B: draft plans suggest that EN 16931-compliant UBL and CII will be acceptable, as well as legacy formats like EDIFACT and even the domestic Facturae. UBL (via Peppol) is expected to play a leading role for connectivity to the central Spanish B2B e-invoicing platform (the planned SPFE), but existing formats won’t be abruptly displaced. This underscores Spain’s recognition that businesses may need to gradually migrate from older systems (like EDIFACT networks or local Facturae infrastructure) toward more harmonized formats. Ultimately, Facturae remains a local standard, not part of the European standard’s syntaxes; long-term, Spain aims for interoperability by embracing EN 16931 while also temporarily accommodating familiar formats. [lawants.com], [lawants.com] [lawants.com]
• Germany – XRechnung: XRechnung is Germany’s national e-invoice specification (CIUS) built on EN 16931. It is not a new syntax, but a set of additional rules and restrictions applied to the EN 16931 model and allowed syntaxes, ensuring consistency for Germany’s needs. XRechnung has been mandatory for B2G invoices in Germany since 2020 and, as of January 2025, German businesses must also be able to receive e-invoices (structured) from their suppliers. XRechnung supports either UBL or CII XML – both are allowed under the XRechnung CIUS guidelines, and tools in Germany often handle both. XRechnung’s rules (around 140+ additional constraints) enforce specifics like IBAN formats, the use of a government routing code (Leitweg-ID) on B2G invoices, and other German legal particulars. Essentially, XRechnung is an example of a CIUS, ensuring that EN 16931’s flexibility is narrowed down for national uniformity. [invoicenavigator.eu]
• Austria – ebInterface: ebInterface is an Austrian XML e-invoice standard developed by the country’s national standards body and in use since before EN 16931. B2G e-invoicing has been mandatory in Austria since 2014, and public entities accept either ebInterface or Peppol BIS (UBL) via a central government portal. ebInterface 6.0 (the current version) is aligned with the EN 16931 semantic model but includes some Austria-specific extensions. For companies operating in multiple markets, Austrian authorities themselves advise that Peppol UBL is the more interoperable choice for B2G, even though ebInterface remains supported. There is no B2B mandate yet in Austria (likely pending EU-level rules), so B2B e-invoicing is voluntary – here again many businesses use Peppol or EDI. [invoicenavigator.eu] [invoicenavigator.eu], [invoicenavigator.eu]
• Finland – Finvoice (and TEAPPSXML): Finland has a long history of e-invoicing with active B2B and B2C use via bank and operator networks. Finvoice is a national XML format maintained by Finance Finland, commonly used by banks and businesses, while TEAPPSXML is another format used by certain operator networks. To align with EU requirements, Finvoice 3.0 and TEAPPSXML 3.0 were updated to follow the EN 16931 semantic model. (Earlier versions did not fully meet the standard’s requirements). Finnish public entities have been required since April 2020 to accept e-invoices that conform to the European standard, and they typically accept either Finvoice or Peppol BIS 3.0 (which Finland has also adopted). In practice, given Finland’s integration with the Pan-European networks, Peppol UBL is increasingly common, but the domestic Finvoice standard remains in use especially for local B2B and bank-facilitated exchanges. Finvoice demonstrates how a country-specific format can evolve to incorporate the common EU standard’s semantic requirements without abandoning its original syntax. [tieke.fi], [tieke.fi] [tieke.fi]
• Poland – KSeF Schema: Poland’s KSeF (Krajowy System e-Faktur), which became mandatory in 2026, uses a proprietary national XML schema for invoices reported to its platform. Poland’s approach is somewhat unique: while the KSeF schema is largely based on EN 16931’s data model, it’s not identical to UBL or CII. It includes additional fields (to cover Polish legal requirements) and a different structure. Since KSeF is a clearance system, all invoices must be submitted in this format (or via JSON APIs that produce it). Poland’s is an example of how a Member State can pursue a custom model while still referencing EN 16931 for core content. Over time, we may see efforts to cross-map KSeF to UBL/CII for interoperability (especially if cross-border invoices require standard formats). [invoicenavigator.eu]
• Other legacy or domestic formats: Several other European countries have had their own e-invoice formats or EDI-based systems:
  • EDIFACT (EDI): Long before XML, electronic invoicing in industries like retail and manufacturing often used EDIFACT messages (the international EDI standard). The INVOIC message in EDIFACT is still popular in many global supply chains. EDIFACT is not an EN 16931-approved syntax, but its data can be mapped to the EN 16931 model. Some national implementations have signaled that EDIFACT invoices will be allowed (e.g., Spain’s planned B2B system explicitly lists EDIFACT as accepted, likely to accommodate big companies with existing EDI systems). In the context of EU compliance, however, if an invoice is transmitted by EDIFACT, it may need to be converted into an EN 16931 XML at the receiving end or through an intermediary to satisfy official requirements. [lawants.com]
  • Other national XML standards: A few countries still support older national standards: e.g., Hungary’s E-Invoice XML (though now overshadowed by real-time VAT reporting requirements), Greece’s UBL-based myDATA format, and others. Many of these are converging toward the EN 16931 model due to the influence of EU harmonization and the need for interoperability. EU countries outside the main Peppol network sometimes maintain their local schema until new mandates push them to switch to (or at least accept) the common formats.

CIUS and Extensions – Tailoring the Standard

To manage the balance between a pan-European standard and local needs, EN 16931 allows controlled extensions and restrictions through CIUS (Core Invoice Usage Specifications) and Extensions. A CIUS is essentially a customized implementation of the European standard: it can add extra business rules or restrict optional fields for a specific context (such as a country or industry). Unlike an entirely separate format, a CIUS still uses one of the base syntaxes (UBL or CII) but with profile-specific rules. For example, XRechnung is the German CIUS, adding 147 rules to EN 16931 for use in Germany. French public sector has its own CIUS (internally called “CIUS FNFE” in some docs) that tailors the standard for domestic B2G needs, even though Factur-X (outside the pure EN 16931 scope) is also used. Meanwhile, Peppol BIS Billing 3.0 can be seen as a transnational CIUS – it applies additional rules on top of the standard’s requirements to facilitate cross-border e‑invoicing between businesses and governments. [invoice-co…verter.com] [invoicenavigator.eu]

EN 16931 also permits Extensions to add information not covered by the standard, if needed by specific industries or processes. However, any such extension must not break core compliance – meaning all mandatory fields are still present and unaltered. In practice, relatively few extensions are used; instead, countries tend to rely on CIUS to narrow or clarify the standard. The presence of CIUS and Extension mechanisms underscores that a “one-size-fits-all” approach doesn’t always suffice – it’s a recognition of diversity in national requirements within a harmonized framework. [ec.europa.eu], [ec.europa.eu]

Why Multiple Syntaxes Coexist (and Will Continue To)

The coexistence of multiple e‑invoice syntaxes in Europe is by design. The EU’s goal was to harmonize invoice content across members – ensuring every essential piece of information is present – while allowing flexibility in how it’s implemented technically. By officially endorsing both UBL and CII, the European standard catered to different stakeholder preferences: [invoicenavigator.eu], [invoicenavigator.eu]

• Historical and community preferences: Some countries/agencies already used UBL (through various initiatives), while others were aligned with UN/CEFACT or EDI frameworks. Embracing both prevented alienating large user bases or existing solutions, smoothing the transition to a common standard. [invoicenavigator.eu], [invoicenavigator.eu]
• Policy neutrality: The EU often avoids prescribing a specific technology where multiple credible options exist, to not favor one standardization body over another. UBL and CII come from different standard bodies, OASIS and UN/CEFACT, respectively – supporting both was a diplomatic choice ensuring broad buy-in.
• Use-case coverage: UBL’s simplicity and widespread use make it ideal for broad adoption and smaller businesses; CII’s rich structure caters to high-complexity scenarios and hybrid PDF integration. Both have merits, and different scenarios may call for one or the other. [invoicenavigator.eu], [invoicenavigator.eu]
• Gradual convergence over time: Rather than forcing immediate uniformity, the EU expects that market forces and cross-border networks (like Peppol) will naturally drive convergence (likely favoring UBL) for many use cases. Meanwhile, formats like Facturae, Finvoice, FatturaPA, or EDIFACT won’t vanish overnight. The strategy is to interoperate and map these to the standard’s semantics, allowing gradual migration. For example, Italy’s SDI converts between European standard invoices and FatturaPA automatically, and service providers increasingly offer format conversion tools (e.g., turning EDIFACT into UBL) to help companies comply with new mandates. [invoicenavigator.eu] [ec.europa.eu]

Looking ahead, the ViDA initiative and 2026 revision of EN 16931 continue to emphasize semantic harmonization while supporting different technical channels and formats. Interoperability will likely trump uniformity. For businesses, the key is to understand the web of formats and plan e‑invoicing architectures accordingly: typically by using an internal canonical data model (based on EN 16931 semantics) and then outputting into whichever syntax is needed for a given country or partner. By designing systems that accommodate multiple formats, organizations can ensure compliance in every EU market and adapt to evolving standards. The multi-syntax reality of European e‑invoicing is not a temporary patch, but a reflection of Europe’s diverse digital landscape – one that companies can master with a strategic, flexible approach. [invoicenavigator.eu]

 

 

---

---