01
Vous pouvez changer de Plateforme Agréée ; la nouvelle PA porte la démarche d’annuaire
Service Public Entreprendre indique qu’une entreprise peut changer de Plateforme Agréée à tout moment si la solution ne répond plus à ses besoins. L’article 242 nonies E ter précise que, lorsqu’une nouvelle PA est désignée pour la réception, cette plateforme d’arrivée effectue les formalités liées au changement et à l’actualisation des informations d’adressage dans l’annuaire central. Cela évite de traiter la migration comme une simple modification locale dans l’ERP. Le point de contrôle est l’annuaire réellement mis à jour pour les adresses concernées, avec une confirmation exploitable de la nouvelle plateforme.
- Identifier la plateforme de départ, la plateforme d’arrivée et le périmètre exact des adresses de facturation concernées.
- Ne pas considérer la signature commerciale comme la preuve que l’annuaire a déjà basculé.
- Conserver la confirmation de mise à jour et la date effective utilisée pour le plan de cutover.
02
L’accord formel doit décrire la volonté de changer et le périmètre d’adressage
Le droit en vigueur demande à la nouvelle plateforme de disposer d’un accord formel permettant l’actualisation de l’annuaire. Cet accord identifie notamment l’entreprise, la plateforme désignée pour la réception, l’ancienne plateforme le cas échéant, la date souhaitée de prise d’effet et le périmètre des adresses concernées. Il est daté, signé et numéroté par la plateforme d’arrivée. Pour l’équipe projet, cette pièce sert de frontière claire entre une intention de migration et une demande effectivement autorisée. Les contrats, pouvoirs de signature et périmètres techniques doivent être alignés avant la bascule.
- Vérifier l’identité de l’entreprise et le mandat de la personne qui autorise le changement.
- Faire correspondre le périmètre signé avec les entités, SIREN/SIRET et adresses réellement utilisés dans les flux.
- Archiver l’accord et les références de migration avec les preuves de cutover.
03
Planifier les délais réglementaires : 2 jours, 5 jours, puis jusqu’à 15 jours ouvrables
L’article 242 nonies E ter prévoit une séquence précise. Dans les deux jours ouvrables suivant la réception de l’accord formel, la plateforme d’arrivée communique son numéro à la plateforme de départ. Celle-ci dispose ensuite de cinq jours ouvrables pour s’opposer au changement, avec des motifs limités à des éléments remettant en cause la volonté réelle de l’entreprise. Après l’accord tacite ou exprès, la plateforme d’arrivée dispose de quinze jours ouvrables pour inscrire dans l’annuaire central les informations nécessaires à l’adressage et informer l’entreprise de l’actualisation. Utilisez ces délais pour construire le runbook de migration au lieu de promettre une bascule instantanée.
- Jour de demande : horodater l’accord formel et le périmètre.
- Suivre séparément notification à l’ancienne PA, période d’opposition et mise à jour de l’annuaire.
- Ne fermer le ticket de migration qu’après confirmation de l’adressage et tests de réception.
04
Préserver la continuité : l’ancienne plateforme garde des obligations après le changement
Service Public Entreprendre précise qu’après le changement, l’ancienne plateforme continue pendant un an à assurer certains services afin de garantir la continuité de réception des factures électroniques. À la demande de l’entreprise, elle transmet aussi à la nouvelle plateforme les informations nécessaires à la continuité de l’activité dans un délai de cinq jours ouvrés. Cette période ne doit pas être confondue avec un fonctionnement normal en double plateforme. Définissez quelle plateforme est autoritative pour les nouvelles opérations, comment les historiques et statuts sont consultés et quel mécanisme de rapprochement traite les factures arrivées pendant la transition.
- Inventorier les données et statuts à récupérer avant de résilier les accès opérationnels utiles.
- Définir un owner pour les factures reçues ou mises à disposition pendant la période de transition.
- Tester la continuité sans créer deux circuits actifs qui pourraient déclencher des traitements en double.
05
Tester le nouveau chemin avec un corpus représentatif — sans confondre pré-validation et mobilité réglementaire
Avant de considérer la migration comme réussie, testez les flux que votre organisation utilise réellement : formats, identifiants, routage, réception, statuts, erreurs, réconciliation et accès aux preuves. Un test de fichier propre n’est pas une preuve que l’annuaire a été actualisé, qu’un flux a été remis au bon destinataire ou que la continuité entre plateformes fonctionne. InvoiceBatch FR peut aider à pré-valider un corpus structuré et à regrouper les défauts de données ou de mapping avant une migration, mais il ne change pas votre Plateforme Agréée, ne met pas à jour l’annuaire, ne transfère pas les historiques et ne certifie pas la réussite de la bascule réglementaire.
- Prélever un corpus couvrant les principaux systèmes sources et variantes métier.
- Conserver séparément preuve locale de validation, preuve d’annuaire et preuve externe de transmission/réception.
- Traiter toute issue inconnue comme une réconciliation à résoudre, pas comme un succès implicite.
Étape suivante
Passer du guide à une vérification concrète.
InvoiceBatch FR reste un preflight technique de corpus : il ne remplace pas votre ERP ou votre Plateforme Agréée et ne constitue ni une certification ni une preuve de transmission.
Pré-valider un corpus avant migration (EN)Sources officielles
Ces sources cadrent les affirmations réglementaires de cette page. Les contrats et API d’une PA réelle doivent en plus être vérifiés auprès du fournisseur concerné.