What happens when an e-invoice fails validation?

A failed e-invoice comes back as a list of findings, each with a rule ID, a severity and the exact spot in your XML. This explains how to read one and which failures actually block you.

Nothing is rejected with a bare “invalid”. A validation failure is a list of findings, and each one names the rule that fired, how serious it is, and where in your document it fired. The work is reading that list, not guessing.

A validation result separates findings by severity. Anything at fatal or error lands in errors and makes the document invalid. Anything at warning or info lands in warnings and does not. Every finding carries four things:

ruleIdstring

The official identifier of the rule that fired, for example BR-01 or BR-DE-15.

severityenum

One of fatal, error, warning, info.

locationxpath

An XPath pointing at the element in your source XML.

messagestring

A plain-language description you can paste into a ticket.

So a failure is directly actionable. You are not told the invoice is wrong; you are told that BR-DE-15 fired at a named path because an XRechnung invoice must contain a buyer reference.

The prefix tells you which rulebook rejected you, which in turn tells you who to ask about it:

A BR-CO-10 failure (“sum of line net amounts must equal invoice net amount”) is your arithmetic. A BR-DE-15 failure is a German requirement that does not exist elsewhere in Europe, and it will not appear if you validate the same document as a plain EN 16931 invoice. Which overlay ran is not a setting you pass; it is read from the CustomizationID the document itself declares.

A warning does not make a document invalid, and most of them are genuinely advisory. Two cases deserve attention anyway.

The first is a rule the artifact that judged you does not carry, but another validator downstream does. Beliq reports one of these as an advisory: severity: "info", with a deliberately unofficial ID ending in _NOT_ENFORCED so you can tell it apart from a real rule. It never changes the verdict, because the verdict reflects only the artifacts that actually ran. It is there because staying silent about a known divergence is not neutral when your invoice is going somewhere that checks it.

The second is France. The French CTC rule pack currently flags most of its rules as warnings, but a plateforme agréée refuses a document carrying any of them regardless of the severity the pack assigns. So a French document can validate as valid: true and still be unsendable, which is why the validation result carries franceCtcBlockingRuleIds as a separate answer to a separate question.

If you validate an existing file, a failure is a normal 200 response with valid: false and the findings. Validation succeeded; the document did not.

If you ask Beliq to build a document from your data and the result would not be compliant, that is an error response instead: 422 INVALID_INVOICE, with the same findings under details.validationResult.errors. You get no file, because a file that fails its own rulebook is not something worth handing you. Two related refusals work the same way: one when the profile you asked for cannot satisfy the standard you asked for, and one when you ask a format that only accepts invoices for a credit note. Both name the combinations that would have worked, in the error reference.

The cost of a downstream rejection is not always just a resend. Under the French reform an invoice number is unique on the number, the supplier SIREN and the invoice year, so a rejected invoice has to be reissued under a new number: the rejection spends the number. That is the clearest example of why validating before transmission is worth the round trip, but the general case holds everywhere. A rejection at the network or the tax authority is slower, less specific and more expensive than a rejection from a validator you called yourself.