How to check a Factur-X invoice is valid (and why it would be rejected)
Checking a Factur-X invoice: how to extract the XML, the most common EN 16931 errors, and how to fix them.
Em resumo
- •A Factur-X invoice can open perfectly in a PDF reader and still be technically invalid: the PDF looks fine, the XML is wrong.
- •Fastest test: open the PDF and look for the `factur-x.xml` attachment in the attachments pane. No attachment = not Factur-X.
- •Rejections almost always come from three causes: a missing identification field, a missing VAT exemption reason, or totals that don't add up to the cent.
- •EN 16931 imposes codified calculation rules (`BR-CO-10`, `BR-CO-13`…) — a one-cent rounding gap is enough to fail validation.
- •The right reflex: use a tool that validates before export rather than discovering the rejection at the customer's end.
The trap: an invoice that looks perfect
This is the classic bad surprise of structured invoicing. You open your Factur-X invoice: it renders nicely, the amounts are right, your logo is there. You send it. Three days later the customer's platform rejects it.
The reason is simple: what you looked at is the PDF. What the machine reads is the XML inside. The two can diverge, and nobody warns you.
Test 1: is it really Factur-X?
The fastest test, ten seconds:
If there is no attachment, it is not a Factur-X invoice — it's an ordinary PDF, whatever your software promises. That single test already rules out a good share of tools claiming compliance.
Note: browser PDF viewers and many mobile apps do not display attachments. An apparent absence in Chrome proves nothing — redo the test in a real reader.
Test 2: is the XML valid?
Extract the `factur-x.xml` file (right-click the attachment → save) and run it through an EN 16931 validator. The French administration provides a checking service on its e-invoicing portal, and public validators are maintained by the ecosystem.
The validator returns a list of coded errors. That's where it becomes readable.
The most common errors
Totals that don't add up
By far the number one cause, and the sneakiest. EN 16931 imposes strict summing rules:
| Code | What it requires |
|---|---|
| `BR-CO-10` | Sum of line totals = net amount |
| `BR-CO-13` | Net − allowances + charges = taxable base |
| `BR-CO-14` | Sum of per-rate VAT = total VAT |
| `BR-CO-15` | Taxable base + VAT = gross total |
| `BR-CO-16` | Gross total − prepaid = amount due |
The trap: these rules must hold on the two-decimal rounded amounts you display. Software computing in floating point and rounding at display time regularly produces one-cent gaps — invisible to the eye, fatal to the validator. Well-built tools compute in integer cents precisely to avoid this.
Missing VAT exemption reason
If you are VAT-exempt, your invoice shows 0% VAT. The standard does not accept a bare zero rate: it requires a VAT category (`E` for exempt) and a written reason.
Many tools write that mention in the visible PDF… and forget it in the XML. Result: rejection.
Incomplete identification
The XML demands data your PDF tolerated omitting:
An empty field in your settings becomes a blocking error in the XML. That's why good software makes you fill these in before letting you export.
Malformed dates or currencies
Technical but frequent: dates must be `YYYYMMDD`, currencies ISO codes (`EUR`), countries two-letter ISO codes (`FR`). A spelled-out "France" instead of `FR` is enough to break parsing.
The method that avoids all of this
Validating after the fact is already too late: you've sent the invoice. The right approach is validation before export.
That's what Robi does: before generating the Factur-X, the app checks every field the EN 16931 profile requires and names the missing ones so you can fill them in on the spot. Amounts are computed in integer cents, so the `BR-CO-*` rules hold by construction.
Checklist before sending
Going further
If the format itself is still fuzzy, start with what Factur-X is.
Perguntas frequentes
How do I know my PDF really is a Factur-X invoice?+
Open the PDF in a desktop reader and look at the attachments pane: a Factur-X invoice contains an attached file named factur-x.xml. No attachment means it is not Factur-X, just an ordinary PDF.
Why was my electronic invoice rejected?+
Usually for one of three reasons: a missing identification field, a missing VAT exemption reason inside the XML if you are VAT-exempt, or totals that don't add up exactly to the cent.
What is a BR-CO-10 error?+
It is an EN 16931 calculation rule: the sum of line totals must exactly equal the invoice net amount. The error flags a gap, usually one cent, caused by successive roundings.
My invoice opens fine, so is it valid?+
No, and that is the main trap. How the PDF renders says nothing about the validity of the embedded XML: an invoice can be perfectly readable and still be rejected by the recipient's platform.
Coloque a casa em ordem
Automatize todas as suas notas fiscais com Robi AI e salve mais de 10 horas todos os meses.
Get Started Free