La facturation électronique ne consiste pas seulement à générer une facture au format PDF.
Pour les logiciels métier, back-offices, outils de gestion et applications SaaS, l’enjeu est de connecter le système existant à une plateforme agréée, transmettre les factures, recevoir les statuts, gérer les erreurs et historiser les échanges.
Cette connexion passe généralement par une API ou par un connecteur intermédiaire capable de faire le lien entre le logiciel métier et les services de facturation électronique.
Codisys accompagne cette architecture avec son expertise en intégration de la facturation électronique.
Vous pouvez aussi vérifier une facture Factur-X avec l’outil Codisys avant de l’intégrer dans un flux API ou de l’envoyer vers une plateforme.
Calendrier réglementaire à anticiper
À date du 22 mai 2026, le calendrier officiel prévoit l’obligation de réception des factures électroniques pour toutes les entreprises à partir du 1er septembre 2026.
L’obligation d’émission démarre le 1er septembre 2026 pour les grandes entreprises et les ETI, puis le 1er septembre 2027 pour les PME, TPE et micro-entreprises.
Source officielle : Service Public Entreprendre, facturation électronique.
Pourquoi une API est nécessaire pour la facturation électronique
Un logiciel métier doit pouvoir échanger automatiquement avec une plateforme de facturation électronique.
L’API permet de transmettre les données de facture, récupérer les statuts, consulter les erreurs, suivre le cycle de vie et mettre à jour le back-office.
Sans API ou connecteur, les utilisateurs risquent de devoir réaliser des opérations manuelles : exporter les factures, les importer ailleurs, vérifier les statuts séparément et ressaisir les informations dans le logiciel métier.
Pour le rôle général des intégrations, consultez notre guide sur les API et connecteurs pour logiciel métier.
Le rôle des plateformes agréées
Dans le cadre de la réforme, les factures électroniques devront transiter par des plateformes agréées par l’État.
Un logiciel métier peut se connecter directement à une plateforme, ou passer par un service intermédiaire capable de centraliser les échanges.
Le choix dépend de l’architecture existante, du nombre d’applications concernées, des besoins de supervision et du niveau d’automatisation attendu.
Les ressources de la DGFiP rappellent que les entreprises devront désigner une plateforme pour émettre et recevoir leurs factures électroniques ou déclarer leurs données. Source : impots.gouv.fr, facturation électronique en 4 questions.
API directe ou connecteur intermédiaire ?
Deux approches sont possibles.
La première consiste à connecter directement le logiciel métier à l’API d’une plateforme agréée.
La seconde consiste à créer un connecteur ou service intermédiaire entre le logiciel métier et la plateforme.
Le service intermédiaire peut être utile lorsque plusieurs applications doivent utiliser les mêmes flux de facturation électronique, ou lorsque l’on souhaite centraliser les journaux, les statuts, les erreurs et les accès API.
Avantages d’un service intermédiaire
- mutualiser les appels API,
- éviter de dupliquer le connecteur dans plusieurs logiciels,
- centraliser les clés techniques,
- historiser tous les échanges,
- gérer les erreurs dans un seul endroit,
- simplifier les applications métier,
- faciliter la supervision,
- préparer l’évolution vers plusieurs plateformes.
Ce que doit faire un connecteur de facturation électronique
Un connecteur de facturation électronique ne se limite pas à envoyer une facture.
Il doit préparer les données, transmettre les éléments attendus, recevoir les retours, interpréter les statuts, gérer les erreurs et mettre à jour le logiciel métier.
Il doit aussi fournir une traçabilité suffisante pour comprendre ce qui a été transmis, quand, avec quel résultat.
Fonctions possibles
- préparer les données de facture,
- contrôler les champs obligatoires,
- transmettre la facture,
- récupérer les statuts,
- gérer les rejets,
- recevoir les factures fournisseurs,
- traiter les erreurs API,
- relancer un traitement,
- historiser les échanges,
- notifier les utilisateurs,
- mettre à jour le back-office,
- archiver les références techniques.
Données à préparer avant l’envoi
Avant d’envoyer une facture via API, le logiciel métier doit disposer de données fiables.
Une API ne compense pas des fiches clients incomplètes, des taux de TVA mal renseignés, des adresses absentes ou des règles de facturation incohérentes.
La préparation des données est donc une étape essentielle.
Les sources officielles rappellent que la réforme implique aussi de nouvelles mentions obligatoires sur les factures, ce qui peut nécessiter une adaptation des données collectées par le logiciel. Source : Service Public Entreprendre, mentions obligatoires sur une facture.
Données à vérifier
- identité de l’émetteur,
- identité du client,
- identifiants d’entreprise,
- adresse de facturation,
- lignes de facture,
- montants hors taxe et TTC,
- taux de TVA,
- dates,
- numéro de facture,
- références internes,
- mentions obligatoires,
- statut de la facture,
- dossier métier associé.
Contrôle des données avant transmission
Un connecteur doit contrôler les données avant transmission.
Cette vérification permet d’éviter l’envoi de factures incomplètes ou incorrectes.
Lorsque les informations sont absentes ou incohérentes, le logiciel doit afficher un message clair à l’utilisateur afin qu’il puisse corriger la facture avant envoi.
Contrôles possibles
- client complet,
- adresse valide,
- identifiant renseigné,
- lignes de facture présentes,
- montants cohérents,
- TVA correctement définie,
- date de facture présente,
- numéro de facture conforme,
- mentions obligatoires complètes,
- statut autorisant l’envoi.
Transmission des factures via API
La transmission via API permet d’envoyer la facture vers la plateforme agréée ou vers un service intermédiaire.
Le logiciel métier doit ensuite conserver une référence de transmission afin de pouvoir suivre l’état de la facture.
Cette référence permet de rapprocher la facture interne avec son traitement dans le circuit de facturation électronique.
Informations à conserver
- identifiant interne de la facture,
- référence externe,
- plateforme utilisée,
- date d’envoi,
- utilisateur à l’origine de l’action,
- statut initial,
- réponse API,
- erreur éventuelle,
- horodatage de la tentative.
Récupération des statuts
La récupération des statuts est l’un des points les plus importants.
Une fois la facture transmise, le logiciel métier doit pouvoir connaître son état : envoyée, reçue, rejetée, refusée, acceptée, en anomalie ou traitée.
Ces statuts doivent être affichés de manière compréhensible dans le back-office.
Cette partie rejoint les back-offices et outils de gestion.
Exemples de statuts internes
- brouillon,
- prête à transmettre,
- en cours d’envoi,
- transmise,
- en attente de statut,
- reçue par la plateforme,
- rejetée,
- refusée,
- acceptée,
- à corriger,
- traitement terminé,
- archivée.
Statuts techniques et statuts métier
Il faut distinguer les statuts techniques et les statuts métier.
Un statut technique indique ce qui s’est passé dans l’échange API : appel réussi, erreur d’authentification, donnée invalide, délai dépassé ou service indisponible.
Un statut métier indique l’état de la facture dans le processus : à envoyer, envoyée, rejetée, acceptée, payée ou archivée.
Le rôle du connecteur est de transformer les retours techniques en informations compréhensibles pour l’utilisateur.
Gestion des erreurs API
Une API peut échouer pour plusieurs raisons.
Le service externe peut être temporairement indisponible, une donnée peut être invalide, une clé API peut être expirée ou une facture peut être rejetée.
Le logiciel métier doit gérer ces cas proprement afin que l’utilisateur sache quoi faire.
Types d’erreurs possibles
- erreur d’authentification,
- donnée obligatoire absente,
- format invalide,
- client non reconnu,
- facture déjà transmise,
- rejet de facture,
- indisponibilité temporaire,
- délai d’attente dépassé,
- erreur réseau,
- erreur interne du connecteur.
Messages compréhensibles pour les utilisateurs
Les erreurs techniques ne doivent pas être affichées telles quelles aux utilisateurs métier.
Un message API brut peut être incompréhensible pour une personne qui gère la facturation.
Il est préférable de traduire ces erreurs en messages clairs : donnée manquante, facture à corriger, service temporairement indisponible ou action à relancer.
Exemple : au lieu d’afficher un code technique comme invalid_customer_identifier, le back-office peut indiquer que l’identifiant de l’entreprise cliente est manquant ou invalide.
Relance des traitements
Certains échecs peuvent être temporaires.
Le connecteur doit donc permettre de relancer un traitement lorsque cela est pertinent : nouvel appel API, récupération de statut, réenvoi après correction ou reprise d’un échange interrompu.
Il faut toutefois éviter les relances automatiques incontrôlées, notamment lorsque l’erreur vient d’une donnée métier incorrecte.
Bonnes pratiques de relance
- distinguer erreur temporaire et erreur métier,
- conserver l’historique des tentatives,
- limiter les relances automatiques,
- permettre une relance manuelle,
- afficher le dernier message d’erreur,
- bloquer les relances si la facture doit être corrigée.
Journalisation des échanges
La journalisation est indispensable pour une intégration de facturation électronique.
Chaque appel API, statut reçu, erreur, correction ou relance doit pouvoir être retrouvé.
Ces journaux facilitent le support, la maintenance, les audits internes et la compréhension des incidents.
Éléments à journaliser
- facture concernée,
- action réalisée,
- date et heure,
- utilisateur ou service,
- plateforme appelée,
- statut reçu,
- erreur éventuelle,
- référence externe,
- tentative de relance,
- résultat final.
Réception des factures fournisseurs
La réception des factures électroniques doit aussi être prévue.
Le logiciel peut devoir récupérer les factures fournisseurs, les associer à un fournisseur, les rapprocher d’un dossier interne, afficher leur statut ou permettre une validation administrative.
Même si l’émission n’est pas immédiatement obligatoire pour toutes les entreprises, la réception est généralisée dès le 1er septembre 2026, selon le calendrier officiel.
Fonctions de réception possibles
- récupérer les factures reçues,
- associer une facture à un fournisseur,
- afficher les documents associés,
- suivre les statuts,
- permettre une validation interne,
- rapprocher une facture d’un dossier,
- exporter vers la comptabilité,
- historiser les traitements.
Émission des factures clients
L’émission des factures clients nécessite une préparation plus complète.
Le logiciel doit permettre de produire la facture, vérifier les données, transmettre les informations et suivre les statuts jusqu’à la fin du traitement.
L’obligation d’émission est progressive : grandes entreprises et ETI au 1er septembre 2026, puis PME, TPE et micro-entreprises au 1er septembre 2027.
Pour une vue d’ensemble, consultez notre guide pour intégrer la facturation électronique dans un logiciel métier.
E-reporting et données de transaction
Selon les cas, le logiciel métier peut aussi devoir préparer des données liées à l’e-reporting.
Ces flux doivent être distingués des factures électroniques elles-mêmes.
L’architecture doit donc séparer les données de facturation, les statuts, les données de transaction et les informations utilisées uniquement pour le suivi interne.
Facturation électronique et annuaire
L’annuaire de la facturation électronique joue un rôle important dans le routage des factures.
Il permet d’identifier la plateforme associée à une entreprise ou à une entité concernée.
Pour un logiciel métier, cela peut impliquer de prévoir des informations permettant de rapprocher correctement le client, son identifiant et sa plateforme de réception.
L’AIFE présente l’annuaire comme le référentiel qui recense les entreprises et entités publiques concernées et indique la plateforme agréée qui gère leurs données et adresses de facturation. Source : AIFE, facturation électronique interentreprises.
Sécurité des clés API et des accès
Une intégration API manipule des données sensibles : factures, clients, montants, statuts et identifiants d’entreprise.
Les clés API, jetons d’accès et secrets techniques doivent donc être protégés.
Il faut éviter de les stocker en clair dans le code applicatif ou de les exposer à des utilisateurs non autorisés.
Bonnes pratiques de sécurité
- stocker les secrets dans un espace sécurisé,
- séparer test et production,
- limiter les droits des clés API,
- tracer les appels,
- prévoir une rotation des secrets,
- protéger les échanges,
- limiter les données exposées,
- contrôler les droits utilisateurs.
Environnement de test
Avant de connecter la facturation électronique en production, il est important de tester les flux.
Un environnement de test permet de vérifier les données, les statuts, les erreurs, les relances et la bonne mise à jour du logiciel métier.
Les tests doivent couvrir les cas simples et les cas d’échec.
Cas à tester
- facture correcte,
- donnée client manquante,
- identifiant invalide,
- facture rejetée,
- récupération de statut,
- erreur API temporaire,
- relance après correction,
- réception d’une facture fournisseur,
- affichage dans le back-office.
Supervision des flux
Une fois le connecteur en production, il faut pouvoir superviser les flux.
La supervision permet de repérer les factures bloquées, les erreurs récurrentes, les statuts non récupérés ou les échanges interrompus.
Sans supervision, les problèmes peuvent rester invisibles jusqu’à ce qu’un utilisateur constate une anomalie.
Indicateurs utiles
- factures en attente,
- factures rejetées,
- erreurs API,
- statuts non récupérés,
- relances nécessaires,
- temps moyen de traitement,
- dernières transmissions,
- factures fournisseurs reçues,
- flux en erreur.
Back-office de suivi
Le back-office doit rendre la facturation électronique compréhensible.
Les utilisateurs doivent pouvoir voir où en est chaque facture, quelles actions sont nécessaires et quelles erreurs doivent être corrigées.
Le back-office peut aussi proposer des filtres, des alertes, des exports et des journaux de traitement.
Fonctions utiles dans le back-office
- liste des factures par statut,
- détail d’une facture,
- dernier retour plateforme,
- historique des échanges,
- bouton de relance,
- message d’erreur lisible,
- filtres par date ou client,
- indicateurs de suivi,
- lien vers le dossier métier.
Connecteur mutualisé pour plusieurs applications
Lorsqu’une structure possède plusieurs logiciels, il peut être intéressant de mutualiser le connecteur de facturation électronique.
Un service central peut recevoir les demandes de plusieurs applications, les transmettre à la plateforme agréée, récupérer les statuts et renvoyer les informations aux applications concernées.
Cette approche évite de dupliquer le même connecteur dans chaque logiciel.
Applications concernées
- logiciel métier,
- back-office interne,
- application SaaS,
- outil de facturation,
- portail client,
- application administrative,
- service de génération documentaire.
Exemple : Formadmin
Formadmin, solution éditée par Codisys, doit progressivement intégrer les nouveaux usages liés à la facturation électronique.
Dans ce contexte, un connecteur API peut permettre de transmettre les factures, recevoir les statuts, gérer les erreurs et suivre les traitements depuis le back-office.
L’objectif est de conserver un usage simple pour les organismes de formation, tout en intégrant les contraintes techniques des nouveaux flux.
Exemple d’architecture technique
Une architecture possible consiste à séparer le logiciel métier du connecteur de facturation électronique.
Le logiciel métier reste responsable des données, des factures, des utilisateurs et de l’interface.
Le connecteur gère les échanges avec la plateforme agréée, les appels API, les journaux, les erreurs et les statuts.
Cette séparation rend l’ensemble plus maintenable.
Exemple de flux
- l’utilisateur valide une facture dans le logiciel métier,
- le logiciel vérifie les données obligatoires,
- le connecteur reçoit la demande,
- le connecteur transmet la facture via API,
- la plateforme retourne une référence ou un statut,
- le connecteur journalise la réponse,
- le logiciel métier met à jour la facture,
- l’utilisateur suit le statut dans le back-office.
Les erreurs à éviter
Une intégration API de facturation électronique peut devenir fragile si elle est conçue trop rapidement.
Il faut éviter de limiter le projet à un simple bouton “envoyer la facture”.
Les statuts, erreurs, journaux, droits, reprises et tests sont aussi importants que l’envoi initial.
Erreurs fréquentes
- ne pas vérifier les données avant l’envoi,
- ignorer la réception des statuts,
- ne pas gérer les rejets,
- ne pas journaliser les appels API,
- exposer les erreurs techniques aux utilisateurs,
- stocker les clés API dans le code,
- ne pas prévoir de relance,
- ne pas tester les cas d’échec,
- dupliquer le connecteur dans plusieurs applications,
- oublier la réception des factures fournisseurs.
Comment réussir une intégration API de facturation électronique ?
La réussite repose sur une démarche progressive.
Il faut commencer par analyser les données existantes, définir l’architecture, choisir le mode de connexion, concevoir les statuts, gérer les erreurs et tester les flux avant la mise en production.
L’objectif est de créer une intégration fiable, compréhensible et maintenable.
Étapes recommandées
- analyser les données de facturation,
- vérifier les mentions obligatoires,
- définir le mode d’intégration,
- choisir connexion directe ou service intermédiaire,
- concevoir les statuts internes,
- développer le connecteur API,
- journaliser les échanges,
- gérer les erreurs et rejets,
- tester les scénarios simples et complexes,
- afficher le suivi dans le back-office,
- superviser les flux,
- maintenir le connecteur dans le temps.
Pourquoi faire appel à Codisys ?
Codisys accompagne les structures qui souhaitent connecter leurs logiciels métier, back-offices ou applications SaaS à des services externes.
Pour la facturation électronique, nous pouvons concevoir un connecteur API, un service intermédiaire, un back-office de suivi ou une intégration progressive dans votre outil existant.
Notre approche consiste à rendre les flux techniques compréhensibles pour les utilisateurs : statuts clairs, erreurs exploitables, historique, sécurité et maintenance.
Elle s’appuie sur nos expertises en intégration de la facturation électronique, API, connecteurs et intégrations logicielles, automatisation des processus métier et maintenance et évolution logicielle.
Conclusion
L’API est au cœur de l’intégration de la facturation électronique dans un logiciel métier.
Elle permet de transmettre les factures, récupérer les statuts, gérer les erreurs, recevoir les factures fournisseurs et mettre à jour le back-office.
Pour être fiable, cette intégration doit être pensée comme un véritable processus métier : données propres, statuts compréhensibles, journaux, sécurité, relances, supervision et maintenance.