ZUGFeRD Explained: Germany's Hybrid PDF E-Invoice (2026)

Short answer: ZUGFeRD is a German e-invoice format that looks like a normal PDF but has a structured XML file embedded inside it. People read the PDF. Software reads the XML. Under German law the XML is the invoice. The current version is ZUGFeRD 2.5.2 (August 2026), and it is technically identical to France’s Factur-X. For German B2B sales, ZUGFeRD counts as an e-invoice from version 2.0.1 in every profile except MINIMUM and BASIC WL.

This guide is for people who’ve been told “please send a ZUGFeRD invoice” by a German customer, their accountant or their software, and want to know what that means and how to produce one. For who must send e-invoices in Germany and from when, see E-invoicing in Germany.

ZUGFeRD at a glance

What it is	A hybrid e-invoice: a PDF/A-3 file with a CII XML file embedded inside
Name	Zentraler User Guide des Forums elektronische Rechnung Deutschland
Maintained by	FeRD (Forum elektronische Rechnung Deutschland), part of the AWV in Eschborn, jointly with France’s FNFE-MPE
Current version	ZUGFeRD 2.5.2, published 4 August 2026 (= Factur-X 1.09.2)
XML syntax	UN/CEFACT Cross Industry Invoice (CII), D22B schema since version 2.4, backward compatible with D16B
Built on	The European e-invoicing standard EN 16931
Profiles	MINIMUM, BASIC WL, BASIC, EN 16931 (formerly COMFORT), EXTENDED, plus the XRECHNUNG reference profile
Valid German e-invoice?	Yes from version 2.0.1, except the MINIMUM and BASIC WL profiles
Cost	Free to use. The specification is a free download from FeRD

Do you need ZUGFeRD? Find your situation

Your situation	What to send
German business invoicing a German business, and your customer asked for ZUGFeRD	ZUGFeRD in the EN 16931 profile is the safe default
German business invoicing a German business, no format requested	ZUGFeRD or XRechnung. Both count. ZUGFeRD is easier for customers without e-invoice software, because they can still open the PDF
Invoicing a German public body	Usually XRechnung. ZUGFeRD’s XRECHNUNG profile may be accepted, but check with the authority first
Invoicing a French business	Factur-X, which is the same file. In France it must go through a Plateforme Agréée
Foreign business with no German establishment, invoicing German customers	Not required by law, but large German buyers often ask for it. See foreign businesses
Invoice of €250 or less, or sales to consumers	No e-invoice needed. A normal PDF is fine (see the German exceptions)

How a ZUGFeRD file works

A ZUGFeRD invoice is one file, usually named something like RE-2028-0142.pdf. Inside it are two things:

1. A PDF/A-3 document. PDF/A is the archiving version of PDF (ISO 19005). Version 3 allows other files to be attached. This is what you see when you open the invoice.
2. An XML file, attached inside the PDF and normally named factur-x.xml. It holds every invoice detail as structured data: seller, buyer, VAT numbers, lines, rates and totals.

The PDF’s metadata (its XMP block) declares which profile the XML uses, so software can find and read the data without guessing.

Which part counts? The XML. FeRD’s own June 2026 release note puts it plainly: only the structured XML part of a ZUGFeRD invoice entitles the buyer to deduct input VAT. Germany’s GoBD record-keeping rules, as amended in July 2025, also say keeping the structured part is enough, unless the PDF holds extra tax-relevant information. That has two practical consequences:

• Every mandatory invoice detail must be in the XML, not just printed on the PDF.
• The PDF and the XML must agree. If your software prints one total and writes another into the XML, you’ve sent a broken invoice.

What the XML looks like

Here is a shortened excerpt from the XML of a ZUGFeRD invoice in the EN 16931 profile. It’s the same Leipzig candle order used in the Germany guide: 120 candles at €9.00 for a Hamburg gift shop. The comments show which EN 16931 business term each element carries.

<rsm:CrossIndustryInvoice
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
    xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <!-- BT-24: the profile. This value means "EN 16931" -->
      <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>RE-2028-0142</ram:ID>             <!-- BT-1: invoice number -->
    <ram:TypeCode>380</ram:TypeCode>          <!-- BT-3: 380 = commercial invoice -->
    <ram:IssueDateTime>
      <udt:DateTimeString format="102">20280112</udt:DateTimeString> <!-- BT-2 -->
    </ram:IssueDateTime>
  </rsm:ExchangedDocument>
  <!-- ...invoice lines, seller, buyer and delivery details... -->
