Infinite IT Solutions Blog | EDI | e-Invoicing Compliance

XRechnung vs ZUGFeRD vs Factur-X: E-Invoice Formats Explained Before Germany's 2027 Mandate

Written by Admin | Oct 26, 2026, 12:14:29 PM

From 1 January 2027, German businesses with prior-year turnover above EUR 800,000 must issue structured e-invoices for domestic B2B transactions, and from 1 January 2028 the obligation covers every business. The law does not prescribe a single format. It accepts any invoice that conforms to the European standard EN 16931 or can be fully extracted into it, which in practice means a choice between XRechnung, ZUGFeRD and, for cross-border flows with France, Factur-X.

This guide explains how XRechnung, ZUGFeRD and Factur-X differ in structure, syntax, profiles and legal acceptance, how they relate to Peppol BIS Billing 3.0 and to EN 16931, and how to decide which format your ERP or e-invoicing platform should produce before the German deadline. It is written for IT managers, compliance officers and finance leaders who need to specify a format, not just recognise the acronyms. For the wider regulatory context, see our Complete Guide to Global E-Invoicing Compliance.

Key takeaways

  • XRechnung is a pure XML format (UBL 2.1 or UN/CEFACT CII) maintained by KoSIT. It is the designated standard for invoices to German public authorities and fully valid for B2B.
  • ZUGFeRD is a hybrid format: a PDF/A-3 file with an embedded CII XML. Only the BASIC, EN 16931 and EXTENDED profiles (plus the XRECHNUNG reference profile) qualify as e-invoices under German VAT law; MINIMUM and BASIC WL do not.
  • Factur-X is technically the same specification as ZUGFeRD, published jointly by FeRD (Germany) and FNFE-MPE (France). ZUGFeRD 2.5 corresponds to Factur-X 1.09, released on 10 June 2026.
  • In a hybrid invoice, the XML is the legally decisive part. If the PDF and the XML disagree, the XML governs and the mismatch creates VAT risk.
  • Most multinational groups end up supporting more than one format. The decision is less about which format is "best" and more about which the receiver's channel requires.

Why the format question matters in Germany now

Germany's e-invoicing mandate under the Growth Opportunities Act (Wachstumschancengesetz) is phased. Since 1 January 2025, every business established in Germany must be able to receive structured e-invoices for domestic B2B supplies, and the buyer's consent is no longer required. Until 31 December 2026, suppliers may still issue paper invoices or, with the recipient's agreement, unstructured formats such as plain PDFs.

From 1 January 2027, suppliers whose total turnover in the previous calendar year exceeded EUR 800,000 must issue structured e-invoices. The threshold is tested at the level of the legal entity, so 2026 turnover decides whether a company is in scope from the first day of 2027. From 1 January 2028, the obligation applies to all remaining businesses, and the transition allowance for legacy EDI invoices that cannot be mapped to EN 16931 also ends. The Federal Ministry of Finance (BMF) has rejected calls for a postponement, and its FAQs were updated again in March 2026 without any change to the timeline.

Some invoices stay outside the obligation: small-amount invoices up to EUR 250 gross, passenger transport tickets, supplies exempt under section 4 numbers 8 to 29 of the German VAT Act (UStG), B2C sales and cross-border transactions. Small businesses (Kleinunternehmer) are exempt from issuing, but must still be able to receive. For everyone else, the practical question becomes: which structured format should the ERP, billing system or e-invoicing platform generate?

German law answers that question only indirectly. Section 14 UStG defines an e-invoice as an invoice issued, transmitted and received in a structured electronic format that enables electronic processing and either complies with EN 16931 or is interoperable with it. XRechnung and ZUGFeRD are the two national formats explicitly named by the BMF as compliant. Factur-X enters the picture because it is the French-branded twin of ZUGFeRD and one of three formats accepted under France's mandate, which has applied to invoice reception for all French businesses since 1 September 2026.

