Offboarding from Compliance Network | Product Documentation Documentation

Why France offboarding is different from other countries

Under the French e-invoicing reform, a French taxpayer's e-invoicing address is registered in two distinct external systems. Both must be managed when a customer leaves Sovos as their PA.

The Central Directory (Annuaire PPF): The DGFiP-managed directory that holds the taxpayer's reachability entry for regulated invoice flows.
The PEPPOL SML/SMP: The PEPPOL network's discovery infrastructure, where an Access Point (AP) is registered as the endpoint for the taxpayer's PEPPOL Participant ID (scheme 0225).

ISV partners operating on Sovos infrastructure use a virtual PEPPOL AP on the Sovos platform. The SMP registration for a customer's PEPPOL Participant ID is held under the partner's AP identity. When a customer offboards, the partner's virtual AP registration must be released on the PEPPOL SMP.

The PEPPOL SMP registration is the blocking dependency. A new PA cannot register the same PEPPOL Participant ID under their own AP until the existing SMP record is released. The Annuaire entry can be updated by the new PA, but only after the new PA has followed the mandatory procedure defined by the DGFiP (Processus Choix PA et mobilité V1.2) and the outgoing PA has not challenged the request within five working days. For the outgoing PA, Annuaire deletion is a housekeeping step, not the action that unblocks the new PA.

Platform scope: Sovos does not validate whether the new PA has obtained the customer's formal designation agreement (opt-in form or accord formel) before they act on the Annuaire or SMP. That is a contractual matter between the customer and the new PA, governed by French law and the PEPPOL France framework. When a partner triggers an offboarding operation using the API, the platform releases the registrations as requested.

Recommended path: Structured migration using the migration token

For customers migrating to another PEPPOL-connected PA, the recommended path is the structured PEPPOL SMP migration using the migration token. This path makes sure PEPPOL routing is continuous and the SMP registration transfers cleanly between Access Points (AP).

Scope

The migration token applies only to the PEPPOL SMP registration. It does not affect the Annuaire entry, which can be managed independently by either PA.

Note:

Step 1 is currently available. Steps 2 and 3 are in development and will be available soon.

Migration sequence


Step	Operation	Status	Description
1	Retrieve migration token	Available	Gets the PEPPOL SMP migration token for the customer's PEPPOL Participant ID. The token is returned in the API response and must be passed to the new PA by the customer or partner. The platform does not transmit the token to the new PA directly.
2	Cancel migration	Coming soon	If the customer changes their mind after the token has been retrieved, this operation cancels the migration on the SMP and restores the endpoint to its active registered state under the partner's AP. Can be triggered at any point before finalization.
3	Finalize migration	Coming soon	After the customer confirms the move is proceeding, this operation completes the SMP migration and deregisters the partner's AP from the SMP for this Participant ID. The migrated address is removed from CN.
4	Delete endpoint and Annuaire entry	Available	Removes the endpoint configuration from CN and removes the Annuaire entry. This is the same deletion operation described under Endpoint deletion (France-specific considerations) below, applied at the conclusion of the migration flow. Annuaire deletion here is a cleanup step. The new PA will typically have already updated the Annuaire entry to point to themselves before this step is triggered. Do not execute step 4 until the one-year minimum service period has ended. See One-year minimum service obligation below.

Note:

Note on step sequencing. The SMP migration (steps 1 through 3) is the blocking sequence and must be completed before the endpoint is deleted from CN (step 4). The Annuaire entry can be overridden by the new PA independently at any point during the migration, so there is no Annuaire-side blocker that requires deletion first.

Operational deadlines — obligations on PAs

Deadlines apply to any PA receiving a migration request from another PA. Partners operating their own virtual AP on the Sovos platform are bound by these deadlines in their capacity as a PA.

Two categories of obligation apply:

Statutory obligations

Obligations under Décret n°2026-677 (Article 242 nonies E ter of Annex II to the CGI). These are DGFiP regulatory requirements.

Operational obligations

Obligations under the AIFE Processus Choix PA et mobilité V1.2 and the PEPPOL France Enterprise Interoperability Architecture (EIA) v1.2.0. These are network-level requirements and are not DGFiP statutory requirements. They do not appear in the Dossier général v3.2, XP Z12-012 V1.4, or XP Z12-014 V1.4. Do not cite them as DGFiP regulatory obligations in customer-facing content.

Deadline table


Deadline	Category	Detail
The new PA must update the Annuaire within 15 business days of the outgoing PA's express or tacit agreement.	Statutory (Article 242 nonies E ter, Décret n°2026-677)	The effective date entered in the Annuaire must be at least three business days in the future from the moment of registration.
The outgoing PA must acknowledge a migration request within 24 hours of receipt.	Operational (AIFE Mobility Guide V1.2; PEPPOL France EIA v1.2.0)	This applies when the partner's virtual AP receives a migration request from an incoming PA. The acknowledgment confirms receipt of the request tied to the customer's Participant ID and desired effective date.
The outgoing PA must make the migration token available no later than four calendar days before the effective date of the corresponding Annuaire address lines.	Operational (AIFE Mobility Guide V1.2)	This makes sure the Annuaire change and SMP record transfer are synchronized. The migration token API provides the mechanism to retrieve the token; the scheduling discipline is the partner's responsibility.
Allow at least seven calendar days from the initial migration request to the effective date.	Operational (AIFE Mobility Guide V1.2)	If the desired effective date is within five days of the initial request and the token has not been transmitted within those five days, the effective date must be postponed by at least two days after the five-day window.

