Skip to content

How to validate a Factur-X invoice before sending it

Four checks, in the order problems show up: the PDF container, the embedded XML, the declared profile, then the EN 16931 and French business rules.

Published 26 September 2026 · reviewed 26 September 2026

The short answer: open the invoice in a validator that reads the XML inside the PDF and evaluates it against the official rules for the declared profile — for example the Factur-X validator, which runs in your browser without sending the file. For the French reform, add the France validator and its BR-FR rules. The rest of this page explains what is checked and how to fix the common failures.

What a Factur-X is, in one sentence

A human-readable PDF/A-3 that embeds a CII XML file named factur-x.xml for machines. The current release is Factur-X 1.09.2 (equivalent to ZUGFeRD 2.5.2), published on 4 August 2026 by FNFE-MPE and FeRD. The profiles are explained on our Factur-X reference page.

1. The PDF container

  • The PDF carries a factur-x.xml attachment, declared as associated.
  • The XMP metadata declares the profile (fx:ConformanceLevel) and the embedded file name.
  • The file is a conforming PDF/A-3. eDocument Tools does not check PDF/A-3 conformance, and the result says so: for that, use a dedicated PDF/A validator such as the open-source veraPDF.

2. The embedded XML

The XML must be well-formed and valid against the profile's XSD schema. A failure here — an unexpected element, a malformed date — often prevents every later check. CII writes dates as YYYYMMDD with format="102": a date written 2026-09-01 is a schema error.

3. The declared profile

The profile appears twice: in the PDF's XMP metadata and in the XML (GuidelineSpecifiedDocumentContextParameter). They must agree. For a complete electronic invoice aim for EN 16931 or EXTENDED: MINIMUM and BASIC WL carry only header and footer data, with no lines.

4. The business rules

Beyond the schema, EN 16931 imposes consistency rules (BR-… identifiers), and the French reform adds its own (BR-FR-…, the EXTENDED-CTC-FR profile). The ones that fail most often:

RuleWhat it checksUsual cause
BR-CO-10Sum of invoice line net amounts (BT-106) equals the sum of the lines (BT-131)Lines rounded after the total was computed: round each line, then add them up
BR-CO-15Total with VAT (BT-112) = total without VAT (BT-109) + total VAT (BT-110)VAT computed differently for the PDF and for the XML
BR-CO-16Amount due (BT-115) = total with VAT (BT-112) − paid (BT-113) + rounding (BT-114)A prepayment deducted in the PDF but missing from the XML
BR-S-02A standard-rated line requires a seller VAT identifierSeller's intra-EU VAT number missing

A useful validator tells you which rule failed and where in the document — which is what the eDocument Tools validators do, with the official rule packages pinned.

The standard is moving

A new edition, EN 16931-1:2026, has replaced EN 16931-1:2017; the old one remains usable during a migration period. If your software or platform announces a move to the new edition, revalidate a few real invoices at that point.

Automating the checks

To validate invoices from software rather than by hand, a Validation API is in private beta; self-service sign-up is not open yet.

Sources

Frequently asked questions

Does passing an online validator make my invoice compliant?

No. A validator checks the file’s structure and business rules; it replaces neither your approved platform, which runs its own checks, nor a review of the content itself (prices, applicable VAT, mentions specific to your business).

Why does my Factur-X look fine but fail validation?

Because what you see is the PDF, and what is checked is the XML inside it. Your software produces the two separately: a total that is right in the PDF can be wrong, or rounded differently, in the XML.

Do I have to upload my invoice to validate it?

Not here: the eDocument Tools Factur-X validator runs in your browser and does not send the file. You can confirm it in the network tab of your browser’s developer tools.