EN 16931: the common semantic model behind all three formats

EN 16931 is the European standard for the semantic data model of a core electronic invoice. It defines around 160 business terms (BT) grouped into business groups (BG), such as seller, buyer, VAT breakdown and invoice line, together with business rules that every compliant invoice must satisfy. The standard is syntax-neutral: the same semantic invoice can be expressed in UBL 2.1 XML or in UN/CEFACT Cross Industry Invoice (CII) XML.

National or sector-specific restrictions of the model are called Core Invoice Usage Specifications (CIUS). A CIUS may make optional elements mandatory or forbid certain elements, but it cannot add new ones. Extensions, by contrast, add elements beyond the core. XRechnung is a CIUS. ZUGFeRD's EN 16931 profile is a direct implementation of the core model, its BASIC profile is a subset, and its EXTENDED profile is an extension.

The standard was revised in 2026. CEN approved EN 16931-1:2026, with the definitive text released in March 2026, to widen the model from its original B2G focus toward complex B2B transactions and the digital reporting requirements that ViDA will introduce for intra-EU trade from 2030. Existing implementations keep their legal validity during the transition, but format publishers are already aligning their releases to the new text. We cover the revision in detail in EN 16931 Explained.

XRechnung: Germany's pure-XML standard

XRechnung is the German CIUS of EN 16931, developed and maintained by KoSIT (Koordinierungsstelle für IT-Standards), the coordination office for IT standards hosted by the Free Hanseatic City of Bremen. It exists in two syntaxes, UBL 2.1 and CII, and both are equally valid. KoSIT publishes new versions twice a year, effective 1 February and 1 August, together with a validator and Schematron rules. The current major version is XRechnung 3.0, with the 3.0.2 bundle receiving a bug-fix release dated 31 August 2026 that updated the validator and CEN artefacts without changing the standard itself.

XRechnung is the standard designated for invoices to the German public sector. Under the federal E-Rechnungsverordnung, suppliers have had to submit e-invoices for federal direct contracts worth EUR 1,000 net or more since 27 November 2020, and the federal e-invoicing portal also accepts other EN 16931-compliant formats, such as ZUGFeRD from version 2.2.0, provided they carry the federal mandatory fields. The federal states apply their own B2G rules. The format adds German business rules on top of the core model. The best known is the Leitweg-ID, a routing identifier that the public-sector buyer provides and the supplier must place in the BuyerReference field. Other national rules concern identifier schemes for German parties, tax representative details and restrictions on some optional EN 16931 elements.

Federal bodies receive e-invoices through the OZG-RE submission portal, which absorbed the former ZRE in September 2025, by email or over the Peppol network. Since Germany's national Peppol ruleset of February 2025, a Peppol BIS Billing 3.0 invoice in UBL is treated as content-equivalent to an XRechnung for federal recipients, which matters for foreign suppliers that already operate on Peppol. Note that BIS Billing 3.0 is UBL-only, so a CII XRechnung cannot be sent through that channel.

For B2B, XRechnung is simply one of the accepted EN 16931 formats. Its advantage is precision: there is no PDF to reconcile, the validator is free and authoritative, and the UBL variant travels natively over Peppol. Its disadvantage is that the file is not human-readable without a viewer, which still unsettles accounts-payable teams used to opening a PDF.

ZUGFeRD: the hybrid PDF/A-3 format

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is published by FeRD, the German e-invoicing forum, together with the French FNFE-MPE. A ZUGFeRD invoice is a PDF/A-3 document with an embedded XML file in UN/CEFACT CII syntax. The reader sees a familiar invoice image; the accounting system reads the XML. The current release is ZUGFeRD 2.5, published on 10 June 2026, which updated code lists and validation artefacts to the latest EN 16931 code list release and added EXTENDED-profile elements anticipating the revised EN 16931-1. A technical corrigendum, ZUGFeRD 2.5.2, followed on 4 August 2026 and applies from 1 September 2026. FeRD now aims to publish an update shortly after each semi-annual EU code list release, with gross-invoice support planned for a later release.

