What is a ZUGFeRD invoice?
A readable document with the invoice data inside it: how the hybrid file is built, which of the six profiles count as an invoice in Germany and why the embedded XML now decides.
Format
ZUGFeRD: a readable document with the invoice data inside it
ZUGFeRD is a hybrid invoice format: a PDF/A-3 document that a person reads, with a structured XML file embedded inside it that a system processes. It is developed by the Forum elektronische Rechnung Deutschland, FeRD, with the support of the Federal Ministry for Economic Affairs and Energy, and it is free to use. The data model follows EN 16931 and the XML uses the UN/CEFACT CII syntax.
Two things have changed what the format means in practice. Since 1 January 2025 the embedded XML is the invoice and the visible document is a copy of it, where before the PDF took precedence. And not every profile counts as an invoice: the Federal Ministry of Finance recognises ZUGFeRD from version 2.0.1, with MINIMUM and BASIC WL excluded.
2.5.2
The current version, information package of 4 August 2026
6 profiles
Five data profiles plus the reference profile XRECHNUNG, four of which are an invoice in Germany
8 years
Retention period, with the structured file as the original
How a ZUGFeRD file is built
One file, two parts. The container is a PDF/A-3 document, the archiving variant of PDF standardised as ISO 19005-3, which requires among other things that every font used in the visible part is embedded so the document still renders correctly years later. Inside it sits the invoice as XML.
01
The visible part
A normal invoice layout that anyone can open and read. It is a copy of the data, not the invoice itself.
02
The embedded XML
UN/CEFACT CII, conforming to a valid profile. One invoice document per PDF, named factur-x.xml or xrechnung.xml.
03
Identical content
Both parts have to say the same thing. The tax authority has set no prescribed check for this, so sender and recipient are advised to run their own.
factur-x.xml in the attachments panel on the left. The XML is the invoice, the page around it is the copy.The XML leads. Until 31 December 2024, where the two parts disagreed, the visible document prevailed. With the obligatory e-invoice that relationship was reversed: the structured part is now the leading one, the PDF serves human readability, and for bookkeeping the XML decides. Technical defects against the PDF/A standard are a warning rather than a fatal error, as long as the XML is valid and can be extracted.
What a ZUGFeRD invoice looks like
From the outside a ZUGFeRD invoice looks like an ordinary invoice PDF, and that is the point of it. The difference sits in the attachment: the same invoice once more, as XML. The example below shows the places a recipient looks at first when checking a ZUGFeRD file.
ZUGFeRD XML, profile EN 16931factur-x.xml
rsm:CrossIndustryInvoice xmlns:rsm="..."
urn:cen.eu:en16931:2017
372026-R150
380
udt:DateTimeString format="102"20261112
1000.00
1190.00
1190.00
How to read the profileFrom the identifier at the head of the file.
urn:cen.eu:en16931:2017 stands for the profile EN 16931, also called COMFORT. MINIMUM, BASIC and the reference profile XRECHNUNG each carry their own identifier in the same place.What the recipient looks atInvoice number, type code 380 for an invoice, the issue date and the summation. These are the values their system books, whatever the visible PDF says.
Example invoicesFeRD publishes ZUGFeRD example invoices as sample documents, among them a recurring rent invoice, construction invoices with partial and final billing, a small business without a VAT ID and a cancellation credit note. More examples come with the information package for version 2.5.2.
The PDF is not the invoice
The two layers are supposed to carry the same content, but nothing in the file enforces it. A document can show one amount on the page and carry another one in the embedded XML, and both parts will open without complaint. Since 1 January 2025 it is the XML that is booked, so the visible page is the part you can afford to be wrong the least about.
PDF layer
800,00 €
what the person sees
XML layer
1.000,00 €
what gets booked
A viewer that renders the embedded XML rather than the PDF page is the only way to see the difference before the invoice is booked.
Which part countsThe embedded XML. The visible page is a copy of it, and technical defects against PDF/A are a warning rather than a fatal error as long as the XML is valid and can be extracted.
Where attachments liveInside the XML or as further embedded files in the PDF/A-3 container, not in the visible layout. A recipient who only prints the page loses them.
What to compareInvoice number, totals, VAT rates and payment terms in both layers. The tax authority prescribes no check for this, so sender and recipient run their own.
The six profiles
A profile determines how much of the data model the XML carries, from a booking aid to a full invoice with extensions. Five are data profiles, the sixth is a reference profile. The column that matters in Germany is whether the profile is a complete invoice under the VAT Act.
EN 16931 (COMFORT)Invoice under the VAT Act Covers EN 16931-1 in full and focuses on the core elements. Receipt and processing by the buyer are mandatory. This is the profile to use where nothing else has been agreed.
EXTENDEDInvoice under the VAT Act Builds on EN 16931-1 for more complex processes: several deliveries or delivery locations on one invoice, structured payment terms, more detail at line level. Exchange has to be agreed bilaterally.
BASICInvoice under the VAT Act A subset of EN 16931-1 for simple invoices. Receipt and processing are a matter of bilateral agreement.
Reference profile XRECHNUNGInvoice under the VAT Act Carries an XRechnung inside the PDF. Only the CII syntax is permitted here, although XRechnung itself also allows UBL. Receipt and processing by the buyer are mandatory.
BASIC WLNot an invoice Carries no invoice lines, so it cannot represent an invoice under the VAT Act. At document level it holds everything needed to book the amount, which makes it a booking aid.
MINIMUMNot an invoice Buyer, seller, total amount and total VAT, with only the buyer reference at line level. No VAT breakdown. A booking aid as well.
EXTENDED does not mean outside EN 16931. It carries the full EN 16931 content and adds structured business information on top, which is why FeRD asks recipients and service providers to recognise and validate it correctly rather than checking it against XRechnung rules.
Legal status in Germany
Section 14 of the VAT Act requires an e-invoice to be issued, transmitted and received in a structured electronic format that permits electronic processing. The Federal Ministry of Finance states that the hybrid format ZUGFeRD from version 2.0.1, with the exception of the profiles MINIMUM and BASIC WL, falls under the permitted formats.
Three consequences follow. A ZUGFeRD file below 2.0.1 is not an e-invoice for this purpose. MINIMUM and BASIC WL remain useful as booking aids but cannot replace an invoice. And EXTENDED, often assumed to be a special case, is permitted, although the parties have to agree on its use beforehand, which is not required for the other profiles.
The obligation itself follows the German calendar: receiving since 1 January 2025, issuing from 1 January 2027 above EUR 800,000 of prior-year turnover and from 1 January 2028 for everyone else. The detail is on e-invoicing in Germany.
Versions
The current version is ZUGFeRD 2.5.2, with the information package published on 4 August 2026. The package is free and contains the schema files, XSLT files and code lists that implementers and validation tools build on.
ZUGFeRD handles versions differently from XRechnung, and this is the point most often misunderstood. XRechnung versions are withdrawn: only the version in force may be used. ZUGFeRD specifications have no expiry date, so an older version stays usable as long as it is at least 2.0.1 and the profile is one that counts as an invoice.
The exception is the reference profile XRECHNUNG. Because it carries an XRechnung, its form and content have to follow the XRechnung specification that is currently valid, which means it inherits the XRechnung version rules.
ZUGFeRD and Factur-X
Factur-X is the French name for the same format. FeRD develops it together with the French forum FNFE-MPE, and since version 2.0 of 24 March 2020 ZUGFeRD and Factur-X are identical in substance. A file produced as ZUGFeRD is readable as Factur-X and the other way round.
The profile names carry both heritages, which is why the same profile appears as EN 16931 in one document and as COMFORT in another. They are the same thing.
ZUGFeRD or XRechnung
Both conform to EN 16931 and both are permitted in Germany. The difference is what arrives and who decides.
ZUGFeRD
One file with a readable document and the data inside it. Useful where the recipient is not fully automated, or where a person has to look at the invoice before it is booked. Common between businesses.
XRechnung
Plain XML in UBL or CII, with German validation rules on top of the European standard. Mandatory towards German public authorities, where the Leitweg-ID also applies.
The two meet in the reference profile: a ZUGFeRD document can carry an XRechnung, which keeps the readable layer while satisfying a recipient that asks for XRechnung. What a validator checks differs, though. A valid ZUGFeRD EN 16931 or EXTENDED invoice can produce errors when it is checked against XRechnung rules alone, without being faulty. Each format has to be validated against its own rule set.
Attachments and payment terms
Two details decide more rework than they should.
Supporting documentsDocuments belonging to the invoice have to be embedded in the XML, base64 encoded. That is possible only in the profiles EN 16931 and EXTENDED. Attaching them to the PDF as well is optional and works in every profile, but the PDF attachment is not the invoice attachment.
One invoice per fileThe current specification permits exactly one invoice document per PDF/A-3, referenced as
factur-x.xml or xrechnung.xml.Early payment discountIn BASIC and EN 16931 a discount can only be expressed as free text in the payment terms. EXTENDED has structured fields for the period, the basis amount and the percentage. The XRECHNUNG profile uses the notation
#SKONTO#TAGE=14#PROZENT=2.00#.TransportThe format says nothing about how the file travels. E-mail, a file upload, an invoice portal or the Peppol network are all possible.
Validation
There is no statutory duty to validate a ZUGFeRD invoice. The Federal Ministry of Finance nevertheless calls it sensible in its FAQ and recommends doing it when the invoice is created and sent. Its letter of 15 October 2025 adds, at marginal number 35a, that a trader exercising the care of a prudent businessman may rely on the technical result of a validation by a suitable application, and that keeping the validation report is advisable.
Our free e-invoice validator takes a ZUGFeRD file, extracts the XML and checks it against the schema, the European business rules and the rules of the profile. The report names the rule and the element behind each finding.
Retention
Invoices are kept for eight years under section 14b (1) sentence 1 of the VAT Act. An electronic invoice is retained in the form in which it was received and has to remain machine-evaluable, in line with the GoBD. For ZUGFeRD that means the file as it arrived, PDF and embedded XML together, rather than one of the two parts.
Where the invoice came by e-mail, the e-mail is the envelope and does not have to be kept, unless it carries information belonging to the invoice that is itself subject to retention.
How we help
Invoice-Portal produces ZUGFeRD in the profiles that count as an invoice, converts between ZUGFeRD, XRechnung and Peppol BIS, and validates the file before it goes out.
- Output as a PDF/A-3 document with the CII data embedded, in the profile the recipient expects
- Conversion from an existing XRechnung, a CSV, an IDoc or your own layout without re-entering data
- Validation against the profile rules, with the report kept alongside the document
- Delivery by e-mail or over the Peppol network as a certified access point
Frequent questions
Which ZUGFeRD version should we use?
The current version is 2.5.2. Older specifications do not expire, so a file built on an earlier 2.x version remains usable, provided it is at least 2.0.1 and uses a profile that counts as an invoice. New implementations are better built on the current version.
Is ZUGFeRD 1.0 still allowed?
No. Only ZUGFeRD from version 2.0.1 is recognised as an e-invoice, and MINIMUM and BASIC WL are excluded even then. Version 1.0 predates the alignment with EN 16931.
Which profile do we send if nothing was agreed?
EN 16931, the COMFORT profile. Receipt and processing are mandatory for the buyer, so it travels without a prior arrangement. EXTENDED has to be agreed beforehand, and BASIC is a matter of agreement as well.
What does a ZUGFeRD invoice look like as an example?
Like an ordinary invoice PDF, with the XML file attached inside it. The structure of that XML is shown in the example above, and complete sample documents are published by FeRD under ZUGFeRD example invoices, with further ones in the information package for version 2.5.2.
What happens if the PDF and the XML disagree?
Since 1 January 2025 the XML is the leading part and decides for bookkeeping. Before that the visible document took precedence. The sender should check that both match before dispatch, and the recipient should visualise and validate the XML rather than reading the PDF alone.
Can we send supporting documents with it?
Yes, embedded in the XML as base64 and only in the profiles EN 16931 and EXTENDED. Additionally attaching them to the PDF is possible in every profile, but a recipient that reads only the XML will not see them there.
Do public authorities accept ZUGFeRD?
That depends on the receiving body. German public bodies generally require XRechnung, and the reference profile XRECHNUNG is the way to deliver one inside a ZUGFeRD document. Check the requirement of the authority before sending, and remember that the Leitweg-ID is needed either way.
Is ZUGFeRD a piece of software?
No. It is a specification that describes how the document is built. Producing, sending, receiving and validating is done by software that implements it, which is why many products carry the ZUGFeRD label.
Resources
FeRD: ZUGFeRD and Factur-XThe standard itself, with the current information package for version 2.5.2 FeRD: ZUGFeRD example invoices
Sample documents to download, from a recurring rent invoice to a cancellation credit note FeRD: questions on ZUGFeRD
Profiles, legal status, attachments, payment terms and validation, from the body that maintains the format KoSIT: versions and bundles of XRechnung
Relevant for the reference profile XRECHNUNG, which follows the valid XRechnung specification
Check a ZUGFeRD file before it goes out
Upload the PDF, the validator takes the XML out of it and checks it against the profile it declares.
- The XML extracted from the PDF/A-3 document automatically
- Checked against the profile it declares, not against foreign rules
- A plain report: the rule, the element and where it sits
Open the validator
Free and unlimited · the file stays in your browser session
What happens next
- 01You send the form, we reply within one business day.
- 02A short call, a test account and a first invoice checked on your own data.
Prefer to talk directly? info@invoice-portal.de · +49 561 56014568
Send your request
Your contact details
Let us start with the basics.
Your situation
Three questions, so the first answer is a useful one.
Almost done
Add a message and send it.
