Factur-X Validator

A Factur-X file is two documents, and only one of them is validated here

Factur-X wraps a machine-readable invoice inside a PDF a person can read. The wrapper is a PDF/A-3 file with the invoice attached to it; the payload is a UN/CEFACT Cross Industry Invoice. They are governed by different specifications and they fail in different ways, so a tool that reported a single verdict over both would be hiding the more useful half of the answer.

This page validates the payload. It runs the rules of the Factur-X profile the file declares — the same official packages the France validator uses, because there is only one set of them — and reports each finding with the rule identifier the artefact itself emitted.

It does not validate the wrapper. PDF/A-3 conformance is not checked, and that limitation is printed on every result rather than buried in a footnote. A Factur-X file can satisfy every business rule while failing the container requirements: a missing output intent, an attachment declared with the wrong relationship, a font that was never embedded. Those are real rejection causes and this tool cannot see any of them.

What it tells you about the container anyway

Not conformance — but plenty that is worth knowing, and that no rule engine will tell you. The page opens with the structural facts: how many pages, how large, which PDF version, how many embedded files. Then the attachments, each with its filename, its type as detected from its bytes rather than its extension, and its size, with the one that was actually parsed as the invoice marked as such.

Then the metadata. A Factur-X PDF carries an XMP block declaring its document type, the filename of the attached XML, the Factur-X version and the conformance level — the profile. All four are shown as the file states them. Any PDF/A claim in that metadata is shown too, described as a claim, because that is what it is: something the file says about itself, not something anyone verified.

Finally, the evidence. This tool does not assume a PDF is Factur-X because an attachment is called factur-x.xml. It lists what it found — a filename the specifications define, an attachment whose content parses as a Cross Industry Invoice, metadata that agrees with the attachment — and states a confidence level. A file that only half fits is described as half fitting.

When the file contradicts itself

The container and the invoice each name a profile, independently, and they can disagree. When that happens both declarations are shown and nothing is validated until you say which one applies. Neither is treated as more authoritative, because neither is: the XMP conformance level is what the producer wrote into the PDF metadata, and the guideline identifier is what the producer wrote into the XML, and a mismatch means one of the two is wrong without saying which.

Choosing for you would produce a page full of findings from rules your document never claimed to follow, which reads exactly like a broken invoice and is not one.

Which page you want

• Factur-X Viewer — to look at the file. It renders the PDF pages, extracts the XML and lays out the invoice data. No rules, no verdict.
• Factur-X Validator — this page. Container inspection, then the profile rules against the embedded invoice.
• France e-invoice validator — when the question is French compliance rather than Factur-X, or when your document is standalone UBL or CII rather than a PDF. It runs the French national rules on top of the profile rules.

What a clean result does not mean

This is an independent tool. It is not an official, government or approved validator, and it has no affiliation with the DGFiP, the AIFE, the FNFE-MPE or FeRD. A clean result means the pinned rule packages found nothing wrong with the embedded invoice, at the versions named on the page — and says nothing about the PDF container, about transmission through an approved platform, or about whether a recipient's system will accept the file.