Under clearance e-invoicing, an invoice that fails validation was never issued. Not delayed, not rejected: legally nonexistent.
That moves where correctness has to live. If the tax platform is the thing that grants existence, our own validation has to reach the same verdict before we submit, otherwise we are shipping documents whose legal status we cannot predict.
Three parts of that in practice.
We evaluate EN 16931 business rules locally, and every report entry carries the rule id and the element path that failed. "Invalid invoice" is not a result. BR-CO-13 on a named element is, because that maps to a field in the interface and to an answer for whoever has to fix it.
We compute the VAT breakdown per category and rate, not per line. Lines get grouped by tax category, rate and exemption reason, the taxable amount is summed for the group, the tax is computed on that sum, and rounding happens at group and total level in the order the standard defines. Round every line and add the results up, and a one-cent drift turns into a rejected document.
We model line-level allowances and charges as their own structures, the way BR-41 through BR-44 require: amount, reason, and a base amount plus percentage that reconcile with each other. Fold a discount into a unit price and the totals stay arithmetically correct while the structure does not.
Our take: in a clearance regime, validation is the issuing step rather than a pre-send check. The document stays a draft until the platform says otherwise, and the data model should say so too, with the clearance response stored as the artifact that proves the invoice exists.
If you are already live on a clearance platform, you probably know which rule class generates most of your rejections: totals and rounding, or party and identifier data.