E-Invoicing in Europe: Which Countries Require It and How to Comply

Here is the part most PrestaShop merchants get wrong: emailing a PDF invoice is not e-invoicing. A PDF — even a tidy, VAT-correct one straight out of your back office — is a picture of an invoice that a human reads. A real electronic invoice is a structured data file (usually XML) that a machine reads, validates, and books straight into accounting software, transmitted through a government-approved channel. The two are not interchangeable, and across Europe the legal definition is hardening around the second one. Italy already enforces it. France, Germany, Poland and Spain have firm dates on the calendar. If you sell B2B into any of those markets, this is a compliance deadline, not a someday-maybe.

This guide owns one specific question: which European countries require e-invoicing, by when, in which format — and what your PrestaShop store has to do to be ready. It is not about laying out your invoice PDF (that's invoice customization in PrestaShop), nor about VAT rates and OSS/IOSS (that's VAT in the EU). It is about the one thing e-invoicing actually demands of you: clean, complete, structured invoice data, and a route to push it through the right pipe.

Digital invoice vs e-invoice — the distinction that decides everything

Get this wrong and every other decision is wrong. The table below is the whole compliance question in miniature.

So what does this mean for your store? PrestaShop, out of the box, produces the left column. Every order generates a PDF via the AdminPdfController and the HTMLTemplateInvoice class (classes/pdf/HTMLTemplateInvoice.php), rendered from the template in pdf/invoice.tpl. That PDF is a perfectly good digital invoice — and in mandate countries it is not, on its own, a compliant electronic one. Closing that gap is the job, and almost all of the work is making sure the data inside the invoice is complete and correct, because the structured format is unforgiving about missing fields.

Country-by-country: who requires it, when, and in what format

Dates and thresholds in this area move — several have already slipped once — so treat the timeline as direction and confirm the exact date for your markets with your accountant before you act. What is not in doubt is the direction: every major EU economy is heading to mandatory structured e-invoicing.

Two patterns are worth pulling out of that table. First, almost every new format is an EN 16931 variant — the EU's common semantic standard — so investment in clean, complete data carries across borders even though the file wrappers differ. Second, reception comes before issuance in most rollouts: the first deadline that hits you is usually the obligation to receive structured invoices from your suppliers, which is a procurement/accounting concern, not something your storefront generates.

The EU-wide direction: ViDA

None of these national systems is a one-off. They're the run-up to VAT in the Digital Age (ViDA), the EU initiative to standardise e-invoicing and introduce near-real-time digital reporting for intra-EU transactions, with the structured-invoice requirements aimed at the back half of this decade. The practical reading for a store owner: the national format you implement now is a stepping stone, not a dead end, because they're all converging on the same EN 16931 core. Getting your invoice data right is the durable investment; the transmission wrapper is the part you'll most likely outsource.

What this actually demands of your PrestaShop store

Strip away the acronyms and e-invoicing asks three concrete things of you. Only the first is genuinely your store's job — and it's where most failures happen.

1. Invoice data quality (this is 90% of the work)

Structured e-invoicing systems reject invoices with missing or malformed fields outright — there's no human on the other end to shrug and fix it. A FatturaPA file missing a buyer VAT number doesn't get queried; it bounces. So the foundational task is making sure every PrestaShop invoice carries the full EN 16931 field set:

• Seller and buyer VAT/tax identifiers — and for B2B the buyer's must be present and valid. PrestaShop stores these on the address (vat_number, plus company and siret/dni where applicable), but they're only filled if your checkout asks for them and you validate them.
• Complete structured addresses — street, postcode, city, country code, each in its own field (the XML wants them separated, not as one free-text blob).
• Tax breakdown per line and per rate — the total VAT has to reconcile against the per-rate subtotals, which is exactly where loose tax configuration bites you. If your rates and rules aren't clean, the structured file won't validate; tax configuration in PrestaShop covers getting that right at source.
• A unique sequential invoice number — with gaps explained where local law or accounting practice requires it. Many tax systems require unique sequential numbering, but whether a sequence must be strictly gapless is country- and accounting-rule-specific, and XML validation systems generally don't reject an invoice solely because another number is missing. PrestaShop's default counter is per-shop and resets/forks in ways that surprise people; the deeper treatment is in invoice and order number customization.
• Clear product descriptions, codes and payment terms — generic line text and missing payment/bank details are common rejection causes.

