← All posts

XRechnung vs ZUGFeRD: The Difference, Shown With Real Files and Validator Results

· Barış Çelik · Diesen Beitrag auf Deutsch lesen

  • einvoicing
  • xrechnung
  • zugferd
  • germany
  • opensource

XRechnung and ZUGFeRD are the two formats most German businesses will use for e-invoices. Both follow the European standard EN 16931, so either one counts as an e-invoice. They still differ in what your customer receives and in which fields are mandatory. This post shows the difference with the same invoice in both formats, made by Inkvoice and checked with the official validator. All files are in the sample pack.

The short answer

ZUGFeRD XRechnung
What you send A PDF with the XML inside (PDF/A-3) XML only
Who can read it People (PDF) and software (XML) Software, or a viewer
XML syntax UN/CEFACT CII UBL or CII (Inkvoice uses UBL)
Typical customer Businesses Public authorities with a Leitweg-ID
Counts as an e-invoice From version 2.0.1, not in the MINIMUM or BASIC-WL profile Yes

If your customer is a company, ZUGFeRD is the safer default: their accounting team can open the PDF, and their software reads the XML. If your customer is a public authority, it will usually ask for XRechnung and give you a Leitweg-ID.

The same invoice, two files

Our sample invoice bills a German company €1,960 net at 19 % VAT. In XRechnung the first lines say which standard the file follows. The validator uses that line to pick its rules:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ID>INV-2026-0002</cbc:ID>
<cbc:IssueDate>2026-11-02</cbc:IssueDate>
<cbc:DueDate>2026-11-16</cbc:DueDate>
<cbc:BuyerReference>INV-2026-0002</cbc:BuyerReference>

The XML inside the ZUGFeRD PDF says the same in another syntax. Its guideline ID is the plain EN 16931 one, which is the ZUGFeRD profile also called EN 16931 or COMFORT:

<rsm:ExchangedDocumentContext>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

One wrong character in that first line, and the validator does not recognise the file at all. That happened to us: our XRechnung files before Inkvoice 0.3.4 used an outdated form of the ID, and the validator answered “no matching scenario” for every one of them.

What makes a ZUGFeRD PDF real

A PDF with an XML file attached is not automatically ZUGFeRD. The format asks for:

  • a PDF/A-3 file, the archive variant of PDF that allows attachments. All fonts must be embedded, and the colours need a declared profile;
  • the XML attached as factur-x.xml, marked as an alternative form of the document;
  • XMP metadata that tells readers the PDF carries a Factur-X/ZUGFeRD invoice, in which profile and under which file name.

Readers look for that metadata. Without it, a validator like Mustang reports “no ZUGFeRD XML found”, even though the attachment is there. We learned this the hard way too; Inkvoice 0.3.4 writes all three.

What XRechnung adds on top of EN 16931

XRechnung is the German “core invoice usage specification” of EN 16931. It makes some fields mandatory that the base standard leaves optional. These are the rules that rejected our own first files, with the rule IDs the validator prints:

Rule What it requires
BR-DE-1 Payment instructions, for example a SEPA transfer with your IBAN
BR-DE-15 A buyer reference (BT-10). Authorities give you their Leitweg-ID; for a company, any reference works
BR-DE-5, 6, 7 A seller contact: name, phone number and e-mail address
BR-DE-3, 4 Your postcode and city
BR-DE-8, 9 The customer’s postcode and city
PEPPOL-EN16931-R010, R020 An electronic address for you and for the customer. An e-mail address counts

None of these is hard to provide, but each one turns a whole file red. Inkvoice now fills them from your settings and lists what is missing when you create the e-invoice, for example a phone number.

Payment instructions in XRechnung look like this:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cbc:PaymentID>INV-2026-0002</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
    <cbc:Name>Anna Beispiel</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Code 58 means SEPA credit transfer. All data in the samples is example data.

Special cases the standard cares about

A few everyday invoices need extra care, in both formats:

  • 7 % VAT is not its own VAT category. It is “standard rated” (S) at 7 %. A category AA breaks the code list check.
  • Discounts on the whole invoice must be split per VAT rate, and each rate’s taxable amount is lines minus discount. The VAT is then calculated on the discounted amount.
  • Credit notes use type 381 and carry positive amounts; the type says it is a credit.
  • Reverse charge (§ 13b UStG) needs category AE and an exemption reason, for example VATEX-EU-AE.
  • Kleinunternehmer invoices use category E with a reason such as “Kleinunternehmer gemäß § 19 UStG”.

Each of these is one sample file in our pack.

How the check works

The KoSIT validator is the reference tool from the German coordination office for IT standards. With its XRechnung configuration (we use 3.0.2 from 31 August 2026) it does three things:

  1. It reads the CustomizationID or guideline ID and picks a scenario: XRechnung UBL, XRechnung CII, or plain EN 16931.
  2. It checks the XML schema: element names and their order.
  3. It runs the business rules (Schematron): the EN 16931 rules plus, for XRechnung, the German ones above.

The result is a report that recommends accepting or rejecting the file. For the PDF side, Mustang runs a PDF/A check (veraPDF) and validates the embedded XML.

Inkvoice runs both on 27 sample invoices on every change to its e-invoice code. Today: 27 of 27 accepted by KoSIT, 13 of 13 ZUGFeRD PDFs valid in Mustang. You can open the XRechnung report and the ZUGFeRD report, or download all files with their reports and run the validator yourself.

Which one should you use?

  • Business customers: ZUGFeRD, unless the customer asks for something else.
  • Public authorities: XRechnung with their Leitweg-ID.
  • Unsure: ask your customer. Their accounting software decides what it can import.

How to set either one up in Inkvoice is in How to send an e-invoice with Inkvoice. The deadlines are in Germany’s e-invoicing mandate.

Sources