Why does the same invoice pass one validator and fail another?

Four things differ between validators, the ruleset version, which overlay ran, whether the published rules match the standard's text, and how severity is graded. Only one of them is your file.

You validate an invoice, it passes, you send it, and it comes back rejected. The file did not change, so one of four things differs between the two validators. It is worth knowing which, because three of them are not defects in your document.

This is the most common cause and the least interesting. Authorities publish new rule releases on their own schedules, and vendors adopt them at different times. A rule that was absent last year is present this year; a code list drops a value; a threshold changes. Both validators are running the authority’s rules, just not the same edition.

The tell is in the response. If the tool tells you which artifact versions it applied, you can compare them directly. If it does not, you cannot, and that is a reason to be wary of the tool rather than of your invoice.

European e-invoicing is a core standard plus national and network overlays, and which overlay applies is decided by the document’s own CustomizationID. Validate a document as a plain EN 16931 invoice and the German rules never run. Validate it as XRechnung and they do. Neither result is wrong; they answer different questions.

Some overlays need more than the identifier. Peppol’s rules only apply to UBL, because the network only carries UBL, so a CII document that happens to declare a Peppol identifier is not judged by Peppol rules. The French CTC overlay runs on its own set of triggers: an explicit opt-in, the EXTENDED-CTC-FR identifier, or a cadre de facturation code from a closed list in the document. Miss the trigger and a French document sails through a validation that never asked a single French question.

So before treating a disagreement as a bug, check that both tools were judging the document as the same kind of document.

This one surprises people. A standard is a normative text; the Schematron published for it is an implementation of that text, and the two can drift apart. A rule can sit in the specification while the published artifact omits it, which means an invoice can pass a validator that runs the artifact and be rejected by one that implements the text more fully.

There is a live example. BR-CO-25 requires that an invoice with a positive amount due carries either a payment due date or payment terms. CEN’s technical committee agreed to drop it, and it was removed from the EN 16931 Schematron in an April 2026 release. That removal is now contested on the upstream tracker, and while the question is open, several other packs still enforce it: the Mustangproject Factur-X packs, the FNFE-MPE French EXTENDED-CTC-FR overlay and the Romanian RO-CIUS overlay. An invoice judged by the core rules alone passes; the same invoice judged by one of those is rejected.

Beliq’s position here is to run the pinned artifact and nothing else, because that is what makes a ruleset fingerprint mean anything, and to say so out loud when a known divergence applies to your document. That is what an advisory finding is: severity: "info", an ID that ends in _NOT_ENFORCED so it is obviously not an official rule, and no effect on the verdict. It exists to tell you about a rejection risk you would otherwise meet downstream.

A rule can exist in both packs and carry a different severity in each. This is not academic. The French CTC pack currently flags most of its rules as warnings, but a plateforme agréée refuses a document that trips any of them whatever the pack says. A validator reporting the pack’s own severity is being accurate and still leaves you with a document that cannot be sent, which is why the French blocking rules are surfaced as a separate field rather than folded into the verdict.

For Italy’s FatturaPA, Spain’s Facturae and Slovenia’s e-SLOG, no machine-readable business rules exist at all. Any validator claiming a business-rule verdict on those formats is applying house rules of its own invention, and two tools’ house rules will not agree. A schema check is the honest ceiling, which is why those formats carry a Schema-checked label rather than the Authority-checked one.