fiskaly.

13 min read

E-invoice format guide: UBL, XRechnung, FatturaPA, and Facturae compared

UBL and CII are XML syntaxes; XRechnung and Factur-X build on them; FatturaPA and Facturae don't. A side-by-side guide to every major EU e-invoice format.

Victoria Waba, Content Marketing Manager
Victoria WabaContent Marketing Manager
woman on laptop

A payment or invoicing team building for one EU market can pick a format and stop thinking about it. A team building for four or five markets can't, because the four names that come up most, UBL, XRechnung, FatturaPA, Facturae, don't sit on the same level. Two of them are XML syntaxes. Two are national schemas that predate the European e-invoicing standard entirely and don't use either syntax. This guide sits alongside fiskaly's format-specific deep dives on XRechnung, ZUGFeRD/Factur-X, UBL vs. CII, and Italy's and Spain's national systems; rather than covering any one format in isolation, it lines them up against each other so the differences that actually matter for a multi-market rollout are visible in one place.

TL;DR

  • UBL and CII are XML syntaxes, not finished invoice formats. Country-level specs decide which fields are mandatory.
  • XRechnung and Factur-X/ZUGFeRD build on those syntaxes and comply with the EN 16931 standard.
  • FatturaPA (Italy) and Facturae (Spain) predate EN 16931 and use neither UBL nor CII.
  • Factur-X/ZUGFeRD ships in six profiles, from MINIMUM up to EXTENDED, each carrying a different depth of data.
  • Peppol BIS Billing 3.0 is a UBL profile for network exchange, not a competing format.

What is UBL, and where is it used?

UBL (Universal Business Language) is an open XML standard maintained by OASIS that defines a generic structure for business documents, including invoices, credit notes, and orders. A UBL invoice uses two namespace prefixes: cbc (Common Basic Components) for simple fields like dates and amounts, and cac (Common Aggregate Components) for structured blocks like parties and addresses. The root element of a UBL invoice is <Invoice>; credit notes use <CreditNote> instead.

UBL 2.1 is the current version in active use for e-invoicing. It is broader than any single national mandate: it supports dozens of optional fields that individual countries or networks then restrict into a CIUS (Core Invoice Usage Specification). Peppol BIS Billing 3.0, Germany's XRechnung (UBL variant), and the Netherlands' NLCIUS are all CIUS profiles built on the same UBL 2.1 schema. The underlying XML grammar does not change across borders; only the business rules layered on top of it do.

What is UN/CEFACT CII, and how does it differ from UBL?

CII (Cross Industry Invoice) is the second EN 16931-recognized syntax, maintained by UN/CEFACT, and it is the syntax used inside hybrid formats like Factur-X and ZUGFeRD. Structurally, CII organizes an invoice around trade-transaction concepts, using elements like ExchangedDocument, SellerTradeParty, BuyerTradeParty, and SpecifiedTradeSettlement, rather than UBL's document-component model. Both syntaxes can express the same EN 16931 semantic content.

In practice, the choice between UBL and CII is not usually made invoice by invoice. It is set by whichever format the receiving country or platform expects. Germany's XRechnung, for example, lets the sender choose either UBL or CII XML for the same underlying data, and the resulting files are functionally equivalent once validated. That free choice applies to XRechnung itself; the transmission channel can constrain it in practice, since Peppol BIS Billing 3.0 requires UBL and ZUGFeRD/Factur-X hybrids use CII only. Direct submission through a portal like OZG-RE still allows either syntax.

What is XRechnung, and is it UBL or CII?

XRechnung is Germany's national CIUS (Core Invoice Usage Specification) of EN 16931: a pure, structured XML file with no PDF or visual layer, available in either UBL or CII syntax. It is not a hybrid format. An XRechnung file is meant to be processed by software, not opened and read directly.

The current version is XRechnung 3.0.2, identified in the XML by its CustomizationID field, which confirms both EN 16931 compliance and the specific German extension rules. XRechnung 4.0, implementing EN 16931-1:2026, is expected in late 2026 and will supersede 3.0.2. Because XRechnung is a CIUS rather than a separate schema, its UBL variant is compatible with the broader Peppol BIS Billing 3.0 profile. A UN/CEFACT CII-based XRechnung file uses the same underlying schema as the EN 16931 profile embedded in a ZUGFeRD 2.x PDF. Invoices to German federal bodies go through the OZG-RE platform, which replaced the ZRE in 2025; Länder and municipalities operate their own channels. These platforms validate incoming files against the same open-source KoSIT validator rules that most German software uses to check compliance before sending. fiskaly also offers SIGN DE for German fiscalization; it runs on a separate, country-specific API today, with a shared integration onto fiskaly's unified platform planned for 2027.

What is Factur-X/ZUGFeRD, and what are its profiles?

Factur-X and ZUGFeRD are the same hybrid invoice format under two names: a human-readable PDF/A-3 document with a structured CII XML file embedded inside, jointly developed by France's FNFE-MPE and Germany's FeRD. Since ZUGFeRD 2.1 (2020), the two specifications have been technically identical: same XML schema, same PDF/A-3 container, same profile tiers, and even the same embedded filename, factur-x.xml. Only the brand name differs by market.

