Why does XML pass XSD but fail EN 16931?

A simple real-life example

Imagine a paper form.

The XSD check asks:

• Have the correct fields been filled in?
• Is the date entered in the correct format?
• Is the amount entered as a number?
• Is the information in the correct place?

If so, the form looks technically correct.

The EN 16931 check asks:

• Are the calculations correct?
• Has VAT been calculated correctly?
• Does the sum of the items match the total amount?
• Is all mandatory business information included?

If not, the validator will return a violation of the relevant rule. Whether the document is sent or received also depends on the severity of the rule and the process used.

A practical example

Let’s consider an invoice:

However, the total invoice amount is stated as:

€120

From the perspective of XSD validation, the values are syntactically correct:

• the numbers are written correctly,
• the dates are in the correct format,
• all data is in the correct place.

Therefore, the XSD validation passes.

However, the business rules show that:

100 + 50 ≠ 120

Therefore, the EN 16931 validation fails.

Another example

The invoice states a zero VAT rate, but the mandatory reason for the tax exemption is missing.

From the perspective of the XSD schema, the invoice is technically valid.

The XSD therefore does not identify the problem.

However, the EN 16931 rules require this information to be included.

Result:

• The XSD passes
• EN 16931 fails

What exactly does XSD check?

The XSD mainly checks:

• the document structure,
• the date format,
• value types,
• permitted elements,
• the correct organisation of data.

Put simply:

Can the system even read the invoice?

What does EN 16931 check?

EN 16931 checks:

• defined logical relationships,
• calculation rules and totals,
• defined rules for VAT data,
• mandatory business data,
• permitted codes and identifiers.

Put simply:

Does the data comply with the defined semantic and calculation rules?

Validation does not verify whether the supply actually took place, whether the price corresponds to the contract, or whether every tax conclusion is factually correct.

Why is this important?

Many companies think:

“Our XML invoice has passed validation, so it must be correct.”

However, this may not be true.

A successful XSD check merely means that the document is technically readable.

It does not mean that:

• it can be delivered,
• it will be accepted by the recipient,
• it complies with European rules on electronic invoicing.

How the e-invoice validation works

In simple terms:

1. Technical check

Is the XML file correctly formatted?

2. EN 16931

Does the data comply with the EN 16931 standard?

3. Peppol rules

Does the invoice comply with Peppol network rules?

4. National rules

Does it meet the requirements of the specific country?

Only after successfully passing all checks can the invoice be considered ready for production use.

Conclusion

If the XML passes the XSD validation, this merely means that the document has been created correctly from a technical point of view.

However, if it fails to pass EN 16931, it means that the document has breached at least one defined validation rule of this layer.

Put simply:

XSD answers the question: ‘Can the system read the invoice?’

EN 16931 answers the question: “Does the document comply with the defined semantic rules?”

Successful XSD validation is therefore only the first step and does not in itself confirm the correctness of the e-invoice.

Technical resources

• EN 16931
• Peppol BIS Billing 3.0
• OpenPeppol Validation Artefacts
• e-Invoice validation rules catalogue