Knowledge · E-invoicing
Validating e-invoices and reading the validation report correctly
When an e-invoice from your software is rejected, your team has to work out from the validation report which field triggered the message and who can correct it.
We show how to read a validation report and where validation belongs in your software.
What is checked when an e-invoice is validated
A validator checks an e-invoice against three rule sets in turn and records every deviation in a validation report.
XML schema of the syntax
An e-invoice under EN 16931 comes in one of two syntaxes, UBL or UN/CEFACT CII. All common application specifications are built on these two syntaxes, for example XRechnung, ZUGFeRD and Peppol BIS Billing 3.0.
The XML schema of the syntax defines which elements are allowed, in which order they appear and which data type they have.
Schema errors have no rule ID. The XML parser reports them with its own codes, for example cvc-complex-type.2.4.a for an element in a place where the schema does not expect it.
With ZUGFeRD, a CII file is embedded in a PDF. The validator checks the XML part. Where it deviates from the visual part, this XML part prevails, according to the German Federal Ministry of Finance letter of 15 October 2025 on the introduction of mandatory e-invoicing.
Business rules of EN 16931
The business rules check the content of an e-invoice for logical errors, for example whether mandatory fields are filled and whether the totals add up. The European Committee for Standardization (CEN) publishes these rules as Schematron files on GitHub, one set each for UBL and for CII.
The prefix of the rule ID tells you what kind of check it is. Rules with BR and a number check mandatory fields and their cardinality, BR-CO checks calculations and dependencies between fields, BR-CL checks code lists and BR-DEC the decimal places of amounts. Rules such as BR-S, BR-AE or BR-IC check the information on individual VAT categories.
The CEN files also contain syntax-specific rules. Rules with the prefix UBL-CR, for example, issue a warning when a UBL file contains elements that are not part of the EN 16931 data model.
Rules of XRechnung and Peppol BIS Billing 3.0
XRechnung and Peppol BIS Billing 3.0 are application specifications of EN 16931, technically called CIUS (Core Invoice Usage Specification). They make additional fields mandatory and add their own rules to EN 16931. A CIUS may not introduce new data fields.
The XRechnung rules start with BR-DE and come from the Coordination Office for IT Standards (KoSIT). Peppol BIS Billing 3.0 adds rules with the prefixes PEPPOL-EN16931 and PEPPOL-COMMON, as well as country-specific rules.
The specification identifier in BT-24 determines which application specification applies to the file. The KoSIT validator uses this identifier to select the matching validation scenario. A wrong or outdated identifier can therefore cause the file to be checked against different rules or to be rejected.
What validation does not check
A validator does not recognise whether the tax rate matches the goods or services, or whether the description of goods or services is sufficient.
According to the German Federal Ministry of Finance, all mandatory VAT information must be contained in the structured part of the e-invoice. A mere reference to an attachment containing the description of goods or services is not enough. An item name such as “see attachment” in BT-153 still passes validation, because no rule assesses the content of this field.
KoSIT and the Forum elektronische Rechnung Deutschland (FeRD) have published a table that maps the mandatory information under the German VAT Act to the corresponding BT fields. With this table, you can decide which mandatory information your software should safeguard with its own plausibility checks.
Structure of a validation report
Each entry in the validation report usually contains four items of information.
Rule ID
The rule ID, such as BR-CO-15 or BR-DE-2, refers to the rule in the documentation of the respective rule set.
Severity
A validator flags each message as an error or as a warning. In the Peppol rules, errors are called fatal. A warning on its own does not usually lead to rejection. Some validators also output notices, i.e. recommendations for a clean implementation that do not affect the result. At the end of its report, the KoSIT validator recommends accepting or rejecting the document.
Peppol often introduces new rules as warnings first and upgrades them to errors in a later release. With version 3.0.21, for example, the rules PEPPOL-COMMON-R052 and PEPPOL-COMMON-R053 were changed from warnings to errors, as stated in the release notes of Peppol BIS Billing 3.0.
Location
The location is an XPath expression that points to the affected element in the XML. The same BT number sits in different places in UBL and CII. The invoice total amount with VAT (BT-112) is in the element cbc:TaxInclusiveAmount under cac:LegalMonetaryTotal in UBL, and in the element ram:GrandTotalAmount under ram:SpecifiedTradeSettlementHeaderMonetarySummation in CII.
For rules that compare several fields, the location often points to a parent element. You then find the value that triggers the message via the message text.
Message text
The message text describes the rule and usually names the BT numbers involved. The message for BR-CO-15, for example, states that the invoice total amount with VAT (BT-112) must equal the sum of the invoice total amount without VAT (BT-109) and the invoice total VAT amount (BT-110).
Since version 3.0.21, the texts of the Peppol rules begin with the rule ID.
Evaluating validation reports in the right order
A long validation report often comes down to a few causes.
-
Fix schema errors
As long as the file does not comply with the schema, the results of the business rules are of little value or missing entirely. Fix the schema errors in the export first and then validate the file again.
-
Group entries by rule ID
A mapping error can occur in every invoice line. An invoice with 40 lines then produces 40 entries for the same rule, all going back to a single cause. Evaluate the report by rule ID for this reason.
-
Recognise consequential errors
One missing element can violate several rules at once. If the VAT breakdown (BG-23) is missing, the validator reports, for example, BR-CO-18 and additionally rules of the affected VAT category, such as BR-S-01. Fix the cause first and validate again before working through the remaining messages one by one.
-
Use the BT number to get into your own data model
The BT number connects the validation report with your software. Maintain a mapping from each BT number to the database field, to the form field in your interface and to the responsibility. The responsibility determines whether your team fixes an error or your customer does, for example when master data is missing.
-
Assess and document warnings
For each warning, decide whether to fix it or deliberately accept it, and document the decision. With every new release, check whether an accepted warning is being upgraded to an error.
Typical causes of errors by rule group
The rule group often already shows where in your software the correction needs to be made.
Schema errors without a rule ID
The cause lies in the element order, the namespace or a wrong data type in the export. The correction is made in the export function, once for all customers.
BR with a number
The cause is a mandatory field that is not mapped or is empty in the master data. The correction is made in the mapping or at the mandatory field in the interface.
BR-CO and BR-DEC
The cause lies in totals, rounding, allowances and charges at document level. The correction is made in the calculation logic of invoice creation.
BR-CL
The cause is an outdated or custom code, for example for units of measure or countries. The correction is made in the code lists in your software.
BR-S, BR-AE, BR-IC and other categories
VAT category, tax rate and exemption reason do not match. The correction is made in the tax logic and in the item master data.
UBL-CR
The export contains UBL elements outside the EN 16931 data model. The correction is made in the export function.
BR-DE
Seller contact details, payment information or the buyer reference are missing. The correction is usually made in your customers’ master data.
PEPPOL-EN16931 and PEPPOL-COMMON
The electronic address is missing or an identifier has the wrong format. The correction is made in the master data and in the management of Peppol IDs.
Missing buyer reference in XRechnung (BR-DE-15)
The rule BR-DE-15 reports a missing buyer reference in BT-10. For invoices to the public administration, this field holds the authority’s Leitweg-ID (routing ID). For B2B invoices, according to the German Federal Ministry of Finance, a placeholder such as “-” is sufficient for VAT purposes if the invoice recipient does not specify its own identifier. Your software can therefore prefill the field for B2B invoices with a placeholder that your customers can overwrite.
Rounding differences in VAT (BR-S-09)
The rule BR-S-09 compares the VAT amount of the standard-rate category with the product of the taxable amount and the tax rate. If your software rounds the VAT per line and adds up the amounts, the total can deviate from this. With many lines, the deviation can exceed the tolerance the rule allows. Calculate the tax amount per category from the taxable amount and the tax rate, as the rule specifies.
Building validation into your software
Validation belongs in five places in your software and your development process.
Before sending
Your software should validate every e-invoice immediately after it is created and stop sending if there are errors. Your customers can do little with a rule ID or an XPath expression. Translate the rules that your customers can fix themselves into a hint at the affected form field. The hint for BR-DE-6, the seller contact’s telephone number in BT-42, could for example read “Please enter a telephone number for queries”.
Your customer cannot fix errors caused by your mapping or your calculation logic. Such errors should go to your team as an internal notice.
On receipt
Your software should also validate incoming e-invoices and display the result on the document. Store the original file unchanged and the validation report as a separate document next to it. The German Federal Ministry of Finance requires that at least the structured part of an e-invoice is retained intact in its original form.
If an incoming invoice contains errors, your customer can request a corrected invoice from the sender. Your software can support this step, for example with a prepared query to the sender that includes the validation report.
In automated tests
Build a collection of test invoices that covers your invoice types with their codes, for example 380 for an invoice and 384 for a corrected invoice. Also cover every VAT category your customers use, plus allowances and charges and every syntax your software produces. Include deliberately faulty files as well, and check that the validator rejects them.
The KoSIT validator is an open-source command-line program and can be integrated into a build pipeline. KoSIT also provides a test suite with sample invoices that is a good starting point for your own collection.
After every update of the rule sets
The rule sets change even without a new version number. For XRechnung 3.0.2, KoSIT regularly publishes bundles with bug fixes, most recently the version of 31 August 2026. XRechnung 3.0 remains in force until at least 31 July 2027.
The preliminary version of the XRechnung 4.0 specification was published on 15 September 2026. It is expressly not intended for productive use, but gives you an early overview of the new and changed functionality. The final version is expected in spring 2027, together with the technical components.
OpenPeppol regularly publishes new releases of Peppol BIS Billing 3.0, in recent years in May and November. Version 3.0.21 was published on 20 May 2026 and has been mandatory since 17 August 2026.
Schedule a fixed date for each release on which you validate your test collection against the new rules. Record in every validation report which version of the validator and rule set produced it. This lets you trace a result even if the rules have changed in the meantime. For the switch to XRechnung 4.0, your test environment should be able to check both versions in parallel.
Evaluating validation reports across all customers
If your software produces e-invoices for many customers, it pays to evaluate the validation reports across all customers. If the same rule ID suddenly appears for many customers, the cause probably lies in the mapping or in a new rule set. If it only occurs for one customer, the cause is more likely in that customer’s master data.
Validation with InvoiceRails
You can implement all the steps in this article yourself. The one-off effort is manageable, the ongoing effort is not: rule sets, code lists and validation configurations change several times a year, and every change has to go into your tests, your sending process and your release planning.
Validation, sending and the maintenance of the rule sets can therefore also be handed over to a certified Peppol Access Point such as InvoiceRails.
E-invoice validator for individual checks
The free InvoiceRails e-invoice validator checks XML files in UBL and CII as well as hybrid PDF invoices, without registration. It automatically detects syntax, version and profile, including XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X and other EN 16931 profiles. It then validates the file against the XML schema and against the Schematron and business rules of the detected profile. You can download the validation report as a PDF or share it via a link, for example when your support team discusses a rejected invoice with a customer.
InvoiceRails API in your software
InvoiceRails is the OpenPeppol-certified Peppol Access Point from fino data services. Your software connects to InvoiceRails via a REST API and uses it to send and receive e-invoices for any number of customers, as a white-label solution if desired.
The API offers validation as a dedicated endpoint, likewise with automatic profile detection. Your software can use it to check e-invoices immediately after they are created. Each message in the response contains the rule ID, severity, message text and location as XPath. Your software can store the validation ID with the invoice and retrieve the result again for at least 90 days.
InvoiceRails validates every file your software sends via Peppol, even without this call. Your software must check in advance which formats a recipient supports.
InvoiceRails also checks incoming e-invoices and passes the original file to your software together with the extracted invoice data. A webhook notifies your software of every change in delivery status.
Your software remains responsible for mapping the fields from your data model, for the understandable hints in your interface and for the plausibility checks on mandatory information that no rule covers.
