A French supplier sends what looks like the same invoice it sent in August. Same layout, same logo, and near the payment terms a QR code pointing at a payment page. Since September that file also carries an XML document inside it, and the XML is the part the customer's accounting software reads. The code is not in it, and it never will be.
That single fact decides where a code belongs on a French invoice and what you can reasonably ask it to do.
The reform, in the shape that matters here
France has moved business-to-business invoicing onto structured data exchanged through accredited intermediaries. Two dates carry the change. Since 1 September 2026, every company subject to VAT in France must be able to receive a structured electronic invoice, and large companies and ETI must issue theirs that way. From 1 September 2027 the issuing obligation reaches PME, TPE and micro-entreprises.
The exchange does not happen by email. It happens through a plateforme agréée, the term the tax administration now uses for the accredited platforms previously called PDP, registered by the State and listed on impots.gouv.fr. Three structured formats are in scope: Factur-X, UBL and CII. Platforms convert between them, which is why your customer can receive an invoice in a format you never produce.
What this does to the PDF you have been sending for years is subtle. The PDF does not disappear. It stops being the invoice.
Factur-X is a PDF with the invoice hidden inside it
Factur-X is the format most French small suppliers will meet, because it looks like what they already send. A Factur-X file is a PDF/A-3 document with an XML file attached inside the container, always named factur-x.xml. The page is the human-readable invoice. The XML carries the same invoice as data, in CII syntax, following the semantics of the European standard EN 16931.
It is a Franco-German artefact. FNFE-MPE publishes it in France, FeRD publishes the technically identical ZUGFeRD in Germany, and one file satisfies both. It comes in profiles of increasing richness, from MINIMUM up to EXTENDED, with the EN 16931 profile, often called COMFORT, mapping exactly onto the European standard.
The point for anyone laying out an invoice: two representations of one document travel together, and the issuer is responsible for their consistency. Everything present in the XML has to be present and consistent in the readable page. Where amounts or tax data disagree, the structured data is what automated processing acts on.
The code is in the picture, and the picture is not the data
A QR code you place on the page is a graphic sitting in the PDF layer. Nothing in the XML describes it, refers to it, or knows it exists. Your customer's software imports the XML, posts the invoice, queues the payment, and never renders the page. Whatever the code says reaches exactly one audience: a person who opens the PDF and holds a phone up to a screen.
That is not a reason to leave it off. It is a reason to be honest about the job. Payment instructions already have fields of their own in the structured data: the account to be paid, the due date, the reference to quote. Those fields are what a payment run reads. A code that repeats them is a convenience for a human. A code that contradicts them is a consistency problem you created yourself, on a document you have to keep for six years under article L. 102 B du livre des procédures fiscales and ten years under article L. 123-22 du code de commerce.
Four mentions the reform added
Worth handling while the template is open, because the readable page has to show them too:
- The customer's SIREN, for domestic business-to-business invoicing between taxable persons established in France.
- The delivery address, when the place the goods go is not the billing address.
- The nature of the operation: supply of goods, provision of services, or both.
- The option for paying VAT on debits, where a service provider has taken it, on every invoice issued.
These sit on top of the mentions a French invoice already carried. The sanction for a missing or inaccurate mention is the fine under article 1737 du code général des impôts, assessed per mention and capped as a proportion of the invoice. Nobody has ever been fined for an absent QR code. Getting one of these wrong is the expensive mistake, and it is the one worth your attention first.
So what should the code actually do?
Jobs that suit the readable layer, roughly in order of how often they earn their place:
- Open the customer portal entry for this invoice. One scan, the document, its status, its history, the person who owns it.
- Open a payment page. Useful where you accept card or a hosted transfer, which is a different mechanism from a transfer initiated inside the customer's own banking app.
- Open the dispute or contact route. On a contested invoice, the most-photographed area is the one that says who to call.
- Open the delivery note or the timesheet behind the line items. A link to the supporting document replaces three emails with a scan.
What does not suit it: anything the XML already carries and the payment run will already act on.
The European payment code, and why France is not Switzerland
There is a standard for putting a transfer in a code. The European Payments Council publishes EPC069-12, which defines the payload: a service tag, a version, the beneficiary name, the IBAN, an amount in euro, and a remittance reference. Scanned in a banking app that implements it, the transfer screen arrives pre-filled.
Adoption is the catch, and it is geographic. The countries where this is ordinary are concentrated in the German-speaking area, the Benelux, the Nordics and the Baltics, where banking apps have carried the feature for years and invoices are laid out expecting it to be used. French banking apps have not generalised it in the same way. Our piece on the EPC code and the German Girocode covers what the payload holds. Before you print one on a French template, open your own bank's app, then ask your three largest customers to try theirs. If the scan does nothing, the code is decoration that generates calls to your accounts department.
Practical rules for the code itself
An invoice is an archived document, so treat the code as one that will be scanned long after you have forgotten it exists.
- Make it editable. A destination you can repoint survives a portal migration. A URL hard-coded into a PDF from 2026 does not, and that PDF is still in your customer's archive in 2032.
- Print the destination as text beside it. One line, and it is the only version that works when the code fails or the reader refuses.
- Do not shrink it to fit. Invoices get printed, photocopied and scanned back in at poor quality. Size it for the scan distance and keep the quiet zone clear of the table rule you were tempted to tuck it against.
- Validate the file afterwards. Adding a graphic to a PDF/A-3 container can break the conformance your platform expects. Run the result through a validator rather than trusting the export.
The division of labour is the whole idea. The XML is addressed to a machine that will never look at your page. The code is addressed to a person who will never open your XML. Write each one for its own reader.