ZUGFeRD defines profiles with increasing data depth:

ProfileContentQualifies as an e-invoice under German VAT law?
MINIMUMHeader totals only, no line items or VAT breakdownNo. Lacks mandatory VAT information.
BASIC WLHeader and VAT breakdown, no line itemsNo. Lacks mandatory line-level information.
BASICSubset of EN 16931 with line itemsYes (from version 2.0.1).
EN 16931 (formerly COMFORT)Full EN 16931 core invoiceYes. The recommended B2B profile.
EXTENDEDEN 16931 plus additional elements for complex industriesYes, though receivers may not process the extensions.
XRECHNUNG (reference profile)CII XML conforming to the XRechnung CIUSYes. Suitable for German public-sector recipients.

The profile distinction is where many implementations go wrong. A PDF produced by billing software in the MINIMUM profile looks like a compliant ZUGFeRD invoice but is legally an "other invoice" (sonstige Rechnung), which means the supplier has not met the issuing obligation and the recipient may refuse it. Compliance teams should check which profile the ERP or output management system generates by default and lock it to EN 16931 or higher.

The BMF letter of 15 October 2025, which followed the first letter of 15 October 2024 and amended the VAT application decree, settled another point: in a hybrid invoice, the structured XML is the leading part. If the PDF image shows different content from the XML, the document may be treated as an additional invoice, with the risk of VAT being owed twice under section 14c UStG. Input VAT is to be taken from the XML. The operational consequence is that the PDF and the XML must be generated from the same data set, never from two separate processes.

Factur-X: the same standard with a French passport

Factur-X is the French name for the ZUGFeRD specification. The two forums publish each release jointly, so ZUGFeRD 2.5 equals Factur-X 1.09 and ZUGFeRD 2.5.2 equals Factur-X 1.09.2. The XML schema, the profiles and the validation files are identical; only the branding differs. Since Factur-X 1.0 the format has been based on PDF/A-3 with CII XML, and the 2026 releases are built on UN/CEFACT CII D22B while remaining backwards-compatible with D16B.

Factur-X matters for German companies because of France. Since 1 September 2026, every business established in France must be able to receive e-invoices through an accredited platform (plateforme agréée), and large and mid-sized companies must already issue them; SMEs follow on 1 September 2027. The French mandate accepts three formats: Factur-X, UBL 2.1 and CII. A group with entities in both countries can therefore standardise on a single hybrid output and remain compliant on both sides of the border, as long as the profile, code lists and platform routing follow each country's rules. Our post on France e-invoicing after go-live covers the French side in detail.

One difference to remember is governance. In Germany there is no central clearance platform for domestic B2B: invoices travel directly between trading partners by email, Peppol or portal. In France every B2B invoice passes through an accredited platform that also extracts e-reporting data for the tax authority. The same Factur-X file therefore faces a stricter technical gate in France than in Germany.

XRechnung vs ZUGFeRD vs Factur-X: side-by-side comparison

CriterionXRechnungZUGFeRDFactur-X
PublisherKoSIT (Germany)FeRD (Germany) with FNFE-MPEFNFE-MPE (France) with FeRD
StructurePure XMLPDF/A-3 with embedded XMLPDF/A-3 with embedded XML
SyntaxUBL 2.1 or CIICII onlyCII only
Relationship to EN 16931CIUS (restriction)Profiles from subset to extensionIdentical to ZUGFeRD
Current version3.0.2 (bug-fix bundle 31 Aug 2026)2.5.2 (applies from 1 Sep 2026)1.09.2 (applies from 1 Sep 2026)
Human-readableNo, viewer requiredYes, via the PDF layerYes, via the PDF layer
German B2GDesignated standard for public authoritiesAccepted by the federal portal from 2.2.0 with Leitweg-ID; XRECHNUNG reference profile recommendedNot used
German B2BCompliantCompliant in BASIC, EN 16931, EXTENDEDCompliant (same profiles)
French B2BNot named; UBL 2.1 and CII are accepted as syntaxesAccepted as Factur-XOne of three mandated formats
Peppol transportUBL variant travels as BIS Billing 3.0Requires a Peppol specification for hybrid documents or conversion to UBLSame as ZUGFeRD

