Are ZUGFeRD and Factur-X really identical?

At format level, yes. Same structure, same profiles, same embedded syntax. The names differ because both countries wanted to keep their own brand, not because the files do.

Which Factur-X version applies?

This page describes Factur-X 1.09. Factur-X and ZUGFeRD number their releases separately, even though the underlying specifications are aligned.

What must the embedded file be called?

The filename of the embedded XML is prescribed and differs by standard version. It is not a detail: a checking program looks for exactly that name and will not find an XML stored under a different one.

Is Factur-X enough for invoices to France?

For the format, yes. The French process additionally requires the invoice to travel through an approved platform — the format alone satisfies only one of the two requirements.

Factur-X: the French hybrid format and its relation to ZUGFeRD

One format, two names

Factur-X and ZUGFeRD are the result of Franco-German cooperation. Rather than build two competing hybrid formats, the German FeRD body and its French counterpart agreed on a common technical basis — and each kept its own name.

The result is unusual and pleasant: a file generated in Germany as ZUGFeRD is a valid Factur-X in France. There is nothing to convert.

text

1invoice.pdf  (PDF/A-3)
2├── visible pages
3└── embedded XML in CII syntax

What is the same

The carrier. PDF/A-3, because only that flavour permits embedding.
The syntax. CII, in both countries, with no alternative.
The profiles. MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED — the same tiering with the same meaning.
The ground rule. The embedded XML is the original, the PDF is its rendering.

And therefore the same pitfall: the small MINIMUM and BASIC WL profiles are booking aids, not full e-invoices. That holds on both sides of the border.

What differs

The name of the embedded file. It is fixed by the specification and has not stayed constant across versions. For a checking program that is not a detail: it looks for a particular name among the PDF's attachments and reports "no XML found" when a different one is there — even though the file is present.

🔴 That is one of the most thankless errors there is, because the message points in the wrong direction. Whoever reads it goes looking for a missing attachment and finds one that exists.

The version numbers. Factur-X and ZUGFeRD count separately. The specifications are aligned, the numbers are not — a statement like "we support version 2.x" is unambiguous only with the standard's name in front of it.

The process. And this is where the real difference lies. France regulated its e-invoicing not only through the format but through the route: invoices travel over approved platforms, and the tax administration participates as an additional party — the five-corner model.

Germany has nothing comparable for trade between businesses. So invoicing into France with a correct Factur-X file satisfies the format requirement and not yet the process requirement.

For cross-border invoicing

The practical consequence is pleasingly simple: generate ZUGFeRD in the EN 16931 profile and you have a file that is correct, format-wise, in both countries.

What you additionally have to settle does not concern the file:

By which route does the French recipient expect it?
Is an approved platform involved, and who attaches to it?
Which identifier does the recipient need for addressing?

💡 Keep those two questions cleanly apart — format and delivery route. They get mixed in projects regularly, and then somebody spends days hunting a format bug where a process question is open.

And if the recipient just says "e-invoice"

Then ask for the profile. "We need Factur-X" is a statement about the standard, not about the scope — and between MINIMUM and EN 16931 lies the difference between a booking aid and an invoice.