XRechnung, ZUGFeRD and BIS Billing 3.0: which e-invoice formats your software should support

EN 16931 describes a semantic data model. It defines which information an invoice contains and how the items relate to each other, for example the invoice number as BT-1 or the buyer reference as BT-10. The standard itself is not a file format.

For the technical representation, it permits two syntaxes: UBL and UN/CEFACT CII. Both represent the same semantic model but differ in element names and structure. Software that only reads UBL cannot process a CII invoice automatically, even if it is compliant with the standard.

For the implementation, this determines the maintenance effort. Two parallel mappings mean that every rule change has to be followed up in two places. If you instead map once to the semantic model of the standard and generate both syntaxes from it, you only touch one place per change.

On receipt, it works the other way round: the incoming file is first mapped to the semantic model and from there transferred into your data model.

Above the standard sit the national and network-specific specifications, called Core Invoice Usage Specification in the standard, or CIUS for short. A CIUS narrows the standard. It makes optional fields mandatory, excludes others and brings its own Schematron rules. Specifications that go beyond the scope of the standard are called extensions.

Regardless of syntax and specification, an e-invoice comes either as a pure XML file or as a PDF/A-3 with an embedded XML file. For the second case, the term hybrid format has become established.

XRechnung is a CIUS of EN 16931 and is maintained by the Coordination Office for IT Standards, KoSIT for short. It exists in both syntaxes. It has no visual component; the file is pure XML.

XRechnung is mandatory for invoices to the German federal administration. The invoice is addressed via the Leitweg-ID, which is given in the data record as the buyer reference.

The submission channel depends on the recipient. Options are the ZRE and OZG-RE portals or a Peppol Access Point. In B2B, the Leitweg-ID plays no role. There, XRechnung is just one of several permitted profiles.

Version 3.0.2 currently applies. For XRechnung 4.0, the implementation of EN 16931 in the 2026 edition, a preliminary version already exists. The final version of XRechnung 4.0 is expected to be published in spring 2027.

ZUGFeRD packs an XML file in CII into a PDF/A-3. People see the PDF, while software reads the XML.

The specification has several profiles with different data scopes, from MINIMUM to EXTENDED.

MINIMUM and BASIC WL do not contain a complete invoice and do not meet the standard. From the EN 16931 profile upwards, called COMFORT in older versions, the structured part complies with the standard. Your software should read the profile on import and handle files with MINIMUM or BASIC WL separately, for example through a manual check.

Factur-X is technically largely identical to ZUGFeRD.

ZUGFeRD makes sense above all where your customers invoice recipients who still check invoices visually. Only the embedded XML is legally decisive. If the PDF and XML differ, the data of the structured part takes precedence, according to the German Federal Ministry of Finance letter of 15 October 2025.

An approval process that only checks the PDF can therefore approve an invoice whose decisive content says something else.

When sending, your software should generate the PDF and XML from the same data record so that they do not diverge. On receipt, it should build its own view from the XML for checking instead of displaying the supplied PDF. The German Federal Ministry of Finance also recommends visualising the XML part yourself.

Peppol BIS Billing 3.0 is also a CIUS of EN 16931, fixed to UBL 2.1. OpenPeppol specified it as its own format for exchanging invoices and credit notes over the network.

In addition to the rules of the standard, it brings its own Schematron rules. A file can pass validation against EN 16931 and fail on a Peppol rule. Often these concern code lists or fields that the network defines more narrowly than the standard.

The specification is developed further in versions. If you validate yourself, you should check whether your rule sets are up to date.

In the longer term, Peppol is moving towards PINT, an internationally aligned basis for invoice profiles outside Europe. For implementation in Germany, this changes nothing at present.

For these invoices, your software must be able to generate XRechnung. The recipient’s Leitweg-ID belongs in the invoice data record as a mandatory field and is output in the XRechnung as the buyer reference (BT-10). If it is missing or in the wrong field, the receiving portal rejects the invoice.

The law requires an invoice in accordance with EN 16931 and leaves the format open. XRechnung, ZUGFeRD from the EN 16931 profile upwards and also Peppol BIS Billing are permitted. The embedded XML remains legally decisive. If the PDF and XML differ, the recipient may be checking different information from what legally applies.

Companies in Germany have had to be able to receive e-invoices in accordance with EN 16931 since 1 January 2025. For an e-invoice that complies with the standard, the sender therefore does not need the recipient’s consent, even if the recipient prefers a particular format.

The two parties only need to agree on the transmission channel and on formats outside the standard. In practice, the agreed channel therefore belongs in the master data of the individual business partner.

In addition to Peppol BIS Billing 3.0, XRechnung and, since March 2025, ZUGFeRD as a hybrid file can also be transmitted via the Peppol network. The document types that a recipient has registered in the directory service show which formats it accepts. Before sending, your software must query this registration and choose the right format. For individual checks, the Peppol ID lookup shows this without registration.

