from Patrick Gundlach |

Electronic invoices

Categories: Miscellaneous

The following text is written from a German perspective. This should apply to all parts of the European Union, although with likely differences in other countries.

Since the beginning of 2025, all companies in Germany have had to send and receive electronic invoices (with overriding deadlines and a few exceptions). This affects me too, so I asked myself (out of curiosity), what is an electronic invoice and how can I process it?

E-invoice

An e-invoice is defined in the EN 16931 standard. This consists of several parts:

  1. the first part of the standard describes in general terms how an invoice must be structured. For example, a seller must be specified, the types of VAT are defined and the necessary and optional contents of an invoice are described. There is also a series of (business) rules that check the semantic validity of an invoice.

  2. The second part consists of an analysis of various existing XML standards with regard to compatibility with the first part of the standard. The result of this analysis is that there are two allowed XML standards: CII and UBL (which are two different standards but have the same roots).

  3. the third part describes an assignment of the invoice terms to the XML elements of the CII or UBL implementations.

ZUGFeRD and Factur-X / CII

The German ZUGFeRD and the French Factur-X are identical standards that are based on CII (cross industry invoice). These are hybrid formats that have a human-readable and a machine-readable part, implemented as a PDF document with an XML attachment. The invoice visible in the PDF is also saved as XML in the attachment:

UBL

UBL based invoices (Universal Busines Language, defined in ISO 19845 by OASIS) is a different approach to electronic invoicing. Many countries have ULB based invoices (or a subset of it), for example Denmark has OIOUBL, Norways EHF and you can find many more such examples.

In Germany, UBL based invoices are popular in government agencies, not so much among b2b invoices.

XRechnung

There is yet another invoicing standard in Germany which might lead to confusion. The XRechnung standard is based on both ZUGFeRD CII and UBL format. It also defines some further business rules which are important for government agencies.

Peppol

Peppol (Pan-European Public Procurement OnLine) is a set of applications which includes electronic invoicing (based on the UBL standard). Many countries around the world implement the Peppol standard, see the country profiles list on peppol.org.

Other Countries

There are several sites on the internet that show the standards for electronic invoicing regulations for a lot of countries around the world, for example the page at edicomgroup.com/electronic-invoicing.

ZUGFeRD (and UBL based) XML

How does an XML for the ZUGFeRD/Factur-X format look like? This is described in detail in the documentation which can be downloaded from ferd-net. ZUGFeRD comes in several “conformance levels” (profiles), the EN16931 level should be used for electronic invoices. There are some examples at https://github.com/ZUGFeRD/corpus/tree/master/XML-Rechnung/CII. See the other directories for UBL based invoices.

Attaching an electronic invoice to a PDF

The ZUGFeRD format is (as described) a PDF with an attached XML. The PDF must conform to the PDF/A-3 standard and also include some special metadata. Both are described in the ZUGFeRD documentation.

Attaching a ZUGFeRD invoice with the speedata Publisher is very easy. Just call <AttachFile> with the type ZUGFeRD invoice and the speedata Publisher does the rest automatically. See the

<AttachFile description="Electronic invoice"
            type="ZUGFeRD invoice"
            filename="invoice.pdf" />

Development

I have setup the site erechnung.berlin (in German) mainly for my own purposes to check and visualize ZUGFeRD files and to show a hierarchical list of all allowed XML elements and their cardinality. The checker uses a Go library to read the XML file and is implemented as a WASM program, so it runs in the browser and does not transfer any data to a server.

Conclusion

The whole topic “e-invoices” looks complicated, but once the sender and the receiver have setup a process for these XML files, many new applications for automation can be developed. As a simple example, the banking account number and the due payable amount are stored in well known fields, so you might be able to drop an electronic invoice on the banking software which creates a money transfer template for you.