PDF
XML
History Status
Validation
Entering XML content…
Format
XRechnung: the German usage specification of EN 16931
XRechnung is not a separate invoice format. It is a Core Invoice Usage Specification, a CIUS, of the European standard EN 16931: the same semantic data model, narrowed by German rules on which fields are mandatory and how they are filled. It is maintained by KoSIT, the coordination office for IT standards at the Senator of Finance in Bremen, and published on xeinkauf.de.
Version 3.0 has been in force since 1 February 2024, with the specification document 3.0.2 of 20 June 2024. Because there was no normative release in summer 2026, that version stays in force until at least 31 July 2027. A pre-version of XRechnung 4.0 was published on 15 September 2026 and is expressly not for production use.
3.0.2
The specification in force, valid until at least 31 July 2027
2 syntaxes
UBL 2.1 and UN/CEFACT CII, both of which a recipient has to accept
8 years
Retention period for invoices under section 14b of the German VAT Act
Versions and bundles
XRechnung works differently from most formats: only the version in force may be used for submission, and each version has a validity period. KoSIT publishes the specification together with a bundle of technical components, the schema and validation artefacts that implementers build against. Bugfix releases update the bundle without changing the version in force.
In force since 1 February 2024
XRechnung 3.0
The current version. The specification document is 3.0.2 of 20 June 2024. Version 2.3.1 was withdrawn on the same date and should no longer be used for submission.
31 August 2026 and 13 October 2026
Latest bundle and visualisation bugfixes
The summer 2026 bundle and a later fix to the visualisation component. Neither changes the version in force, but implementations should track them.
Summer 2026
No normative release
Because no new version was issued, XRechnung 3.0 remains in force until at least 31 July 2027. That is the planning horizon to work with.
15 September 2026
Pre-version of XRechnung 4.0
Published for orientation, not for production. The final version and the bundle are expected in spring 2027, which is covered in the next section.
Older versions remain downloadable so that archived documents can be reconstructed, but KoSIT explicitly advises against using them for new submissions. A recipient that validates against the current bundle will reject an invoice built on a withdrawn version.
XRechnung 4.0
XRechnung 4.0 is the German implementation of the revised European standard, EN 16931-1:2026. The semantic data model grows by more than fifty business terms, so this is a larger step than the usual yearly release.
Buyer referenceBT-10 may be given more than once, with an optional scheme identifier that names the coding scheme behind it.
XML attachmentsAttachments in XML form become permissible inside the core invoice.
Early payment discountThe previous free-text Skonto arrangement is replaced by a structured group, BG-35 Early Payment Discount.
Third-party chargesA new group, BG-34 Charges on Behalf of a Third Party, covers amounts collected for someone else.
Delivery detailMore detailed delivery information, and references to several orders and deliveries within one invoice.
The timetable depends on work outside Germany. The syntax binding documents have been published, the CEN validation artefacts are still outstanding, and the technical components cannot be finalised before they arrive. On the current state, KoSIT expects the bundle in spring 2027.
The practical conclusion is not to wait. A process built now is built on 3.0.2 and will live through a version change afterwards. What matters is that the change is a configuration rather than a project.
Syntaxes and structure
EN 16931 defines the semantics, the meaning of each field, and leaves two syntaxes for expressing them. XRechnung permits both, and a recipient has to be able to process both.
UBL 2.1
Universal Business Language, an OASIS specification. The root element is Invoice for an invoice and CreditNote for a credit note, which is the quickest way to tell what a file is.
UN/CEFACT CII
Cross Industry Invoice. The root element is rsm:CrossIndustryInvoice. This is also the syntax inside a ZUGFeRD document, which is why the two formats meet.
UBL 2.1rechnung-ubl.xml
Invoice xmlns="...ubl:schema:xsd:Invoice-2"
urn:cen.eu:en16931:2017#compliant#
urn:xoev-de:kosit:standard:xrechnung_3.0
372026-R150
2026-11-12
991-33333TEST-33
Muster GmbH
UN/CEFACT CIIrechnung-cii.xml
rsm:CrossIndustryInvoice xmlns:rsm="..."
urn:cen.eu:en16931:2017#compliant#
urn:xoev-de:kosit:standard:xrechnung_3.0
372026-R150
udt:DateTimeString format="102"20261112
Muster GmbH
BT-1 in UBL
invoice number
BT-1 in CII
same field, different name
Both files above are the same invoice and both are valid XRechnung. Open a file in a text editor and read the first element: it tells you the syntax before any tool does.
SemanticsIdentical. Every business term of EN 16931 exists in both syntaxes, so no data is lost when one is converted into the other.
Element namesDifferent.
cbc and cac in UBL, ram and udt in CII, which is why a parser written for one does not read the other.Where you meet CIIIt is also the syntax inside a ZUGFeRD document, so the same structure travels in both formats.
An XRechnung is a single XML file. There is no visual document attached to it, which is the main practical difference from ZUGFeRD. A human-readable rendering is produced by a viewer, and KoSIT ships a visualisation component for exactly that purpose.
What the standard requires
Beyond the European core, XRechnung narrows several fields. These are the ones that decide whether an invoice is accepted.
Leitweg-IDThe routing identifier of the receiving public body, carried in BT-10. It comes from the authority, is validated before dispatch, and without it a B2G invoice cannot be routed.
Contact dataA contact point for the seller with name, telephone and e-mail, so the recipient can query an invoice without looking up a switchboard.
Payment termsStructured where the standard provides a field. Free text is accepted only where no structured element exists, which changes with version 4.0.
Identifiers with schemeAn endpoint or party identifier needs its scheme identifier, a GLN for instance with 0088.
Totals that reconcileThe sum of the line amounts plus VAT equals the invoice total. A rounding difference of one cent fails the check.
Dates in ISO 8601YYYY-MM-DD in the structured data, whatever a rendering of it shows.
All 164 business terms of EN 16931 and how XRechnung, Peppol BIS Billing and ZUGFeRD treat each one are set out in our comparison table.
Public sector
XRechnung exists because of Directive 2014/55/EU, which obliges public bodies in the EU to receive and process invoices conforming to EN 16931. Germany implemented that through the E-Rechnungsverordnung and chose XRechnung as the national specification, following a decision of the IT Planning Council of 22 June 2017.
In practice this means: towards federal authorities and most state authorities the invoice is an XRechnung, it carries a Leitweg-ID, and it is submitted through a portal, through the portal of the federal state, or over the Peppol network. At federal level that portal is the OZG-RE; in the federal states the arrangements differ.
The details per level of government are on our pages for B2G invoicing in Germany and the federal states.
Between businesses
Since 1 January 2025 every business established in Germany has to be able to receive structured e-invoices for domestic business-to-business supplies. Issuing follows on 1 January 2027 above EUR 800,000 of prior-year turnover and on 1 January 2028 for everyone else.
The law names the European standard, not a product, so XRechnung is one permitted way to comply and ZUGFeRD from version 2.0.1 is another. Which one arrives is decided by the recipient: public bodies require XRechnung, companies state their format in a supplier guide, and some keep EDI alongside the new formats.
The dates, the threshold and the exemptions are set out on e-invoicing in Germany, and what individual large buyers expect on top of the standard is collected under e-invoicing to large companies.
Validation
An XRechnung passes three checks, and they fail for different reasons. The XSD schema asks whether the XML is well formed and structurally correct. The business rules of EN 16931 ask whether the content is consistent. The rules of the XRechnung specification itself add the national requirements on top.
There is no statutory duty to validate. The Federal Ministry of Finance nevertheless recommends it, and its letter of 15 October 2025 states at marginal number 35a that a trader exercising the care of a prudent businessman may rely on the technical result of a validation by a suitable application, and that keeping the validation report is advisable.
Our free e-invoice validator runs all three checks against XRechnung 3.0.2 and earlier versions, and against Peppol BIS Billing and ZUGFeRD, and names the rule behind each finding.
Retention
Invoices are kept for eight years under section 14b (1) sentence 1 of the German VAT Act. For an electronic invoice the structured file is the original: it has to be retained in the form in which it was received and has to remain machine-evaluable, in line with the GoBD. A printout does not satisfy that, and neither does a PDF rendering produced from the XML.
Where the invoice travels by e-mail, the e-mail itself is the envelope. It does not have to be kept unless it carries information belonging to the invoice that is itself subject to retention.
How we help
Invoice-Portal creates, converts, validates and delivers XRechnung in both syntaxes, and moves an invoice between XRechnung, ZUGFeRD and Peppol BIS without re-entering the data.
- Output in UBL 2.1 or UN/CEFACT CII, from data created in the portal or imported from your system
- Validation against the version in force before dispatch, with the report kept alongside the document
- Delivery over the Peppol network as a certified access point, by e-mail or into a public-sector portal
- A version change handled centrally, so a move to XRechnung 4.0 does not become a project on your side
Frequent questions
Which XRechnung version do I have to use?
The one in force, currently 3.0 with the specification document 3.0.2. Unlike ZUGFeRD, older XRechnung versions are withdrawn rather than left running in parallel, and a recipient validating against the current bundle will reject them.
Is XRechnung the same as EN 16931?
No. EN 16931 is the European standard. XRechnung is a national usage specification of it: it uses the same data model, makes certain optional fields mandatory and adds German validation rules. An invoice can conform to EN 16931 and still fail an XRechnung check.
UBL or CII, which one should I send?
Either. A recipient of an XRechnung has to be able to process both syntaxes. In practice the choice follows what your own system produces most reliably, and CII is the natural pick when the same data also has to go into a ZUGFeRD document.
Can an XRechnung be sent by e-mail?
The standard regulates the format, not the transport. Between businesses e-mail is permissible where the recipient agrees. Towards public authorities the submission route is prescribed by the receiving body, and that is usually a portal or the Peppol network rather than a mailbox.
What does the Leitweg-ID do?
It identifies the receiving public body and routes the invoice inside the administration. It is issued by the authority, not by the supplier, and it is carried in BT-10. Our Leitweg-ID database helps to look one up.
What happens when XRechnung 4.0 arrives?
The current expectation is a bundle in spring 2027, after the outstanding CEN validation artefacts have been published. A staged transition is intended rather than a hard cut-over, and the pre-version is there so that implementers can prepare. Until the final version is published, 3.0 is the version to work with.
Does an XRechnung need a PDF alongside it?
No, and sending one is a common source of confusion. The XML is the invoice. If a readable document is wanted alongside the data in one file, the format for that is ZUGFeRD, not an XRechnung with a PDF attached to the e-mail.
Resources
KoSIT: versions and bundles of XRechnungEvery version with its validity period, the current bundle and the archived releases KoSIT: XRechnung 4.0
The pre-version of 15 September 2026, what changes and the expected timetable FeRD: ZUGFeRD and Factur-X
The hybrid format that carries the same CII data inside a PDF/A-3 document Leitweg-ID database
Look up the routing identifier of a German public body
Check an XRechnung before it goes out
Upload the XML and see in seconds whether it holds up against the rules the recipient applies.
- Every version still in circulation, from 3.0.2 back to 1.2.2
- Both syntaxes, UBL and CII, recognised automatically
- A plain report: the rule, the element and where it sits
Open the validator
Free and unlimited · the file stays in your browser session
What happens next
- 01You send the form, we reply within one business day.
- 02A short call, a test account and a first invoice checked on your own data.
Prefer to talk directly? info@invoice-portal.de · +49 561 56014568
Send your request
Your contact details
Let us start with the basics.
Your situation
Three questions, so the first answer is a useful one.
Almost done
Add a message and send it.
