Sylius PDF invoice: what the order plugin really does
Sylius handles PDF invoices through an official plugin, sylius/invoicing-plugin, which creates an immutable invoice when an order reaches a configured state and lets admins and customers download it. That covers a classic order invoice, and it does not by itself make you compliant with French e-invoicing, because a plain PDF is not a structured electronic invoice. Before you build anything, you need to separate those two needs.
I am an independent Sylius developer and I sell this kind of integration, so keep that interest in mind. Every fact below links to its source, and I checked them on 1 November 2026.
What the Sylius documentation says about the invoice plugin
The plugin's README describes a short scope: it creates an invoice once the order is in a given state, with "created" as the default, the invoice cannot change afterwards, and both customers and administrators can download the invoices linked to an order. Packagist lists version 2.3.0, released on 8 October 2026, under the MIT licence, requiring PHP 8.2 or later and Sylius 2.0 or later.
Immutability matters more than it looks. The official documentation ties stored, unchanged invoices to compliance and audit needs, so an error on an order is not repaired by regenerating the file. Your team needs a process for corrections before the first real invoice goes out, not after your accountant finds a problem.
On the back office side, the admin guide places invoices in a grid, usually under Sales, then Invoices, from which they can be downloaded. Note also that the README states the plugin requires telemetry collection when used with Sylius, which your data protection contact may want to read about in the repository's policy.
Generating the PDF invoice: the part that touches your server
The documentation names wkhtmltopdf as the engine behind the PDF files, and it exposes a pdf_generator setting that can switch PDF output off. This is where a simple feature turns into a hosting question. The wkhtmltopdf repository was archived by its owner on 2 January 2023 and is now read-only. It can still run, but you are depending on software that no longer receives upstream development, so you should ask how it gets installed on your production server and what happens at your next system upgrade.
Test this early on an environment that matches production. Check the fonts, your logo, accented characters and long product names, then read a sample invoice with whoever keeps your books. Legal mentions are your responsibility and your accountant's: the plugin gives you a mechanism, not tax advice.
Credit memos are a separate plugin
A refund is the classic gap. The refund plugin (version 2.2.1 on Packagist, published on 6 October 2026) is where credit memos live. Its documentation explains that each refund produces a credit memo, and that delivery is left to your project: it may go out by email or be downloadable from the customer account, but a shop page for it does not appear by itself. If you promised customers they could download their credit notes, someone has to build that page.
| Need | Where it lives | What you still have to do |
|---|---|---|
| Invoice on each order | Official invoicing plugin | Choose the trigger state, adapt the template, have the mentions reviewed |
| PDF file | Same plugin, through wkhtmltopdf | Install and test the binary on your server, plan its long term replacement |
| Credit memo | Official refund plugin | Decide how the customer receives it, build the shop page if needed |
| Structured e-invoice in France | Not in the official plugin, as far as I could verify | Add a format layer and connect to an approved platform |
Why a PDF invoice is no longer the whole answer in France
The French authorities state that the reform has been in effect since 1 September 2026. According to Service Public, all companies must be able to receive electronic invoices since that date, large and mid-sized companies must also issue them, and small businesses and micro-enterprises must issue them from 1 September 2027. E-reporting follows the same calendar, and invoices go through a platform approved by the State.
The format is the trap. Pennylane's guide (a software vendor, but clear on this point) lists Factur-X, UBL and CII as the base formats, and answers plainly that a manually created PDF does not qualify, because its data cannot be processed automatically. Factur-X looks like a PDF to a human reader and also carries a structured XML file.
I found no official Sylius Factur-X plugin. I did find a third party package, tmonier/sylius-facturx-plugin, which says it turns the official plugin's PDFs into Factur-X files using the EN 16931 profile, for Sylius 2.2 and 2.3. I have not audited it and I found no sign of endorsement by Sylius, so treat it as a lead to evaluate. I also wrote about the wider question in this technical guide to the 2026 reform.
When the official plugin is not the right choice
If your invoices already come from an accounting system or an ERP, generating a second set in Sylius creates two sources of truth and two numbering sequences to reconcile. In that case the shop should send order data to the system that issues invoices, and your approved platform or accounting vendor may be better placed than a developer to handle compliance. A shop with very low volume may also find that a ready made invoicing tool costs less than custom work.
Questions worth putting to any provider: which system numbers the invoice, which order state triggers it, how a correction is issued, how your supplier invoices will be received, and who is responsible when the platform rejects a file.
A simple next step
Start with an inventory: your Sylius version, whether the plugin is installed, where invoices are stored, and which platform you designated for the reform. With that list, the remaining work is usually easy to scope. If you want a second opinion, I can look at it with you: see my e-invoicing integration service or my Sylius developer page. You will speak directly with the person who writes the code.