---
title: "Changing platform in Europe"
description: "What changing e-invoicing platform takes in every European country: whether your routing address changes, what you must re-grant at the tax authority, who holds the archive, and how to request a migration without touching the API."
canonical: "https://docs.get-flowie.com/guides/portability-europe"
source: "https://docs.get-flowie.com/guides/portability-europe.html"
---

# Changing platform in Europe

Guides

# Changing platform in Europe

Whether you can leave your current e-invoicing provider, what it takes, and who has to do what — country by country. **[France has a regulated hand-over](<portability.html>)** ; everywhere else, switching is three unrelated jobs that happen to fall in the same week.

You do not need the API to start

Use the [migration request form](<#request>) below. It runs in your browser, needs no account and no API key, and hands us a complete request — identifiers, current platform, target date — by e-mail or clipboard. The endpoints on this page are what _we_ then run on your behalf. 

## The five layers a switch touches

“Changing provider” sounds like one operation. It is five, owned by five different parties, and they fail independently.

Layer| What it is| Who changes it| Portable?  
---|---|---|---  
**Identifier**|  VAT number, SIREN/SIRET, NIP, Peppol participant ID| Nobody — it is yours| Always. Identifiers never change when you switch.  
**Routing address**|  Peppol SMP entry, the French annuaire, the Italian _codice destinatario_|  Your platform or access point| Usually — but the _value_ can change (Italy)  
**Authorisation**|  _delega_ , technical user, KSeF certificate, SPV authorised user| You, at the tax authority| Never transferred — always re-granted  
**Data & archives**| Original XML, lifecycle statuses, the legal archive| Your outgoing provider| The real fight. Regulated only in France  
**Contract**|  Notice period, exit fees, export format| Both parties| Capped by the [EU Data Act](<#eu-right>)  
  
## What it takes, per country

The pattern that decides everything: **where the archive lives**. In centralised-clearance countries the state holds your invoices, so leaving is cheap. In decentralised countries your outgoing provider holds them, so leaving is expensive.

Country| Does your address change?| What you must re-grant| Who holds the archive| Effort  
---|---|---|---|---  
🇫🇷 **France** · PPF| No — SIREN/SIRET addressing is kept; the annuaire is re-pointed| A signed designation agreement (_accord formel_)| You / your platform — with a 1-year continuity duty| Regulated  
🇮🇹 **Italy** · SDI| **Yes** — the _codice destinatario_ belongs to the intermediary|  _Delega_ to the new intermediario; ideally register your _indirizzo telematico_|  You (_conservazione_ , 10 years, signed packages)| Hard  
🇵🇱 **Poland** · KSeF| No address exists — buyers pull from KSeF| A KSeF certificate for the new provider; revoke the old| The state, 10 years| Easy  
🇷🇴 **Romania** · e-Factura| No — everything goes through the SPV| An authorised user holding a qualified certificate| ANAF holds the cleared invoices| Easy  
🇭🇺 **Hungary** · NAV| No — reporting only, no routing| A technical user for the new software| You (reporting regime)| Easy  
🇬🇷 **Greece** · myDATA| No — you declare a transmission channel| The channel declaration + provider credentials| You, with myDATA as the reported record| Medium  
🇪🇸 **Spain** · Crea y Crece| No — private platforms must interoperate| Provider onboarding (rules land with the mandate)| You + the _copia fiel_ at AEAT| Medium  
🇵🇹 **Portugal**|  n/a — but **document series are bound to certified software**|  New series registered under the new software's certificate| You (SAF-T PT is your export)| Hard  
🇭🇷 **Croatia** · Fiskalizacija 2.0| Yes — the state directory names your provider (“AMS”)| The directory entry| You + the reported record| Medium  
🇹🇷 **Türkiye** · GİB| Yes — via your _özel entegratör_|  An activation form signed with your e-seal| Your integrator| Ask us  
🇧🇪 🇳🇱 🇩🇰 🇸🇪 🇳🇴 🇫🇮 and the rest of **Peppol Europe**|  No — the participant ID stays; the SMP entry moves| Nothing at a tax authority| You| Easy  
🇩🇪 **Germany**|  No platform layer to leave (Factur-X by e-mail or Peppol)| Nothing| You (GoBD, 8 years)| Easy  
  
**Effort** is about the switch, not about us: “Hard” means there are counterparties to notify or an archive to move, not that we cannot do it.

## Ask us to migrate you

One field. Type the identifier you already know — a SIRET, a VAT number, or just the company name — and everything else is resolved from our records and the registries we already query: legal name, country, SIREN/SIRET, Peppol id, the annuaire addressing line, and what your country requires. You correct anything that is wrong; you type nothing that we can look up.

Migration request

Your SIRET, VAT number, or company name Your e-mail Fill this in for me

No account and no API key: the page mints a throwaway sandbox key for the lookup and forgets it when you close the tab. Resolution runs against `POST /v1/portability/resolve`.

**Correct something, or fill it in by hand** — only if the lookup got it wrong or found nothing.

Country 🇫🇷 France — PPF 🇮🇹 Italy — SDI 🇵🇱 Poland — KSeF 🇷🇴 Romania — e-Factura 🇭🇺 Hungary — NAV 🇬🇷 Greece — myDATA 🇪🇸 Spain — Crea y Crece 🇵🇹 Portugal — AT 🇭🇷 Croatia — Fiskalizacija 2.0 🇹🇷 Türkiye — GİB Peppol country (BE, NL, DK, SE, NO, FI, DE…) Legal name Platform you are leaving Who signs, for the company Effective date

[Send this request](<mailto:platform@flowie.fr>) Copy as text

The lookup is the only thing that leaves your browser, and only when you ask for it. The button opens your own mail client with the request filled in. We reply within one business day, and run the technical part for you.

**Already a customer?** The same resolution runs against your own records rather than the sandbox, so a signed-in company confirms one screen and types nothing at all.

### What we do once you send it

  1. **We check who holds you today** in the relevant registry — the PPF annuaire, the Peppol SMP, or the national directory.
  2. **We draw up the designation agreement** your country needs, numbered and dated, and start the evidence chain described below.
  3. **We import your companies** — one, or hundreds in a single batch — with one result row per company, so nothing is silently skipped.
  4. **We sequence the cut-over** so your old access is never closed before the new one resolves. That ordering is the single most common cause of lost invoices.



## Why the platform you are leaving cannot just say no

A switch that can be stalled is not a right. In France the decree closes both escapes — the refusal and the silence — and our job is to make the record that proves it.

### The grounds for an objection are narrow, and we classify them

Under **CGI ann. II art. 242 nonies E ter** the outgoing platform may object only on grounds that call your _intent_ to switch into question. Three do:

Ground| What it claims| Admissible  
---|---|---  
`more_recent_agreement`| A later designation agreement exists| Yes  
`identity_mismatch`| The taxpayer named is not the one they hold| Yes  
`mandate_invalid`| The agreement is unsigned, undated or unnumbered| Yes  
An unexpired contract · unpaid invoices · a notice period · “commercial reasons”| Nothing about your intent| No — the port continues  
  
An objection is recorded either way, verbatim. What changes is the verdict: an inadmissible ground is stored with `admissible: false` and the request keeps running, carrying the digest of your signed agreement as the answer to it. And silence is not a veto: once the five-business-day window lapses with no admissible objection, the request moves to `auto_accepted` (`TAC` on the wire) by itself — _le silence vaut accord_.

### The proof: a hash-linked chain, not a mailbox

Every step appends an entry carrying the SHA-256 of its own payload plus the digest of the entry before it. Edit a payload, retime a step, drop one, or reorder two, and verification fails _and names the entry_. That is what turns “we sent it on the 3rd” into something an administration can check.
[code] 
    {
      "seq": 2,
      "kind": "portability.request.notified",
      "at": "2026-09-03T09:12:00+00:00",
      "payloadSha256": "9f2c…",
      "prevSha256": "41ab…",
      "sha256": "7d10…"
    }
[/code]

What we sign and keep, because the decree asks for it: the taxpayer, the incoming platform, the previous one, the effective date, the scope of electronic addresses, the signatory — numbered, retained, and produced to the administration on demand. A request opened without a signatory does not fail; it reports the gap in `mandate.gaps`, because that gap is exactly what an outgoing platform is entitled to object to.

## Run it from an agent, end to end

Four calls, no human judgement in between, so an agent asked to “move this company to Flowie” can carry the whole procedure. The `Portability` tools are on the curated MCP server at `/exchange/mcp` — see [Build with AI](<../build-with-ai/index.html#mcp>).

Step| Call| What it does  
---|---|---  
1| `POST /v1/portability/resolve`| One identifier in; identity, regime and requirements out  
2| `POST /v1/portability/requests`| Opens the request: agreement number, computed clocks, first evidence entry  
3| `POST /v1/portability/requests/{ref}/events`| Records a step: `notified`, `objection`, `acceptance`, `annuaire_updated`  
4| `GET /v1/portability/requests/{ref}`| State re-derived from the chain, with `tacitApproval` and the verification result
[code] 
    # 1 · everything from one identifier
    curl -X POST …/v1/portability/resolve \
      -H "Authorization: Bearer $FLOWIE_KEY" -H "Content-Type: application/json" \
      -d '{"taxpayer": "92137626500017"}'
    
    # 2 · open the request — nothing else is required
    curl -X POST …/v1/portability/requests \
      -H "Authorization: Bearer $FLOWIE_KEY" -H "Content-Type: application/json" \
      -d '{"taxpayer": "92137626500017", "signatory": "Camille Roy, Directrice Générale"}'
    
    # 3 · record the D+2 notice to the outgoing platform
    curl -X POST …/v1/portability/requests/POR-2026-4F2A91C08B7D/events \
      -H "Authorization: Bearer $FLOWIE_KEY" -H "Content-Type: application/json" \
      -d '{"kind": "notified", "channelRef": "msg-2026-09-03-001"}'
    
    # 4 · where does it stand, and is the proof intact?
    curl …/v1/portability/requests/POR-2026-4F2A91C08B7D \
      -H "Authorization: Bearer $FLOWIE_KEY"
[/code]  
  
State is never stored, always folded from the evidence chain, so step 4 is the single source of truth — and an agent that was not running when the request was opened reaches the same answer as one that was. The whole history is also readable as ordinary events (`portability.request.*`) over `GET /v1/events`.

Outside France the same four calls apply, with less law behind them

The clocks and the objection rules are French. Elsewhere the chain still gives you a timestamped record of what you asked for and when — which is what the [Data Act](<#eu-right>) switching right is argued with. 

## Peppol countries: the participant ID stays, the SMP entry moves

In every Peppol country the switch is a registry edit, not a re-addressing. Your participant ID does not change, document-type and process registrations are re-created identically, and only the endpoint and its transport certificate point somewhere new.

The specification provides a **migration key** for this: your outgoing provider generates it, the new provider presents the same key to the SML, and the registration moves. In practice many providers never expose that key, so the real-world sequence degrades to _deregister, then re-register_ — which opens a window where invoices can be misrouted, delivered twice, or lost.

Ask for the migration key in writing before you sign anything

And never terminate the old access point before a lookup shows the new one resolving. Propagation is usually hours, but it can take days with a complex integration. 

## France: the only regulated hand-over

France is the exception. A change of _plateforme agréée_ follows a procedure fixed by decree, with deadlines on both platforms and a continuity obligation on the one you leave. The taxpayer keeps its SIREN/SIRET addressing throughout; what changes is the annuaire entry, and only a platform can write to it.

**[Read the France portability guide →](<portability.html>)** for the designation agreement, the day-by-day timetable, the eight request states and the inter-PA message format.

## Clearance and intermediary countries, one by one

### 🇮🇹 Italy — the address changes, and that is the problem

Your _codice destinatario_ is the intermediary's channel code, so switching changes it and every supplier holding the old one must be told. The mitigation is to register your _indirizzo telematico_ in _Fatture e Corrispettivi_ , so SdI routes to the registered channel. The _delega_ to an _intermediario_ runs for four years unless you set a shorter term, does not auto-renew, and is revocable at any time in the same form it was granted. Your _conservazione sostitutiva_ obligation is ten years, with signed and time-stamped packages, and it applies independently to what you issue and what you receive.

### 🇵🇱 Poland — the state is the archive, so switching is cheap

KSeF stores every invoice for ten years from the end of its year of issue and is the official record, so there is no archive to move and no address to propagate: your buyers pull from KSeF. What you port is credentials. KSeF certificates are live from February 2026; tokens work until the end of 2026 and are replaced by certificate-only access from 1 January 2027. Grant the new provider its own credential, then revoke the old one.

### 🇷🇴 Romania — authorised users, not addresses

e-Factura runs through the SPV, and a provider acts under an authorised user holding a qualified certificate. Switching means registering the new provider's certificate holder and revoking the outgoing one's rights. ANAF holds the cleared invoices.

### 🇭🇺 Hungary — a technical user per software

NAV Online Számla is a reporting regime: no routing to move, no counterparties to notify. Your primary user creates a technical user for the new software and you delete the old keys.

### 🇬🇷 Greece — the transmission channel is a declared choice

myDATA accepts a direct ERP integration, an accredited provider, or the free _Timologio_ app. Switching provider means re-declaring the channel and re-issuing credentials. The B2B mandate lands on 2 March 2026 for turnover above €1M and 1 October 2026 for everyone else, each with a transition period.

### 🇪🇸 Spain — interoperability is mandated, a switch procedure is not

_Crea y Crece_ is a four-corner model: invoices travel through compliant private platforms or the public AEAT solution, and private platforms also submit a _copia fiel_. Mandated interoperability is a strong indirect guarantee — your counterparties stay reachable whoever you pick — but there is no regulated hand-over. Large companies are in scope from 1 October 2027, everyone else from 1 October 2028.

### 🇵🇹 Portugal — the lock-in is the software certificate

Invoices must come from AT-certified software and carry its certification number, the ATCUD and a QR code. A document series is registered under the software that created it, so switching means opening **new series** under the new software's certificate — a series does not follow you. SAF-T (PT) is your export on the way out.

### 🇭🇷 Croatia — a state directory of approved providers

Fiskalizacija 2.0 went live on 1 January 2026 with a state directory of taxpayers and approved providers (“AMS”) alongside the FiskApplication portal. Switching is a directory re-pointing — the closest structural analogue to the French annuaire outside France.

### 🇹🇷 Türkiye — the biggest market, the least public procedure

Around 1.49 million taxpayers file through a private integrator (_özel entegratör_) against roughly 76,000 on the GİB portal, so switching integrator is a mass-market event — but no integrator-to-integrator procedure is published. Talk to us before you give notice.

## Your EU right to switch

Outside France there is no tax rule that governs leaving a provider. There _is_ a horizontal one, and it is stronger than most contracts: the **EU Data Act** , whose switching provisions have applied since 12 September 2025 to data-processing services — e-invoicing platforms included.

  * Providers must remove commercial, technical, contractual and organisational **obstacles to switching**.
  * **Two months' notice** is the maximum they can require of you.
  * The switch must complete within **30 calendar days** , extendable only where it is technically unfeasible.
  * Absent an applicable standard, you must be able to export **all your data in a structured, commonly used, machine-readable format**.
  * It binds **existing contracts** , fixed-term ones included, and reaches non-EU providers serving EU customers.



Looking further out, **ViDA** makes EN 16931 mandatory for intra-EU invoicing from 1 July 2030 and aligns domestic reporting by 1 January 2035. That shrinks the format half of switching cost — but a common format is not portability: it says nothing about who holds your archive or who is registered as your platform.

## Who holds the archive holds the customer

Country| Retention| What it means when you leave  
---|---|---  
🇵🇱 Poland| 10 years, in KSeF| Nothing to move — the state is the record  
🇮🇹 Italy| 10 years, _conservazione_|  Signed, time-stamped packages have to be handed over  
🇩🇪 Germany| 8 years (§14b UStG)| GoBD adds original format, immutability, machine-readability  
🇫🇷 France| 10 years for commercial records| Plus a 1-year continuity duty on the platform you leave  
🇨🇭 Switzerland · 🇦🇹 Austria · 🇬🇧 UK| 10 · 7 · 6 years| Contractual export, no regulated hand-over  
  
## What to demand from the provider you are leaving

Ask before you sign the exit, not after. In France most of this is owed to you; elsewhere the Data Act is your lever.

  1. **Original XML** invoices, probative value intact.
  2. **Human-readable renditions** (PDF or Factur-X).
  3. **Lifecycle statuses** — the full history, in CSV, JSON or XML.
  4. **Counterparty lists** with their addresses and routing codes.
  5. **Attachments** in their original formats.
  6. **Accounting entries** (in France, the FEC).
  7. **Technical logs** , or a signed attestation covering them.
  8. The **Peppol migration key** , in writing, where Peppol applies.
  9. **Registry evidence** that the old entry is deactivated and the new one resolves.
  10. A **credential revocation plan** sequenced _after_ the new provider is authorised.
  11. **In-flight reconciliation** : documents submitted but not yet acknowledged at cut-over.
  12. The **conservation packages** with their signature and timestamp metadata, where the archive stays behind.



## What we could not confirm

Said plainly, because a switch planned on a guess is a switch that slips:

  * The **Türkiye** integrator-to-integrator procedure is not published anywhere we could find.
  * Whether **Greece** restricts myDATA channel changes _within_ a tax year — the one rule that would block a mid-year switch.
  * Whether the registered Italian _indirizzo telematico_ overrides an invoice-level _codice destinatario_ unconditionally.
  * The **Croatian** AMS directory re-pointing procedure and its deadlines.
  * Peppol **in-flight document** handling and rollback during a migration.



Where a country appears above, we verify it live with the registry before we quote you a date.