</rsm:CrossIndustryInvoice>

Further down, the totals block carries the amounts every e-invoice must have:

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1080.00</ram:LineTotalAmount>         <!-- BT-106: sum of lines -->
  <ram:TaxBasisTotalAmount>1080.00</ram:TaxBasisTotalAmount> <!-- BT-109: net total -->
  <ram:TaxTotalAmount currencyID="EUR">205.20</ram:TaxTotalAmount> <!-- BT-110: 19% VAT -->
  <ram:GrandTotalAmount>1285.20</ram:GrandTotalAmount>       <!-- BT-112: gross total -->
  <ram:DuePayableAmount>1285.20</ram:DuePayableAmount>       <!-- BT-115: amount due -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Validators check the arithmetic. €1,080.00 net plus €205.20 VAT must equal the €1,285.20 gross total, or the file fails the EN 16931 rule BR-CO-15.

What’s inside the PDF metadata

The XMP metadata tells software the XML’s file name and profile. The key fields are DocumentFileName (for example factur-x.xml), DocumentType (INVOICE) and ConformanceLevel (for example EN 16931). The profile in the metadata must match the profile ID in the XML (BT-24). A mismatch is one of the most common validation errors.

The attached file name depends on the version:

Version	Embedded file name
ZUGFeRD 1.0	ZUGFeRD-invoice.xml
ZUGFeRD 2.0	zugferd-invoice.xml
ZUGFeRD 2.1 and later (and Factur-X)	factur-x.xml
XRECHNUNG profile	xrechnung.xml

ZUGFeRD versions: 1.0, 2.x and 2.5.2

Version	Released	What changed
1.0	25 June 2014	The first hybrid PDF invoice. Older XML structure, published before EN 16931 existed. Profiles BASIC, COMFORT and EXTENDED
2.0	11 March 2019	Rebuilt on EN 16931 and the CII D16B schema. Added MINIMUM and BASIC WL. COMFORT renamed EN 16931
2.0.1	15 October 2019	Corrections and alignment with Factur-X. The oldest version Germany accepts as an e-invoice
2.1	24 March 2020	First version fully identical to Factur-X. Embedded file renamed factur-x.xml
2.1.1	1 July 2020	Added the XRECHNUNG profile, agreed with KoSIT
2.3	18 September 2024	Joint release with Factur-X 1.07
2.4	4 December 2025, in use from 15 January 2026	Factur-X 1.08. Moved to CII D22B (backward compatible with D16B). Added sub-lines for kits and bundles, and points from the German Finance Ministry’s October 2025 letter
2.5	10 June 2026, in use from 1 July 2026	Factur-X 1.09. Updated EN 16931 code lists. New EXTENDED elements from the revised EN 16931-1, needed for the French reform
2.5.2	4 August 2026	Factur-X 1.09.2. A corrigendum fixing inconsistencies in the new EXTENDED elements. Current version

Sources: FeRD’s ZUGFeRD page, its 2.5.2 announcement and the joint 2.4 press release.

What’s next. FeRD has said the next release is expected in autumn 2026 and will mainly add gross-price invoices (needed by sectors such as book retail and fuel) plus more features from the revised EN 16931. We couldn’t find it published as of 26 October 2026. FeRD aims to publish an update shortly after each half-yearly update of the EN 16931 code lists, so expect a new point release roughly twice a year.

Do you need to upgrade every time? No. Each new version is backward compatible, and the German rules only require version 2.0.1 or later. In practice, keep your software reasonably current, because validators and large buyers move to the newest code lists and rules.

ZUGFeRD profiles: which ones count in Germany

A profile sets how much data the XML carries. Pick the profile your customer asks for. If they don’t ask, use EN 16931.

