XRechnung to ZUGFeRD Converter API
Turn a machine-only XRechnung XML into a ZUGFeRD 2.x hybrid your whole organisation can use. One REST call renders a readable invoice PDF from the structured data and embeds the CII payload inside a PDF/A-3 container with ZUGFeRD XMP metadata.
Since Germany's B2B e-invoicing obligation took effect, companies receive far more raw XRechnung XML than their AP workflows, approvers, and archives were built for. This endpoint gives every one of those XML invoices a human-readable face while keeping the machine-readable data byte-for-byte inside, in a single archivable PDF/A-3 file.
curl -X POST https://api.invoicexml.com/v1/convert/xrechnung/to/zugferd \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]" \ -o invoice-zugferd.pdf
// Binary PDF/A-3 response: ✓ Rendered visual invoice layer ✓ factur-x.xml attachment (CII, EN 16931) ✓ ZUGFeRD XMP metadata (zf: namespace) ✓ PDF/A-3 archival conformance
Convert an XRechnung to ZUGFeRD now
This demo calls the same POST /v1/convert/xrechnung/to/zugferd endpoint your integration will use. Drop an XRechnung XML file (UBL or CII syntax) and the finished ZUGFeRD PDF/A-3 downloads immediately.
Drop an XRechnung XML file to test the API
or browse files to upload
REST API demo · POST /v1/convert/xrechnung/to/zugferd · XML · Max 20 MB
Your file is processed in memory and deleted immediately. Nothing is stored.
From machine-only XML to a file everyone can open
The conversion produces a single PDF/A-3 that carries three synchronised layers, the exact structure German ZUGFeRD readers expect.
A rendered visual layer
Parties, line items, VAT breakdown, payment terms, and the Leitweg-ID buyer reference are laid out as a clean invoice document generated from the XML values themselves, so what the human reads is exactly what the machine processes.
The embedded CII payload
The invoice data is attached as factur-x.xml in CII syntax, rebranded to the EN 16931 baseline that ZUGFeRD consumers require. Every Business Term from the source XRechnung is preserved, including UBL-syntax sources, which are mapped to CII automatically.
An archivable PDF/A-3 container
The container conforms to PDF/A-3 with ZUGFeRD XMP metadata in the zf: namespace, declaring the profile of the embedded XML. It satisfies GoBD-style long-term archiving expectations in one self-contained file.
Built for the receiving side of the German mandate
AP inbox normalisation
Suppliers send XRechnung XML; your approval workflow, DMS, and auditors want PDFs. Convert each incoming XML once at intake and route the hybrid: humans open the PDF layer, your ERP keeps reading the embedded XML.
One-file archiving
Archiving a bare XML plus a separately rendered preview means two artefacts that can drift apart. The hybrid PDF/A-3 keeps the legal data and its visualisation in one immutable, self-describing file.
Forwarding to B2B partners
Not every trading partner ingests raw XRechnung. Re-issuing the invoice as ZUGFeRD lets you serve partners who expect the hybrid format, without maintaining a second invoice generation path.
One request, one hybrid PDF
Send the XRechnung file as multipart/form-data. The response body is the binary ZUGFeRD PDF/A-3, ready to store or forward.
$ curl -X POST https://api.invoicexml.com/v1/convert/xrechnung/to/zugferd \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]" \ -o invoice-zugferd.pdf
On success you receive the PDF with Content-Type application/pdf. On a validation failure you receive HTTP 400 with structured KoSIT findings. Need Factur-X branding instead? Use /v1/convert/xrechnung/to/facturx.
Skip the API. Use getzugferd.com
Our online companion tool. Create and validate ZUGFeRD invoices in your browser, no integration, no API key, no code. Perfect for freelancers, small businesses, and one-off invoices.
Complete ZUGFeRD Toolkit
Everything you need to create, convert, validate, and extract ZUGFeRD invoices, via REST API or online.
Frequently Asked Questions
Why convert XRechnung to ZUGFeRD at all?
XRechnung is pure XML: perfect for portals and ERP intake, useless for a human. Accounts-payable teams, approvers, auditors, and archives all want something a person can open. ZUGFeRD wraps the same EN 16931 data in a PDF/A-3 with a readable invoice layout on top, so one file serves both the machine workflow and the human one.
Does the endpoint accept both XRechnung syntaxes?
Yes. XRechnung allows the invoice to be encoded as UBL or CII. The endpoint detects the root element automatically and handles either, so you do not need to know which syntax your suppliers or systems emit.
Where does the visual PDF layer come from?
It is rendered fresh from the structured XML data: parties, line items, VAT breakdown, payment terms, all laid out in a clean professional invoice design. You do not supply a PDF. If you already have your own rendered PDF and only want the XML attached to it, use POST /v1/embed/zugferd instead.
Why is the embedded XML rebranded from XRechnung to EN 16931?
ZUGFeRD readers expect the embedded conformance URN to belong to the ZUGFeRD / EN 16931 family, not a national CIUS. The API rebrands the customization identifier to the EN 16931 baseline while keeping every Business Term, including the Leitweg-ID in the buyer reference. No data is lost; the document simply declares the profile ZUGFeRD consumers understand.
Is the result also a valid Factur-X file?
Technically the container and attachment are identical; only the XMP branding differs. This endpoint writes ZUGFeRD metadata (zf: namespace). If your recipient checks for Factur-X branding specifically, use POST /v1/convert/xrechnung/to/facturx, which writes the fx: namespace instead.
Is the input validated before conversion?
Yes. The XRechnung document is validated against the KoSIT Schematron rules first. An invalid input returns HTTP 400 with structured findings (rule ID, message, field path) instead of producing a hybrid PDF from broken data.
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.