eliDocs
E-invoicing answers

Is ZUGFeRD the same as Factur-X?

Technically yes, one hybrid PDF format published under two national labels, with the same syntax, schemas and rule pack. The differences are the publisher, one France-only profile, and which name your counterparty uses.

ZUGFeRD and Factur-X are the same wire format under two names. Same XML syntax, same per-profile schemas, same Schematron pack, same file on disk. FeRD publishes it as ZUGFeRD for the German market and FNFE-MPE publishes it as Factur-X for France, and the joint pack carries both labels.

What the format actually is

What the format actually is

Both are hybrid invoices: a PDF/A-3 document that a person can open and read, with the structured invoice embedded inside it as UN/CEFACT CII XML. The attachment has a fixed name, factur-x.xml, under both labels. So one file serves two readers. Your customer’s accounts-payable clerk sees an invoice; their software reads the XML and never looks at the rendering.

That is the whole idea, and it is why the format spread: it does not force the receiving side to change anything before the sending side can start. A hybrid invoice degrades to a readable PDF for anyone not yet processing the XML.

Where they differ

Where they differ

ZUGFeRD Factur-X
Published by FeRD (Germany) FNFE-MPE (France) and FeRD, jointly
XML syntax CII CII, the same
Rule pack The joint pack The same joint pack
French B2B reform overlay Not available extended-ctc-fr
In the Beliq API standard: "zugferd" standard: "facturx"

The only substantive difference is the last profile. EXTENDED-CTC-FR is a France-only regulatory overlay for the French B2B reform, so it exists under the Factur-X label and not the German one. Everything else is identical, including the validation pipeline: the schema check, the EN 16931 business rules, then the profile rules the document’s own identifier selects.

Five profiles, and they are not all EN 16931 invoices

Five profiles, and they are not all EN 16931 invoices

Both labels ship the same five profiles, and picking one is a real decision rather than a formality:

  • MINIMUM carries header data only: invoice number, dates, totals. No line items.
  • BASIC WL is header-level data without line items.
  • BASIC adds essential line items.
  • EN 16931 (also called Comfort) is a full EN 16931 invoice, and the sensible default.
  • EXTENDED is EN 16931 plus additional fields.

MINIMUM and BASIC WL are reduced profiles and are not complete EN 16931 invoices. They exist for specific receiving systems that ask for them, and choosing one because it looks simpler will produce a document a compliance regime does not accept. If nobody has told you which profile to send, send EN 16931.

Which label should you use?

Which label should you use?

It makes no difference to the bytes, so use whichever your counterparty and your market name. German buyers and German documentation say ZUGFeRD; French buyers and the French reform say Factur-X. A document produced under one label is readable by a system expecting the other, because there is nothing to translate.

Where it does matter is validation depth: both sit at Authority-checked, on the builder-round-trip tier. The Schematron judging your document is the authority’s own, pinned by version and hash, but the publisher does not release a per-rule test corpus to check that ruleset against. Correctness rests on the authority’s positive sample invoices and round-trips through Beliq’s own generator instead. That is a weaker footing than the formats with a published unit-test corpus, and it is stated rather than smoothed over.

Generating one

Generating one

POST /v1/generate with standard: "zugferd" or "facturx" and output: "pdf" returns the PDF/A-3 with the XML embedded; the same request with output: "xml" returns just the XML. If you omit profile, you get EN 16931. The engine embeds the XML and then validates the resulting file as PDF/A-3b before returning it, so a hybrid that is not valid PDF/A does not reach you.

Related