ZUGFeRD vs XRechnung vs Factur-X

ZUGFeRD and Factur-X are the same hybrid format under two national names: a readable PDF with invoice XML embedded inside it. XRechnung is pure XML with no visual document at all. All three satisfy the European standard EN 16931 and all three are accepted under the German B2B mandate. The choice comes down to whether anyone on the receiving end still needs to look at an invoice page.

The three names get used as if they were competing products. They are not. Two of them are literally the same specification, and the third solves a different problem. Here is what each one is, where it came from, and how to pick.

ZUGFeRD vs XRechnung vs Factur-X at a glance

The first two columns are the same technology. That is not a simplification.

Is ZUGFeRD the same as Factur-X?

Yes. Since ZUGFeRD 2.0 the German and French specifications have been aligned, and from version 2.1 they are identical documents describing the same file format. They share the same XML schema based on the UN/CEFACT Cross Industry Invoice, the same set of profiles, and the same PDF/A-3 container. A file produced by a Factur-X generator is readable by a ZUGFeRD parser and the reverse is equally true.

Two names survive because governance is national. The German standard is maintained by FeRD and the French one by FNFE-MPE, each with its own publication cycle and its own community. For a business building a pipeline, the practical consequence is the useful part: you build one thing and it serves both the French and the German obligation.

What is XRechnung, and why is it different?

XRechnung is Germany's national implementation of EN 16931, published as a CIUS, which is a tightened national profile of the European standard. It is a pure XML file. There is no page, no layout, and nothing to look at without software that renders it.

It came out of public-sector procurement. Since 2020 German federal authorities have required suppliers to submit electronic invoices, and XRechnung became the format for that. Public bodies process invoices through systems, not through people flipping through PDFs, so the visual layer was pure overhead. Strip it out and you get a smaller file, a simpler validation story, and no risk of the picture disagreeing with the data.

That last risk is real and worth naming. In a hybrid file the visual page and the embedded XML are two representations of the same invoice, and nothing physically stops them from saying different things. A generator that renders one total on the page and writes another into the XML produces a file that passes a schema check and is still wrong. With XRechnung there is only one version of the truth.

Which format should I use?

Pick based on who reads the invoice on the other end.

Use ZUGFeRD or Factur-X when your customers include businesses that still review invoices by eye, when your supplier base is mixed in size and technical maturity, or when you are moving off emailed PDFs and want the transition to be invisible to recipients. Small customers can carry on opening an attachment that looks exactly like what they have always received, while the customers with automated systems read the XML. This is the pragmatic default for most B2B businesses, and it is why the hybrid formats were designed in the first place.

Use XRechnung when you invoice German public-sector bodies, which is where it is expected, or when both ends of the exchange are fully automated and nobody needs the page. It is also the cleaner choice if you are worried about the visual layer and the data layer drifting apart.

You do not have to choose once and forever. Plenty of businesses issue hybrid files as standard and switch to XRechnung for the specific customers who ask for it, because both are generated from the same underlying invoice data.

Which ZUGFeRD profile do I need?

This is where format choice turns into a compliance question, and it catches teams out. ZUGFeRD and Factur-X both define a ladder of profiles, and not all of them are legal invoices under the German mandate.

German Ministry of Finance guidance issued on 15 October 2024 confirms that ZUGFeRD from version 2.0.1 meets the requirements, while excluding MINIMUM and BASIC WL because they omit fields the standard requires. BASIC WL stands for "without lines" and carries no line-item table at all.

Target the EN 16931 profile. It is the level the mandate is built around and it holds the full line-item detail: description, quantity, unit, unit price, line amount, and the tax rate on every row.

When do these formats become mandatory?

Germany already applies to you on the receiving side. Since 1 January 2025 a German business cannot refuse a compliant electronic invoice from a supplier. Issuing follows later: businesses with turnover above 800,000 euros must issue from 1 January 2027, and everyone else from 1 January 2028. The accepted formats are XRechnung, ZUGFeRD 2.0.1 and above excluding the two thin profiles, and other EN 16931 syntaxes including Factur-X and Peppol BIS Billing 3.0.

