Supported countries
Source
What is supported is generated from docs/supported-countries.md, which the product builds from the constants its code reads; the roadmap is the "Country roadmap" table of its README.md. Both at the pinned revision 5ab878035219.
What this release supports. The page is generated from the constants the tax rules and the plugin's startup check read, so it cannot claim more than the code accepts.
Seller and buyers
The seller is established in Germany: the VAT rules, rates and invoice requirements applied are German. A seller established elsewhere stops the plugin at startup (UNSUPPORTED_SELLER_COUNTRY).
| Seller — tax rules | Buyer | Document | Delivery | Since |
|---|---|---|---|---|
| 🇩🇪 Germany | 🇩🇪 Business or consumer in Germany | ZUGFeRD / Factur-X, EN 16931 profile — or XRechnung 3.0, if you prefer it | File: XML, or PDF/A-3b | 0.1.0 |
| 🇩🇪 Germany | 🇩🇪 Public-sector buyer in Germany, with a Leitweg-ID | XRechnung 3.0 | File: XML, or PDF/A-3b | 0.1.0 |
| 🇩🇪 Germany | 🇪🇺 Any other EU member state, except Italy and Poland; Iceland, Liechtenstein and Norway (EEA) | ZUGFeRD / Factur-X, EN 16931 profile | File: XML, or PDF/A-3b | 0.1.0 |
| 🇩🇪 Germany | 🇨🇭 🇬🇧 Switzerland and the UK | ZUGFeRD / Factur-X, EN 16931 profile | File: XML, or PDF/A-3b | 0.1.0 |
Not supported: 🇮🇹 Italy (SDI), 🇵🇱 Poland (KSeF) — clearance platforms with an XML of their own, which no EN 16931 document can serve; out of scope. A buyer anywhere else, and a seller outside Germany, are refused too.
A buyer in Italy or Poland is refused as UNSUPPORTED_BUYER_COUNTRY_CLEARANCE, any other unsupported buyer as UNSUPPORTED_BUYER_COUNTRY.
Which document a buyer receives, and why: tax-semantics.md.
Territories with a VAT treatment of their own
These addresses carry an ordinary country code, but the territory's VAT treatment is not that country's. They are recognised by postcode and refused (SPECIAL_VAT_TERRITORY) rather than invoiced with the wrong category. Northern Ireland is refused for goods only; a service there is taxed as in the country its code names.
| Country code | Territory | Why |
|---|---|---|
| DE | Heligoland | outside the EU VAT area although part of an EU member state |
| DE | Büsingen am Hochrhein | outside the EU VAT area although part of an EU member state |
| ES | The Canary Islands | outside the EU VAT area although part of an EU member state |
| ES | Ceuta | outside the EU VAT area although part of an EU member state |
| ES | Melilla | outside the EU VAT area although part of an EU member state |
| FI | The Åland Islands | outside the EU VAT area although part of an EU member state |
| FR | A French overseas department or territory | outside the EU VAT area although part of an EU member state |
| GR | Mount Athos | outside the EU VAT area although part of an EU member state |
| IT | Livigno | outside the EU VAT area although part of an EU member state |
| IT | Campione d'Italia | outside the EU VAT area although part of an EU member state |
| GB, XI | Northern Ireland | inside the EU VAT area for goods under the Windsor Framework although part of the UK |
Delivery
Every document is a file stored with the order: the CII XML, or a PDF/A-3b with the XML embedded when a PDF is configured. It is downloaded from Medusa Admin, or by the customer through the Store API. Nothing is sent through a network such as Peppol.
What comes next, country by country: the country roadmap.
Country roadmap
Every country, including what comes next. Dates are targets, not promises.
| Country | What is covered | Formats / delivery | Status | Target release | Why (mandate) |
|---|---|---|---|---|---|
| 🇩🇪 Germany | Seller tax rules + buyer profiles (B2B and B2G) | XRechnung 3.0 (CII), ZUGFeRD 2.x / Factur-X (EN 16931, XRECHNUNG), PDF/A-3b; delivery as a file | Released | 0.1.0 — 2026-10-24 | B2B e-invoice issuance mandatory from 2027-01-01 (turnover > €800k) and 2028-01-01 (all) |
| 🇪🇺 Any EU/EEA buyer of a German seller | Buyer profile only (intra-Community supply, export) | EN 16931 hybrid (Factur-X / ZUGFeRD EN 16931) | Released | 0.1.0 — 2026-10-24 | Accepted EU-wide as a valid EN 16931 invoice |
| 🇨🇭 🇬🇧 Swiss / UK buyer of a German seller | Buyer profile only (export) | EN 16931 hybrid | Released | 0.1.0 — 2026-10-24 | No e-invoice mandate; hybrid PDF widely accepted |
| 🇳🇴 Norway | Seller tax rules + buyer profile | EHF 3.0 (= Peppol BIS Billing 3.0, UBL); Peppol delivery via an access-point provider | Planned | 0.2.0 — 2026-12-01 | B2B e-invoicing mandatory from 2027-01-01 |
| 🇩🇰 Denmark | Seller tax rules + buyer profile | Peppol BIS Billing 3.0 (UBL); OIOUBL → NemHandel BIS transition tracked | Planned | 0.2.0 — 2026-12-01 | Bookkeeping Act: digital bookkeeping systems must exchange e-invoices |
| 🇸🇪 Sweden | Seller tax rules + buyer profile | Peppol BIS Billing 3.0 (UBL) | Planned | 0.2.0 — 2026-12-01 | B2G mandatory since 2019; no B2B mandate yet |
| 🇩🇰 🇳🇴 🇸🇪 Nordic specifics | Corrections (384), partial credit notes, national identifiers (CVR, ELMA, GLN) | — | Planned, tentative | 0.3.0 — 2027-04 | — |
| 🇦🇹 Austria | Buyer profile via EN 16931 hybrid or Peppol BIS; seller tax rules | — | On request | — | B2G only; no B2B mandate |
| 🇧🇪 🇳🇱 Belgium, Netherlands | Buyer profile via Peppol BIS (after 0.2.0); seller tax rules | — | On request | — | BE: B2B mandatory since 2026-01-01 (Peppol) |
| 🇫🇮 Finland | Peppol BIS / Finvoice | — | On request | — | Buyers may demand e-invoices by law |
| 🇫🇷 France | Buyer profile: Factur-X is produced already; seller tax rules and the mandatory certified-platform (PDP) submission flow are not | — | On request | — | Reception mandatory from 2026-09-01; issuance 2026-09-01 (large/mid) and 2027-09-01 (SMEs) via a PDP |
| 🇮🇹 🇵🇱 Italy, Poland | — | SDI / KSeF are clearance systems with their own XML — no EN 16931 document can serve them | Not supported | — | — |
| 🇪🇸 Spain | — | Verifactu / Facturae — different model | Not supported | — | — |
Legend: Released — on npm, in the release named · In development — code exists and its fixtures pass the official validators, not yet released · Planned — scheduled with a target date · On request — the core supports it technically; the country's rules are added when a paying implementation asks for them · Not supported — out of scope by design.