ZUGFeRD

If your company does business in Germany—selling to German customers, running a German entity, or invoicing German public-sector clients—you’ll run into two terms very quickly: ZUGFeRD and XRechnung. Both are Germany-specific e-invoicing standards (not global standards), built on top of the European model, and they matter because German recipients—especially government bodies—often require them in day-to-day invoicing operations.

This article explains what a ZUGFeRD invoice is, how it works, how to implement it (especially in SAP), and how it differs from XRechnung—so you can choose the right format for your German business processes.

Contact us now!

A ZUGFeRD invoice is a hybrid electronic invoice standard used in Germany. It combines:

• a human-readable PDF/A-3 invoice (the file people can open and review), and
• embedded structured XML invoice data (the part systems can read and automate)

In other words: “PDF for people + XML for systems” in one file—designed for real-world invoicing ecosystems in Germany, where not every trading partner is equally digital.

The process is straightforward:

1. Your ERP generates the invoice as a PDF (layout, branding, legal text)
2. In parallel, the system creates the XML dataset (invoice header, parties, taxes, line items, totals, payment terms, references)
3. The XML is embedded into the PDF/A-3 container
4. The recipient can either:
   • review the PDF manually, or
   • import the XML automatically into their AP/ERP stack

That’s why a ZUGFeRD invoice is often the easiest way to move German invoicing from “PDF-only” toward automation—without forcing partners to change overnight.

ZUGFeRD isn’t “one fixed template.” It comes in profiles that define how much data is included and how strict the structure is. That matters because:

• some profiles are good for “getting started,” but
• for serious automation and compliance-like requirements, you usually need a profile aligned with structured processing needs

Practical guidance for Germany:
If your goal is automation (matching, posting, fewer disputes), pick a profile that supports fully structured invoice data—not just a minimal dataset.

At scale, you should not create ZUGFeRD manually. Professional setups generate ZUGFeRD via:

• ERP systems (e.g., SAP)
• accounting software
• e-invoicing platforms / middleware

A robust end-to-end flow usually looks like:

1. Data quality checks (master + transactional data)
2. PDF generation (your standard invoice output)
3. XML mapping (taxes, totals, units, references)
4. Embedding XML into PDF/A-3
5. Validation against the selected ZUGFeRD profile
6. Delivery (email, portal, network/platform depending on the German recipient)
7. Monitoring & exception handling (rejections, partner rules, version changes)

If you treat ZUGFeRD as “just output,” it will become expensive. If you treat it as an operational process, it scales.

To your customer in Germany, a ZUGFeRD invoice looks like a normal PDF invoice—nothing new to learn.

Behind the scenes, the same file contains structured XML fields such as:

• invoice number/date
• seller/buyer identifiers
• line items with quantities, unit prices, tax categories
• totals and tax breakdown
• payment terms and bank details
• PO numbers / references

Result: humans can read it, systems can automate it.

Before sending ZUGFeRD invoices, validate them. You’ll reduce disputes and speed up payments.

ZUGFeRD itself is typically not “the one mandatory format” in every scenario. What matters is the recipient requirement and whether you’re in:

• B2B (business-to-business): ZUGFeRD is widely used because it keeps the PDF while enabling automation
• B2G (business-to-government in Germany): Public-sector invoicing often expects XRechnung (XML-only) as the target format

So the smart question for Germany is:
Which format does my German recipient accept or require—ZUGFeRD profile X, or XRechnung?

If you invoice German customers out of SAP, the success factors are consistent:

This is the key distinction for companies operating in Germany:

• ZUGFeRD = hybrid (PDF + embedded XML)
  Best fit when your German business partners still rely on PDFs but want structured data for automation.
• XRechnung = XML-only
  Best fit (and often expected) when invoicing German public-sector entities and recipients that require strict machine-only formats.
  

Many companies in Germany run a two-lane strategy:

• ZUGFeRD for B2B partners
• XRechnung for B2G recipients

A well-run ZUGFeRD process delivers practical gains:

• high acceptance in Germany (still a PDF for humans)
• structured data for automation (fewer manual keying errors)
• faster invoice cycles and fewer disputes (better data quality)
• realistic step-by-step digitalization (no big bang)
• improved scalability when combined with monitoring and validation

ZUGFeRD is a strong choice if you:

• invoice German B2B customers
• have partners at different digital maturity levels
• want automation but must keep the PDF as the “front end”
• run SAP and need a governed, scalable invoicing process
• want a practical bridge while you standardize on structured e-invoicing

For companies doing business in Germany, ZUGFeRD is a highly practical hybrid: it keeps the familiar PDF experience while enabling structured, automated processing. It’s ideal when you need compatibility across German trading partners but still want to move toward real e-invoicing automation.

If you want ZUGFeRD to scale in SAP, don’t start with the XML. Start with the operating model: recipient requirements in Germany, profile strategy, validation governance, delivery channels, and archiving.

• SAP e-invoicing (ZUGFeRD/XRechnung/PEPPOL):
  E-invoicing with SAP | PEPPOL | X-Rechnung | ZUGFeRD - Fink IT-Solutions
• Contact:
  Meeting mit Niklas Reisinger