ZUGFeRD vs Factur-X vs XRechnung vs Peppol

These four names come up together constantly, usually as if you had to choose one over the others. You mostly do not. They are not competing formats; they sit at different layers, and some of them are the same thing under two names. This page sorts out what each one actually is and which you need.

In one paragraph: EN 16931 is the European standard that defines what data an invoice must contain. ZUGFeRD and Factur-X are the same hybrid format (a PDF with that data embedded as XML), one named in Germany and one in France. XRechnung is Germany's rulebook for invoicing the public sector, sent as pure XML. Peppol is not a format at all: it is the network invoices travel over. PolyDoc generates the ZUGFeRD / Factur-X hybrid PDF.

They are not the same kind of thing

The single most useful idea here is that these terms live on four separate layers. Once you see the layers, the comparison stops being confusing.

1. The standard: what data an invoice must carry. This is EN 16931, the European semantic model for an invoice. It says an invoice has a seller, a buyer, line items, VAT breakdowns, totals, and so on. It does not say how to write that down in a file.
2. The syntax: how the data is written as XML. Two XML languages comply with EN 16931: UN/CEFACT CII (Cross Industry Invoice) and OASIS UBL 2.1. They express the same information with different tags.
3. The usage specification: a country's or network's extra rules. A specification narrows EN 16931 to a specific context (which optional fields become mandatory, which code lists are allowed). XRechnung, Peppol BIS Billing, and the profiles inside ZUGFeRD / Factur-X all live here.
4. The transmission: how the invoice gets delivered. Email, a portal, or a network. Peppol is the dominant network for cross-border EU exchange.

With that in mind, here is each term.

ZUGFeRD and Factur-X: the hybrid PDF

ZUGFeRD and Factur-X are one and the same standard with two names. ZUGFeRD is the German name, Factur-X is the French name, and they are maintained jointly by the German FeRD and the French FNFE-MPE. A file produced as one is readable as the other; the version numbers even track each other (Factur-X 1.09 corresponds to ZUGFeRD 2.5).

Their defining feature is that they are hybrid: a single PDF/A-3 file that a person can open and read like any invoice, with the structured EN 16931 data embedded inside it as CII XML. One file serves both the human and the machine. That is what makes them convenient for ordinary B2B invoicing: you send one attachment, and whether the recipient processes it by eye or by software, it works.

Both come in the same set of profiles, which control how much structured data the XML carries:

Profile	What it holds	Valid EN 16931 invoice?
MINIMUM	Totals and payment data only, no line items	No (accounting aid only)
BASIC WL	Header and payment data, no line items	No (accounting aid only)
BASIC	Line items, without allowances or charges	Yes (reduced)
EN 16931 (COMFORT)	The full core standard	Yes
EXTENDED	The core plus extra fields for complex cases	Yes
XRECHNUNG	Carries XRechnung-conformant data in the hybrid PDF	Yes

The MINIMUM and BASIC WL profiles are booking aids, not legally valid electronic invoices on their own, so most senders use EN 16931 (or BASIC for simple invoices).

XRechnung: Germany's public-sector rulebook

XRechnung is a CIUS (a Core Invoice Usage Specification) of EN 16931: it takes the European core and tightens it with the specific rules German authorities require. It is the mandatory format for B2G invoicing (selling to the German public sector) and is maintained by KoSIT.

Two differences from ZUGFeRD / Factur-X matter in practice:

• It is pure XML, not a hybrid PDF. An XRechnung is a standalone XML file (in either UBL or CII syntax). There is no human-readable PDF layer built in, though the receiving system may render one.
• It is a rulebook, not a container. You can carry XRechnung-conformant data inside a ZUGFeRD hybrid PDF using ZUGFeRD's XRECHNUNG profile, which is how you get "one PDF" convenience while still satisfying the public-sector rules.

Peppol: the network, not a format

Peppol is the one that is genuinely different in kind. It is not an invoice format. It is an international network for exchanging business documents, governed by OpenPeppol. It works on a four-corner model: your system hands the invoice to your access point, your access point routes it to the recipient's access point, and that delivers it to the recipient's system. The access points are certified providers that speak the Peppol protocol so you do not have to.

The invoice you send over Peppol still has to be in a format. That format is Peppol BIS Billing 3.0, which is itself a CIUS of EN 16931, written in UBL syntax (CII is accepted only if the specific recipient has opted into it). So Peppol answers "how does the invoice travel", and Peppol BIS answers "what does the invoice look like on that network".

Side by side

Versions below are current as of mid-2026; the standards bodies revise them periodically.

	Kind	Primary scope	XML syntax	Hybrid PDF	Maintained by	Version
ZUGFeRD	Hybrid format + profiles	Germany (accepted EU-wide)	CII	Yes	FeRD	2.5
Factur-X	Same standard, French name	France + cross-border	CII	Yes	FNFE-MPE + FeRD	1.09
XRechnung	Usage spec (CIUS)	Germany, B2G	UBL or CII	No (pure XML)	KoSIT	3.0.2
Peppol BIS Billing	Usage spec (CIUS) on a network	Pan-European	UBL	No	OpenPeppol	3.0
EN 16931	The standard itself	EU	CII or UBL	n/a	CEN/TC 434	:2026

Which one do I need?

• B2B invoicing in Germany, and you want one file that is both readable and structured: ZUGFeRD, EN 16931 profile. (BASIC is fine for simple invoices.)
• B2B invoicing in France: Factur-X. It is the same file; use the facturx label.
• Cross-border EU B2B, and you are unsure: the EN 16931 profile of ZUGFeRD / Factur-X is the safe, interoperable middle. It is the bare European core with no country-specific narrowing.
• Selling to the German public sector (B2G): XRechnung. Send it as pure XML, or carry XRechnung-conformant data in a ZUGFeRD XRECHNUNG profile hybrid PDF if you want a visible document too.
• Exchanging invoices over the Peppol network: Peppol BIS Billing 3.0 (UBL), delivered through a Peppol access point.

If your requirement is simply "send a compliant invoice that both a person and a machine can read", the hybrid PDF (ZUGFeRD / Factur-X) is almost always the pragmatic answer, and it is what PolyDoc produces.

Where PolyDoc fits

PolyDoc is focused on HTML-to-PDF conversion. It generates the ZUGFeRD / Factur-X hybrid PDF (a PDF/A-3 with EN 16931 CII XML embedded) from your JSON, with the layout under your control, in a single API call. That is a good fit when a hybrid PDF is what you need and you are already rendering PDFs with PolyDoc. See Generate e-invoices with PolyDoc.

If e-invoicing itself is the goal, our dedicated e-invoicing product beliq is usually the better tool. It produces and validates the full set of formats in the table above (XRechnung, Peppol BIS, and UBL, as well as Factur-X / ZUGFeRD), checks invoices against EN 16931 and country rules, and keeps pace with each standard's revisions. For delivery over the Peppol network itself, use a Peppol access point.

Next steps

• Understand the foundation: EN 16931 explained.
• Build it: Generate e-invoices with PolyDoc.
• New to PolyDoc? Create a free account, 150 conversions per month, no credit card.