Moving parties between Plateformes Agréées

A company can change Plateforme Agréée (PA) at any time. The new PA sends a MOBILITY_REQUEST to the old one, and the old PA answers with a MOBILITY_RESPONSE: accepted, accepted on another date, or refused. Invopop handles both sides of this exchange:

Incoming: another PA asks to take over an address registered through Invopop.
Outgoing: you register an address another PA holds.

Incoming requests

Setup

Add the PPF incoming migration workflow to your workspace, then select it as the migration workflow in the France app’s configuration. In the Apps view, open the France app, click Configure, and select the workflow under Migration Workflow. When another PA asks to take over addresses registered through Invopop, Invopop starts one migration job per requested address. Each job runs the configured workflow on the silo entry that registered the address. Invopop only accepts a request when it comes from the requesting platform’s registered contact address. Anything else is refused and no job starts.

Takeover form

The Respond to incoming migration step publishes a link_url under the migration-link key in the silo entry meta. Each silo entry has one link, which always opens the latest request for its address. The form shows the requesting platform and the address, and lets the user:

Accept the takeover, on the requested date or on another effective date picked from a calendar.
Refuse the takeover.

To answer from your own system instead of the form, call Answer a migration request with the silo entry ID. The same rules apply.

Answer deadline

The company has 5 business days from the request’s arrival to answer. This deadline only applies to workspaces with a migration workflow configured (see Setup). The form shows the deadline. If the address is still unanswered after that, Wait for migration response accepts it automatically.

Response

Complete incoming migration sends the MOBILITY_RESPONSE for the address to the new PA:

Answer	Response status
Accepted on the requested date	`ACCP`
Accepted on another date	`ACWC`, with the agreed effective date
Refused	`RJCT`, with motif `REFUS_CLIENT`

PPF incoming migration workflow

PPF incoming migration

Add to my workspace →

Workflow
Code

PPF incoming migration workflow

{
    "name": "PPF incoming migration",
    "description": "Respond to an incoming PA migration request and, if accepted, migrate the party's Peppol registration and disable it in the Directory",
    "schema": "org/party",
    "steps": [
        {
            "id": "2f34cb83-c72a-11f1-998e-a62046e2e5be",
            "name": "Set state",
            "provider": "silo.state",
            "summary": "Set state to `processing`{.state .processing}",
            "config": {
                "state": "processing"
            }
        },
        {
            "id": "33084d80-cee9-11f1-9bf2-dd7a2ff728fc",
            "name": "Respond to incoming migration",
            "provider": "gov-fr.migration.start"
        },
        {
            "id": "3e0e9180-cee9-11f1-9bf2-dd7a2ff728fc",
            "name": "Wait for migration response",
            "provider": "gov-fr.migration.wait.approval",
            "next": [
                {
                    "status": "NA",
                    "code": "accepted",
                    "steps": [
                        {
                            "id": "2f2d6970-c72a-11f1-9faf-a62046e2e5be",
                            "name": "Start Peppol migration",
                            "provider": "peppol.migrate"
                        },
                        {
                            "id": "4d33fab0-cee9-11f1-9bf2-dd7a2ff728fc",
                            "name": "Complete incoming migration",
                            "provider": "gov-fr.migration.complete"
                        },
                        {
                            "id": "2f34ccb2-c72a-11f1-bda9-a62046e2e5be",
                            "name": "Wait for Peppol migration",
                            "provider": "peppol.wait.migration"
                        },
                        {
                            "id": "2f34cd29-c72a-11f1-8188-a62046e2e5be",
                            "name": "Unregister supplier from Peppol",
                            "provider": "peppol.unregister"
                        },
                        {
                            "id": "5e976d00-cee9-11f1-9bf2-dd7a2ff728fc",
                            "name": "Disable party in Directory",
                            "provider": "gov-fr.directory.disable"
                        },
                        {
                            "id": "2f34cd87-c72a-11f1-aed2-a62046e2e5be",
                            "name": "Set state",
                            "provider": "silo.state",
                            "summary": "Set state to `void`{.state .void}",
                            "config": {
                                "state": "void"
                            }
                        }
                    ]
                },
                {
                    "status": "NA",
                    "code": "rejected",
                    "steps": [
                        {
                            "id": "53939a00-cee9-11f1-9bf2-dd7a2ff728fc",
                            "name": "Complete incoming migration",
                            "provider": "gov-fr.migration.complete"
                        },
                        {
                            "id": "65d7cf60-cee9-11f1-9bf2-dd7a2ff728fc",
                            "name": "Set state",
                            "provider": "silo.state",
                            "summary": "Set state to `registered`{.state .registered}",
                            "config": {
                                "state": "registered"
                            }
                        }
                    ]
                }
            ]
        }
    ],
    "rescue": [
        {
            "id": "2f34cdf5-c72a-11f1-b5cc-a62046e2e5be",
            "name": "Set state",
            "provider": "silo.state",
            "summary": "Set state to `error`{.state .error}",
            "config": {
                "state": "error"
            }
        }
    ]
}

