A contribution from our partner Munich Data Quality GmbH, Dr. Matthias Nopper
Have you ever tried to verify an e-invoice with different online validators? If so, you may have encountered different results for the same message. One file appeared correct in one validation, but numerous errors were flagged in the next. To explain this phenomenon, we’ll first demonstrate the tests you can apply to the XML formats on which e-invoices are based, as defined by the EN 16931 standard. Then we’ll discuss the specifics of e-invoice validations.
There are essentially three levels of XML validation. The simplest is the well-formedness check. 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 generally cannot be processed by the target system to which they are sent.
The next level is checks against a document type definition (DTD) or an XML schema (XSD). In both cases, these are specifications for 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. Since XSDs offer more functionality than DTDs, you will rarely find the latter. The structural specifications for the vast majority of e-invoice formats are also recorded in XSDs.
As a third level, Schematron rules can be integrated into an XML validation. They are particularly useful for checking more complex relationships within a message, often across multiple elements. For example, you might want to compare whether the total amount specified for all discounts at the document level corresponds to the sum of the individual discounts at the document level. Because creating Schematron rules requires time and expertise, these checks are not available in all XML validation interfaces.
XML files that violate a DTD, XSD, or Schematron check can sometimes still be processed by a target system, but will generally require rework.
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 as defined by the European standard EN 16931: the Cross-Industry Invoice (CII) and the Universal Business Language (UBL), more specifically the invoice schema within the UBL.
These two formats are used in different specifications. The most well-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 the item level must show a surcharge amount. Users can restrict which information may be used in the CIUS. However, they can add elements to the core invoice model with an extension.
In Germany, the XRechnung is the CIUS for the B2G environment, but it can also be used as an XRechnung extension. In this case, it can 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 according to this specification.
To ensure that only correct invoices are processed, invoice recipients can apply the three levels of XML validation. We are now approaching the core of our question: while well-formedness checks 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 EN 16931 specifications, the associated checks are omitted. However, if trading partners exchange invoices via the PEPPOL network, the corresponding Schematron rules are added for this case.
To summarize: Which specifications are included in a validation depends on various factors:
You should therefore understand which check specifications are used when validating a file. Especially with error messages, you should consider whether the issues are actually relevant to your business processes before making any unnecessary adjustments to invoice generation.
At our partner Munich Data Quality, we use CIUS XRechnung or Factur-X with EN 16931 profile in the latest standard for validating e-invoices according to EN 16931. Upon request, we are also happy to adapt the checks to our customers’ requirements.