Statutory obligations source

Décret n°2026-677 du 27 juillet 2026, Article 242 nonies E ter of Annex II to the CGI.

Operational obligations source

AIFE Processus Choix PA et mobilité V1.2 (AIFE, August 10, 2026) and PEPPOL France Enterprise Interoperability Architecture v1.2.0, §4.8.1.

Token handover — partner responsibility

The migration token is retrieved using the Sovos CN API by an authorized role (WORKSPACE_ADMIN, API_ADMIN, or ADMIN). It is returned in the API response. The responsibility for delivering the token to the new PA rests with the customer or partner. The platform does not transmit the token to the new PA. Establish a secure token handover process with the new PA as part of your migration planning.

Endpoint deletion: France-specific considerations

The endpoint deletion API removes all PEPPOL endpoints registered under a company on the platform at once. For most active French migrations, this is not the recommended path. The recommended path is the structured migration using the migration token described above. Use endpoint deletion only in the specific circumstances described below.

Note:

This approach does not follow the French recommendation to use the PEPPOL migration key. Use it only with all parties' agreement. It is particularly appropriate when the customer has never transacted on the platform, for example because the address was registered by mistake or the customer changed their plans before using it.

When to use endpoint deletion:

The customer is closing activity entirely.
The new PA does not use the PEPPOL network.
A migration has been completed out of band and both parties confirm the addresses are ready to be released.
The customer never transacted under that endpoint on the outgoing platform.

Endpoint deletion removes the following registrations:

The company's PEPPOL SMP/SML registration from the partner's virtual AP. This is the primary blocking dependency for the new PA.
The company's entry from the Central Directory (Annuaire PPF).
The endpoint configuration from CN.

After endpoint deletion, the customer's e-invoicing addresses are no longer registered under the partner's AP. The new PA can then register the same PEPPOL Participant IDs under their own infrastructure.

Note:

No lifecycle state pre-condition. Endpoint deletion does not require the company to be in a specific lifecycle state, such as Closed or Locked. It is available to authorized roles (WORKSPACE_ADMIN, API_ADMIN, PORTAL_ADMIN, and ADMIN) without a lifecycle pre-condition.

Pre-conditions to confirm before triggering endpoint deletion:

The API does not enforce all of these checks automatically. It is the partner's and customer's responsibility to confirm them before calling the endpoint.


Pre-condition	Why it matters
All invoices submitted through the platform have completed their mandatory PPF status transmissions (Déposée, Rejetée, Refusée, Encaissée where applicable).	The 24-hour transmission deadline (Dossier général v3.2 §3.6.5 and §3.6.6) runs from the status timestamp and does not pause during offboarding. Any status pending at the time of endpoint deletion will miss its regulatory deadline if not cleared first.
The customer has confirmed that outstanding invoices with pending business-side lifecycle statuses (buyer approvals, Refusée, Encaissée for cash-basis VAT) are settled, or the customer explicitly accepts the residual risk described below.	After endpoint deletion, inbound lifecycle statuses from counterpart PAs for pre-existing invoices may be undeliverable. See Residual lifecycle risk after endpoint deletion below.
Where the customer is migrating to another PEPPOL-connected PA, both parties have agreed on the effective migration date and understand the implications of using endpoint deletion instead of the structured migration token path.	Endpoint deletion releases the SMP registration but does not transfer it to the new AP. The new PA must re-register independently. During the gap between deletion and re-registration, invoices addressed to the customer's PEPPOL ID will be undeliverable.
The one-year minimum service obligation has been considered.	Do not delete endpoints before the one-year minimum service period has ended. See One-year minimum service obligation below.

Important:

Residual lifecycle risk after endpoint deletion — mandatory disclosure. You must communicate the following to your end customers before executing endpoint deletion.

The following risks apply after endpoint deletion:

Inbound lifecycle statuses for invoices already transmitted through the platform (including buyer-originated Refusée, Prise en charge, Approuvée, and Paiement transmis) will either be undeliverable or routed to the new PA if its PEPPOL SMP/SML registration is already active. These statuses may arrive weeks or months after the original invoice.
Seller-initiated statuses (Encaissée for invoices where VAT is due at encaissement) do not require the outgoing platform's endpoint to be active. They can be submitted by the seller through their new PA or other means.
After the customer's SMP migration is finalized on the new PA, inbound lifecycle statuses for all subsequent documents will route to the new PA, not to the outgoing platform. The residual risk is therefore confined to the window between endpoint deletion and the new PA's SMP registration becoming active.
Customers should make sure their new PA is operationally ready to receive lifecycle statuses before endpoint deletion is executed.

Annuaire deletion behavior — handling previous action by the new PA

