ZUGFeRD guide: what is ZUGFeRD and when does it make sense?

ZUGFeRD is a widely used German e‑invoicing format where structured invoice data is embedded into a PDF. This makes an invoice both human‑readable (the PDF you see) and machine‑readable (data that accounting systems can validate and import).

This guide explains when ZUGFeRD is a good fit, how it works technically, what recipients typically validate, and which setup choices help you avoid rejections.

Note: This is general information and not legal or tax advice. Requirements can vary by recipient (e.g., public sector) and by workflow.

1) ZUGFeRD in one sentence

ZUGFeRD combines a PDF invoice with embedded structured invoice data so recipients can automate processing without switching to a pure XML‑only flow.

2) Key takeaways (if you only read one section)

  • ZUGFeRD is a hybrid invoice: PDF for people, data for systems.
  • It can be used in B2B, B2G, and B2C, but the decision is usually driven by what your recipient/portal requires.
  • Most failures come from data quality (mandatory fields, taxes, rounding), not from “the PDF”.
  • If a recipient requires XRechnung, plan for an XML-first workflow instead.

3) When is ZUGFeRD useful?

Typical scenarios where ZUGFeRD helps:

  • B2B invoices where recipients want automated booking/import
  • workflows that still rely on PDF, but benefit from structured data
  • reducing manual work by enabling machine‑readable extraction

ZUGFeRD is often a pragmatic way to modernize a PDF-based process without forcing recipients into a “XML only” world.

If a recipient explicitly requires an XRechnung (common in the public sector), ZUGFeRD may not always be sufficient—this depends on the exact scenario.

4) ZUGFeRD vs. XRechnung (practical view)

Both formats support electronic invoicing, but they are often used differently:

  • ZUGFeRD: typically a PDF‑centric workflow with embedded data
  • XRechnung: typically an XML‑centric workflow, especially relevant for public sector recipients

To choose, focus on:

  • what the recipient requires,
  • what the recipient’s systems can process,
  • whether you want PDF to remain the primary document.

If you need XRechnung details, see: /en/xrechnung

5) A simple workflow

  1. Capture invoice data (customer, items, taxes, payment terms)
  2. Generate the invoice
  3. Optionally produce a ZUGFeRD version (PDF + embedded structured data)
  4. Send it to the recipient
  5. Archive it (retrievable, complete, not silently altered)

6) Where ZUGFeRD comes from (and why this matters)

ZUGFeRD is developed by the Forum for Electronic Invoicing Germany (FeRD). It is aligned with:

  • EU requirements for electronic invoicing in public procurement (Directive 2014/55/EU)
  • the European invoice standard EN 16931

Why this matters: many validations and mandatory fields are derived from those foundations. If your invoice is rejected, it’s usually because a structured invoice rule is violated (missing reference, inconsistent totals, invalid tax coding) even if the PDF looks correct.

Official background and downloads (FeRD):

7) How ZUGFeRD works technically (hybrid PDF + structured data)

At a high level, a ZUGFeRD invoice is:

  1. a PDF/A‑3 document (archivable PDF), and
  2. an embedded structured invoice file based on UN/CEFACT Cross‑Industry Invoice (CII).

The recipient can read the PDF like any normal invoice, while their accounting system can parse the embedded data.

Practical implications:

  • The structured data must match the PDF values exactly (totals, tax amounts, dates).
  • If you post-process the PDF (merge, stamp, re-render), you can break consistency.
  • Treat the PDF + data as a single “locked” business document once you publish it.

8) ZUGFeRD profiles — what do they mean?

In practice, you’ll see different ZUGFeRD profiles. They roughly determine how much structured data is included.

  • BASIC: reduced data set (for simpler invoices)
  • EN 16931: aligned with the European core invoice model
  • EXTENDED: additional fields/structures for more complex scenarios

The name matters less than the recipient requirement:

  • Can the recipient process ZUGFeRD at all?
  • Do they expect a specific profile?
  • Are there portal/EDI rules?

Important: profile sets and rule details can evolve across versions. If a portal mandates a profile, follow that requirement first.

If the recipient explicitly requires XRechnung, see: /en/xrechnung

9) What recipients typically validate

Recipient systems often validate two layers:

  1. Technical layer: is the invoice data well-formed and consistent?
  2. Business layer: do totals, taxes, and mandatory fields match?

