XRechnung

If your company does business in Germany and invoices German public-sector customers (federal, state, municipal authorities and related public institutions), XRechnung is the format you must treat as your default. XRechnung provides the technical foundation for fully digital, end-to-end invoice processing—and it’s designed for automated validation, routing, and posting.

For companies running ERP landscapes such as SAP ECC or SAP S/4HANA, XRechnung is no longer a “nice add-on.” It’s an operational and compliance requirement: invoice data must be structured, valid, and audit-ready from document creation all the way to archiving.

This know-how article explains—clearly and practically—what XRechnung is, how it works, when it is required in Germany, and how to implement it efficiently (including an SAP perspective). You’ll also get a crisp comparison to ZUGFeRD, and why XML-first standards like XRechnung are the long-term direction for Germany’s public-sector invoicing.

Contact us now!

XRechnung is a standardized, XML-based invoice format used in Germany for invoicing public-sector contracting authorities. Unlike a PDF, XRechnung is purely structured and machine-readable, enabling automated processing without manual re-keying or “PDF interpretation.”

Simple way to remember it:
PDF is a view. XRechnung is data.

Germany introduced XRechnung to standardize and accelerate invoice processes where volumes, audit requirements, and compliance expectations are high: the public sector.

Typical objectives include:

• end-to-end digitization of invoice processing
• elimination of media breaks (no PDF as the primary process artifact)
• faster checks and payments
• improved transparency and traceability through defined data fields and rules

In practice, XRechnung becomes mandatory when your recipient requires it—and for German public-sector entities, that’s the common reality.

Key point: The recipient’s requirements matter more than your company size.
If you issue invoices B2G in Germany (business-to-government), treat XRechnung as a standard finance / order-to-cash process, not as a special case.

The general rule is simple: anyone invoicing German public-sector customers must be able to provide the required e-invoice format—typically XRechnung.

This includes:

• companies of all sizes
• service providers
• suppliers
• freelancers / independent professionals

If you invoice multiple public-sector customers, XRechnung quickly becomes a scaling topic: without automation, manual rework grows fast.

• E-invoice is the umbrella term: an invoice issued in a structured electronic format
• XRechnung is a specific Germany-focused standard within that world, designed for Germany’s public-sector requirements

So: Every XRechnung is an e-invoice, but not every e-invoice is automatically an XRechnung.

XRechnung is XML-based and follows strict rules:

• defined data structures
• mandatory fields (depending on the scenario/recipient requirements)
• validation rules (so invoices can be processed automatically)

In real projects, three things decide success:

1. Data quality (master data + invoice document data)
2. Mapping & rules (fields, codes, taxes, payment terms, references)
3. Versioning & operations (rules and specifications evolve—your process must handle that)

Visually: it doesn’t—because XML is not meant for humans.

In practice, XRechnung is made readable via:

• portal viewers
• e-invoicing platforms
• ERP representations (including SAP-based views)

The core idea: systems process first; humans review only when needed.

There are three typical implementation paths—depending on volume, complexity, and system landscape:

Many implementations don’t fail because of XML—they fail because the operating model isn’t ready.

A simple decision matrix helps:

Rule of thumb:
If the recipient is a German authority, XRechnung is usually the safe standard. ZUGFeRD can be excellent in German B2B—but it’s not a universal “one format for everything” strategy.

ZUGFeRD is a strong entry point because it matches how people work: PDF-first habits. But that’s also why it often becomes transitional:

• PDF keeps manual patterns alive (forwarding, side processes, “human-first” review loops)
• Two truths instead of one (PDF view vs XML data must remain consistent)
• Networks and platforms reward structure, not visual artifacts
• Strategic direction is XML-first (data-first, view-on-demand)—exactly what XRechnung enables

In short: ZUGFeRD can be the bridge. XRechnung is the target state when you need scalable automation, governance, and audit readiness—especially for Germany’s public sector.

In SAP environments, success depends on four levers:

Even if obligation is the trigger, the benefits are measurable:

• faster processing through automation
• fewer errors thanks to pre-send validation
• fewer rejections and follow-ups via clear mandatory fields
• stronger compliance and audit readiness
• better scalability (more recipients, higher volume, less manual effort)

Typical transport options in Germany:

• public-sector portals
• e-invoicing networks
• PEPPOL connectivity
• platforms providing mapping, routing, monitoring, and feedback

If you serve many recipients (or operate internationally), a platform approach often pays off—not because of “technology,” but because of operations, transparency, and scalability.

XRechnung is firmly established in Germany’s public sector—and it pushes organizations to modernize invoicing as a true end-to-end process. If you treat it as a “format project,” you’ll pay later in manual rework. If you design it as an operational process (data quality, validation, delivery, monitoring, archiving), you gain faster cycles, fewer errors, and greater transparency.