The format
The ZUGFeRD format: what is inside the file
A ZUGFeRD invoice is a PDF/A-3 with an XML file inside. How software recognises it, which profiles and versions exist, and which of them are an e-invoice — explained on a real file you can download and open yourself.
One invoice, twice in one file
ZUGFeRD joins two things that otherwise travel separately: the invoice page, as any PDF reader shows it, and the invoice data as XML, which accounting software imports without retyping. The XML follows the European standard EN 16931 in the UN/CEFACT CII syntax. It is published by the Forum elektronische Rechnung Deutschland (FeRD), jointly with France’s FNFE-MPE, which publishes the same specification as Factur-X.
Whoever receives a ZUGFeRD file notices nothing at first: it opens like any PDF. The XML is a file attachment inside the PDF, which a reader shows in its attachments sidebar.
The structure, on a real file
Read from case 36 of our sample library, an invoice in the EN 16931 profile to a business. The XML on its own is alongside.
| Part | In the file | What the specification says |
|---|---|---|
PDF 1.6, PDF/A-3u | PDF/A-3, because only that level allows arbitrary attachments. Whether 3a, 3b or 3u does not matter. | |
| Attachment | factur-x.xml, text/xml | Exactly one invoice XML, attached to the document. In the XRECHNUNG profile it is called xrechnung.xml. |
| AFRelationship | /Alternative | The XML is an equivalent version of the page. Mandatory in Germany for BASIC, EN 16931, EXTENDED and XRECHNUNG; MINIMUM and BASIC WL carry /Data. |
| XMP | fx:ConformanceLevel EN 16931 | The metadata name the file and the profile, so that software finds the invoice without opening the XML. |
| XML | rsm:CrossIndustryInvoice | UN/CEFACT CII, since ZUGFeRD 2.3 in the D22B schema, which is backward compatible with the standard’s D16B. |
<rdf:Description rdf:about=""
xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#">
<fx:DocumentType>INVOICE</fx:DocumentType>
<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
<fx:Version>1.0</fx:Version>
<fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
</rdf:Description>The “1.0” in fx:Version and the “1p0” in the namespace are the version of the metadata schema, not of ZUGFeRD: a file under 2.5.2 writes the same as one under 2.1.
<rsm:CrossIndustryInvoice
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" …>
<rsm:ExchangedDocumentContext>
<ram:BusinessProcessSpecifiedDocumentContextParameter>
<ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
</ram:BusinessProcessSpecifiedDocumentContextParameter>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<ram:ID>SM-2026-047</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
…The identifier under GuidelineSpecifiedDocumentContextParameter is the specification identifier, BT-24. It, not the XMP, is what validators go by: the KoSIT validator picks the rule set from it.
The six profiles
The profile fixes how much of the invoice the XML holds. Since 2025 it also decides whether the file is an e-invoice for tax purposes: the Federal Ministry of Finance recognises ZUGFeRD from version 2.0.1, except the MINIMUM and BASIC WL profiles.
| Profile | E-invoice | What it holds |
|---|---|---|
MINIMUMurn:factur-x.eu:1p0:minimum | no | Header data and totals only, meant as a booking aid. |
BASIC WLurn:factur-x.eu:1p0:basicwl | no | Header data without lines. |
BASICurn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic | yes | A subset of the standard, with lines. |
EN 16931urn:cen.eu:en16931:2017 | yes | The whole standard, formerly “Comfort”. The usual profile between businesses. |
EXTENDEDurn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended | yes | More fields than the standard knows. Authorities refuse it. |
XRECHNUNGurn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 | yes | A complete XRechnung, inside the PDF as xrechnung.xml. |
Which profile for which recipient, and why EXTENDED fails at authorities although the standard validator says nothing: ZUGFeRD Extended or XRechnung.
The versions
| ZUGFeRD | Factur-X | What changed |
|---|---|---|
| 1.0 | – | 2014. Not yet built on EN 16931, so not an e-invoice under the VAT Act. |
| 2.0 | 1.0.03 | 2019. The first release based on the standard; recognised as an e-invoice from 2.0.1. Embedded file zugferd-invoice.xml. |
| 2.1 | 1.0.05 | March 2020. Technically identical to Factur-X; since then the file has been called factur-x.xml. |
| 2.2 | 1.0.06 | March 2022. |
| 2.3 | 1.0.07 | September 2024. The XML syntax moves to UN/CEFACT CII D22B. |
| 2.4 | 1.08 | December 2025, applicable from 15 January 2026. |
| 2.5 | 1.09 | June 2026, applicable from 1 July 2026. |
| 2.5.2 | 1.09.2 | 4 August 2026, applicable from 1 September 2026. A correction of 2.5; the current release. |
The 2.5.2 validation rules still accept the old profile identifiers of the form urn:zugferd.de:2p0:…. FeRD has announced the next release, with gross-price invoices, for autumn 2026. ZUGFeRD 2.0 and Factur-X 1.0.03 matched only largely; the two have been technically identical since 2.1.
ZUGFeRD and Factur-X
Since 2.1 it has been one specification under two names. A Factur-X invoice from France is a ZUGFeRD invoice in Germany and vice versa. There are two differences: the XRECHNUNG profile is meant for Germany only, and France also allows /Source and /Data, not only /Alternative, for the link to the XML.
Page and XML have to say the same
For tax purposes only the XML counts. The Ministry of Finance calls it the leading part; where the page differs, the XML’s data apply, and a page with other amounts can count as a second invoice. That mostly concerns files assembled from two sources. When ZUGFeRD is the right choice and when plain XML: XRechnung or ZUGFeRD.
Checking and creating
The ZUGFeRD viewer shows whether a PDF carries an XML and lays it out readably, in the browser and without uploading it. The Validator takes the PDF and checks the embedded XML against KoSIT’s rule set, with every broken rule in plain language.
You can create ZUGFeRD in the free generator, from your own PDF through convert a PDF to an e-invoice, and from JSON through the API. Every file made that way follows the structure shown above.
Common questions
What is ZUGFeRD Comfort?
The former name of the EN 16931 profile, which the specification still lists as “EN 16931 (COMFORT)”. It covers the standard’s content in full; the XMP says “EN 16931”.
Is a ZUGFeRD 1.0 invoice still valid?
As an invoice yes, as an e-invoice no: ZUGFeRD 1.0 was not yet based on EN 16931. Between businesses in Germany it is enough in 2027 only for a prior-year turnover of at most €800,000, and from 2028 not at all.
Can I turn an ordinary PDF into a ZUGFeRD file?
Not by converting alone, as the PDF lacks the invoice data in machine-readable form. They have to be entered once; then the XML goes into your PDF and it is brought to PDF/A-3. That is what convert a PDF to an e-invoice does.
Where can I find more sample files?
In our e-invoice examples: 40 cases, each as a ZUGFeRD PDF, UBL and CII, all checked with the KoSIT validator and free to use.
Sources: FeRD, ZUGFeRD 2.5.2; FNFE-MPE, Factur-X; Factur-X 1.07.2 specification, chapters on PDF/A-3 and XMP; Ministry of Finance letter of 15 October 2024 (paras. 25, 30, 31). Read on 25 October 2026.