In live operation, your software should run this query automatically before sending, either directly via the SML and SMP directory services or via the API of your Peppol Access Point. Based on this, a commonly supported format is determined and the e-invoice is then generated in that format.

Incoming invoices arrive in the format the sender has chosen. Your software should therefore be able to read both syntaxes, UBL and CII, and thus also XRechnung in both variants. Add to that ZUGFeRD and Factur-X as hybrid files and, as soon as your customers receive invoices from abroad, the profiles customary there.

Every incoming file contains an identifier stating which specification it uses. In UBL it is in the element cbc:CustomizationID, in CII in the guideline context parameter. Your software should read this identifier first, because it determines which validation rules apply and how the file is transferred into your data model.

Some Peppol Access Points take this step off your hands. They check the incoming file, extract the invoice data and pass it on together with the original file as a uniform data record.

Your software should fully cover receiving before sending, i.e. both syntaxes and the hybrid formats, because your customers already have to be able to receive e-invoices today.

Sending becomes mandatory for your customers in two stages: from 1 January 2027 for more than €800,000 in total turnover in the previous year, and from 1 January 2028 for all other domestic B2B transactions.

If you start with the CII syntax, you can use it to generate XRechnung in the CII variant and ZUGFeRD. UBL becomes necessary as soon as recipients in the Peppol network expect Peppol BIS Billing 3.0, because this format requires UBL.

All mandatory VAT information must be in the structured part of the e-invoice in machine-readable form. This includes the description of goods or services. A reference to an attachment, a delivery note or a link does not replace a mandatory field. The basis is the German Federal Ministry of Finance FAQ on e-invoicing and the German Federal Ministry of Finance letter of 15 October 2025.

The reason lies in the structure of the e-invoice. With hybrid formats such as ZUGFeRD, the data in the XML is leading; the PDF is only a view. Information that is only visible in the PDF therefore does not count.

If a mandatory item of information is missing from the structured part, the invoice is not considered proper, and the recipient’s input VAT deduction may be at risk. Your customers will notice this at the latest when business partners reject invoices for this reason.

Many invoice templates carry mandatory information as text blocks that only appear in the PDF. This often concerns the description of goods or services, for example “as per quotation 2026-114”, the service period in the footer of the invoice and the reference to the reverse-charge mechanism.

In the data model, each of these items should have its own field from which the XML is filled. The service period belongs in the fields for the invoicing period (BG-14), the reverse-charge reference in the tax category with exemption reason (BT-120 and BT-121).

Technical validation checks whether the mandatory fields of the standard are present and formally correctly filled. It does not detect whether a description of goods or services is sufficient for VAT purposes. An invoice can therefore pass validation and still contain a mandatory item of information only insufficiently.

Delivery notes, timesheets and other documents accompanying the invoice can be embedded in the e-invoice as attachments, in EN 16931 via the additional supporting documents group (BG-24). This replaces separate sending and keeps invoice and supporting evidence together in one file.

An XRechnung is checked against two rule sets: the rules of EN 16931 and the additional KoSIT rules. The same applies to Peppol BIS Billing 3.0 with the OpenPeppol rules. A check against the standard alone therefore says only so much about whether the recipient will accept the file. Your software should check against the rule set of the specification the recipient expects.

KoSIT and OpenPeppol regularly publish new versions of their rule sets with adjusted code lists and Schematron rules. If your software does not keep its rule sets up to date, invoices that were previously accepted may be rejected. The rejection then comes from the recipient, but the cause lies in your own outdated rule set.

For tests during development, individual files can be checked against EN 16931 and the Peppol rules with the free e-invoice validator. For automated checking in live operation, InvoiceRails also offers validation via an API, against EN 16931 and profiles such as XRechnung, ZUGFeRD and Peppol BIS Billing. The validation report lists errors, warnings and notices separately.

A mapping is built once; the validation rules behind it can change several times a year. The next major switch is already on the horizon with XRechnung 4.0 and EN 16931 in the 2026 edition.

The 2026 edition is based on UBL 2.5. In compliant implementations, UBL 2.5 can only be used once CEN has published an updated syntax binding. Until then, the existing bindings based on UBL 2.1 apply. Providers can therefore prepare the switch, but not yet implement it.

If you build the connection yourself, you take on this maintenance permanently. This includes keeping the mappings for both syntaxes, the code lists and the Schematron rules up to date and following the version plans of KoSIT, FeRD, OpenPeppol and CEN. This is feasible, but it ties up development time that is then missing in your own product.

Alternatively, format maintenance can be outsourced to a Peppol Access Point. InvoiceRails, the OpenPeppol-certified Access Point from fino data services, covers more than 60 formats via one API, including XRechnung, ZUGFeRD and Factur-X, and continuously maintains validation rules and format updates.

Providers connect sending and receiving once and make the function available to any number of their customers, under their own brand if desired. Mapping their own invoice data to the interface remains with the provider, as do the mandatory fields in their own data model.

How software providers bring e-invoicing into their own product in general is covered in the article on e-invoicing for software providers.