attestwireE-invoicing in France: what Attestwire supports
the data inside the PDF. Not the PDF, the post or the paperwork.
You invoice French customers, or you are about to, and you need to know whether Attestwire covers the French requirements. The short answer: we create and check the invoice data inside a Factur-X file (a PDF invoice with the XML invoice attached inside it), the hosted API builds that PDF itself on every plan (watermarked as a preview on the free one), and we do not deliver the invoice through the French reform or file anything with the tax authority. This page says where each of those lines sits, so you can match it against what your customers and your platform ask for.
Two names come up on every French page and are worth knowing before you read on. The DGFiP is the French tax authority, which publishes the specifications for electronic invoicing. Flux 1 is one of its specifications: the data extract a business reports to the tax authority, which is a different document from the invoice you send a customer. Attestwire works on the invoice, not on the extract.
Key dates
1 September 2026. Every VAT-registered business established in France must be able to receive e-invoices, whatever its size. Issuing phases in from the same date for large and mid-size firms, 2027 for the rest. A business with only a French VAT number and no French establishment is outside the receiving obligation.
The DGFiP specifications used below are version 3.2.
What we cover
- Factur-X EN 16931, the CII XML payload. EN 16931 is the European standard that says what an electronic invoice must contain, and CII is the XML file format used inside a Factur-X PDF. We generate that XML, read it, and validate it against the core EN 16931 rule set.
- Peppol BIS Billing 3.0 base rules. Peppol is the network many European buyers receive invoices through, with its own rule set, and that layer is what French flows share with the rest of Europe.
- Teaching errors in French flows, the same as in German ones: the rule name, the field concerned, what the regulation requires, and what to change.
Factur-X: XML and PDF are separate steps
Factur-X is CII XML inside a PDF/A-3 container. The library writes the XML and does not build the container; the hosted API builds it on every plan, watermarked as a preview on the free one and, on the Solo, Starter, and Scale plans, without it.
Generation returns the CII payload, not a finished Factur-X file. Use a
PDF/A-3 library to attach the XML and set the required PDF metadata, or
call
POST /v1/generate?format=pdf with
facturx-en16931, which returns the Factur-X / ZUGFeRD PDF
(EN 16931 profile) on every plan, watermarked as a preview on the free
plan and, on the Solo, Starter, and Scale plans, without it.
To read an existing file,
extractFacturX(bytes) opens a Factur-X or ZUGFeRD PDF and
returns its CII XML attachment. This function is in the MIT package.
The hosted API reads the PDF too, sent as application/pdf,
and checks its container — the attachment, its
/AFRelationship and MIME type, and the XMP metadata — as
findings that never fail the result; PDF/A conformance itself, and
whether the drawn page agrees with the XML, are not checked.
The browser checker accepts XML, not PDF files.
Flux 1 reporting is separate from invoice validation
Flux 1 is the tax-reporting data extract described above, not the invoice sent to a customer. Attestwire does not generate this extract. The recorded test below checks that boundary; it is not a test of complete French invoice acceptance.
On we ran all eleven of our sample invoices against the official Flux 1 schemas, in both of its profiles, and every one of the 22 combinations failed. The record shows that none of the failures was a defective document or a wrong CII version: each invoice was refused because Flux 1 excludes hundreds of fields (518 paths) that a full invoice carries.
That is the expected result for an invoice tested against a reporting schema, and it is why we describe Flux 1 as a separate deliverable rather than something we support.
The record also notes two limits. The run tests XML structure only, because the DGFiP publishes XML Schema and spreadsheets and no Schematron (the official rule files receivers run against the XML) for Flux 1, so there is no French rule name to cite for any failure.
And
the French business rules themselves (122 of them, written as
G1.01-style ids, 42 of which are flagged as applying to
Flux 1) are stated as prose in an annex spreadsheet, and
nothing in this repository implements them.
Read the whole run: commands, checksums, the per-fixture table
What is explicitly out of scope
Attestwire is not an approved platform and does not transmit invoices through the French reform. France routes electronic invoices through approved platforms (PDPs) and the public platform (the PPF), and public bodies receive them through Chorus Pro. Attestwire does not submit to any of those, and it does not provide an access point or AS4, the transport protocol those platforms exchange documents over.
On request it can also e-mail an invoice to one recipient — plain e-mail is not one of the recognised French channels, so this does not satisfy the reform's transmission requirement.
We also cannot confirm a company's approved-platform registration. That information is available only in the DGFiP directory.