Where Peppol BIS Billing 3.0 fits

Peppol BIS Billing 3.0 is itself a CIUS of EN 16931, expressed in UBL 2.1 and used as the default invoice specification on the Peppol network. It is not a competitor to XRechnung so much as an alternative packaging of the same semantic content. German federal authorities accept it, Belgium built its B2B mandate on it, and the UAE's forthcoming mandate uses a Peppol PINT variant. For a group that already runs Peppol for Belgium, the Nordics or the Gulf, generating XRechnung in UBL for Germany is a small incremental step, and the Access Point handles routing. Our guide on choosing a Peppol Access Point provider lists the criteria that matter.

Hybrid formats are less at home on Peppol. The network exchanges XML business documents, so a ZUGFeRD or Factur-X PDF must either be transported under a specific document specification or be converted to UBL at the sender's Access Point. This is one reason many German companies plan to send XRechnung over Peppol to trading partners who are connected and ZUGFeRD by email to those who are not.

What about EDIFACT and existing EDI invoices?

Large suppliers to German retail, automotive and logistics customers have exchanged EDIFACT INVOIC messages for decades. The BMF has confirmed that EDI procedures remain permissible provided the information required under sections 14 and 14a UStG can be extracted correctly and completely into a format that complies with or is interoperable with EN 16931. Until 31 December 2027 even legacy EDI formats that cannot be mapped may continue with the recipient's consent. After that date, every EDI invoice must satisfy the extraction test.

In practice this means mapping EDIFACT INVOIC to the EN 16931 semantic model and proving it with a documented conversion. It does not mean abandoning EDI. Companies that run both channels need a provider that validates EDI and EN 16931 flows against the same rules, which we discuss in EDI Invoicing vs E-Invoicing.

Validation, errors and input VAT

The October 2025 BMF letter introduced a three-tier view of errors that every implementation should mirror. Format errors are violations of the EN 16931 syntax (UBL or CII). An invoice with a format error is not an e-invoice at all, so the issuing obligation is unmet. Business rule errors are breaches of EN 16931 plausibility rules; they matter for VAT only if mandatory content is affected. Content errors are wrong or missing mandatory VAT details such as the tax rate or the description of the supply, and they generally block the recipient's input VAT deduction even if the file validates technically.

The BMF strongly recommends automated validation and advises keeping the validation reports. A technically clean result can be relied on if the recipient acted with due care, but it does not replace a content check. Corrections must themselves be issued as e-invoices that reference the original. For suppliers, a rejected or incorrect invoice from 2027 onward is not an administrative inconvenience; it delays the customer's cash and the supplier's payment, and breaches of invoicing duties can be fined up to EUR 5,000 under section 26a UStG.

Archiving the structured file

Whatever format is chosen, the structured XML is the original that must be retained. The Fourth Bureaucracy Relief Act shortened the retention period for invoices and accounting documents from ten to eight years with effect from 1 January 2025 (one year later for entities supervised by BaFin), while trading books and annual financial statements remain at ten years. The BMF letter clarifies that at least the structured part must be stored unchanged; a PDF rendering alone is insufficient, and GoBD principles of authenticity, integrity and legibility continue to apply. For hybrid invoices, archive the complete PDF/A-3 container so that the embedded XML and its visual counterpart stay together.

How to choose the right format for your organisation