France moves on 1 September 2026, when every VAT-registered business must be able to receive electronic invoices and large and mid-sized companies must also issue them. SMEs and micro-enterprises follow on 1 September 2027. French invoices route through certified Approved Platforms, renamed from PDP to Plateforme Agreee in July 2025, and the accepted formats are Factur-X, UBL 2.1, and CII.

Notice the pattern in both countries: the obligation to receive lands before the obligation to issue. Teams plan for the issuing date and get caught by the receiving one, because compliant files start arriving from early-moving suppliers well ahead of any deadline of their own.

How do I read a ZUGFeRD or XRechnung invoice I receive?

Read the XML, never the picture. A hybrid invoice already contains perfect structured data, so putting it through OCR or re-keying it from the page is both wasted effort and a way to introduce errors into data that arrived clean. For ZUGFeRD and Factur-X, open the PDF attachment list and pull out the embedded XML file. For XRechnung there is nothing to unwrap, the file is the data.

The complication is that this will not be all of your inbound mail for years. Some suppliers send hybrid files, some send XRechnung, and plenty carry on sending ordinary PDFs and scans that carry no data whatsoever. A single intake process that checks each incoming document for an embedded XML attachment, uses it when it is there, and falls back to automated invoice data capture when it is not will handle the mixed reality without anyone sorting mail by hand. Both routes end up producing the same fields for your ledger.

How do I create a ZUGFeRD file from an existing PDF?

In two steps, and only the first one is difficult.

Step one is getting the invoice data out of the PDF: seller and buyer details, VAT identifiers, invoice number, dates, currency, the tax breakdown by rate, the totals, and every line item. Step two is packaging, where a generator writes those fields as CII XML and embeds them in a PDF/A-3 container with the right XMP metadata. Step two is a solved problem with mature libraries behind it, Mustangproject on the Java side and the factur-x library in Python being the common choices, and commercial PDF toolkits supporting it as well.

Step one is the part with no tidy library, because reading an arbitrary supplier layout is a document-understanding problem rather than a formatting one. That is what PDF to ZUGFeRD and Factur-X data extraction handles: upload any invoice and get the header fields and the complete line-item table back as structured JSON to feed straight into your generator. Teams building this into a product usually call the invoice data extraction API rather than working file by file.

One caution about profiles and effort: it is tempting to start with a thin profile because there is less data to map. Under the German rules that is a dead end, since MINIMUM and BASIC WL are not accepted. Build for the line-item table from the beginning.

Does any of this apply to a US business?

Not directly. There is no federal electronic invoicing mandate in the United States, and the DBNAlliance exchange framework is voluntary. Domestic US invoicing carries on unchanged, and for most American companies the structured invoice they actually deal with is still the EDI 810.

You get pulled in two ways. A US parent with a French or German subsidiary inherits the obligation through that entity, in full. And a US exporter selling to European business customers will start getting requests for compliant files, because those customers now have their own deadline and a PDF in their inbox creates work they are trying to eliminate. That request usually arrives from a customer long before it arrives from any regulator, which is why it tends to land on a finance team with no warning and no budget line.

The preparation is the same either way, and it is not really about formats. It is about whether your invoice data exists as data. Companies whose billing already produces clean structured records can adopt any of these formats in weeks. Companies whose invoices live as PDFs in folders have a data project first and a format project second. If you are in the second group and also reconciling payments across borders, the same discipline pays off elsewhere: getting statements into a clean spreadsheet of transaction lines makes the matching side of the work far less painful too.

The short version

ZUGFeRD and Factur-X are one format with two names, hybrid files that keep a readable page and carry structured XML inside it. XRechnung is pure XML for cases where nobody needs the page. All three meet EN 16931, and the German mandate accepts all three, so the decision is about your recipients rather than about compliance. Whichever you pick, aim at the EN 16931 profile, plan for the receiving deadline before the issuing one, and start with the question of whether your invoice data exists in structured form at all, because that is the step everything else waits on.