Factur-X vs ZUGFeRD: same thing, different names?
By evoicely · Last checked 20 October 2026
Yes: Factur-X and ZUGFeRD are the same format. Since March 2020, the German forum FeRD and the French forum FNFE-MPE have published one joint specification, and FNFE-MPE puts it plainly: "Technically, both Factur-X and ZUGFeRD are identical." Both are a PDF/A-3 invoice with CII XML embedded. ZUGFeRD is the name used in Germany, Factur-X the one used in France, and the version numbers differ. A file made to one is a valid file of the other, as long as the profile fits what the recipient needs.
One specification since 2020
The two began as separate national names for closely related formats. On 24 March 2020, FeRD published ZUGFeRD 2.1 as "the joint invoice standard ZUGFeRD 2.1 / Factur-X 1.0": fully compatible, technically identical formats that from that date share the Factur-X identifiers (FeRD: ZUGFeRD 2.1). Every release since has come out under both names at once:
| Factur-X | ZUGFeRD | Published |
|---|---|---|
| 1.0.05 | 2.1 | 24 March 2020, first joint release |
| 1.07.2 | 2.3.2 | 15 November 2024 |
| 1.09.2 | 2.5.2 | 4 August 2026, current |
Sources: FNFE-MPE: Factur-X (current release and "Factur-X is the same standard than ZUGFeRD 2.5"), FeRD: ZUGFeRD (information package for ZUGFeRD 2.5.2, 4 August 2026), and the FeRD FAQ, which refers to "ZUGFeRD 2.3/Factur-X 1.0.07". The specification is published in English, German and French by both forums.
Profiles: the same names on both sides
The core standard has five data profiles, with the same names and the same identifiers (business term BT-24) in Factur-X and ZUGFeRD:
| Profile | Specification identifier (BT-24) | E-invoice in Germany? |
|---|---|---|
| MINIMUM | urn:factur-x.eu:1p0:minimum | No |
| BASIC WL | urn:factur-x.eu:1p0:basicwl | No |
| BASIC | urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic | Yes |
| EN 16931 (COMFORT) | urn:cen.eu:en16931:2017 | Yes |
| EXTENDED | urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended | Yes |
The identifiers say factur-x.eu even in a file labelled ZUGFeRD. On top of these, the joint specification allows reference profiles for national rules:
FNFE-MPE names XRECHNUNG for Germany and EXTENDED-CTC-FR, a subset of EXTENDED, for France
(FNFE-MPE). What each profile contains is in ZUGFeRD profiles explained.
So what actually differs?
- The name and the version number. Factur-X 1.09.2 and ZUGFeRD 2.5.2 are the same release. When a customer asks for "ZUGFeRD 2.3" or "Factur-X 1.07", they mean the same generation.
- Which national reference profile you'd use. XRECHNUNG is the German one: a PDF carrying an XRechnung. FeRD says the embedded file is then named
xrechnung.xmlinstead offactur-x.xml, and one PDF may hold only one of the two (FeRD FAQ). EXTENDED-CTC-FR is the French one, for the French reform's extra data. - Older German files. Before the joint release, ZUGFeRD 2.0 used its own identifiers (
urn:zugferd.de:2p0:…) and file namezugferd-invoice.xml. Germany accepts ZUGFeRD from version 2.0.1, so you may still receive such files; our validator reads them.
Everything else is shared: the PDF/A-3 container, the CII syntax, the embedded file name factur-x.xml, and the PDF's XMP metadata, which uses the Factur-X namespace even in a "ZUGFeRD" file.
Here is the metadata block evoicely writes into its ZUGFeRD PDFs:
<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>
Inside, the XML is a CII invoice. Its profile sits in the guideline parameter. This excerpt is from a fictional invoice made with evoicely's converter; the full file passes the XML schema and the EN 16931 rules in our validator without errors:
<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" ...>
<rsm:ExchangedDocumentContext>
...
<ram:GuidelineSpecifiedDocumentContextParameter> <!-- BT-24: the profile -->
<ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<ram:ID>INV-2026-0042</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
...
The <!-- --> comment was added for this page. Why it's CII and never UBL is explained in UBL vs CII.
Factur-X in France's e-invoicing reform
France doesn't let businesses send e-invoices straight to each other. Invoices go through a plateforme agréée (PA), an approved platform registered with the tax administration, which also passes the required data on to the administration. Every PA must support a minimum base of three formats built on EN 16931: UBL, CII and Factur-X, and must convert an incoming invoice into another of them if its customer asks (DGFiP, Dossier de spécifications externes, document général v3.2, 30 April 2026). FNFE-MPE adds that Factur-X is one of the three formats every company and PA must accept on receipt, as set out in the AFNOR standard XP Z12-012.
The timeline, according to the tax administration (impots.gouv.fr, fiche 1, updated June 2026):
- Since 1 September 2026: every business must be able to receive e-invoices, and large and mid-sized companies must issue them.
- From 1 September 2027: SMEs and micro-businesses must issue them too, including micro-entrepreneurs under the VAT franchise.
A Factur-X file alone doesn't meet the French rules: it has to travel through a PA, and the reform adds French data requirements on top of EN 16931. evoicely is not a plateforme agréée. For other countries, see EU e-invoicing deadlines by country.
ZUGFeRD in Germany's mandate
Germany has no platform requirement: an e-invoice can go by email. A ZUGFeRD file counts as an e-invoice from version 2.0.1, except the MINIMUM and BASIC WL profiles (BMF letter of 15 October 2025). That leaves BASIC, EN 16931, EXTENDED and XRECHNUNG. FeRD recommends EN 16931 for EU-compliant e-invoices, and that's the safe default. Since 2025, the embedded XML is the invoice; the PDF is a readable copy (FeRD FAQ).
Because the formats are identical, a German customer who asks for ZUGFeRD can be sent a file the generator calls Factur-X, and the other way round. What matters is the profile in BT-24. Who must issue e-invoices from when is in Germany's e-invoicing mandate for Stripe users, and the choice between the hybrid PDF and pure XML in XRechnung vs ZUGFeRD.
Related guides
- ZUGFeRD profiles explained: MINIMUM to EXTENDED and XRECHNUNG.
- XRechnung vs ZUGFeRD: which one your German customers need.
- UBL vs CII: the two syntaxes behind XRechnung, ZUGFeRD and Peppol.
- What is EN 16931?: the standard all of these build on.
Where evoicely fits
evoicely turns your Stripe invoices into ZUGFeRD / Factur-X files with the EN 16931 profile: a PDF/A-3 with the XML embedded as factur-x.xml, checked with the Mustang validator, plus XRechnung where a customer needs it. It doesn't route invoices through French approved platforms. Get started, free for 10 e-invoices a month.
This is general information, not legal or tax advice. Check what applies to your business with your tax advisor.