Outgoing takeovers

To take over an address another PA holds, set the former PA’s line under the fr-former-matricule meta key of the party. The signed agreement then includes an additional section asking the company to consent to the takeover. When you run the PPF register supplier workflow for that address, Register party in Directory (gov-fr.directory.register) sends a MOBILITY_REQUEST to that PA and waits for its answer. Once the takeover is accepted, Invopop registers the line with the agreed effective date, and the step stays queued until that date. If the other PA refuses, or its answer can’t be processed, the step fails with the reason.

Reading migrations

The France dashboard’s Migrations tab lists every takeover request involving your workspace’s addresses, newest first. In the Console, open the Apps view, select the France app, and switch to the Migrations tab. A workspace with no takeovers shows No migrations yet. Each row shows the New PA and Old PA, the Status, the SIREN, the Role, the company’s Denomination, the Request number, the number of Endpoints (addresses) it covers, the New PA and Old PA matricules, and, for failed takeovers, the Failure reason. The Role tells you which side of the exchange Invopop is on:

Role	Meaning
Outgoing	Invopop is the new PA, taking over an address from another platform.
Incoming	Another platform asked to take over one of your addresses. Invopop is the old PA.

Status	Role	Meaning
Created	Outgoing	The request is built but not sent yet.
Sent	Outgoing	The request was emailed to the old PA.
Acknowledged	Outgoing	The old PA acknowledged the request.
Responded	Outgoing, Incoming	Outgoing: the old PA agreed; the Peppol migration code is still to follow. Incoming: your answer has been sent to the new PA, but not every address has a final answer yet.
Received	Incoming	The request is waiting for answers.
Completed	Outgoing, Incoming	The migration has been completed, either accepted or rejected.
Failed	Outgoing	The takeover failed, failure reason is logged in the launcher.

An outgoing takeover moves from Created to Sent, Acknowledged, Responded and Completed, or ends as Failed. An incoming request moves from Received to Responded once your answer is sent, and to Completed once every address has a final answer. The Failure reason explains why an outgoing takeover failed: for example, the old PA rejected it or put it on hold because of a dispute, accepted it without a migration code, sent a reply that couldn’t be read, or the request email couldn’t be sent. If the reason is unclear, contact Invopop support.

Clicking a row opens a read-only side panel titled SIREN followed by the party’s SIREN, with one Details block per address: its Endpoint, the Silo entry ID, the Decision, and the Reason and Effective Date when they are set.

The Decision is your answer on an incoming request, or the old PA’s answer on an outgoing one. It stays blank until the address is answered.

Decision	Meaning
`ACCP`	Accepted on the requested date.
`ACWC`	Accepted on another effective date.
`ACSP`	Accepted in principle; the final answer and Peppol migration code will follow.
`RJCT`	Rejected.
`PDNG`	On hold because of a dispute (outgoing only).

Reading migrations through the API

The same data is available through the France app’s API, authenticated with the enrollment token like the other /apps/gov-fr endpoints:

List migrations (GET /apps/gov-fr/v1/migrations) returns one item per address in every migration of the workspace, newest first, in both roles.
List a silo entry’s migrations (GET /apps/gov-fr/v1/migrations/{silo_entry_id}) returns the items for the address registered by one silo entry. Use it to find out whether an address has a request waiting for an answer.
Answer a migration request (POST /apps/gov-fr/v1/migrations/{silo_entry_id}) accepts or refuses the request, like the takeover form.

Both lists page with offset and limit (default 25, maximum 200), counted in items, and return a next_offset while more results remain. Each item is one address of one request, with:

identifier: the directory address (endpoint) the item refers to, as it appears in the PPF Annuaire.
status: pending until the address has a final answer, then accepted or rejected. An outgoing request that fails without an agreement is failed.
effective_date: the agreed date once the address is answered, otherwise the requested one.
decisions: the answers given so far, with their response code (ACCP, ACWC, RJCT, …) and Peppol migration code. On an incoming item they are your answers; on an outgoing one, the old PA’s.

Testing incoming migrations in sandbox

Simulating an incoming migration is only available in sandbox workspaces. The option isn’t shown in live workspaces, and the request is refused there.

In a sandbox workspace you can trigger an incoming request yourself, to test the takeover form, the answer endpoint and your migration workflow end to end.

Configure the migration workflow first (see Setup), so the simulated request has a workflow to run, without the Peppol migration steps (see below).
In the France dashboard’s Parties tab, click the party to open its side panel.
On an active endpoint, open the ⋯ menu next to the copy button and choose Simulate incoming migration. A toast confirms “Simulated incoming migration for <endpoint>”. Disabled endpoints don’t show the menu.
The request appears in the Migrations tab and in GET /apps/gov-fr/v1/migrations/{silo_entry_id} as an incoming item with status pending, and your migration workflow starts on the silo entry.
Answer it with the takeover form or POST /apps/gov-fr/v1/migrations/{silo_entry_id}, as described in Incoming requests.