Typical checks include:

  • complete seller/buyer details
  • consistent totals (net/tax/gross)
  • correct tax coding (standard/reduced/reverse-charge)
  • plausible service descriptions
  • required business references (especially in B2G scenarios)

10) Validation & testing (a practical approach)

If you introduce ZUGFeRD, a simple test loop helps:

  1. Send a test invoice to yourself (or a test recipient)
  2. Confirm the recipient system detects the structured data
  3. If something fails, check master data, tax logic, and rounding step-by-step

Many workflows use additional validators (via portals or the recipient’s accounting tooling). Which validator is “right” depends on your scenario.

11) Implementation checklist: what to set up before you send real invoices

If you want ZUGFeRD to work reliably, set up these foundations once.

Seller master data

  • Legal name and address (consistent spelling)
  • VAT ID (if applicable) and tax registration details
  • Bank details (IBAN/BIC) and payment terms
  • A clear invoice numbering scheme

Buyer / client master data

  • Correct company name and address
  • VAT ID (if applicable)
  • Any recipient-specific routing info (portal ID, buyer reference, cost center)

Invoice line items

  • Clear service/product description
  • Correct quantities and units
  • Correct tax category / VAT rate
  • Discounts and surcharges represented consistently

Totals & rounding

  • Decide on one rounding approach (line-level vs total-level) and keep it consistent
  • Test with “hard” invoices (many small items, mixed taxes, discounts)

12) Common mistakes (and how to avoid them)

Mistake 1: Missing or inconsistent mandatory fields

Ensure invoice data is complete and consistent. A PDF that looks fine can still fail validation if structured fields are missing or contradictory.

Mistake 2: Rounding differences between PDF and structured data

Small differences can break automated validation.

Example (simplified):

  • line items are rounded individually, but the total is rounded differently,
  • or net/tax/gross are calculated from different rounding stages.

Practical tip: test with a few “realistic” invoices (e.g., many small line items).

Mistake 3: Wrong tax category (especially reverse charge)

Reverse charge and other special tax scenarios require specific codes/fields. A PDF note alone may not be sufficient for structured validation.

Practical tip: create one test invoice per tax scenario you use (standard VAT, reduced VAT, reverse charge) and validate it in the recipient workflow.

Mistake 4: The recipient can’t process ZUGFeRD

Confirm support upfront. Otherwise you just send a PDF without automation benefits.

Mistake 5: Archiving without clear rules

A clean archiving process helps both operationally and in GoBD contexts.

GoBD basics: /en/gobd

13) Troubleshooting: what to do when a recipient rejects your invoice

When an invoice is rejected, triage in this order:

  1. Clarify the target requirement: ZUGFeRD allowed? Which profile? Any portal constraints?
  2. Check mandatory business references (common in B2G): buyer reference / routing IDs.
  3. Reconcile amounts: do net/tax/gross totals match exactly?
  4. Check taxes: correct VAT category and rate? Reverse charge correctly expressed?
  5. Check dates: invoice date, delivery/performance date, due date.
  6. Validate master data: addresses, VAT IDs, bank details.

If you can reproduce the failure with a single test invoice, you can fix most issues quickly.

14) Versioning notes (why “works for one recipient” may fail for another)

Recipients and portals may validate against different versions and rule sets.

FeRD publishes the current ZUGFeRD release downloads and also provides older versions via the version archive.

As of December 2025, FeRD lists ZUGFeRD 2.4 as the current information package. If your process references an older version (e.g., 2.1.x), confirm compatibility with your recipient.

Official links:

15) Quick checklist

  • Confirm recipient requirements (ZUGFeRD vs XRechnung)
  • Validate master data (address, VAT ID, payment terms)
  • Ensure taxes and totals match (including rounding)
  • Ensure mandatory fields are complete (address, dates, clear descriptions)
  • Test with a self-send / test recipient
  • Define archiving and backups

16) Mini FAQ

Do I always need ZUGFeRD?

No. What matters is what your recipient requires and what workflow you want.

What if the recipient requires XRechnung?

Then ZUGFeRD may not be sufficient. See: /en/xrechnung

17) Next steps on this site

18) Want a simple starting point?

If you’re currently sending PDF-only invoices, a pragmatic path is:

  1. keep your PDF workflow,
  2. add ZUGFeRD for recipients that can process it,
  3. move to XRechnung only where it’s explicitly required.

That keeps disruption low while you build a compliant, testable process.