Profile	What it carries	German e-invoice from 2025?	Typical use
MINIMUM	Buyer, seller and totals only. No lines	No	A booking aid, originally for France’s Chorus Pro
BASIC WL (“without lines”)	Header data and totals, no line items	No	A booking aid for accounting
BASIC	Simple line items, a subset of EN 16931	Yes	Simple invoices with few details per line
EN 16931 (formerly COMFORT)	Everything in the European standard	Yes	The default for B2B. Every receiver must be able to process it
EXTENDED	EN 16931 plus extra fields: multiple deliveries, sub-lines, more party details	Yes	Industry, construction, complex billing
XRECHNUNG	The German XRechnung rules inside a ZUGFeRD file	Yes	Public sector customers, or buyers who want XRechnung data

The German status comes from question 7 of the Finance Ministry’s e-invoicing FAQ. MINIMUM and BASIC WL fail because a German VAT invoice must show the quantity and description of what was sold, and those profiles have no invoice lines.

Each profile has its own ID in BT-24:

Profile	BT-24 value
MINIMUM	urn:factur-x.eu:1p0:minimum
BASIC WL	urn:factur-x.eu:1p0:basicwl
BASIC	urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic
EN 16931	urn:cen.eu:en16931:2017
EXTENDED	urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended
XRECHNUNG	urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

Selling into France too? The French reform treats the profiles differently: BASIC isn’t used there, and the French rules add their own EXTENDED-CTC-FR profile. See Factur-X profiles in the French reform.

ZUGFeRD and Factur-X: the same file

ZUGFeRD started in Germany in 2014. France’s FNFE-MPE published Factur-X 1.0 at the end of 2017, building on the same idea. Since ZUGFeRD 2.1 (March 2020) the two have been one joint standard, written together by FeRD and FNFE-MPE and released at the same time under two names:

ZUGFeRD	Factur-X
2.3	1.07
2.4	1.08
2.5	1.09
2.5.2	1.09.2

A Factur-X invoice in the EN 16931 profile is a valid ZUGFeRD invoice in Germany, and the reverse. The differences are in national rules around the file, not the file itself: France requires e-invoices to go through an approved platform and adds French business rules, while Germany lets you send the file by email. The Factur-X guide covers the French side.

ZUGFeRD vs XRechnung vs Factur-X

	ZUGFeRD	XRechnung	Factur-X	EN 16931
What it is	Hybrid: PDF/A-3 + CII XML	Pure XML	Hybrid: PDF/A-3 + CII XML	The European standard the others follow
Readable without software?	Yes, open the PDF	No, needs a viewer	Yes	Not a file format
XML syntax	CII	UBL or CII	CII	Defines the data. UBL and CII are its syntaxes
Maintained by	FeRD (with FNFE-MPE)	KoSIT, for the German IT Planning Council	FNFE-MPE (with FeRD)	CEN, the European standards body
Current version	2.5.2 (Aug 2026)	3.0.2 (4.0 in preparation)	1.09.2 (Aug 2026)	EN 16931-1:2026 (2017 edition still accepted during migration)
German B2B e-invoice?	Yes, except MINIMUM and BASIC WL	Yes	Yes, same rules as ZUGFeRD	The reference for what counts
German public sector	Sometimes, via the XRECHNUNG profile	The standard	Rarely used	n/a
French reform	Yes, as Factur-X	Not one of France’s formats	One of the three base formats	France’s formats follow it

How to create a ZUGFeRD invoice

You almost never write a ZUGFeRD file by hand. Building a valid PDF/A-3, attaching the XML correctly and writing matching metadata is fiddly. Pick the approach that fits your size.

1. Your invoicing or accounting software

Most German invoicing and accounting tools now have an e-invoice export, often labelled E-Rechnung, ZUGFeRD or XRechnung. Before you rely on it, check three things with the vendor:

• Which version it produces. It should be at least 2.0.1, and ideally a current 2.x release.
• Which profile. Ask for EN 16931 unless your customer wants something else. A tool that only makes MINIMUM or BASIC WL files doesn’t meet the German rules.
• That it validates the output before sending, or lets you download the file so you can check it yourself.

Shopify, WooCommerce and similar stores usually create invoices through an app or plugin. The same three questions apply. Consumer orders don’t need e-invoices, so this only matters for your wholesale or B2B invoices.

2. An invoicing API

