XRechnung is Germany’s standard for purely structured e-invoices: an XML file under EN 16931, with no embedded PDF view. Public-sector clients require it: anyone invoicing federal, state or municipal bodies has to deliver XRechnung. In B2B it also satisfies the German e-invoicing mandate, alongside the hybrid format ZUGFeRD.
I set up the full path from generation in the ERP through validation to delivery, both for the issuing mandate from 2027 and for receiving and processing inbound XRechnung files.
Structure instead of visual checks
An XRechnung carries all invoice data in machine-readable form; humans need a viewer to read it. That sounds like a drawback but is actually a strength: there is no dual PDF-plus-XML structure that can drift apart, just one source of data. Recipients can validate, assign accounts and post automatically, provided the data is correct.
Validation is half the standard
There is no binding validation mechanism on the sender’s side, and that is where practice often fails: wrong tax categories, invalid country codes, missing bank details that only surface during the recipient’s import. My field report after one year of the receiving mandate documents the fallout. Validation against the schema therefore belongs before every dispatch, for instance with the freely available KoSIT validator. On the receiving side the same principle applies in reverse: validate first, then post.
Peppol access point: built as a prototype
For transmission via the Peppol network I have implemented an XRechnung access point as a prototype: fully automated dispatch within the Peppol network. I call it that deliberately: not a finished product, but proof that I know the delivery path from hands-on implementation, not just from diagrams. For projects this means I can judge format questions, validation errors and transmission routes concretely before expensive infrastructure decisions are made.
Where XRechnung sits in the full path from document to posting batch is shown on the E-Invoicing & DATEV overview.