ZUGFeRD vs XRechnung: what’s the difference and which format do you need?

Both ZUGFeRD and XRechnung are e‑invoice formats aligned with EN 16931. In practice, they differ in workflow and in what recipients commonly require.

In short:

  • ZUGFeRD is often PDF-first (a PDF with embedded structured invoice data) — convenient in many B2B workflows.
  • XRechnung is typically XML-first — widely used/required for B2G invoicing to the German public sector.

Note: This page is general guidance, not legal or tax advice. In the end, your recipient or portal requirements decide.

0) Key takeaways (fast decision)

  • If you invoice public-sector recipients (B2G) and a portal is involved, XRechnung is often required or the safest default.
  • If you invoice business customers (B2B) and you want a PDF to remain the human-readable document in the workflow, ZUGFeRD is often the practical choice.
  • Most rejections are caused by routing IDs and references (Leitweg-ID, order/case references) and rounding/totals logic.
  • Regardless of format: generate, validate first, submit/send, and archive invoice + evidence in an auditable way.

1) One sentence summary

  • ZUGFeRD: invoice PDF + embedded structured data (hybrid)
  • XRechnung: structured XML invoice (validation-driven)

Both can be correct depending on the recipient.

2) Comparison matrix (practical)

CriterionZUGFeRDXRechnung
RepresentationPDF (human-readable) + structured dataXML (structured data first)
Typical useB2BB2G
Submissionoften email/upload as PDFoften portal upload/specific channels
Validation feelissues can show up laterissues show up quickly in validators/portals
Routing IDssometimes optionaloften central (e.g., Leitweg-ID)
Attachmentsoften possible, recipient-dependentportal-dependent and sometimes strict

Use this as a rule of thumb. Your recipient’s process is the final authority.

3) Typical use cases (B2B / B2G)

When ZUGFeRD is often a good fit

  • you invoice business customers (B2B)
  • your recipient still wants a PDF, but also needs machine-readable data
  • you prefer a simple “generate PDF → send → archive” workflow

More details: /en/zugferd

When XRechnung is often the safe default

  • you invoice public-sector entities (B2G)
  • your recipient explicitly requests XRechnung or EN 16931
  • you must submit invoices via an e‑invoicing portal

More details: /en/xrechnung

4) Recipient requirements: routing IDs and references

A common rejection reason — especially in B2G — is not “the format”, but missing/incorrect references:

  • Leitweg-ID (or another routing identifier)
  • purchase order / case references

Practical advice:

  • clarify identifiers before creating the invoice
  • copy values exactly as provided
  • make routing IDs required for public-sector recipients in your workflow

5) Validation: why XRechnung feels stricter (and why ZUGFeRD still needs validation)

XRechnung is usually validated automatically:

  • technical XML validity
  • business rules (totals, mandatory fields, codes)

That doesn’t mean ZUGFeRD is “loose” — the workflow is just different:

  • with XRechnung, issues show up immediately in validators/portals
  • with ZUGFeRD, the PDF can look fine while embedded data still has errors

A pragmatic workflow for both:

  1. generate
  2. validate
  3. submit/send
  4. archive invoice + evidence

GoBD context: /en/gobd

6) A decision flow you can apply today

If you just need a reliable decision, go through these questions:

  1. Is the recipient public sector (B2G)?

    • Yes → often XRechnung.
    • No → continue.

  2. Is portal submission mandatory?

    • Yes → very often XRechnung (or portal-specific rules).
    • No → continue.

  3. Does the recipient explicitly require ZUGFeRD?

    • Yes → ZUGFeRD.
    • No → continue.

  4. Does the recipient explicitly require XRechnung / EN 16931?

    • Yes → XRechnung.
    • No → ZUGFeRD is often a pragmatic default if accepted.

If you’re unsure: ask the recipient whether they require “XRechnung” or accept “ZUGFeRD”, and whether portal upload is mandatory.

7) Leitweg-ID, purchase orders, and case references

In practice, these are the “invisible mandatory fields”:

  • Leitweg-ID (routing)
  • purchase order number (PO)
  • case/reference ID

Practical tips:

  • copy values exactly (no extra spaces, no formatting changes)
  • store them in customer/project master data for repeat invoicing
  • define internally who obtains them and where they are documented

8) Attachments and submission evidence

Some recipients require supporting documents (timesheets, delivery notes, acceptance protocols).

Pragmatic approach:

  • standardize an “invoice package”: invoice + attachments + submission evidence
  • always archive the submission proof together with the invoice
  • keep portal limits (file types/sizes) documented in your workflow

9) Corrections: don’t overwrite

For both formats, assume corrections must remain traceable.

Good practice:

  • archive the original invoice
  • correct using proper correction documents (cancellation + corrected invoice, or recipient-required process)
  • keep references clear (which invoice corrects which)
  • archive original + correction + submission evidence together

10) Common misconceptions

“ZUGFeRD is always better because it’s a PDF”

True for many B2B workflows. But in B2G contexts, portals often require XRechnung.

“XRechnung is only for large enterprises”

In practice, many small suppliers need it as soon as they invoice public-sector entities.

“If the PDF looks fine, everything is fine”

With ZUGFeRD, the PDF can look fine while embedded structured data still fails validation.

11) Decision helper (quick check)

Choose ZUGFeRD if …

  • your recipient is a private business and accepts ZUGFeRD
  • you want a PDF as the human-readable document in the process

Choose XRechnung if …

  • you invoice the public sector or a portal requires it
  • routing identifiers (e.g., Leitweg-ID) are central to submission

If you’re unsure: ask the recipient whether they require “XRechnung” or accept “ZUGFeRD”, and whether portal submission is mandatory.

12) Pre-submission checklist

  • recipient requirements confirmed (ZUGFeRD/XRechnung, profile/version)
  • routing identifiers available (e.g., Leitweg-ID)
  • master data complete (addresses, tax IDs)
  • totals and taxes consistent (rounding!)
  • file validated (technical + business rules)
  • submission/sending evidence saved
  • invoice and evidence archived

13) FAQ (short)

Can I support both formats?

Yes. Many organizations and tools support both. Your operational process (portal, routing IDs, references) decides what you use per recipient.

Do I need to understand EN 16931 in detail?

Not usually. What matters in practice is completeness of mandatory fields, correct totals/taxes, and correct recipient-specific identifiers.

Can public-sector recipients accept ZUGFeRD?

Sometimes — but many explicitly require XRechnung or a portal-specific workflow. Always confirm requirements.

14) Next steps

If you want the full details: