Understanding validation results for electronic invoices

Have you ever tried to check an e-invoice with different online validators? If so, you may have received different results for the same message. One file appeared correct in one validator, while in the next, it had numerous errors. To explain this phenomenon, we will first show you which tests you can use for the XML formats on which e-invoices as defined by the EN 16931 standard are based. We then move on to the special features of e-invoice checks.

There are basically three levels of XML checks. The simplest is the check for well-formedness. This refers to compliance with the basic structure of an XML file. An example from this category is checking whether only a single root element exists. XML files that are not well-formed can generally not be processed by the target system to which they are sent.

The next level are checks against a document type definition (DTD) or an XML schema (XSD). In both cases, these are specifications on how an XML document must be structured. For example, they specify how the elements must be nested within each other so that the file can be processed correctly. As XSDs offer more functions than DTDs, you will rarely find the latter. The structural specifications for the vast majority of e-invoice formats are also defined in XSDs.

Schematron rules can be integrated into an XML validation as a third level. In particular, you can use them to check more complex relationships in a message, often across several elements. For example, you want to compare whether the total amount specified for all discounts at document level corresponds to the sum of the individual discounts at document level. As the creation of Schematron rules requires time and knowledge, you will not find these checks in all XML validation interfaces.

XML files that violate a DTD, XSD or Schematron check can still be processed by a target system in some cases, but will generally require reworking.

The term “electronic invoice” covers a wide range of formats and content. Let's start with the fact that there are two XML-based formats that can be used to implement an e-invoice in accordance with the European standard EN 16931: The Cross-Industry-Invoice (CII) and the Universal Business Language (UBL), more precisely the invoice schema within the UBL.

These two formats are used in different specifications. The best known in Germany are probably the XRechnung and the ZUGFeRD invoice. The ZUGFeRD invoice is now also known as Factur-X. Both XRechnung and Factur-X exist in different versions; in addition to the current version, there are versions that have been discontinued.

One of the characteristics of the EN 16931 standard is that it distinguishes between a European core invoice model, national application specifications (CIUS) and extensions. The core invoice model contains a limited number of specifications regarding the content of the invoice. This includes, for example, the requirement that surcharges at item level must show a surcharge amount. In the CIUS, users can restrict which information may be used. With an extension, however, they can add elements to the core invoice model.

In Germany, the XRechnung is the CIUS for the B2G environment, but it can also be used as an XRechnung extension. It can then contain sub-items, for example. These are not included in the core invoice model. In principle, however, private companies can also create a CIUS for an EN 16931 format and request their trading partners to create invoices in accordance with this specification.

To ensure that only correct invoices are processed, invoice recipients can apply the three levels of XML validations. We are now approaching the core of our question, because while checks for well-formedness are universal, data recipients can use different XSDs or Schematron rules for their checks.

For example, if a data recipient does not use any application specifications or extensions beyond the requirements of EN 16931, the associated checks do not apply. If, on the other hand, the trading partners exchange invoices via the PEPPOL network, the corresponding Schematron rules are added for this case.

Let's summarize: Which specifications are included in a validation depends on various factors:

You should therefore understand which check specifications are used when you validate a file. In the case of error messages in particular, you should consider whether the issues are relevant to your business processes at all before making any unnecessary adjustments to invoice generation.

At Munich Data Quality, we use the CIUS XRechnung or Factur-X with EN 16931 profile in the current standard as standard for validating e-invoices in accordance with EN 16931. However, we are also happy to adapt the checks to our customers' requirements on request.