The format defines six profiles, each carrying progressively more structured data:

ProfileStructured Data DepthTypical Use Case
MINIMUMAround 15-20 core fields (invoice number, date, seller, total)Very simple B2C invoices; does not suffice as a valid B2B e-invoice from January 2026 onwards
BASIC WL (Without Lines)Basic fields, no structured line itemsSimple invoices without automation needs; does not suffice as a valid B2B e-invoice from January 2026 onwards
BASICStructured line items, taxes, totalsStandard invoices with structured line items; does not fully cover EN 16931 and does not suffice as a valid B2B e-invoice from January 2026 onwards
EN 16931 (COMFORT)Full EN 16931 semantic model, 200+ possible elementsPublic procurement (B2G); most common profile for full automation
EXTENDEDEN 16931 plus industry-specific extensionsManufacturing, logistics, construction supply chains

MINIMUM and BASIC WL are reduced-data profiles originally driven by French requirements (Chorus Pro) and intended as booking aids or transition formats. They don't satisfy Germany's invoicing requirements and shouldn't be used there. For B2B, EN 16931 (COMFORT) is the practical default; B2G in Germany requires the XRECHNUNG profile or native XRechnung.

What is FatturaPA, and why doesn't it use EN 16931 syntax?

FatturaPA is Italy's own XML schema for electronic invoicing, predating EN 16931, and it is the format the Sistema di Interscambio (SDI) requires for domestic invoicing. UBL and CII files are not valid substitutes for domestic transactions. Cross-border suppliers invoicing Italian public bodies can instead use CIUS-IT ("FatturaEU"), an EN 16931-compliant profile the SDI maps onto the national schema. Every FatturaPA file has a single root element, <FatturaElettronica>, split into a FatturaElettronicaHeader (routing and party data) and one or more FatturaElettronicaBody sections (line items, totals, payment terms). The schema is maintained and periodically updated by the Agenzia delle Entrate at fatturapa.gov.it.

A few structural details set FatturaPA apart from UBL- or CII-based formats:

  • Invoices to public bodies must carry a digital signature (CAdES (.p7m) or XAdES); for B2B and B2C transactions the signature is optional, though still recommended.
  • Routing depends on a CodiceDestinatario (a seven-digit recipient code registered with the SDI) or a certified PEC email address when no code is registered.
  • The TipoDocumento field classifies the transaction type. TD01 marks a standard invoice, TD04 a credit note, and so on: a classification concept with no direct UBL or CII equivalent in the same form.
  • File naming follows a fixed pattern: the sender's VAT-prefixed country code, VAT number, and a progressive number (for example, IT01234567890_00001.xml).

Because FatturaPA sits outside the EN 16931 family, any business generating UBL or CII invoices for other EU markets needs a separate conversion path specifically for Italian counterparties.

What is Facturae, and how does it differ from FatturaPA?

Facturae is Spain's national XML schema, used for B2G invoicing since 2015 through the FACe platform, and, like FatturaPA, it is not built on the UBL or CII syntax. The current schema version is 3.2.2 (the FACe platform requires at least 3.2.1). A valid Facturae file follows four main blocks in a fixed sequence: the file header (with SchemaVersion, Modality, and InvoiceIssuerType fields), the parties block, the invoice or batch details, and the invoice totals. Reordering those blocks triggers an immediate validation failure. Facturae's XSD schema strictly enforces both field order and data types.

Spain's upcoming B2B e-invoicing mandate under the Crea y Crece law does not retire Facturae. It adds UBL, CII, and EDIFACT as accepted formats between private platforms, while still requiring a "faithful copy" of every invoice in UBL format to reach the AEAT's public platform. That makes Spain one of the few EU markets where a legacy national schema and the EN 16931 syntaxes are both explicitly accepted side by side, rather than one replacing the other.

Key takeaways

  • Germany and France share the same format family. EN 16931-based formats, XRechnung and Factur-X, cover both markets without a separate national schema.
  • Italy and Spain need dedicated schema logic. A generic UBL/CII pipeline will not produce a valid FatturaPA or Facturae file; both require purpose-built generation and validation.
  • EN 16931 (COMFORT) is the safe default profile for Factur-X/ZUGFeRD. MINIMUM and BASIC WL don't carry enough data for German domestic use and shouldn't be treated as interchangeable with COMFORT.
  • Peppol adoption is growing as the transport layer, but it doesn't remove the need to generate FatturaPA or Facturae for markets that don't accept UBL directly.
  • A four- or five-market rollout typically needs at least three distinct XML pipelines: UBL/CII-based, FatturaPA, and Facturae, generated from the same underlying invoice data.

How do these formats relate to Peppol BIS Billing 3.0?

