E-invoicing, and what gets an invoice rejected
An electronic invoice is not an invoice in PDF form. It is a PDF that carries its invoice, as XML, in a format your customer's machine reads and refuses at the slightest deviation. Here is what the standard demands, and how to check a file without sending your billing to anyone.
The European standard, and the French deadline
EN 16931 is the European semantic standard for electronic invoicing. It defines what an invoice must carry (around a hundred and fifty business terms, numbered BT-1 to BT-165), and a set of business rules that a receiving system checks automatically.
From 1 September 2026, every French company must be able to receive an electronic invoice. Issuing follows by size: large and mid-cap companies in September 2026, small businesses and micro-enterprises in September 2027. Germany started earlier, with the same format under the name ZUGFeRD.
What changes for the sender is that a machine reads the invoice before a human does. A rejected invoice does not exist in the recipient's accounts, and the payment clock does not start.
What a Factur-X file is, in one minute
A Factur-X file is a PDF/A-3 (an archival PDF, readable by any viewer), carrying as an attachment an XML file structured according to the UN/CEFACT CII syntax. The human reads the PDF, the machine reads the XML, and the two are supposed to say the same thing.
The format is co-published by the French FNFE-MPE and the German FeRD: Factur-X and ZUGFeRD are technically the same format under two names. A valid German invoice is valid in France, and the other way round.
The standard allows a second syntax. EN 16931 permits the same content in UBL (OASIS): that is the form of Peppol BIS Billing 3.0 and of the German XRechnung, and it usually travels as a bare XML file, with no PDF around it, since the human-readable PDF is optional in the standard. Our validator reads both syntaxes, and an XML file dropped without a PDF is read as it is.
That dual nature explains most rejections: a document can be a perfect PDF with a wrong XML, a perfect XML inside a badly built PDF, or both correct but contradicting each other.
Why an invoice is rejected: four layers
The container. Is the PDF a genuine PDF/A-3? Are the fonts embedded, the output intent present, the document unencrypted? This is the most frequent technical error, and it has nothing to do with accounting.
The attachment. Is the XML there, is it named factur-x.xml, is it declared as another form of the document (/AFRelationship /Alternative) rather than an annex? A perfect XML filed under the wrong name will not be read.
The grammar. Does the XML follow the CII syntax: the right elements, in the right order, with the right cardinalities?
The business rules. This is the layer that rejects most: the total with VAT must equal the total without VAT plus the VAT, the VAT total must match the breakdown, an exemption must state its reason. These rules carry codes (BR-CO-15, BR-E-10), and those are what your customer's portal will send back to you.
The profile trap
Factur-X has five profiles: MINIMUM, BASIC WL, BASIC, EN 16931 and EXTENDED. They do not carry the same content, and that is where it goes wrong.
MINIMUM and BASIC WL are genuine Factur-X profiles that are not EN 16931 compliant: they carry no invoice lines at all. They are accounting headers, meant for posting, and many packages produce them by default.
The profile is declared inside the XML, and that value is what the compliance checks look at. An invoice that contains lines but declares MINIMUM will be judged on what it declares.
Checking without sending the invoice
Online validators exist and they work. They all ask you to upload the invoice, which carries an IBAN, a turnover figure, a customer's identity, sometimes a negotiated discount.
Here nothing leaves. The file is read by your browser, on your machine, and the page's content security policy forbids any outgoing connection: connect-src 'self'. Your browser applies that rule, and you can check it yourself in thirty seconds.
As many invoices as you like. There is no server to pay for, so no per-document pricing, no account to create, no volume limit. An accounting firm can run its entire client portfolio through it without a single file leaving the office.
What this tool does not do
We are not an accredited transmission platform. We send nothing to any tax authority, to Chorus Pro, or to your customer: we read a file and tell you what is wrong with it.
We issue no compliance certificate, and the report never says "compliant invoice". It says "no error detected across the N rules tested", N being the number of checks actually run, because that is what is true.
PDF/A conformance is not checked exhaustively. The industry reference, veraPDF, has no equivalent that runs in a browser: we test the fifteen or so conditions that cause the vast majority of real rejections, and we call that a pre-flight check.
We do not fix your invoice. The tool tells you which field, which line, which expected value: the fix belongs in the software that produced the file.