EU e-invoicing for PrestaShop stores: what to change

I wrote this while preparing the invoicing module of Vlnkovo, a PrestaShop 9 store in Slovakia, for the Slovak mandate that starts on 1 January 2027. Most of what I ran into is not Slovak at all: it is the same EN 16931 standard, the same Peppol rules and the same gaps in PrestaShop that stores in Belgium, Germany or Croatia are hitting right now. The dates below were checked on 24 September 2026. Several countries have moved their dates more than once, so check again before you plan around them.

Where each country stands

These are domestic mandates: they apply when a business established or VAT-registered in that country sells to a business in the same country. Sales to other EU countries are a separate step, covered by the EU’s ViDA package from 2030.

Country	Who must issue e-invoices	Consumers (B2C)	Channel and format
Italy	Everyone, since 2019	Yes, if an invoice is issued	SdI clearance platform, FatturaPA XML
Belgium	All VAT-registered businesses, since 1 January 2026	No	Peppol, Peppol BIS 3.0
Croatia	VAT payers since 1 January 2026, others from 1 January 2027	No e-invoice, but every retail sale is fiscalised in real time	Fiskalizacija 2.0, UBL 2.1 with Croatian rules
Poland	Largest companies since 1 February 2026, most since 1 April 2026, the smallest from 1 January 2027	Optional	KSeF clearance platform, FA(3) XML
France	Large and mid-size companies since 1 September 2026, SMEs from 1 September 2027. Everyone must receive since 1 September 2026	No e-invoice, but B2C sales are e-reported	Accredited platforms, Factur-X, UBL or CII
Germany	Everyone must receive since 1 January 2025. Issue: turnover over €800k from 1 January 2027, everyone from 1 January 2028	No. Invoices up to €250 are also exempt	No mandated network; XRechnung or ZUGFeRD
Slovakia	VAT payers from 1 January 2027	No	Peppol, EN 16931 UBL
Romania	Everyone, B2B since 2024	Required since 2025; a 2026 law may have narrowed this, sources disagree	RO e-Factura clearance platform
Spain	Planned: companies over €8m about a year after the implementing order, everyone else a year later	No	The implementing order is still a draft
Netherlands	Planned for 1 July 2030	No	Not law yet

Two dates matter everywhere. From 1 July 2030, ViDA makes e-invoicing and near real-time reporting mandatory for B2B sales between EU countries, with EN 16931 as the default standard. And in every country above, you have to be able to receive e-invoices from your own suppliers, usually earlier than you have to send them.

Does it apply to your store?

Almost always only for the orders where the buyer is a business. Three questions:

Is your business established or VAT-registered in a country with a mandate in force?
Does the order come from a business in the same country? A company, and in several countries also a sole trader or a business that is not VAT-registered. In Slovakia, for example, a sole trader outside the VAT system still gets an e-invoice.
Is it a consumer order? Then, in most countries, nothing changes. The exceptions are Italy (every invoice goes through SdI, including one a consumer asks for), France (B2C sales are reported, not e-invoiced) and Croatia (real-time fiscalisation of retail sales, including card and PayPal payments).

If you answered yes to the first two, the next section is about you.

Where PrestaShop trips up

None of this is covered by a guide that lists deadlines. It is what you find when you build the XML and run it through the official validation rules.

Telling business orders apart

PrestaShop’s address form has a company field and a VAT number, and that’s it. The mandates need more:

The right identifier for the buyer’s country. In Slovakia the Peppol ID is the tax number, written as 0245:DIČ. Without it you cannot address the invoice at all. France uses the SIREN number, Poland the NIP, Italy the Partita IVA or a recipient code. None of them is the VAT number the checkout usually asks for.
Businesses without a VAT number. If your store treats an order as B2B only when a VAT number is filled in, sole traders slip through as consumers.

In practice the checkout needs a “buying as a business” switch with the identifier fields your market requires, and those values have to be saved on the invoice, not only on the address.

One cent of VAT