When endpoint deletion is triggered, the platform attempts to remove the company's entry from the Central Directory (Annuaire PPF). The new PA may have already updated or overridden the Annuaire entry before this call is made, because they are entitled to do so after following the mandatory DGFIP procedure.

The platform handles this transparently:

If the Annuaire entry is already absent or no longer attributed to the partner's AP, the platform proceeds without error and completes the endpoint deletion on CN.
The outcome (entry deleted, or already absent) is recorded in the audit log.
The caller gets a success response in both cases.

Do not pre-check the Annuaire state before calling the endpoint deletion API. The platform handles both cases. The same behavior applies to the Annuaire deletion step in the migration token flow (step 4).

Note:

No entitlement validation. The platform does not verify whether the new PA held the required customer consent (opt-in form or accord formel) before they acted on the Annuaire. That is a matter between the customer, the new PA (who must contact the outgoing PA under the mandatory procedure), and the governing French regulatory framework. The platform releases the registration on the instruction of the authorized role triggering the API call.

Available API methods for endpoint deletion:: For the endpoint deletion methods available in the CN API, see Company endpoints in the API reference. The relevant methods cover deleting an endpoint by ID, asynchronously requesting deletion of all endpoints for a company, and retrieving the status of a bulk deletion request.

Regulatory obligations during the offboarding window

24-hour status transmission deadline

Source:: Dossier général v3.2, §3.6.5 (invoice data) and §3.6.6 (lifecycle statuses).

The platform is required to transmit mandatory lifecycle statuses and Flow 1 invoice data to the PPF within 24 hours of the status timestamp. The following conditions apply to this deadline:

Runs from the timestamp of the status event, not from when the platform receives or processes it.
Accounts for batching (allotissement) — batching must be designed so that no status exceeds the 24-hour window.
Does not pause or reset during offboarding.

Any status pending at the time of endpoint deletion is still subject to this deadline. This is why confirming that the queue is clear is mandatory before endpoint deletion is triggered.

One-year minimum service obligation

Source:: Finance Act 2026, Article 123, amending Article 289 bis III of the Code Général des Impôts (CGI); cited in Dossier général v3.2, §3.5.5.5. The implementing decree (Décret n°2026-677 du 27 juillet 2026) has been published and defines this obligation in Article 242 nonies E quater of Annex II to the CGI.

French law requires the outgoing PA to continue providing minimum services for at least one year after a PA change. The minimum services covered include the following:

Making lifecycle status information available to users.
Enabling users to update processing statuses where applicable.
Transmitting status information to the administration and to the accredited platforms of the parties to the transactions.

In practice, this obligation applies primarily to the window before the customer's SMP migration is complete. After the SMP migration to the new PA is finalized (step 3 of the migration token flow), inbound lifecycle statuses for documents issued after that point will route to the new PA, not to the outgoing platform. The one-year obligation therefore applies to the residual tail of documents transmitted before the effective PA change date for which lifecycle statuses may still be outstanding.

To meet this obligation, do not delete company endpoints until the one-year minimum service period has ended. Deleting endpoints before this period ends prevents the outgoing PA from processing documents or lifecycle statuses received after termination. Make sure your end customers understand this before initiating offboarding. The platform does not block the offboarding action based on elapsed time since registration. Compliance with the one-year window is the customer's responsibility to manage.

Important:

Implementing decree published. Décret n°2026-677 du 27 juillet 2026 defines the scope of "services minimaux" in Article 242 nonies E quater of Annex II to the CGI. The obligation covers lifecycle status processing for documents transmitted during the active period — making statuses available, enabling user updates, and transmitting to the administration and counterparty PAs. The minimum service period is one year from the effective date of the PA change.

Clarification on the "48-hour" migration token requirement

Some partners have referenced a "48-hour" pre-provisioning requirement for the migration token. The following table gives the correct framing.


Topic	Correct position
The requirement	The correct requirement is four calendar days, not 48 calendar hours or two working days. The outgoing PA must make the migration token available no later than four calendar days before the effective date of the corresponding Annuaire address lines.
The source	AIFE Processus Choix PA et mobilité V1.2 (AIFE, August 10, 2026), Step 6. Note that the earlier PEPPOL France EIA v1.2.0 stated two working days; the AIFE guide (published later) is the current authoritative operational document and specifies four calendar days.
Is it a DGFiP regulatory obligation?	No. This is an operational network rule. It does not appear in the Dossier général v3.2, XP Z12-012 V1.4, or XP Z12-014 V1.4. Do not cite it as a DGFiP statutory requirement in customer-facing content.
Who is bound by it?	Any PA receiving a migration request from another PA, including partners operating a virtual AP on the Sovos platform in their capacity as an accredited PA. The Sovos platform provides the API mechanism to retrieve and issue the token. The scheduling discipline and PA-level obligation rest with the partner.

Future offboarding capabilities

Sovos will continue to expand France offboarding capabilities. Additional capabilities are planned, including company lifecycle state management in Network Services, data extraction, data deletion, and other elements identified in the offboarding initiative. No ETAs are available at this time.