Create an XRechnung or ZUGFeRD E-Invoice

Creating an electronic invoice in the EN 16931 sense means producing machine-readable structured data — not a picture of an invoice. XRechnung is Germany's public-sector profile: a pure XML file with no visual layer. ZUGFeRD (and its French twin Factur-X) is a hybrid: a normal-looking PDF/A-3 with the same structured XML embedded inside. This guide explains which format is mandated where, how validation works, and the practical ways to create a compliant file. Note that this site's own invoice generator produces a visual PDF only — it is not a compliant e-invoice.

Published · Last updated

Why there is no one-click converter on this page

A compliant e-invoice is generated from validated business data — tax IDs, VAT category codes, a routing ID — mapped into an exact XML vocabulary and, for ZUGFeRD, embedded into a PDF/A-3 container. Getting any of those semantics wrong produces a file that validators reject, so a trustworthy result comes from the accounting tools and validators described below, not from a generic in-browser converter.

Disclosure: this page contains affiliate placeholder links. If they were live, we could earn a commission at no extra cost to you.

AFFILIATE PLACEHOLDER: Recommended desktop PDF suite (placeholder link)

One framing note before the checklist: everything here is an informational overview of formats and tooling, not legal or tax advice. Which mandate applies to you, which VAT treatment your lines need, and when your transition deadlines fall are questions for your accountant or tax advisor.

How to create a compliant e-invoice (step by step)

Method 1: Accounting or invoicing software with native support

  1. Confirm the required format. Ask the recipient which format they accept: German public-sector buyers require XRechnung (pure XML, UBL or UN/CEFACT CII syntax), while most business partners accept ZUGFeRD or Factur-X (a PDF/A-3 with embedded XML), profile EN 16931 or higher.
  2. Enter the mandatory structured fields. In software with native e-invoicing support, fill in every EN 16931 mandatory field: seller and buyer identification, invoice number and date, line items with quantities and net prices, VAT breakdown per rate, payment terms, and — for German B2G — the buyer's Leitweg-ID as the buyer reference.
  3. Export in the required profile. Use the software's export function and select XRechnung (producing an .xml file) or ZUGFeRD/Factur-X at profile EN 16931 (producing a .pdf that contains the XML as an embedded attachment).
  4. Validate before sending. Run the file through the KoSIT validator with the current XRechnung scenario to check schema and business rules; for ZUGFeRD, additionally verify the PDF/A-3 container with veraPDF.
  5. Submit through the required channel. Deliver the invoice the way the recipient specifies: German federal portals (ZRE or OZG-RE) accept upload or email of XRechnung XML, while ZUGFeRD invoices are usually sent as ordinary email attachments.

Method 2: Official portal entry forms (low volume, zero cost)

  1. Register on the portal your public-sector customer names — for German federal authorities that is the ZRE (direct federal administration) or OZG-RE (indirect and many state bodies).
  2. Choose the portal's manual entry option and type the invoice into its web form; the portal generates the XRechnung XML for you, so field-level syntax errors are impossible.
  3. Enter the Leitweg-ID from your order paperwork where the form asks for the buyer reference — submission fails without it.
  4. Submit and download the receipt; the portal validates on upload, so a rejected invoice comes back immediately with the failed rule listed.

Method 3: Libraries and command-line tools (developers, batch volume)

  1. Use the open-source Mustangproject (Java) to generate CII XML from invoice data, or to embed an existing XML file into a PDF: java -jar Mustang-CLI.jar --action combine takes a visual PDF plus the XML and writes a ZUGFeRD PDF/A-3.
  2. Convert your visual layer to PDF/A-3 first if the tool requires it — see our PDF to PDF/A guide for how that conversion works.
  3. Validate in the same pipeline: Mustang-CLI has a --action validate mode, and the KoSIT validator runs headless as a Java JAR, so both fit into CI or an invoicing batch job.

How it works

EN 16931 is the European norm that defines the semantic model of an invoice: around 160 numbered business terms (BT-1 invoice number, BT-10 buyer reference, BT-112 grand total, and so on), rules about which are mandatory, and two permitted XML syntaxes to express them — OASIS UBL 2.1 and UN/CEFACT Cross-Industry Invoice (CII). A national profile called a CIUS (Core Invoice Usage Specification) can tighten the norm but not contradict it. XRechnung is exactly that: Germany's CIUS, which for example makes the Leitweg-ID in BT-10 and an email or payment reference practically required for public-sector routing. Because the data is structured, the receiving system books the invoice without OCR or human retyping — that machine-readability, not the file's appearance, is the whole point.

