What is ZUGFeRD? Germany’s hybrid e-invoice format

ZUGFeRD is a hybrid invoice format: an ordinary PDF file that also carries a complete, machine-readable copy of the same invoice inside it. Open the file in a PDF reader and you see an invoice, exactly as always. Feed it to accounting software and you get fields instead of pixels — invoice number, line items, tax rates, IBAN. It is one document, not two, and both halves are required to say the same thing.

The name stands for Zentraler User Guide des Forums elektronische Rechnung Deutschland. FeRD was founded on 31 March 2010 in Berlin and works under the umbrella of the AWV, Germany’s association for economic administration; federal and state ministries sit on it alongside the major industry bodies. The first release, ZUGFeRD 1.0, appeared on 25 June 2014 — years before the European standard the format now follows.

What is actually inside the file

A ZUGFeRD file has three parts, wrapped in a single envelope.

• The envelope: PDF/A-3. This is the only flavour of the PDF/A archiving standard that permits an arbitrary file to be embedded in the PDF and marked as an equal part of it. Hence PDF/A-3 rather than any PDF: in a normal PDF an attachment is an extra, here it is part of the document.
• The visible page. Perfectly ordinary PDF — your layout, your logo, your fonts. It has to be readable without the recipient installing anything.
• The XML attachment. Normally named factur-x.xml, written in the UN/CEFACT Cross Industry Invoice (CII) syntax. Which fields it contains and what they are called is covered in XML structure.

On top of that sit XMP metadata inside the PDF, naming the version and the profile. That is how a recipient can tell what arrived without opening the attachment — and it is where a surprising number of hand-built files fall over: the XML is there, but nothing declares it.

Why hybrid rather than plain XML?

Because two very different parties work on an invoice. The recipient’s software wants fields: it has to post the document, trigger the payment run, claim the input tax — automatically. The human at the recipient wants to see what they are paying for: whether the work was done, whether the price is right, whether the correct cost centre is on it.

A plain XML file serves only the first of those. It is unreadable without tooling, and that alone is why smaller businesses baulk at the switch. A plain PDF serves only the second: nothing can be extracted from it mechanically except by recognising characters and guessing at fields, with the errors that brings (see Convert a PDF invoice).

The hybrid format sidesteps the choice. That is why it is the format small and mid-sized firms in Germany and France grow into — not because it is technically more elegant, but because nobody has to re-educate their recipients.

Which version is current

ZUGFeRD is published jointly with its French sibling Factur-X; the version numbers run in parallel.

2.5.2 is a corrigendum to 2.5: it fixes inconsistencies in the validation rules, rounding and VAT breakdown, chiefly in the EXTENDED profile, and ships updated XSD and Schematron. A further release is expected in autumn 2026.

Profiles — and which of them do not count as an e-invoice

“ZUGFeRD 2.x” does not yet tell you how much data is in the file. That is decided by the profile. The 2.x line defines five: MINIMUM, BASIC WL, BASIC, EN 16931 (formerly COMFORT) and EXTENDED.

And here lies the most expensive trap in the whole subject: MINIMUM and BASIC WL do not count as e-invoices for VAT purposes. The German finance ministry stated this in its ruling of 15 October 2024 and confirmed it in 2025. MINIMUM carries reduced header data only; BASIC WL contains no invoice lines at all — “WL” stands for without lines. Neither carries the mandatory particulars required by § 14 of the German VAT Act, so a file in those profiles is legally an “other invoice”, not a structured one.

What makes this treacherous is that a MINIMUM file is technically flawless: it validates, it opens, it looks like an e-invoice. It just does not count. For the normal case use EN 16931; BASIC is enough for simple invoices without complications; EXTENDED is only needed for situations the standard does not model.

ZUGFeRD and Factur-X: one format, two names

The two are often described as competing formats. Since ZUGFeRD 2.1 / Factur-X 1.0 that has not been true: they rest on the same foundation — EN 16931 in CII syntax — and use the same schema and the same validation rules. A file produced in the EN 16931 profile is accepted as valid by both sides.

What differs is the origin, the naming of some profiles, and the national extras: the XRECHNUNG profile on the ZUGFeRD side, the requirements of the French transition on the Factur-X side. For a German–French invoice in the EN 16931 profile there is nothing to switch.

ZUGFeRD or XRechnung?

