Your invoicing software produced a nice PDF, your certified platform (PA in France, PDP before) transmitted it… and the invoice comes back rejected, often with an error code that means nothing to anyone. Good news: a rejection is almost never mysterious. The platform inspected technical layers your PDF reader doesn’t show — and those layers can be diagnosed methodically, including locally, without sending the invoice to a third-party service.
Since September 1st, 2026, receiving electronic invoices is mandatory for all French businesses, and large companies and mid-caps must already issue through a platform (SMEs and micro-businesses: September 2027). Rejections are pouring in at issuers discovering the format — this guide helps you understand yours.
Why the invoice “looked fine”
A Factur-X is a hybrid file: a human-readable PDF/A-3, plus a structured XML file embedded as an attachment, read by software. When you open the invoice in a PDF reader, you only see the first half. Rejection causes live in the second — or in the technical properties of the container itself, invisible on display.
A certified platform doesn’t “read” your invoice the way you do: it unwraps the container, extracts the XML and applies validation rules before accepting or routing the document. A flawless rendering can coexist with an absent, corrupted or arithmetically inconsistent XML.
The real causes of rejection, layer by layer
Diagnosing a rejected invoice follows a logical order: from container to content. That is exactly the order applied by Document Flare’s Factur-X Diagnosis tool, which evaluates five layers and stops at the first blocker.
1. The container is not a PDF/A-3
Factur-X requires a PDF/A-3 (ISO 19005-3), signalled in the XMP metadata by pdfaid:part=3. An ordinary PDF — or a PDF/A of another profile — fails here. Two complementary signals are checked: the presence of an OutputIntent (color profile, mandatory in PDF/A) and the declaration of the Factur-X extension schema in the XMP (fx:DocumentType and its companions ConformanceLevel, DocumentFileName, Version).
Typical case: an invoice “flattened” or reconverted downstream by a generic tool — the conversion produced a standard PDF, and the PDF/A-3 character is lost.
2. The XML is absent, misnamed or misdeclared
The XML must be attached under a recognized name: factur-x.xml (the most common), zugferd-invoice.xml or xrechnung.xml for the German flavors. A file attached as facture.xml or data.xml is not a Factur-X — the platform simply finds no electronic invoice in your PDF.
Two more traps on this layer:
- AFRelationship: the attachment must be declared in relation to the document —
Alternativeis the expected value for Factur-X (Datais tolerated). A missing or incorrect relationship causes rejections at the PA even though the XML is perfectly present. - Corrupted XML: the file is there but doesn’t parse — truncated export, broken encoding. Nothing left to diagnose: it must be regenerated.
You can check the XML’s presence by hand with Unpack attachments, or automatically with the Factur-X Diagnosis.
3. The XML structure is incomplete
A Factur-X’s XML is a CII invoice (CrossIndustryInvoice). Three sections are indispensable: ExchangedDocumentContext (whose URN declares the profile), ExchangedDocument (number, date) and SupplyChainTradeTransaction (seller, buyer, lines, totals). A monetary summation (SpecifiedTradeSettlementHeaderMonetarySummation) must also be present.
The standard’s minimum mentions also fall on this layer: invoice number (BR-1, BT-1), issue date (BR-2, BT-2), seller name (BR-11, BT-27), buyer name (BR-17, BT-44).
4. The totals don’t add up (BR-CO-* rules)
The EN 16931 arithmetic rules are a major rejection cause: they verify that the XML is consistent with itself. The main ones:
| Rule | What must hold |
|---|---|
| BR-CO-10 | The sum of line amounts equals the line total (BT-106) |
| BR-CO-13 | Net total (BT-109) = lines − allowances + charges |
| BR-CO-14 | VAT total (BT-110) = sum of VAT per rate (BT-117) |
| BR-CO-15 | Gross total (BT-112) = net total + VAT |
| BR-CO-16 | Amount due (BT-115) = gross − prepayments + rounding |
Comparisons tolerate a half-cent discrepancy (intermediate roundings exist). Add the BR-DEC precision rules: invoice amounts fit on 2 decimals maximum, unit price on 4. Finally, BR-16 requires at least one invoice line as soon as the profile exceeds MINIMUM — a “lineless” BASIC Factur-X that declares itself plain BASIC will be rejected.
5. The French identifiers are malformed
The France-specific layer: the SIREN (scheme 0002) must hold 9 digits, the SIRET (scheme 0009) 14 digits, on the seller side (BT-30) as on the buyer side (BT-47). An identifier declared with the wrong scheme or an incorrect length is flagged.
Note: platforms often verify beyond the format — active SIREN in the directory, known recipient. A well-formed but struck-off SIREN can therefore pass the file diagnosis and fail at transmission.
Diagnosing the rejected invoice, in practice
The Factur-X Diagnosis tool applies this entire cascade inside your browser — the file never leaves your device, which matters for a document containing your amounts, your clients and sometimes your bank details.
- Drop the rejected PDF (one file at a time).
- Read the per-layer report: each layer is compliant, in discrepancy, blocking (fatal) or not evaluated.
- A blocking layer short-circuits the next ones — no point hunting a BR-CO error if the XML is absent: fix the fatal layer first, then rerun.
- For covered discrepancies, the report states the exact rule (BR-CO-10, FX-EMBEDDED-AFREL…) and a correction lead.
The diagnosis covers the tested core (version 1.3.16 of the validation artefacts, code lists as of May 15, 2026). It is a first-intent diagnosis: it does not replay the full official Schematron rules — for exhaustive validation, the FNFE-MPE validator remains the reference.
Fix or regenerate?
The question differs depending on the faulty layer:
- Regenerate if the XML is absent, corrupted, structurally incomplete, or if the declared amounts are wrong. The business data (totals, lines, identities) belongs to your invoicing software or your platform: no PDF tool can invent it cleanly. Check the export settings — chosen Factur-X profile, mandatory mentions filled in — then re-export.
- The container layer is the only domain where a file-level fix is conceivable (missing OutputIntent, misdeclared AFRelationship). In practice, the clean fix still belongs to the generator: “repairing” a container by hand without mastering the PDF/A-3 specs often produces a new rejection. And a useful reminder: converting a PDF to PDF/A is not enough — Document Flare’s PDF/A conversion produces best-effort 1b profile, not the PDF/A-3 + XML + XMP bundle that makes a Factur-X.
- If the diagnosis comes back clean but the platform still rejects: the cause is on the transmission side (inactive SIREN, directory, flow configuration). The PA’s rejection message and its support become your best lead.
A time-saving habit: keep the exact rejection message. “Invoice non-compliant” and “BR-CO-10” don’t dig the same way — the second takes you straight to layer 4.
In short
An electronic-invoice rejection is diagnosed by going down the layers: PDF/A-3, embedded and properly declared XML, complete CII structure, EN 16931 arithmetic, French identifiers. Most rejections originate on the first two layers — invisible in the PDF, detectable in seconds locally. Diagnose first, regenerate from the issuing software second: that’s where the data lives, and that’s where it gets fixed. For MINIMUM and BASIC profiles rejected while the file “passes” validators, that’s a different problem — see which Factur-X profile to choose.