Peppol BIS Billing 3.0 is not a separate invoice format. It is a CIUS that restricts UBL 2.1 for exchange over the Peppol network. It takes the broad, mostly-optional UBL 2.1 schema and makes specific fields mandatory (both trading parties' legal name, address, and Peppol endpoint ID, for example), so that any two businesses on the Peppol network can exchange invoices without a prior bilateral agreement on which optional fields to use. How that exchange is actually routed between the two parties, through access points and the four-corner model, is its own topic; a separate fiskaly guide to the Peppol network covers that mechanism in depth.

This is why a UBL-based XRechnung and a Peppol BIS Billing 3.0 invoice can look nearly identical at the XML level. Both are EN 16931-compliant CIUS profiles of the same base UBL schema, with different mandatory-field rules layered on top. FatturaPA and Facturae sit outside this relationship entirely, since neither is a UBL or CII derivative.

Comparison table: format overview

FormatBase SyntaxFile TypeEN 16931-Compliant?Primary Market/NetworkHuman-Readable Without Software?
UBL 2.1UBL (OASIS)Pure XMLPartly includedDepends on CIUSPeppol network, multi-countryNot included
UN/CEFACT CIICIIPure XMLPartly includedDepends on CIUSEmbedded in hybrid formatsNot included
Peppol BIS Billing 3.0UBL 2.1 (CIUS)Pure XMLIncludedPeppol network (Belgium mandatory, EU-wide voluntary/growing)Not included
XRechnungUBL or CII (CIUS)Pure XMLIncludedGermany (B2G mandatory, B2B accepted)Not included
ZUGFeRD / Factur-XCIIHybrid PDF/A-3 + embedded XMLIncludedEN 16931/COMFORT profile and aboveGermany, France (mandatory in France from Sept 2026)IncludedPDF layer
FatturaPAProprietary XMLPure XMLNot includedItaly (SDI, mandatory since 2019)Not included
FacturaeProprietary XMLPure XMLNot includedSpain (B2G since 2015; B2B alongside UBL/CII from 2026 onward)Not included

How to choose which format(s) to support

  1. List every country you invoice from and every country you invoice to. Format acceptance is set at the country level, and a format valid in one market may be worthless in another.
  2. Check whether the country accepts EN 16931 formats or requires a proprietary schema. Germany and France accept EN 16931-based files. Italy requires FatturaPA specifically, and Spain requires Facturae or a UBL "faithful copy" depending on the flow.
  3. Decide between a pure XML format and a hybrid format where you have a choice. XRechnung (pure XML) suits fully automated back-office processing; Factur-X/ZUGFeRD suits mixed environments where a human sometimes still needs to open and read the invoice.
  4. Pick the right profile if you are generating Factur-X/ZUGFeRD. EN 16931 (COMFORT) covers most B2G and standard B2B needs. Move to EXTENDED only if your industry genuinely requires the additional trade data.
  5. Confirm the transmission path separately from the format. A correctly built XRechnung still needs to go through Peppol or a platform like the OZG-RE; a correctly built FatturaPA file still needs to go through the SDI.
  6. Build conversion logic once you support more than two formats. Businesses operating in Germany, France, Italy, and Spain simultaneously typically need to generate at least three structurally different XML outputs (UBL/CII-based, FatturaPA, and Facturae) from the same underlying invoice data.

Bottom line

Every major EU e-invoice format falls into one of two families: EN 16931-based formats built on UBL or CII syntax (XRechnung, Factur-X/ZUGFeRD, Peppol BIS Billing 3.0), and older national schemas that predate the European standard (FatturaPA, Facturae). Knowing which family a market belongs to, and which specific profile or schema version it expects, matters more than knowing the EU's general e-invoicing direction. The file your software generates has to match exactly what the receiving country's platform will validate.

For the country-by-country deadlines and mandate status behind these formats, see fiskaly's guide to Europe's e-invoicing mandates. For format generation, validation, and Peppol connectivity across multiple markets from a single integration, see fiskaly E-INVOICE.

Frequently asked questions

No. XRechnung is a pure XML file with no PDF component. ZUGFeRD is a hybrid format that embeds a similar structured XML, in CII syntax, inside a human-readable PDF. Both can comply with EN 16931, but they are different file types.

Yes, since ZUGFeRD 2.1 (2020). They use the same XML schema, the same PDF/A-3 container, the same six-profile structure, and even the same embedded filename, factur-x.xml. Only the brand name differs by market.

Not as a valid e-invoice under Italian law. Italy's SDI only accepts FatturaPA XML for domestic B2B, B2C, and B2G transactions, so a UBL file would need to be converted to FatturaPA first.

Yes. Facturae remains mandatory for Spanish B2G invoicing via FACe, and it stays on the list of accepted formats for private B2B exchange even as UBL, CII, and EDIFACT are added under the Crea y Crece framework.

The EN 16931 (also called COMFORT) profile. It fully covers the European semantic standard and is the profile most public-sector recipients expect. MINIMUM and BASIC WL exist mainly for simple, low-automation scenarios and should not be used for German domestic invoices.

No. Peppol BIS Billing 3.0 is built directly on UBL 2.1. It is a stricter usage profile of the same schema, not an alternative to it.

No. Format requirements are set per country. A business invoicing only within Germany, for example, only needs to handle EN 16931-compliant formats accepted there (XRechnung or ZUGFeRD/Factur-X), not FatturaPA or Facturae.