XRechnung is not a hybrid format but a plain XML file — the German national adaptation (CIUS) of EN 16931, mandatory towards many public-sector buyers. ZUGFeRD from 2.0.1 onwards and XRechnung are both permitted formats for the German B2B obligation; which you use is a question about your recipient.

Rule of thumb: public-sector buyers generally take XRechnung, and usually require a routing ID (Leitweg-ID) with it. In B2B, ZUGFeRD is the more comfortable choice, because the recipient can still look at the invoice even when their software cannot yet do anything with it. E-Rechnung Pro issues ZUGFeRD and Factur-X; it can validate XRechnung files, but does not issue them.

What the obligation actually requires

For businesses established in Germany:

• Since 1 January 2025 you must be able to receive e-invoices. No transition period, regardless of your size — an email inbox counts as a receiving channel.
• From 1 January 2027 you must issue e-invoices if your previous-year turnover exceeded €800,000. From 1 January 2028 the same applies to all other domestic B2B turnover.
• Exempt are small-amount invoices up to €250 gross, travel tickets, B2C sales and certain exempt supplies. Small enterprises under § 19 of the VAT Act are permanently exempt from issuing — not from receiving.
• Retention: eight years. § 14b of the VAT Act was cut from ten years to eight by the Fourth Bureaucracy Relief Act; this applies to invoices whose period had not yet expired on 31 December 2024. What must be kept is the structured part, unaltered and traceable.

One limit that marketing copy tends to skip: passing validation confirms that the file conforms to the standard — not that the invoice is correct. Since its ruling of 15 October 2025 the German finance ministry distinguishes explicitly between format errors, breaches of business rules and errors of content under § 14. A validator sees the first two.

Do freelancers and small firms actually need this?

Receiving: yes, since 2025, with no exception. Issuing: from 2027 or 2028 depending on turnover, and not at all as a small enterprise under § 19. In practice, though, the question is usually settled earlier — by clients. Anyone supplying large corporates or the public sector gets the format handed to them long before the law bites.

The effort involved is smaller than the subject’s reputation suggests. An invoice with a few lines, one tax rate and an IBAN needs no project, just a tool that builds the file correctly from the start — see Create your first invoice. What you should not do is reach for the MINIMUM profile to keep things simple. See above.

Frequently asked questions

Is ZUGFeRD just a PDF with a stamp on it?

No. Inside the PDF sits a complete structured dataset following EN 16931 — the same fields an XRechnung contains. The difference from an ordinary PDF is not cosmetic; it is the difference between a picture of an invoice and an invoice.

Does the recipient need special software to open it?

No. The file opens in any PDF viewer like any other invoice. Software is only needed if they want to use the embedded data — which is rather the point.

How do I tell whether a file I received really is ZUGFeRD?

Most reliably by running it through a validator. If no embedded XML is found, it is an ordinary PDF — even if the sender says otherwise. The procedure in detail is in Validate an invoice.

Does an old ZUGFeRD 1.0 file count as an e-invoice?

No. What is recognised is ZUGFeRD from version 2.0.1, excluding MINIMUM and BASIC WL. Version 1.0 dates from 2014 and does not yet follow EN 16931.

What happens if the PDF page and the XML disagree?

The XML governs. A discrepancy is not merely untidy — it puts the input VAT deduction at risk, per the German ruling of 15 October 2025. Which is why both halves belong to the same data source and should never be patched by hand afterwards.

Does the format replace my accountant?

No. It automates the exchange of data, not the judgement applied to it. What gets posted, which tax rate applies and whether a supply is exempt is still decided by a person.

Do I have to convert my invoice archive?

No. The obligation covers invoices you issue from the relevant date onwards. Old PDF invoices remain valid and may be kept as they are.

In short

• One file, two readers. PDF/A-3 with a visible page and embedded CII XML — human and software get the same document.
• The current version is 2.5.2 (4 August 2026, in force from 1 September 2026). Version 3.0 does not exist.
• MINIMUM and BASIC WL do not count. Technically valid, but not e-invoices for VAT. When in doubt, EN 16931.
• ZUGFeRD and Factur-X are the same format under two names, since 2.1 / 1.0.
• Receive since 2025, issue from 2027 or 2028, keep for eight years.
• Where they disagree, the XML wins — the visible page must not promise more than the data.

Want to produce conformant ZUGFeRD invoices without hand-building XML? Create a free account — or start by checking an existing file without signing up.