If you run a SaaS or a custom shop, an e-invoicing API can take your invoice data as JSON and return a finished ZUGFeRD PDF, an XRechnung XML, or both. When comparing APIs, ask which versions and profiles they support, whether they return a validation report, and whether they can also deliver over Peppol if a customer asks for it.

3. Open-source libraries

For developers who want to generate files in-house, these libraries are actively maintained as of October 2026:

Library	Language	What it does	Licence
Mustang	Java (also a command-line tool)	Reads, writes, validates and converts ZUGFeRD 1 and 2, Factur-X and CII XRechnung. Version 2.26.0 (August 2026) supports ZUGFeRD 2.5 and 2.5.2	Apache 2.0
factur-x by Akretion	Python	Embeds an XML in a PDF to make a Factur-X/ZUGFeRD file, extracts the XML, and checks it against the official schema and schematron	BSD-style
horstoeko/zugferd	PHP	Builds and reads ZUGFeRD, Factur-X and CII XRechnung documents	MIT
ZUGFeRD-csharp	.NET (C#)	Creates and reads ZUGFeRD invoices. Maintenance ends on 30 November 2026: the author has announced the project will then be archived, with no support for new standard versions	Apache 2.0

If you’re on .NET and starting now, note the ZUGFeRD-csharp end date. Existing releases stay usable under their open-source licence, but you’ll need a fork, another library or a commercial option to keep up with new versions.

A typical developer workflow:

1. Generate the invoice PDF as you do today.
2. Build the CII XML from the same data, in the EN 16931 profile.
3. Use the library to convert the PDF to PDF/A-3, attach the XML and write the metadata.
4. Validate the result (next section) in your test suite before going live.

How to validate a ZUGFeRD invoice

A ZUGFeRD file can fail in three places: the PDF/A-3 file, the XML schema, or the business rules (missing fields, wrong totals, bad codes). A good validator checks all three.

Tool	What it checks	Cost
Mustang command-line tool	XML schema, EN 16931 and profile rules, plus PDF/A through the built-in veraPDF	Free, open source
veraPDF	The PDF/A-3 part only	Free, open source
EN 16931 validation artefacts	The official European schematron rules for CII and UBL (version 1.3.17, October 2026)	Free, for developers
KoSIT validator	Files in the XRECHNUNG profile, or a ZUGFeRD XML checked against XRechnung rules	Free, open source
FNFE-MPE validator	Factur-X files under the French rules. Useful if you also invoice French customers	Free, account required

With Mustang, validating a file is one command:

java -Xmx1G -Dfile.encoding=UTF-8 -jar Mustang-CLI-2.26.0.jar --action validate --source RE-2028-0142.pdf

It prints an XML report and exits with code 0 if the file is valid, which makes it easy to run in a build pipeline.

Common errors

• The profile in the PDF metadata doesn’t match BT-24 in the XML.
• The totals don’t add up, often from rounding each line differently in the PDF and the XML.
• The seller’s VAT number is missing from the XML, even though it’s printed on the PDF.
• The PDF isn’t real PDF/A-3, for example because fonts aren’t embedded.
• MINIMUM or BASIC WL was used for an invoice that must be a full e-invoice.

Worked example: a Leipzig candle maker switches to ZUGFeRD

A candle maker in Leipzig had €310,000 turnover in 2026. Under the German rules it can keep sending PDFs with consent during 2027, but from 1 January 2028 its wholesale invoices to German shops must be e-invoices (see the Germany timeline).

Its wholesale customers are small gift shops. Most don’t have e-invoice software, so a pure XML file would confuse them. It chooses ZUGFeRD 2.5.2, EN 16931 profile:

• Order: 120 candles at €9.00 = €1,080.00 net
• VAT at 19%: €205.20
• Total: €1,285.20

The gift shop opens the PDF and sees a normal invoice. Its accountant’s software reads the XML and books it without retyping. The candle maker keeps the file, with its XML, for 8 years.

A follow-up order of 15 candles comes to €160.65 including VAT. That’s under the €250 small-invoice limit, so a plain PDF would also be fine. Many businesses send ZUGFeRD anyway, so every B2B invoice goes through the same process.

How GoodVat helps

A ZUGFeRD file is only correct if the VAT data inside it is correct: the right rate, the right VAT category, the reverse charge where it applies, and your VAT number in the right place. GoodVat Global Tax Compliance handles that side:

• Maps your obligations across Germany, France and the rest of the EU, including which e-invoice formats and mandates apply to your sales
• Registers you for German VAT, OSS or IOSS where you need it
• Calculates the right VAT for every product and customer, and sends your customers compliant invoices
• Files your VAT returns in the EU, the UK and US states

GoodVat is not an e-invoicing platform, a Peppol access point or a format validator. Use the tools above to check your files.

Asked for a ZUGFeRD invoice?

Tell us where you invoice from and who your customers are. We’ll map which e-invoice formats and VAT obligations apply in Germany, France and every other country you sell to, then send compliant invoices and handle the VAT registrations and filings for you.

Ask a tax expertor email hello@goodvat.com

A real person replies within one business day

FAQ

What is a ZUGFeRD invoice?

A ZUGFeRD invoice is a PDF that people can read, with an XML file inside it that software can read. The PDF is a PDF/A-3 archive file and the XML follows the UN/CEFACT Cross Industry Invoice (CII) syntax and the European standard EN 16931. Under German law the XML is the actual invoice, and the PDF is a human-readable copy.

Is ZUGFeRD the same as Factur-X?

Yes, technically. Since ZUGFeRD 2.1 in 2020, ZUGFeRD and Factur-X have been one joint standard maintained by Germany’s FeRD and France’s FNFE-MPE. Each ZUGFeRD release has a matching Factur-X release with the same content, for example ZUGFeRD 2.5.2 and Factur-X 1.09.2.

What is the latest version of ZUGFeRD?

ZUGFeRD 2.5.2, published by FeRD on 4 August 2026, which is identical to Factur-X 1.09.2. It corrects the ZUGFeRD 2.5 release of 10 June 2026. FeRD has said a further release, mainly adding support for gross-price invoices, is expected in autumn 2026.

Which ZUGFeRD profiles count as an e-invoice in Germany?

From ZUGFeRD 2.0.1 onwards, the profiles BASIC, EN 16931 (formerly COMFORT), EXTENDED and XRECHNUNG count as e-invoices under the German VAT Act. MINIMUM and BASIC WL do not, because they don’t carry all the details a VAT invoice needs. ZUGFeRD 1.0 files don’t qualify either.

What is the difference between ZUGFeRD and XRechnung?

ZUGFeRD is a PDF with embedded XML, so a person can read it without special software. XRechnung is pure XML, in UBL or CII syntax, and needs a viewer. Both count as e-invoices for German B2B sales. Public bodies usually ask for XRechnung, which ZUGFeRD can carry through its XRECHNUNG profile.

How do I create a ZUGFeRD invoice?

Most businesses use their invoicing or accounting software’s e-invoice export, or an invoicing API that returns a finished PDF/A-3 with the XML attached. Developers can use open-source libraries such as Mustang for Java or factur-x for Python. Whatever you use, check the version and profile, and validate the output before sending it.

How do I check if a PDF is a valid ZUGFeRD invoice?

Open the PDF’s attachments panel and look for an embedded file named factur-x.xml, zugferd-invoice.xml or xrechnung.xml. To check that it’s valid, run it through a validator such as the free Mustang command-line tool, which tests the XML against the official schema and business rules and checks the PDF/A-3 file.

Can I still use ZUGFeRD 1.0?

Not for German B2B invoices that must be e-invoices. The Finance Ministry only accepts ZUGFeRD from version 2.0.1, in the qualifying profiles. ZUGFeRD 1.0 predates the European standard EN 16931 and uses an older XML structure.

Related guides

• E-invoicing in Europe: every EU mandate, the main formats and the ViDA timeline
• E-invoicing in Germany: who must issue e-invoices, from 2027 and 2028, and the exceptions
• XRechnung explained: Germany’s pure-XML format, the Leitweg-ID and public sector invoicing
• Factur-X explained: the French name for the same hybrid format, and the French profile rules
• EN 16931 explained: the European standard behind every format on this page
• E-invoicing in France: the 2026 and 2027 deadlines and approved platforms
• Selling to Germany: rates, rules and compliance: German VAT rates and invoicing basics