Disclaimer

Not official, not approved, not affiliated

eDocument Tools is an independent project. It is not operated by, endorsed by, certified by or affiliated with any tax administration, any standards body, or any approved platform. In particular it has no connection with the DGFiP, the AIFE, the FNFE-MPE, OASIS, UN/CEFACT, CEN or FeRD, and it is not a plateforme de dématérialisation partenaire or any equivalent under any national scheme.

What it does is execute validation artefacts those organisations publish, unmodified, in your browser. That is a useful thing and a narrow one, and the difference matters.

A clean result is not compliance

A validator sees one file. An e-invoicing mandate governs a process, and most of that process leaves no trace in the file:

• Transmission. Whether the invoice was sent through an approved platform, and accepted by it.
• Lifecycle. The statuses that must be returned and recorded after an invoice is issued.
• Reporting. Transaction and payment reporting, where it applies to you.
• Retention. Keeping the original electronic document for the statutory period.
• Substance. Whether the amounts, the tax treatment and the parties are correct. A syntactically perfect invoice can be wrong in every way that matters.

The France page sets this out concretely for the French reform, including which document families exist and which of them this site touches.

What is not checked

Where a check is not performed, the result says so rather than staying silent. The significant cases:

• PDF/A-3 conformance. The Factur-X validator and the viewer read the PDF container and report what it declares, but neither checks it against PDF/A-3. That requires a conformance checker this project does not ship. A file can pass every business rule here and be rejected elsewhere for a container defect.
• The UN/CEFACT release of a CII document. Every release shares one namespace, so a CII file does not record which one it was built against. Where D22B rules run, they run because a validation target requiring D22B was selected — not because the document proved anything.
• Digital signatures and seals. Not verified, in any format.
• Profiles with no rule package. Factur-X MINIMUM and BASIC are defined by the specification but ship no executable rules in the pinned release, so they are not offered as validation targets.

Rule versions move

Every result names the exact artefact versions that produced it. Those versions are pinned and checksummed, and they are updated when their issuers publish new ones. An update can change what this site reports about a document that has not changed — that is the rule set correcting itself, and it is why the version is printed rather than assumed.

This is not an archive

Nothing you open in the browser tools is stored: no database, no object storage and no record of your document after the tab is closed. A document sent to the Validation API is held in memory for that request and is not stored either. Using this site does not satisfy any retention obligation and does not constitute archiving of any kind. Keep your own originals.

Reference material

The standards pages explain formats and rules as this project understands them, and link to the primary sources. They are technical writing, not legal or tax advice, and they are not a substitute for the specifications themselves or for professional advice about your obligations.

When this page is wrong

A disclaimer is a statement about limits, not a shield for defects. If a tool here reports something incorrect about a document — a rule that should have fired and did not, a finding attributed to the wrong identifier, a claim on a result page that overstates what was checked — that is a bug. Saying so — through the contact form, with the rule identifier and what you expected — is more useful to this project than anything on this page.

Nothing on this page limits that. A disclaimer explains what a result does not prove; it is not a reason to leave a wrong result standing.