There is no single correct answer, but the decision usually follows the receiver, the channel and the ERP landscape. The following questions settle most cases:

  1. Who receives the invoice? German federal and most state authorities expect an EN 16931 invoice carrying the Leitweg-ID, in practice XRechnung (UBL via Peppol or portal upload). German B2B customers accept XRechnung or ZUGFeRD. French customers need Factur-X, UBL or CII through an accredited platform.
  2. Which channel will you use? Peppol favours UBL, which means XRechnung or BIS Billing 3.0. Email favours the hybrid PDF, which means ZUGFeRD or Factur-X in the EN 16931 profile.
  3. Do you need human readability? If accounts-payable staff at your customers still open invoices manually, the hybrid format reduces friction. If both sides are automated, pure XML is leaner and avoids PDF-versus-XML inconsistencies.
  4. What does your ERP produce natively? SAP, Microsoft Dynamics and Oracle each offer XRechnung and ZUGFeRD output, but profile, version and code list currency vary. Many groups outsource format generation to an e-invoicing platform so that the ERP delivers one canonical data set and the platform renders the format each receiver needs.
  5. How many countries are in scope? If Germany is one of ten mandates you must satisfy, choose a platform approach that converts a single EN 16931 data model into XRechnung, Factur-X, Peppol BIS, KSeF FA(3) and others rather than building format-specific logic for each.

Infinite IT Solutions generates and validates XRechnung, ZUGFeRD and Factur-X invoices from a single ERP integration, routes them over Peppol, email or portal, and keeps the format versions current through its Compliance Tracker. Details of the German service are on our e-invoicing in Germany page.

Conclusion: pick the format by receiver, then automate the rest

XRechnung, ZUGFeRD and Factur-X are three expressions of the same European semantic model. XRechnung is pure XML and the default for German public authorities; ZUGFeRD wraps CII XML in a PDF/A-3 for readability; Factur-X is ZUGFeRD under its French name and one of France's mandated formats. All three are compliant for German B2B invoicing from 1 January 2027, provided the profile is EN 16931 or higher, the XML and PDF are consistent, the file validates against current artefacts, and the structured original is archived for eight years.

With the issuing obligation two months away for businesses above the EUR 800,000 threshold, the format decision should already be made and tested with your largest customers. If it is not, or if your group needs to serve Germany, France and other mandates from one platform, contact Infinite IT Solutions to discuss a compliant format strategy and integration plan.

Frequently asked questions

What is the difference between XRechnung and ZUGFeRD?

XRechnung is a pure XML e-invoice standard (UBL 2.1 or CII) maintained by KoSIT and the designated standard for invoices to German public authorities. ZUGFeRD is a hybrid format that embeds CII XML inside a PDF/A-3 so the invoice is both machine-readable and human-readable. Both comply with EN 16931 and both are accepted for German B2B e-invoicing.

Is Factur-X the same as ZUGFeRD?

Yes. Factur-X and ZUGFeRD are the same technical specification published jointly by the French FNFE-MPE and the German FeRD; ZUGFeRD 2.5 corresponds to Factur-X 1.09. Factur-X is one of the three formats accepted under France's e-invoicing mandate alongside UBL 2.1 and CII.

Which ZUGFeRD profiles meet the German e-invoicing mandate?

The BASIC, EN 16931 (formerly COMFORT) and EXTENDED profiles, as well as the XRECHNUNG reference profile, qualify as e-invoices under German VAT law from ZUGFeRD version 2.0.1 onward. The MINIMUM and BASIC WL profiles do not, because they omit mandatory VAT and line-item information.

Is e-invoicing mandatory in Germany in 2027?

Receiving structured e-invoices has been mandatory for all German businesses since 1 January 2025. Issuing them becomes mandatory on 1 January 2027 for businesses whose previous-year turnover exceeded EUR 800,000 and on 1 January 2028 for all other businesses, with limited exemptions such as invoices up to EUR 250 and certain tax-exempt supplies.