SSolarc Labs

Checklist fournisseur

10 questions à poser à votre logiciel ou intégrateur pendant le go-live 2026

« Compatible facturation électronique » n’est pas assez précis pour exploiter un go-live. Cette checklist transforme la promesse commerciale en dix questions observables à poser à l’éditeur du logiciel, à l’intégrateur ou au cabinet qui vous accompagne. Le but n’est pas de remplacer leur contrat ni de certifier la solution : il est de savoir qui fait quoi, quelle plateforme agréée intervient, quelles sorties sont réellement produites et quelles preuves vous pouvez voir lorsque le flux fonctionne ou échoue.

Revu le 2026-09-01•Sources officielles DGFiP
À propos de ce modèle. Checklist opérationnelle indépendante, non officielle. Vérifiez vos obligations exactes auprès de la DGFiP et les fonctions, délais, contrats et API auprès de votre fournisseur ou de la plateforme agréée concernée.

01

Questions 1 à 4 : rôle, plateforme et état réel du go-live

Commencez par la chaîne de responsabilité. Demandez : 1) notre outil est-il une plateforme agréée ou une solution raccordée à une plateforme ? 2) quelle plateforme agréée exécute effectivement la réception et la transmission ? 3) quelles fonctions sont opérationnelles pour nous aujourd’hui, notamment la réception et, si notre calendrier l’exige, l’émission ? 4) quelles étapes restent de notre côté : activation, mandat, paramétrage, données ou migration ? Notez les réponses avec le nom de l’interlocuteur et la version de l’offre concernée.

  • Nom et statut de la plateforme réellement utilisée.
  • Fonctions opérationnelles aujourd’hui et limites connues.
  • Actions client restantes, owner et date cible.

02

Questions 5 à 7 : formats, données et scénarios réels

Demandez ensuite : 5) quels formats ou profils sont produits ou acceptés pour nos factures ? 6) comment notre logiciel transforme-t-il les données actuelles en champs structurés obligatoires ? 7) pouvons-nous tester plusieurs factures représentatives issues de nos vraies sources et reproduire un défaut observé ? Une réponse qui se limite à « nous générons un PDF » mérite d’être clarifiée : la DGFiP distingue le PDF ordinaire envoyé par mail du document électronique structuré transmis par le dispositif.

  • Format et profil explicitement nommés.
  • Mapping ou provenance des données métier critiques expliqué.
  • Cas de test représentatifs convenus, pas seulement une facture de démonstration.

03

Questions 8 à 10 : rejets, preuves et responsabilité après incident

Terminez par l’exploitation : 8) quels statuts, accusés ou reçus pouvons-nous consulter après une soumission ? 9) comment sont traités un rejet, un timeout ou un état externe inconnu sans créer de doublon ? 10) qui corrige quoi lorsqu’un défaut vient de notre donnée source, du mapping, du routage ou du transport ? Demandez une réponse qui peut être testée et rejouée. L’hypercare est plus solide lorsque chaque erreur a une classe, un owner et une preuve de re-test plutôt qu’un simple ticket fermé.

  • Statuts et reçus accessibles et corrélables à la facture.
  • Procédure de réconciliation avant tout retry ambigu.
  • RACI clair pour donnée, mapping, route et transport.

É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.

Voir le brief intégrateur

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é.