So what? If your invoices already capture and validate buyer VAT numbers, carry clean per-rate tax breakdowns, and number sequentially, you are most of the way to e-invoicing readiness regardless of which national pipe you eventually plug into — because every one of those pipes wants the same underlying data. This is where the right modules pull their weight: Financial Revolution produces invoices with the complete field set European compliance expects, Invoice Number enforces the strict sequential numbering these systems demand, and Automatic EU VAT Checker validates buyer VAT numbers against VIES at checkout so a bad number never makes it onto an invoice that's about to be machine-rejected. The benefit isn't "compliance" in the abstract — it's that your invoice data is clean before a deadline forces the issue, instead of after.

2. Format conversion (XML generation)

Your clean PrestaShop data still has to become a FatturaPA, XRechnung, Factur-X or KSeF XML file. There are two realistic ways to get there, and for most merchants the second is correct:

3. Transmission

The file then has to travel through the approved channel — Italy's SDI, Poland's KSeF, France's PDP network, the Peppol network for Belgium and others. Direct integration with these is genuinely complex and certificate-heavy, which is why the overwhelmingly common pattern for small and mid-size merchants is to hand transmission to an intermediary (often the same provider that does format conversion) for a per-invoice fee. Your store's responsibility ends at producing correct data; theirs is getting it through the pipe and back with a receipt.

B2C: mostly not yet, but don't bet on it staying that way

Today the mandates are overwhelmingly B2B (and B2G). Most B2C invoices are exempt or simplified — with Italy the notable exception, where the mandate already covers consumer sales. The pragmatic stance: even where B2C e-invoicing isn't required of you, the data-quality work above costs you nothing extra to keep up to standard, and it means a future B2C extension in one of your markets is a configuration change rather than a fire drill. Note too that distance selling to consumers carries its own documentation obligations regardless of e-invoicing — see distance selling regulations.

Your action plan

You don't need to solve every country at once. You need to know your exposure and get your data clean — in that order.

• Map your B2B markets to deadlines. List the countries you actually issue B2B invoices in, then pin the current date and format for each. Imminent: Italy (live), then France, Germany, Poland, Spain.
• Audit your invoice data now. Pull ten recent B2B invoices and check every EN 16931 field above is present and correct. The gaps you find today are the rejections you'd hit on go-live day.
• Fix the data at source. Validate buyer VAT numbers at checkout, tidy your tax rules, and lock down sequential numbering — the three jobs that make every downstream format work. The modules above do exactly this from the back office, no developer invoice.
• Pick conversion + transmission per market. A national module if you have one or two markets and the appetite to own schema updates; an intermediary provider if you have several or would rather not.
• Talk to your accountant. They should already be tracking the exact dates and thresholds for your specific situation — this guide tells you what to ask, not what to file.
• Re-check the timeline twice a year. Several of these dates are still being finalised and have moved before; a calendar reminder beats a last-minute scramble.

E-invoicing is not the most thrilling item on a store owner's list, but it has a quality the exciting ones don't: a hard deadline. The merchants who get caught out aren't the ones who started late on transmission — that's a provider's problem they can buy their way out of in a week. They're the ones whose underlying invoice data was a mess, who discovered on a mandate's go-live morning that half their B2B invoices were missing a valid buyer VAT number or didn't number cleanly. Get the data right while it's still optional, and the deadline, when it lands, is somebody else's emergency.

Related guides

• Invoice Customization in PrestaShop: PDF Templates and Legal Requirements — the human-readable PDF side.
• Invoice and Order Number Customization: Why Default Numbers Are Not Enough — getting sequential numbering compliant.
• VAT in the EU: OSS, IOSS and What Your PrestaShop Store Must Handle — where the VAT itself is owed.
• Tax Configuration in PrestaShop: EU VAT Rules Explained — clean rates that survive structured validation.
• B2B E-Commerce with PrestaShop: VAT Handling, Net Prices and Payment Terms — the B2B context e-invoicing lives in.