Remove the Peppol migration steps

Before simulating, remove the Start Peppol migration, Wait for Peppol migration and Unregister supplier from Peppol actions from the migration workflow you test with.

Start Peppol migration (peppol.migrate) hands the party’s Peppol migration key to the new PA, which here is made up. Wait for Peppol migration stays queued until the Peppol network routes the participant to another provider’s Access Point, which never happens for a simulated request, so the job would never finish. Unregister supplier from Peppol (peppol.unregister) acts on the party’s real Peppol registration, so don’t run it for a simulated request either.

The rest of the workflow (Wait for migration response, Complete incoming migration) stays as it is. The request comes from a made-up platform and is handled like a real one. No email is ever sent to any platform for a simulated request.

FAQ

How does the 5-day deadline work?

The company has 5 business days, to answer, counted from the moment Invopop receives the request and ending at the same time of day (Paris time). For example, a request received on Friday at 15:00 expires the following Friday at 15:00. French public holidays are not taken into account. The form shows the date to answer by.Until then, Wait for migration response stays queued, and the workflow continues as soon as the company answers. If the address is still unanswered at the deadline, Invopop accepts it automatically: on the date the new PA requested when that is still possible, otherwise on the earliest possible date. Once the response is sent, the answer can’t be changed.The deadline only applies to workspaces with a migration workflow configured.

Which effective dates can the company choose?

The form’s calendar only offers dates from the earliest the switch can happen: at least 3 business days and 4 calendar days from the answer, whichever is later. Business days are Monday to Friday.If the company accepts without choosing a date, the date the new PA requested is used. If that date is already too soon, the earliest possible date is used instead, and the answer is sent as ACWC.

When is a migration request complete?

An incoming request can cover several addresses, and each address gets its own job and form. Each answer is sent to the new PA as soon as it’s given, with the addresses not answered yet marked pending.The request is complete once every address in it has been answered and the last answer has been sent. Until then, it shows as Received in the Migrations tab.

What does the Reason in the Migrations tab mean?

When an address was refused, the side panel of the Migrations tab shows the Reason next to the Decision. REFUS_CLIENT means the company refused the takeover, and ADRESSE_INCONNUE means the address isn’t held at Invopop. Reasons from other platforms appear as they sent them.

What happens if I don't have a migration workflow configured?

Invopop receives and records the request, but no workflow job starts for your workspace’s addresses: there is no form link, no automatic acceptance at the deadline, and no MOBILITY_RESPONSE is sent to the other PA.To answer it, add the PPF incoming migration workflow and select it in the France app configuration, then contact Invopop support to have the pending request processed again. The 5-day deadline still counts from when the request first arrived, so if it has already passed, the address is accepted automatically as soon as the workflow runs.

Does the 'Start Peppol migration' action always have to run?

No, it’s optional. Run it on the accepted branch when the party is registered on Peppol: its migration key is passed to the new PA, which uses it to move the party’s Peppol registration.Without it, the response carries NEANT, meaning there is nothing to migrate on Peppol. The key is never sent for refused addresses.

What outcomes does the 'Wait for migration response' action have?

The step stays queued until the company answers or the deadline passes, then ends with one of these codes:

accepted: the address was accepted, on the requested date or another one, either by the company or automatically at the deadline.
rejected: the company refused the takeover. The response is sent as RJCT with motif REFUS_CLIENT.

Both outcomes continue to Complete incoming migration, which sends the answer to the other PA. A typical workflow runs Start Peppol migration only on the accepted branch.

More available in our France FAQ section

🇫🇷 Invopop resources for France


Compliance	Invoicing compliance in France Compliance timeline
Apps	France Peppol Chorus Pro France
Guides	Chorus Pro — Supplier registration · Issuing invoices PA Guide — Registration · Invoicing · Status · Reporting · Public sector
FAQ	France FAQ
GOBL	France Tax Regime Chorus Pro Addon French Factur-X Addon
GitHub	gobl.xinvoice

Networks

Countries

Set-up

GOBL

Apps

API

Features

Moving parties between Plateformes Agréées

Incoming requests

Setup

Takeover form

Answer deadline

Response

PPF incoming migration workflow

PPF incoming migration

Outgoing takeovers

Reading migrations

Reading migrations through the API

Testing incoming migrations in sandbox

Remove the Peppol migration steps

FAQ

​Incoming requests

​Setup

​Takeover form

​Answer deadline

​Response

​PPF incoming migration workflow

PPF incoming migration

​Outgoing takeovers

​Reading migrations

​Reading migrations through the API

​Testing incoming migrations in sandbox

​Remove the Peppol migration steps

​FAQ

Incoming requests

Setup

Takeover form

Answer deadline

Response

PPF incoming migration workflow

Outgoing takeovers

Reading migrations

Reading migrations through the API

Testing incoming migrations in sandbox

Remove the Peppol migration steps

FAQ