German public buyers do not read invoices; their reception platforms do, checking conformity with the XRechnung specification and bouncing whatever misses a BR-DE rule or a Leitweg-ID. InvoiceXML validates with the same official artifacts, specification 3.0.2 and KoSIT Schematron 2.5.0, in both UBL and CII. The first time your invoice meets the portal is not the first time it has been checked. And when 4.0 arrives, the switch happens on our side on the official effective date, not in your code.
curl -X POST https://api.invoicexml.com/v1/create/xrechnung \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "invoice": { ... }, "options": { "syntax": "ubl" } }'
{
"valid": true,
"data": {
"profile": "xrechnung",
"customizationId": "urn:cen.eu:en16931:2017#compliant#
urn:xeinkauf.de:kosit:xrechnung_3.0"
}
}
XRechnung is a CIUS, not a syntax: it legally exists in both UBL and CII, and in the wild it also arrives wrapped in hybrid PDFs or stamped with retired identifiers. Every route lands in the right rule set without you declaring anything.
| Route | How it's created | How it's recognized | What we run |
|---|---|---|---|
| XRechnung in UBL | POST /v1/create/xrechnung | CustomizationID read from the document | EN 16931 + KoSIT Schematron, UBL binding |
| XRechnung in CII | /v1/create/xrechnung · syntax: cii | BT-24 names the KoSIT guideline | EN 16931 + KoSIT Schematron, CII binding |
| ZUGFeRD XRechnung reference profile | Arrives from suppliers as a hybrid PDF | The xrechnung.xml attachment is extracted automatically |
The same KoSIT rules, end to end |
| Retired XRechnung 2.x | Legacy systems still emit it | 2.x identifiers, invalid since February 2024 | Reported clearly as retired, never silently passed |
data.profile and data.customizationId, so which rulebook ran is part of the record. Identifiers we hold no dedicated rules for fall back to the EN 16931 core with a PROFILE-DETECTION warning, not an invented failure. The UBL syntax side has its own deep dive on the UBL hub, and the XRechnung CustomizationID itself, including the xoev-de to xeinkauf.de change, is unpacked on the identifier reference page.
Six endpoints with free in-browser companions, sharing one engine and one rulebook per route.
Invoice JSON in, a validated XRechnung 3.0 document out, totals and VAT computed.
Open toolBR-DE findings in plain language, before the platform sees the file.
Open toolTurn a plain UBL invoice into a portal-ready XRechnung.
Open toolBridge B2G to B2B: the same invoice as a hybrid PDF.
Open toolA readable preview of any XRechnung file, for sign-off and archives.
Open toolBT-mapped JSON from received XRechnung documents, straight into your ERP.
Open toolKoSIT has announced XRechnung 4.0, the German CIUS of the revised EN 16931, for late 2026; an effective date has not been set. Our handling is already written down: we build and verify the new rule artifacts during the authority's transition window, and the API switches on the effective date, announced ahead of time in the changelog. Doing nothing is the plan. 2.x went out through the same machinery: its identifiers stopped being valid in February 2024, and our validator says so instead of guessing.
Read the version lifecycle policyAnnounced for late 2026, effective date pending. When the window opens we prepare and verify the new rules; on the effective date the API switches. Nothing to change on your side.
The BR-DE family is where XRechnung gets German: seller contact details, payment instructions, the Leitweg-ID. Each finding names the rule, the layer, the business terms involved, and the JSON path to light up in your UI.
No decoding sessions with the Schematron source: the message already says what to add and where.
{
"valid": false,
"data": {
"profile": "xrechnung",
"customizationId": "urn:cen.eu:en16931:2017#compliant#
urn:xeinkauf.de:kosit:xrechnung_3.0"
},
"errors": [
{
"rule": "BR-DE-15",
"layer": "cius",
"message": "The buyer must have a reference
(Leitweg-ID). This is mandatory for
German public sector invoices.",
"btCodes": ["BT-10"],
"fields": ["buyerReference"]
}
]
}
XRechnung began as procurement plumbing and became the reference point of German e-invoicing. Under the B2B rules it qualifies as an e-invoice outright, so the same documents serve ministries and Mittelstand.
Directive 2014/55/EU set the European floor, and the federal portal documentation lives at e-rechnung-bund.de. For how Germany fits the wider rollout, see the Mandate Map.
Your invoices are processed in memory and returned in the same response. Zero data retention is not a policy we enforce, it is an architecture we built.
Processed in volatile memory only. Never written to disk, never queued, never backed up.
Servers in Frankfurt, Germany. No transfers outside the European Economic Area.
Never used for analytics, never to train AI models, never shared with third parties.
SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.
GDPR compliant by design · nothing stored on our servers
Specification 3.0, in force in Germany since February 2024, using artifacts 3.0.2 and KoSIT Schematron 2.5.0. Retired 2.x identifiers are reported as exactly that, retired, with a clear finding instead of a silent pass or a cryptic failure.
Whichever your counterpart prefers; both are first-class XRechnung. POST /v1/create/xrechnung emits the UBL binding by default; set options.syntax to cii for the CII binding. On validation you declare nothing: syntax and profile are detected from the file.
Into BT-10, the buyer reference (buyerReference in our JSON model). German public-sector buyers route invoices internally with it, and rule BR-DE-15 makes it mandatory; when it is missing, the finding points at the exact field to fix.
No. 4.0 is announced for late 2026 without an effective date yet. We build and verify the new rule set during the official transition window and switch on the authority's effective date; your requests keep working unchanged, and the flip is announced ahead of time.
Yes. Hybrid PDFs carrying an xrechnung.xml attachment are recognized, the embedded XML is extracted, and the KoSIT rules run against it like any other XRechnung.
Yes. Under the German B2B rules, in force for reception since January 2025, XRechnung qualifies as an e-invoice. If your counterparties expect a PDF they can open, the hybrid ZUGFeRD route pairs with it, and both come from the same API.
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.