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 can read, and refuses at the slightest deviation. Here is what the standard demands, and how to check it 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 not the gesture (you still press "send") but the fact that a machine reads the invoice before a human does. A rejected invoice is not a late invoice: it 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.
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 nobody states loudly enough
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. Many packages produce them by default, and their users believe they are issuing compliant e-invoices until the first rejection.
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.
Why check here rather than somewhere else
Online validators exist and they work. They all share one flaw: you have to upload the invoice. And an invoice carries an IBAN, a turnover figure, a customer's identity, sometimes a negotiated discount no competitor should ever see.
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'. That is not a promise, it is a rule enforced by your browser, and you can check it yourself in thirty seconds.
One direct consequence: 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, and that is the only place it will stick.