ZUGFeRD Profiles and Versions: Which Count as E-Invoices?
ZUGFeRD profiles from MINIMUM to XRECHNUNG with guideline IDs and e-invoice status, plus the full version history from 1.0 to 2.5.2 and the Factur-X numbers.
Key takeaways
- Under the German VAT guidelines, ZUGFeRD from version 2.0.1 is an e-invoice in every profile except MINIMUM and BASIC WL.
- That leaves BASIC, EN 16931, EXTENDED and the XRECHNUNG reference profile; the profile is stored in BT-24 of the XML.
- The latest release is ZUGFeRD 2.5.2 of 4 August 2026, identical to Factur-X 1.09.2; FeRD expects the next release in autumn 2026.
- German law does not require a specific 2.x release, and ZUGFeRD 1.0 from 2014 is not an e-invoice.
- German federal authorities accept ZUGFeRD only in the XRECHNUNG profile and only as a pure XML file without the PDF.
On this page
ZUGFeRD profiles BASIC, EN 16931, EXTENDED and XRECHNUNG count as e-invoices in Germany from ZUGFeRD version 2.0.1. MINIMUM and BASIC WL do not, according to the German Finance Ministry (BMF) letter of 15 October 2025. German law does not require a specific 2.x release. The latest version is ZUGFeRD 2.5.2 of 4 August 2026.
This reference is for finance teams, foreign suppliers of German customers and developers who receive or produce hybrid PDF invoices. It lists the guideline ID of every profile, the release history with dates and Factur-X equivalents, and a two-minute check for incoming files. For the basics of the format, read What Is ZUGFeRD?.
What is a ZUGFeRD profile?
A ZUGFeRD profile defines which data fields the XML embedded in a ZUGFeRD invoice may and must contain. FeRD (Forum elektronische Rechnung Deutschland) defines five profiles of increasing scope: MINIMUM, BASIC WL, BASIC, EN 16931 and EXTENDED. On top of these come reference profiles, which only describe how another specification is carried inside ZUGFeRD. The German one is XRECHNUNG; FeRD's FAQ says it was defined in 2022. France uses EXTENDED-CTC-FR, a subset of EXTENDED.
You find the profile in two places:
- In the XML, in business term BT-24 (specification identifier). In CII syntax the path is
rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. - In the XMP metadata of the PDF, in the field
fx:ConformanceLevel, for example "EN 16931".
Both must name the same profile. For VAT purposes the XML is what counts: in a hybrid format the structured data is the leading part, and it prevails over the PDF if the two differ (section 14.4 (3) of the German VAT Application Decree, Umsatzsteuer-Anwendungserlass or UStAE, as amended by the BMF letter of 15 October 2025).
Which ZUGFeRD profiles count as e-invoices?
The table shows every ZUGFeRD 2.x profile with its BT-24 value and its status under the BMF letter. These identifiers have not changed since ZUGFeRD 2.0. The "1p0" inside them stays the same in every new release, so it is not a version number.
| Profile | BT-24 value (guideline ID) | Invoice lines | E-invoice in Germany? |
|---|---|---|---|
| MINIMUM | urn:factur-x.eu:1p0:minimum | no | no, other invoice |
| BASIC WL | urn:factur-x.eu:1p0:basicwl | no | no, other invoice |
| BASIC | urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic | yes, simple | yes |
| EN 16931 | urn:cen.eu:en16931:2017 | yes | yes |
| EXTENDED | urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended | yes, extended | yes |
| XRECHNUNG | urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 | yes | yes |
The suffixes explain the logic. "compliant" means the profile restricts EN 16931 and adds nothing the standard does not know. "conformant" means the profile extends the standard with extra elements. That applies to EXTENDED, which since ZUGFeRD 2.5 also carries elements from the revised EN 16931-1.
MINIMUM and BASIC WL have no en16931 identifier. Neither supports invoice lines ("WL" stands for "without lines"), and neither covers the full data model of the standard. The BMF wording is that ZUGFeRD from version 2.0.1, "excluding the profiles MINIMUM and BASIC-WL", is based on EN 16931 and is a permitted e-invoice format.
Which profile fits which invoice?
| Situation | Profile | Why |
|---|---|---|
| Domestic B2B invoice in Germany, standard case | EN 16931 | covers the full core data model |
| Very simple invoice with few lines | BASIC | enough as long as you need no line-level allowances or extra data |
| Customer needs data outside the standard | EXTENDED | only by agreement, because the recipient must process the extra fields |
| Customer is a German public authority | XRECHNUNG, as XML only | adds the German business rules (BR-DE) |
| Customer in France | check the French requirements | France uses Factur-X with its own reference profile EXTENDED-CTC-FR |
ZUGFeRD version history: which versions exist?
The dates below come from FeRD's version archive and press releases. Since ZUGFeRD 2.0 the standard has been technically identical to the French Factur-X. The table gives the Factur-X number where FeRD has published it.
| Version | Released | Factur-X | Note | E-invoice? |
|---|---|---|---|---|
| 1.0 | 25 Jun 2014 | – | own data model, profiles BASIC, COMFORT, EXTENDED | no |
| 2.0.1 | 15 Oct 2019 | – | minimum version named by the BMF; based on EN 16931 and CII | yes (from BASIC) |
| 2.1 | 24 Mar 2020 | – | embedded file named factur-x.xml | yes (from BASIC) |
| 2.1.1 | 1 Jul 2020 | – | follow-up release to 2.1 | yes (from BASIC) |
| 2.2 | 1 Mar 2022 | – | XRECHNUNG reference profile, named in the federal FAQ | yes (from BASIC) |
| 2.3 | 18 Sep 2024 | – | follow-up release to 2.2 | yes (from BASIC) |
| 2.3.2 | 13 Nov 2024 | – | current when the receiving obligation started on 1 Jan 2025 | yes (from BASIC) |
| 2.3.3 | 7 May 2025 | – | follow-up release to 2.3 | yes (from BASIC) |
| 2.4 | 4 Dec 2025 | 1.08 | sub-lines, CII D22B, in force from 15 Jan 2026 | yes (from BASIC) |
| 2.5 | 10 Jun 2026 | 1.09 | new code lists, new EXTENDED elements | yes (from BASIC) |
| 2.5.2 | 4 Aug 2026 | 1.09.2 | corrigendum to 2.5, current release | yes (from BASIC) |
FeRD no longer offers versions 1.0 to 2.5 for download; the archive only documents them. For version 2.4, FeRD states that it is based on UN/CEFACT CII D22B and fully backward compatible with D16B. The next release is announced for autumn 2026 and is expected to add gross-price invoices and further content from the revised EN 16931-1.
Which ZUGFeRD version is mandatory?
No specific release. The BMF only sets the floor at 2.0.1. An invoice made with ZUGFeRD 2.2 in the EN 16931 profile is still a valid e-invoice, and so is one made with 2.5.2. According to the BMF letter, which permitted format the parties use is a matter of civil law between them.
Updating is still worth it. FeRD releases new versions in step with the twice-yearly update of the EN 16931 code lists. Software stuck on a 2022 release does not know newer codes and may reject them on import.
How to spot ZUGFeRD 1.0
ZUGFeRD 1.0 uses its own data model and is not an e-invoice. Three signs give it away:
- the root element is
rsm:CrossIndustryDocument, notrsm:CrossIndustryInvoice; - the identifier looks like
urn:ferd:CrossIndustryDocument:invoice:1p0:comfort; - the embedded file is
ZUGFeRD-invoice.xml, notfactur-x.xml.
The exact 2.x release (2.1, 2.3 or 2.5.2) is hard to tell from the file, because the BT-24 values have stayed the same since 2.0. For the e-invoice question that does not matter: the profile decides.
Worked example: is this incoming invoice an e-invoice?
Beispiel AG, a German subsidiary of an international group, receives invoice RE-2026-0042 from its supplier Muster GmbH as a PDF. The shared-service centre abroad wants to know whether it counts as an e-invoice or as an other invoice. After extracting the XML, the context block reads:
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:factur-x.eu:1p0:basicwl</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
The value ends in basicwl, so the file uses the BASIC WL profile and is an other invoice for VAT. That is acceptable until the end of 2026 if Beispiel AG has agreed to receive it. The team still asks Muster GmbH to switch to the EN 16931 profile from January. If the value were urn:cen.eu:en16931:2017, the invoice would be an e-invoice and the XML data, not the PDF, would be what counts.
ZUGFeRD profile vs XRechnung vs Factur-X
| Term | What it is | Relation to ZUGFeRD profiles |
|---|---|---|
| ZUGFeRD profile | scope of the invoice data in the CII XML | MINIMUM to EXTENDED, plus reference profiles |
| ZUGFeRD version | release of the specification, such as 2.5.2 | every 2.x release contains all profiles |
| Factur-X | French name of the same standard | Factur-X 1.09.2 equals ZUGFeRD 2.5.2 |
| XRechnung | German specification by KoSIT, based on EN 16931 | carried as CII XML in the XRECHNUNG reference profile |
| EN 16931 | European standard for the invoice data model | the yardstick for "e-invoice or not" |
For the naming question, see ZUGFeRD vs Factur-X. Short definitions are in the glossary entry on the ZUGFeRD profile.
What applies to German public authorities?
For invoices to the German federal administration, XRechnung is the default. The FAQ of the federal e-invoicing service (opens in a new tab) allows other standards that meet EN 16931, the federal e-invoicing ordinance (E-RechV) and the platform's terms of use. It names ZUGFeRD 2.2.0 in the XRECHNUNG profile, accepted "only and exclusively as a purely structured XML file without a visual format". In practice you upload the embedded XML, not the PDF. Federal states and municipalities run their own portals and may differ.
How to check the profile with docutools.pro
- Open the tool to extract XML from a PDF and click "Choose PDF". It runs in your browser, so the file does not leave your computer. The free version handles one PDF at a time.
- Check number, date and totals in the "Invoice summary". The tool does not name the profile, so open "XML source" and search for
GuidelineSpecifiedDocumentContextParameter. Compare the value with the profile table above. For ZUGFeRD 1.0 no summary appears, which is itself a hint at the old version. - Save the file with "Download XML" and upload it to the ZUGFeRD validator. The file is sent to our server for the check; the free plan allows two uploads per day of up to 500 KB.
- Read the result according to the profile. XRECHNUNG files get the EN 16931 and XRechnung rules, EN 16931 files only the rules of the standard. The KoSIT configuration has no scenario for MINIMUM, BASIC WL, BASIC or EXTENDED. Like the KoSIT validator, the viewer rejects them before any rule runs, with the message "None of the loaded scenarios matches the specified document". For BASIC and EXTENDED this does not mean the file is not an e-invoice; it only means this validator does not cover the profile.
- If you need a test file of your own, you can create a ZUGFeRD invoice without an account. The exports "ZUGFeRD XML" and "ZUGFeRD PDF" write the XRECHNUNG identifier (XRechnung 3.0 in CII) into BT-24. The German BR-DE rules therefore apply as well, including the buyer reference in BT-10.
To check PDF/A-3 and metadata on top of that, follow Validate a ZUGFeRD PDF. What the official tool checks is explained in KoSIT Validator. More guides are in the ZUGFeRD and Factur-X category.
Sources
- BMF letter of 15 October 2025 on e-invoicing, section 14.1 (14) UStAE (German) (opens in a new tab)
- ZUGFeRD version archive, FeRD (German) (opens in a new tab)
- News "ZUGFeRD 2.5.2 veröffentlicht", 4 August 2026, FeRD (German) (opens in a new tab)
- News "Neue ZUGFeRD-Version 2.4 veröffentlicht", 4 December 2025, FeRD (German) (opens in a new tab)
- ZUGFeRD FAQ, FeRD (German) (opens in a new tab)
- FAQ of the federal e-invoicing service (German) (opens in a new tab)
- § 14 UStG on gesetze-im-internet.de (German) (opens in a new tab)
Last reviewed: October 2026
This article is general information, not tax or legal advice.
Tools for this article
- ZUGFeRD / Factur-X XML ExtractorExtract, view and download the embedded e-invoice XML from ZUGFeRD and Factur-X PDFs.Open tool →
- XRechnung ViewerParse, validate & repair German e-invoices with GoBD-compliant audit trail.Open tool →
- E-Invoice GeneratorCreate compliant XRechnung XML and ZUGFeRD hybrid PDF invoices instantly.Open tool →
Frequently asked questions
What is the latest ZUGFeRD version?
The latest version is ZUGFeRD 2.5.2, published on 4 August 2026 by FeRD, the German Forum for Electronic Invoicing, together with its French partner FNFE-MPE. It matches Factur-X 1.09.2 and mainly corrects inconsistencies in version 2.5 of 10 June 2026. FeRD has announced the next release for autumn 2026, expected to add support for gross-price invoices.
Which ZUGFeRD profile do I need for invoices in Germany?
For a standard invoice between two businesses in Germany, use the EN 16931 profile. It covers the full core data model of the European standard and is accepted as an e-invoice. BASIC and EXTENDED also qualify. MINIMUM and BASIC WL do not. For German federal authorities, use the XRECHNUNG profile and upload only the XML file, not the PDF.
Is a Factur-X invoice valid in Germany?
Yes, if it uses a qualifying profile. Factur-X and ZUGFeRD have been technically identical since ZUGFeRD 2.0, and Factur-X 1.09.2 equals ZUGFeRD 2.5.2. The German Finance Ministry accepts any format that complies with EN 16931. A Factur-X file in the EN 16931 profile is therefore an e-invoice in Germany, while MINIMUM and BASIC WL files are not.
Is ZUGFeRD BASIC WL an e-invoice?
No. The German Finance Ministry letter of 15 October 2025 explicitly excludes the MINIMUM and BASIC WL profiles. Both have no invoice lines and do not cover the full EN 16931 data model. A BASIC WL file therefore counts as an other invoice (sonstige Rechnung), like a plain PDF, which is allowed only during the transition period that ends on 31 December 2027 at the latest.
Do I have to upgrade to ZUGFeRD 2.5.2?
Not for VAT purposes. Every 2.x release from 2.0.1 onwards remains a permitted e-invoice format in Germany. An update still makes sense, because each release adopts the twice-yearly EN 16931 code list updates. Outdated software may write or reject codes that current validators assess differently. Ask your software vendor which release it supports.