PrestaShop calculates VAT line by line and adds it up. EN 16931 checks the VAT per rate, on the total taxable amount for that rate, rounded once (business rule BR-CO-17). The two methods can differ by a cent, and a cent is enough to fail validation. A Belgian merchant reported exactly this on PrestaShop’s GitHub in October 2025: €226.30 by Peppol’s method, €226.31 in PrestaShop.

Discounts across VAT rates

A cart rule of “€10 off the whole order” on a basket with products at two VAT rates has to be split between the rates, and the split has to add up exactly in the XML. On a PDF nobody notices. In the XML it has to be correct to the cent, and it is the hardest part of the job. In Vlnkovo it is the one case that is still being reconciled before go-live.

VAT categories PrestaShop does not know about

Every line needs an EN 16931 VAT category: S for a standard rate, Z for zero-rated, AE for reverse charge, O when the seller is not VAT-registered. PrestaShop stores a tax rule, not a category. The mapping has to be written, and reverse charge has to be detected from the order.

Units of measure

Every invoice line needs a unit code from the UN/ECE list. “pcs” or “ks” is not valid; a piece is C62. A store that sells by the metre, the kilogram or the pack needs a mapping per product.

Corrections are credit notes

A sent e-invoice cannot be edited. A mistake or a returned order means a credit note (CreditNote in UBL) that points back to the original invoice. The returns flow has to produce one in the same format.

Validation needs a separate tool

The official EN 16931 and Peppol validation rules are published as Schematron compiled to XSLT 2.0. PHP’s built-in XSLT processor only handles XSLT 1.0, so it cannot run them. You need a separate validator such as Saxon, or an e-invoicing provider that validates for you, but checking before sending saves a rejected invoice later.

Three ways to do it

Your accounting or invoicing software issues the invoices. The store sends orders across and the software creates the e-invoice. Ask your vendor which countries and channels they support, and make sure the buyer’s identifier actually arrives from the store.
An e-invoicing provider behind the store. A Peppol access point or a platform connected to KSeF, SdI or the French platforms takes invoice data from PrestaShop and handles the format, the delivery and the reporting. Good when you sell into several countries.
The store issues the invoices itself. This is what Vlnkovo does. You own the XML, and the provider only delivers it. More work up front, full control afterwards.

Peppol countries (Belgium, Slovakia, and Croatia with its own rules) and clearance countries (Italy, Poland, France) do not use the same transport. The core is shared, though: build the invoice once in EN 16931 terms, then convert and send it per channel.

How I built it into a store

The Vlnkovo module takes the third route:

The XML is built from the saved invoice, not from the order. When the invoice is issued it is stored as a fixed record, and both the PDF and the XML are generated from it. If the XML were built from the order, a later edit to the order would make the two disagree.
Only for business orders. Consumer invoices stay PDF only. An order counts as a business order when the customer ticks “buying as a business” and fills in any of the identifiers, so sole traders outside the VAT system are included.
The Peppol ID comes from the tax number, as 0245:DIČ. If it is missing, the invoice is marked as unaddressable and cannot be sent, instead of quietly falling back to the VAT number.
Invoices and credit notes. A UBL Invoice and a CreditNote that points to the original invoice.
The VAT summary comes from PrestaShop’s per-rate totals, with discounts already allocated, and each line gets its EN 16931 category.
Validation before sending. The module is built to run the official rules through Saxon and to show each failed rule in the admin by its number, in plain words. Bundling the rule files is the next step before go-live.
Delivery is behind an interface. The provider can be changed without touching the invoices. Today it is a placeholder that stores the XML; the real access point is next, while Slovakia’s voluntary period still runs.

A checklist for this year

Find out where your invoices are created: in the store, in accounting software, or by hand.
Check every country you invoice businesses in against the table above, and look at the receiving deadline, not just the sending one.
Add the business identifiers to checkout that your markets need, and save them on the invoice.
Map VAT categories and units of measure for your catalogue.
Test with the official validation rules before the first real invoice. Rounding and multi-rate discounts are where it will fail.
Have your accountant or tax adviser confirm the setup. This is an engineer’s view from a real implementation, not tax advice.

If you run a PrestaShop store and are not sure which of the three routes suits you, send me the store’s address. I will tell you what I would change first.

EU e-invoicing mandates: what a PrestaShop store has to change