French e-invoicing: bringing PrestaShop into compliance
PrestaShop's PDF invoice is not an electronic invoice under the French reform. What is really missing from your database, and a step-by-step compliance plan.

Why your current PDF invoice is not enough
If you sell into France, French e-invoicing is the compliance topic to get right, and it rests on a common misunderstanding: "I already issue PDF invoices, so I am ready."
An electronic invoice, as the French reform defines it, is not a PDF. It is a structured, machine-readable document sent through an approved platform. The most widely used format in France, Factur-X, is a PDF/A-3 with a standardised XML file embedded inside it. The PDF stays readable by a human; the XML is what actually counts as the exchanged document.
PrestaShop, meanwhile, generates its invoices through PDF/HTMLTemplateInvoice.php, which produces an ordinary PDF. No standard version of PrestaShop produces Factur-X out of the box.
Two regimes that are easy to confuse
This is the distinction that gets explained worst, and it shapes everything that follows.
B2B sales fall under electronic invoicing proper: the invoice has to travel through an approved platform, which delivers it to the buyer and to the tax authority.
B2C sales fall under e-reporting: you do not send an invoice to a private customer, but you do have to report transaction data to the tax authority at regular intervals.
The overwhelming majority of PrestaShop stores sell B2C, with a larger or smaller share of B2B alongside. In practice that means most merchants have to handle both regimes, through different technical chains.
What is actually missing from your database
Before you pick a tool, take stock of your data. A structured invoice requires fields that PrestaShop does not always collect.
Identifying the business buyer. The SIREN or SIRET number becomes central to routing B2B invoices. PrestaShop stores the intra-EU VAT number (vat_number on both the address and the customer), but not the SIRET. You need to add a field, and above all make it mandatory at checkout for business customers.
A reliable B2B / B2C split. Plenty of stores treat a filled-in company name as proof of a business customer. That is not enough. You need an explicit criterion, usually carried by a dedicated customer group.
Line-by-line VAT detail. The XML requires the VAT rate and amount on every line, plus any exemption wording that applies. Stores using intra-EU reverse charge or shipping outside the EU need to check that the matching legal wording is carried correctly.
Numbering. The invoice sequence has to be continuous, with no gaps. Stores that have migrated, or that use more than one invoicing module, often have broken sequences to fix before anything else.
The technical breaking points
Three configurations reliably block the addition of a connector:
- An override of
HTMLTemplateInvoice. Very common as soon as an agency has customised the invoice. The connector no longer finds the structure it expects. - A third-party invoicing module that replaces native generation entirely. You then have to check whether its vendor plans to support the reform, or change tool.
- Multistore, where several legal entities share one installation. Each entity has to be connected separately.
The compliance plan
- Audit the existing data. How many B2B orders, what proportion of business customers have no VAT number on file, where the invoice sequence breaks.
- Choose the platform. This is as much an accounting decision as a technical one: your accountant and your accounting software need to be in the loop. The PrestaShop connector is chosen afterwards, not the other way round.
- Fill the gaps in data collection. Add the SIRET, firm up the business customer group, check VAT rates line by line.
- Clear out the invoicing overrides that stand in the way of injecting the XML.
- Test against a real set of orders: French B2B, French B2C, intra-EU B2B, sales outside the EU, credit notes and partial refunds. Credit notes are where most implementations come apart.
- Plan the archiving. Structured invoices must be kept and retrievable for the full statutory period.
Getting the timing right
The classic trap is treating this as a module you install the week before the deadline. Fixing data takes far longer than plugging in the technical connector: filling in missing SIRET numbers across an existing customer base means running a contact campaign.
Start with the data audit, even if you have not settled on a platform. That work pays off whichever solution you end up with.
If your store is still running an older version, this is a good moment to deal with the version question too: see our article on the end of support for PrestaShop 8.
Have your invoicing chain audited
We audit your invoicing data, fix the blockers and integrate the connector you have chosen. See our e-commerce store management service.
This article covers the technical implications of the French reform for a PrestaShop store. It is not a substitute for advice from your accountant on your own tax position.
Read next
ps_facetedsearch vulnerability: the PrestaShop update you cannot skip
A flaw scored 10 out of 10 lets an attacker take over a store from a single URL. How to check whether yours is affected, and whether it has already been visited.
Read 30 July 2026Hacked PrestaShop: detecting and removing a card skimmer
A skimmer steals card numbers for weeks without slowing the store down. The signs to look for, the diagnostic commands and the full clean-up procedure.
Read 29 July 2026Update Assistant stuck: repairing a PrestaShop 9 upgrade
Cache that will not clear, a missing Symfony service, a process that stops halfway: the Update Assistant errors we actually see, and how to switch to the CLI.
Read