ZUGFeRD (from version 2.1 identical in content to Factur-X) solves a different problem: keeping a human-readable document while carrying the same structured data. The container is PDF/A-3, the archival PDF flavor that explicitly permits embedded file attachments; the invoice XML (canonically named factur-x.xml) is attached with relationship AF (associated file) and described in the XMP metadata so software knows which profile — MINIMUM, BASIC, EN 16931, or EXTENDED — the data claims to meet. Only the EN 16931 profile and above carry the full mandatory dataset; the MINIMUM profile is not a valid e-invoice for the German B2B rules. Legally, in a hybrid file the XML is the invoice and the visible pages are merely a courtesy rendering: if the two disagree, the structured data governs.

The mandates are what turn this from optional plumbing into a deadline. Germany has required XRechnung for invoices to federal public-sector buyers since November 2020, and the Growth Opportunities Act extended structured e-invoicing to domestic B2B: from January 2025 every business must be able to receive EN 16931 e-invoices, and the permission to keep sending paper or plain-PDF invoices phases out between 2027 and 2028 depending on the seller's turnover. France is on a parallel path, phasing in mandatory e-invoicing via certified platforms, with large companies first and all businesses obliged to receive from the first wave. Validation is mechanical at every stage: the KoSIT validator applies the XSD schema plus hundreds of Schematron business rules (totals must sum, VAT categories must be consistent, the Leitweg-ID must be plausible) and emits an accept/reject report, while veraPDF independently checks that a hybrid file's container genuinely conforms to PDF/A-3. A file that fails either check will bounce from a portal, so validating locally before sending is the single highest-value habit in this workflow.

Worked example: one invoice, visual PDF vs. ZUGFeRD

A Berlin IT consultant bills a corporate client 3,570.00 EUR gross (3,000.00 net + 19% VAT, invoice 2026-041). The visual-only PDF from a generator like ours weighs about 18 KB and is perfectly readable — but a validator sees no XML attachment and rejects it as an e-invoice outright. The consultant instead exports from her accounting package as ZUGFeRD 2.3, profile EN 16931: the output is a 96 KB PDF/A-3 whose embedded factur-x.xml is about 9 KB of CII, carrying her VAT ID in BT-31, the 19% category S breakdown (BT-118/BT-119), and payment terms of 14 days in BT-20.

She drags the file onto her local KoSIT validator instance: the first run fails rule BR-CO-25 because she left both the due date and the payment terms empty; filling the terms field and re-exporting produces a clean report — 0 errors, 0 warnings. veraPDF confirms PDF/A-3b conformance. Total overhead versus the plain PDF: one extra export dropdown and about two minutes of validation, in exchange for a file her client's ERP books automatically.

Frequently asked questions

What is the difference between XRechnung and ZUGFeRD?

XRechnung is a pure XML file with no visual part, defined as Germany's national profile of EN 16931 and required by German public-sector buyers. ZUGFeRD (internationally aligned with France's Factur-X) is a hybrid: a normal-looking PDF/A-3 invoice with the same kind of structured XML embedded inside it, so both humans and software can read one file.

Is a normal PDF invoice a valid e-invoice in Germany?

No. Since the German B2B rules that began phasing in during 2025, an e-invoice is defined as one issued in a structured electronic format conforming to EN 16931, which a visual-only PDF is not. A plain PDF counts as an 'other invoice' and loses its status as the default format during the 2025–2028 transition.

What is a Leitweg-ID and where do I put it?

The Leitweg-ID is a routing identifier that German public authorities assign so invoices reach the right internal office; the buyer gives it to you with the order. In an XRechnung it goes into the buyer reference field (business term BT-10), and validation against a federal portal will fail without a plausible value.

How do I check that my e-invoice is actually compliant?

Validate the XML with the KoSIT validator loaded with the current XRechnung scenario, which checks both the syntax schema and the EN 16931 business rules and produces a pass/fail report. For ZUGFeRD or Factur-X, also run the PDF through veraPDF to confirm the container really conforms to PDF/A-3.

Can I create a ZUGFeRD invoice for free?

Yes. Several accounting packages include ZUGFeRD export in their base tier, public-sector portals offer free XRechnung entry forms, and the open-source Mustangproject library can generate or embed the XML from the command line. Free routes cost more time per invoice, which matters once volume grows.

Does this site's invoice generator produce an XRechnung or ZUGFeRD file?

No. The create-invoice tool on this site produces an ordinary visual PDF with no embedded XML, so it is not an EN 16931 e-invoice and will not pass an XRechnung or ZUGFeRD validator. Use it for recipients who accept normal PDF invoices, and one of the methods on this page when a mandate applies.

Related tools