XRechnung guide: what is XRechnung and when is it required?

XRechnung is the commonly used German standard for electronic invoices in public procurement (B2G). In practice, an XRechnung is typically an XML-based invoice that follows EN 16931.

If you invoice German public-sector entities, XRechnung is often not optional—many recipients require it so invoices can be accepted and processed automatically.

This guide explains the format in practical terms (what matters, where things go wrong, and how to ship your first B2G invoice without rejections).

Note: This page is general information, not legal or tax advice. Requirements can vary depending on the submission portal, region, and the recipient’s internal processes.

1) XRechnung in one sentence

XRechnung is a standardized, machine-readable invoice format (usually XML) used for e‑invoicing to public-sector recipients in Germany.

2) Key takeaways

XRechnung is XML-first: portals validate the structured data strictly.
Most rejections are caused by routing IDs and references (Leitweg-ID, order/case references), not by “advanced XML”.
Validate before submission and archive the submission proof (ticket ID/confirmation) together with the invoice.

3) When do you need XRechnung?

Typical situations where XRechnung matters:

You invoice public-sector recipients (authorities, municipalities, public institutions).
Your recipient explicitly requests “XRechnung” or “EN 16931”.
You must submit invoices via an e-invoicing portal.

For private-sector customers (B2B), ZUGFeRD can be sufficient depending on the recipient’s workflow—what matters is the recipient’s requirement.

4) XRechnung vs. ZUGFeRD (practical view)

Both are e‑invoice formats, but the workflow differs:

XRechnung: usually XML-first. The focus is strict validation and automated processing.
ZUGFeRD: often PDF-first (PDF with embedded structured data), which can be convenient in many B2B processes.

If you invoice the public sector, XRechnung is often the safer default because many portals and recipients explicitly expect it.

More context: /en/zugferd

5) What XRechnung “is” technically (without going too deep)

In practice, XRechnung is:

an XML invoice that follows the semantic model defined by EN 16931
constrained by additional validation rules (schema + business rules)
usually submitted as a file upload to a portal (or via a defined transmission channel)

What matters for you operationally:

XRechnung is designed for automatic processing.
Small inconsistencies (rounding, missing fields, wrong tax category) can lead to a hard rejection.

6) Typical requirements (what usually matters)

Without diving into specifications, these points commonly decide whether an invoice is accepted:

Mandatory fields must be complete and consistent

seller/buyer details (including addresses)
clear service description
amounts, taxes, totals (including rounding)
invoice date and (where required) supply date/period

Routing identifiers (e.g., Leitweg-ID)

Public-sector recipients often require additional identifiers (such as Leitweg-ID) so the invoice can be routed and assigned correctly.

Validation rules (schema + business rules)

XRechnung files are typically checked automatically:

the XML must be technically valid
totals and codes must satisfy business rules

7) Routing IDs and references: the most common rejection reason

In day-to-day public-sector invoicing, rejection is often caused less by “complex XML rules” and more by missing or incorrect references:

Leitweg-ID (or a comparable routing identifier): provided by the recipient.
Purchase order / case references: if the recipient expects an order number or internal reference.

Practical tips:

Copy identifiers exactly as provided (no extra spaces, no creative formatting).
Clarify early where the routing ID comes from (offer, order, portal, contact person).
If you use customer templates: make routing IDs a required field for public-sector recipients.

A quick “recipient requirements” capture template

Before you invoice a public-sector customer for the first time, collect:

submission channel/portal name
required routing ID (Leitweg-ID) and where to get it
required references (order number, case ID, contract reference)
which attachments are required (if any)
who to contact for invoice rejections

8) Submission via portals: what to prepare

Many public-sector recipients only accept XRechnung through a portal or a specific submission channel. Typically, you’ll need:

the correct file format (XRechnung XML or the portal’s upload container)
required metadata (e.g., routing ID, contact email)
sometimes attachments (e.g., proof of service) — depending on the recipient

Practical tip: archive not only the invoice but also the submission evidence (upload confirmation, ticket ID, protocol). It helps a lot when questions arise later.

9) Attachments: what to do (and what not to do)

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

Practical rules:

Keep attachments stable and clearly named.
Archive attachments together with the invoice and the submission proof.
If a portal restricts attachment types/sizes, standardize your internal “B2G invoice package”.

10) Validation and testing: a pragmatic approach

A strong workflow is to validate before submission, not after rejection.

Practical steps:

Technical validation: is the XML well-formed and valid?
Business rules: do totals, tax coding, and mandatory fields match the rules?
Recipient specifics: some portals are stricter or expect certain fields.

When a validator reports errors:

start with the first errors (missing mandatory fields are common)
then verify totals/tax/rounding
fix early errors first — many “follow-up errors” disappear automatically

11) A simple workflow for B2G invoicing

Clarify recipient requirements
- profile/version expected
- portal/submission channel
- required routing identifiers (e.g., Leitweg-ID)
Keep master data clean
- addresses and tax identifiers
- payment terms
Create the invoice
- correct line items + taxes
- clear descriptions
Generate and validate the XRechnung
- validate with a validator tool
Submit and archive
- keep submission evidence
- store invoices in an auditable way with backups

GoBD context: /en/gobd

12) Corrections and cancellations (don’t “edit” old invoices)

In B2G invoicing, you should assume that recipients want a clear audit trail.

Practical approach:

keep the original invoice
correct via the proper correction documents (cancellation + corrected invoice, or the process your recipient expects)
archive original + correction + submission evidence

13) Common validation errors (and how to avoid them)

Error 1: Incomplete or inconsistent addresses

Use complete addresses and consistent spelling across your records.

Error 2: Totals don’t match (rounding)

Even small rounding differences can fail validation. Double-check net/tax/gross logic.

Error 3: Wrong or missing tax codes

Reverse-charge and tax-exempt cases need correct coding.

Error 4: Missing routing identifiers (e.g., Leitweg-ID)

If the recipient expects it, missing routing info often causes rejection.

Error 5: Missing order/case references

If the portal or recipient expects references, treat them like mandatory fields.

14) Quick checklist (first successful submission)

Recipient explicitly requires XRechnung / EN 16931
Routing identifiers available (e.g., Leitweg-ID)
Order/case references collected (if required)
Master data complete and correct
Taxes and totals consistent (including rounding)
XRechnung validated (technical + business rules)
Submission evidence and archiving in place

Optional (depending on recipient workflow):

Attachments/proof of service prepared and archived
Internal workflow defined (who checks, who submits, where it’s stored)

15) Next steps on this site

ZUGFeRD basics: /en/zugferd
GoBD guide: /en/gobd
Glossary: /en/glossary
FAQ: /en/faq
Resources hub: /en/resources