UBL to XRechnung Converter API
Invoice a German public-sector buyer with the UBL you already produce. One REST call rebrands your EN 16931 UBL invoice to the current XRechnung CIUS, enforces the German B2G constraints including the Leitweg-ID, and validates against the full KoSIT Schematron rule set.
Since 2020, federal German authorities only accept e-invoices that conform to XRechnung, and suppliers submitting via ZRE or OZG-RE face strict format validation at intake. If your billing stack already emits Peppol BIS or plain EN 16931 UBL, this endpoint is the last step before submission, with the CIUS version maintained for you on every KoSIT release date.
curl -X POST https://api.invoicexml.com/v1/convert/ubl/to/xrechnung \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]" \ -o invoice-xrechnung.xml
<?xml version="1.0" encoding="UTF-8"?> <Invoice> <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant #urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID> <cbc:BuyerReference>04011000-12345-34</cbc:BuyerReference> … </Invoice>
Convert a UBL invoice to XRechnung now
This demo calls the same POST /v1/convert/ubl/to/xrechnung endpoint your integration will use. Drop an EN 16931 UBL file and the XRechnung document downloads immediately, or you get the exact KoSIT findings that block it.
Drop a UBL 2.1 XML file to test the API
or browse files to upload
REST API demo · POST /v1/convert/ubl/to/xrechnung · XML · Max 20 MB
Your file is processed in memory and deleted immediately. Nothing is stored.
What turns a UBL invoice into an XRechnung
XRechnung is not a different format. It is the German CIUS on top of EN 16931, a set of tightened rules your document must declare and satisfy. The endpoint handles all three parts.
CIUS rebranding (BT-24)
The customization identifier is switched from the EN 16931 or Peppol URN to the currently valid XRechnung URN. This declaration is the first thing ZRE and OZG-RE check, and an outdated version URN is a common silent rejection cause.
German B2G constraints
XRechnung mandates fields the base norm leaves optional: the buyer reference (BT-10) carrying the Leitweg-ID, seller contact details, and payment information. Missing values surface as named findings before submission, not as a portal rejection after.
KoSIT Schematron validation
The output runs through the same KoSIT rule set the receiving platforms execute. Only a document that passes leaves the API, so a 200 response means the format gate at the portal is already cleared.
KoSIT releases a new XRechnung. You change nothing.
XRechnung versions retire on fixed dates, and a document declaring a retired URN is rejected at intake even if every value in it is correct. Teams that hard-code the CIUS URN or self-host the KoSIT validator have to track announcements, upgrade artefacts, and redeploy before each effective date. InvoiceXML switches the conversion target and the validation rules on the official effective date automatically: the same API call that produced XRechnung 3.0 documents yesterday produces the successor version the day it becomes mandatory.
One request, portal-ready output
Send the UBL file as multipart/form-data. The response body is the XRechnung XML, ready for ZRE, OZG-RE, or Peppol delivery to a German authority.
$ curl -X POST https://api.invoicexml.com/v1/convert/ubl/to/xrechnung \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]" \ -o invoice-xrechnung.xml
On success you receive the XRechnung document with Content-Type application/xml. On a validation failure you receive HTTP 400 with each KoSIT finding as a structured object: rule ID, message, and field path.
Skip the API. Use getzugferd.com
Our online companion tool. Create and validate XRechnung invoices in your browser, no integration, no API key, no code. Perfect for freelancers, small businesses, and one-off invoices.
Complete XRechnung Toolkit
Everything you need to create, convert, validate, and preview XRechnung invoices, via REST API or online.
Frequently Asked Questions
What does the conversion change in my UBL document?
Structurally very little, and that is the point. Your invoice is already EN 16931 UBL; XRechnung is a German CIUS on top of the same model. The API rebrands the customization identifier (BT-24) to the currently valid XRechnung URN, applies the German B2G constraints, and validates the result against the full XRechnung Schematron rule set. What you get back is the same invoice, now formally conformant to XRechnung.
What happens if my invoice is missing the Leitweg-ID?
The buyer reference (BT-10), which carries the Leitweg-ID for German public-sector buyers, is mandatory in XRechnung. If it is missing, the conversion fails with HTTP 400 and a finding that names BT-10 and the exact field path, so you can prompt the user for the routing ID instead of having the invoice bounce at ZRE or OZG-RE later.
Which XRechnung version does the output use?
Always the currently effective one. KoSIT publishes new XRechnung releases on fixed dates, and InvoiceXML switches the conversion target and the validation rules on the official effective date automatically. Your integration keeps calling the same endpoint and always produces a currently valid XRechnung.
Do German federal and state portals accept the output?
The output passes the same KoSIT Schematron rule set the intake platforms run, which is the formal gate at ZRE, OZG-RE, and the state-level portals. Uploads can still be rejected for non-format reasons (an unknown Leitweg-ID, a closed procurement reference), which no format converter can check.
Can I get XRechnung in CII syntax instead of UBL?
This endpoint keeps the UBL syntax, which every German receiving platform accepts. If you specifically need the CII flavour of XRechnung, convert your document to CII first with POST /v1/convert/ubl/to/cii and then promote it with /v1/convert/cii/to/xrechnung.
Ready to automate your invoices?
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.