Generix Group nomme Sophie Pietremont en tant que Directrice Marketing & Communication Groupe Lire le communiqué de presse
Points essentiels à retenir
À gérer dès la préparation 2026 : les statuts obligatoires attendus par le PPF, les statuts recommandés utiles au pilotage finance, et vos statuts internes ERP. L’enjeu n’est pas de créer une liste de plus, mais de transformer chaque statut en événement exploitable.
Au 28 juillet 2026, la page impots.gouv.fr dédiée aux spécifications externes et normes pour la facturation électronique, modifiée le 02/07/2026, indique que la version applicable des spécifications externes est la V3.2 du 30/04/2026 pour la facturation électronique BtoB, GtoB et BtoG. Cette base doit être votre référentiel de cadrage, avec les documents normatifs AFNOR associés.
Le ministère de l’Économie rappelle aussi que l’obligation de réception démarre le 1er septembre 2026 pour toutes les entreprises assujetties à la TVA, puis que l’émission se généralise progressivement entre septembre 2026 et septembre 2027. Le calendrier doit donc être traduit dans vos backlogs ERP, interfaces, workflows AP/AR et procédures support, et pas seulement dans un planning réglementaire.
Generix recommande de distinguer trois familles. Les statuts obligatoires sont ceux qui doivent remonter au PPF via les plateformes agréées : ils relèvent de la conformité. Les statuts recommandés structurent le pilotage opérationnel : mise à disposition, prise en charge, suspendue, en litige, approuvée, approuvée partiellement, paiement transmis ou complétée selon les cas. Les statuts libres correspondent enfin à vos besoins internes : contrôle litige niveau 2, relance bloquée, validation trésorerie, ou escalade support.
Cette séparation évite une erreur fréquente : confondre le statut réglementaire et l’état comptable de la facture. Une facture peut être déposée au sens cycle de vie, mais encore en attente de comptabilisation fournisseur dans votre ERP. À l’inverse, un statut interne « bon à payer » ne devient pas automatiquement un statut à transmettre au PPF.
Pour le vocabulaire de base, vous pouvez renvoyer vos équipes à notre définition de la facture électronique, puis utiliser cet article comme guide d’exécution pour le câblage des statuts.
Le même libellé n’a pas le même impact selon son émetteur. Dans votre cartographie, Generix conseille d’indiquer systématiquement : l’acteur qui déclenche le statut, la plateforme qui le relaie, l’objet concerné, le flux technique et l’action ERP attendue.
La FAQ AIFE/Chorus Pro précise que le PPF prend en charge les flux F1 pour les données réglementaires e-invoicing, F10 pour les données e-reporting et F6 pour le flux cycle de vie. Dans nos projets, nous faisons donc porter la gouvernance sur deux niveaux : le flux technique transmis et l’objet métier facture suivi dans l’ERP.
La PA doit transmettre quatre statuts obligatoires au PPF : « Déposée », « Rejetée », « Refusée » et « Encaissée ». Le rôle de l’ERP est de fournir ou de consommer les données nécessaires sans ambiguïté sur l’émetteur, le motif et l’horodatage.
La FAQ AIFE consultée en juillet 2026 indique explicitement que les statuts « Déposée », « Encaissée », « Rejetée » et « Refusée » doivent obligatoirement être transmis au PPF. Elle précise aussi leurs émetteurs : plateforme d’émission pour « Déposée », plateforme d’émission ou de réception pour « Rejetée », acheteur via sa plateforme pour « Refusée », vendeur via sa plateforme pour « Encaissée ».
Le statut « Déposée » signale que la facture a été transmise à la plateforme de réception. Dans l’ERP vendeur, il doit au minimum verrouiller la preuve de dépôt, enregistrer l’identifiant de facture et alimenter le suivi client. Il ne signifie pas que l’acheteur a accepté la facture.
Le statut « Rejetée » traduit un blocage détecté par une plateforme : non-conformité, adressage, incohérence ou impossibilité de traitement. Notre recommandation est de le router vers une file de correction technique ou fonctionnelle, avec motif normalisé, responsable et possibilité de rejeu contrôlé.
Le statut « Refusée » correspond à une décision métier de l’acheteur. Il doit être traité par les équipes finance, administration des ventes ou relation client : qualification du litige, suspension de relance si nécessaire, émission d’un avoir ou d’une facture rectificative selon le cas.
Le statut « Encaissée » est émis côté vendeur et doit être rapproché des informations de paiement, de lettrage et de TVA à l’encaissement lorsque l’opération est concernée. Il appelle une collaboration étroite entre ERP, trésorerie et plateforme agréée.
L’encaissement est plus sensible qu’un simple statut de suivi. La FAQ AIFE indique qu’au démarrage de la réforme en septembre 2026, la date de création du cycle de vie « Encaissée » sera prise en compte pour le pré-remplissage de la TVA ; elle signale aussi une évolution prévue en 2027 pour intégrer une date d’encaissement distincte. Votre ERP doit donc prévoir la traçabilité de la date, du montant, de la devise le cas échéant, du rapprochement et des ventilations TVA.
Dans notre approche, le statut « Encaissée » ne doit pas être généré par défaut à partir d’un simple paiement bancaire importé. Il doit résulter d’une règle maîtrisée : rapprochement facture-paiement, traitement des paiements partiels, prise en compte des avoirs, annulation ou correction si un statut erroné a été transmis.
Le bon mapping ERP associe chaque statut à un déclencheur métier, un événement système, une action attendue et une preuve. Sans cette table de correspondance, les statuts restent des messages techniques difficiles à exploiter par la DAF, l’IT et le support.
Le tableau ci-dessous est un modèle de travail. Generix l’utilise comme base de discussion entre finance, DSI, intégration et équipes métier afin d’éviter les interprétations divergentes entre émission, réception et recouvrement.
| Statut clé | Déclencheur métier | Événement ERP | Action attendue | Responsable principal |
|---|---|---|---|---|
| Déposée | Facture transmise à la plateforme de réception | Passage en suivi d’émission, preuve de dépôt horodatée | Surveiller la suite du cycle de vie et bloquer les modifications non autorisées | Comptabilité clients / ADV |
| Rejetée | Blocage par la plateforme d’émission ou de réception | Création d’une anomalie avec code motif | Corriger, générer un nouveau flux si nécessaire, tracer le rejeu | Support facturation / IT intégration |
| Refusée | Décision métier de l’acheteur | Ouverture d’un dossier litige | Qualifier le motif, suspendre la relance, décider avoir ou rectificative | Credit management / relation client |
| Mise à disposition | Facture rendue disponible côté réception | Notification de réception attendue | Déclencher le workflow AP ou le rapprochement commande-réception-facture | Comptabilité fournisseurs |
| Prise en charge | Facture entrée dans le processus acheteur | Passage en traitement fournisseur | Suivre validation, litige ou approbation | AP / approbateur métier |
| En litige | Désaccord métier ou documentaire | Gel du paiement ou du recouvrement selon le sens | Documenter le motif et piloter la résolution | Finance / métier demandeur |
| Approuvée ou approuvée partiellement | Validation totale ou partielle par l’acheteur | Mise à jour du bon à payer ou du reste dû | Préparer paiement, lettrage ou ajustement | AP / trésorerie |
| Paiement transmis | Information de paiement émise | Attente d’encaissement ou rapprochement bancaire | Surveiller l’écart entre paiement annoncé et encaissement réel | Trésorerie |
| Encaissée | Encaissement rapproché côté vendeur | Lettrage ou encaissement partiel | Transmettre le statut selon le périmètre applicable et conserver la preuve | Comptabilité clients / trésorerie |
Votre modèle de données doit éviter les champs « fourre-tout ». Generix recommande de créer des attributs dédiés pour l’identifiant unique de facture, l’identifiant de flux, le statut cycle de vie reçu ou émis, le code motif, le libellé motif, l’horodatage, le montant concerné, le statut comptable, l’utilisateur ou groupe responsable, et le lien vers la preuve.
Si votre ERP ne peut pas porter tous ces champs nativement, un middleware ou un référentiel de supervision peut conserver les détails techniques, à condition que les événements utiles soient renvoyés dans l’ERP. L’objectif est simple : une équipe finance doit savoir quoi faire sans ouvrir un journal technique, tandis que l’IT doit pouvoir diagnostiquer sans reconstituer le cycle de vie manuellement.
Pour les mentions de facture à contrôler en amont, notre article sur les nouvelles mentions obligatoires de la facture électronique dans l’ERP complète ce guide, sans remplacer la table de mapping des statuts.
Rejetée et Refusée ne veulent pas dire la même chose. Le rejet relève d’un blocage technique ou fonctionnel détecté par une plateforme ; le refus est une décision métier de l’acheteur. Les deux cas exigent une traçabilité stricte.
Un rejet doit être traité comme une anomalie contrôlée. La FAQ AIFE cite notamment des motifs tels que REJ_INC, REJ_INEX, REJ_RG, REJ_HAB ou REJ_ENCAISSEMENT pour les rejets liés aux statuts. Elle précise aussi des motifs d’adressage tels que DEST_INC, ADR_ERR ou REJ_ADR. Dans vos workflows, ces motifs doivent orienter la file de traitement : données facture, adressage, habilitation, cohérence d’encaissement ou règle de gestion.
Le rejeu ne doit jamais écraser la preuve initiale. Notre préconisation est de conserver le flux rejeté, le motif, l’utilisateur ou service correcteur, la correction appliquée, le nouvel identifiant de flux si nécessaire et le résultat du rejeu. Cette piste d’audit protège à la fois la conformité fiscale, le contrôle interne et la relation client.
Un refus ne se corrige pas comme une erreur syntaxique. Il faut d’abord qualifier le motif : prix contesté, quantité, prestation non réalisée, mauvais destinataire, commande absente, condition contractuelle ou litige commercial. Selon le cas, l’action peut être une explication, un avoir, une facture rectificative ou une nouvelle émission.
Dans nos projets, nous recommandons de lier le statut « Refusée » au module de recouvrement ou de credit management. La relance automatique doit être suspendue si le refus est recevable, ou maintenue avec justification si le refus est contesté. Le point clé est de documenter la décision : qui a qualifié, sur quelle base, avec quelle action et quel impact sur l’encours client.
Les statuts de cycle de vie modifient l’order-to-cash car ils donnent une visibilité partagée sur dépôt, rejet, refus, paiement transmis et encaissement. Bien exploités, ils aident à prioriser le cash plutôt qu’à relancer toutes les factures de la même façon.
Le ministère de l’Économie souligne que la facturation électronique doit améliorer la traçabilité, les relations commerciales et le respect des délais de paiement dans sa page Tout savoir sur la facturation électronique pour les entreprises. Pour Generix, cette promesse devient opérationnelle uniquement si les statuts alimentent réellement vos processus de lettrage et de recouvrement.
Un ERP doit rapprocher quatre dimensions : le statut de cycle de vie, l’échéance contractuelle, l’information de paiement et l’encaissement bancaire. Une facture déposée mais non mise à disposition n’appelle pas la même action qu’une facture approuvée mais non payée. Une facture avec paiement transmis mais sans encaissement exige une surveillance trésorerie, pas forcément une relance commerciale immédiate.
Les paiements partiels sont un point d’attention. Votre mapping doit préciser si l’événement ERP porte sur le montant total, un montant partiel, un solde restant dû ou une ventilation par taux de TVA. Cette granularité évite des erreurs de lettrage et des incohérences lors de la transmission du statut « Encaissée ».
Dans une logique order-to-cash automatisée, les statuts doivent alimenter les règles de priorité. Une facture refusée avec motif prix passe en résolution litige ; une facture approuvée et échue passe en relance ; une facture rejetée pour adressage revient au support facturation ; une facture encaissée sort du portefeuille de relance.
Cette segmentation réduit les relances inutiles et améliore l’expérience client. Elle donne aussi à la DAF une vision plus fiable du cash prévisionnel : factures émises, factures acceptées, factures contestées, montants annoncés comme payés, montants réellement encaissés.
Le câblage SI doit être événementiel : chaque statut entrant ou sortant déclenche une mise à jour ERP, une supervision, une règle métier et une preuve. Le choix API, EDI, fichier ou middleware dépend de vos volumes, de votre ERP et de votre gouvernance.
Une intégration API convient aux échanges fréquents, aux besoins de quasi temps réel et aux architectures modernes. L’EDI reste pertinent pour les environnements B2B structurés, multi-partenaires et à forte volumétrie. Les fichiers peuvent suffire pour des périmètres limités, mais ils doivent être strictement supervisés. Le middleware est souvent nécessaire lorsque plusieurs ERP, outils de facturation, portails clients ou systèmes de trésorerie coexistent.
La FAQ AIFE distingue les retours synchrones et asynchrones : les cycles de vie de flux F1, F6 et F10 ont un délai inférieur à une minute, tandis que les cycles de vie d’objet métier F1 et F6 sont asynchrones avec un délai maximum d’une heure. Votre supervision doit donc gérer l’attente normale avant de déclencher une alerte.
Notre logiciel EDI SaaS Generix s’inscrit dans cette logique d’intégration B2B : plus de 300 interconnexions, une présence dans 50 pays et 3 000 mappings préconstruits documentés sur notre page EDI. Ces capacités servent le câblage et la supervision ; elles ne se substituent pas aux obligations réglementaires.
La supervision doit montrer l’état du flux et l’état de la facture. Un flux peut être recevable alors qu’un objet métier est rejeté ultérieurement. À l’inverse, l’absence de retour dans un délai attendu peut être normale ou anormale selon le type de cycle de vie. Cette distinction doit être comprise par le support niveau 1 comme par l’équipe intégration.
Generix recommande une gouvernance des codes motifs en trois couches : codes réglementaires et normatifs, codes techniques d’intégration, codes métier internes. Chaque code doit avoir un propriétaire, une règle de routage, une sévérité, un délai cible et une procédure de reprise. C’est cette discipline qui évite de transformer la réforme en empilement de fichiers d’erreurs.
Le plan de test doit prouver le cycle complet : émission conforme, rejet, refus, encaissement, avoir, facture rectificative, doublon, adressage et reprise sur erreur. Tester uniquement une facture nominale ne suffit pas pour sécuriser la bascule.
La page officielle des plateformes agréées indique que l’immatriculation définitive est accordée après réussite des tests d’interopérabilité en conditions réelles, et que les plateformes agréées doivent émettre, transmettre, recevoir les factures et transmettre les données utiles à l’administration. Votre plan de test entreprise doit compléter ces tests de plateforme par des scénarios ERP et métier.
Generix recommande au minimum les jeux d’essai suivants :
Un test est accepté seulement si les trois fonctions valident. La finance vérifie le sens métier, les écritures, le lettrage, la relance et les impacts TVA. L’IT vérifie les flux, identifiants, horodatages, rejets, rejeux et alertes. Le support vérifie la lisibilité des messages, les files de traitement, les délais et les procédures de résolution.
Dans notre méthode, chaque scénario doit produire une preuve : capture de supervision, journal ERP, événement de workflow, message transmis ou reçu, décision métier et résultat final. Cette approche permet de passer d’un test technique à une répétition générale du processus finance.
Les statuts deviennent utiles lorsqu’ils sont partagés entre PA, ERP, workflows finance, EDI/API et partenaires. Une architecture collaborative évite les silos : conformité fiscale d’un côté, comptabilité de l’autre, intégration à part et relation client en décalage.
La réforme impose un langage commun, mais chaque entreprise doit décider comment l’exploiter. Si la PA connaît le statut, mais que l’ERP ne le reçoit pas, la finance continue à travailler à l’aveugle. Si l’ERP reçoit un code sans motif exploitable, le support multiplie les analyses manuelles. Si le recouvrement ignore les refus et litiges, la relation client se dégrade.
L’approche collaborative consiste à définir un référentiel partagé : statuts, motifs, règles d’orchestration, responsabilités, preuves et indicateurs. Elle relie la conformité au pilotage opérationnel : factures déposées, factures rejetées, refus en cours, montants approuvés, paiements transmis, encaissements rapprochés.
Generix dispose d’une Plateforme Agréée immatriculée DGFiP n°0002. La liste officielle publiée par l’administration confirme la présence de GENERIX Group parmi les opérateurs satisfaisant aux conditions, incluant les tests d’interopérabilité, dans la publication impots.gouv.fr sur les plateformes agréées.
Notre différenciation tient à l’association entre PA, intégration B2B et pilotage des cycles de vie. Nous ne traitons pas les statuts comme un simple retour réglementaire : nous les connectons aux processus finance, aux interfaces ERP, aux workflows d’exception et à la supervision des échanges.
Pour cadrer votre préparation, nous pouvons vous aider à formaliser votre mapping ERP, vos scénarios de test, vos règles de rejet/refus, votre supervision et votre gouvernance des motifs. Vous pouvez demander un diagnostic de câblage des statuts avec notre Plateforme Agréée Generix pour la facturation électronique.
En résumé
Les quatre statuts obligatoires sont Déposée, Rejetée, Refusée et Encaissée. Ils doivent être transmis au PPF par les plateformes agréées selon l’acteur et le cas de gestion concernés.
Le statut « Déposée » est émis par la plateforme d’émission. Il signale au PPF que la facture concernée a bien été transmise à la plateforme de réception, sans préjuger de son traitement métier ultérieur par l’acheteur.
Une facture rejetée correspond à un blocage technique ou fonctionnel détecté par une plateforme : non-conformité, adressage, incohérence ou règle non respectée. Une facture refusée traduit une décision métier de l’acheteur, par exemple un litige sur prix, quantité, commande ou prestation.
Le statut « Encaissée » fait partie des quatre statuts obligatoires à transmettre au PPF selon la FAQ AIFE. Son traitement doit être vérifié dans les spécifications en vigueur, notamment pour les opérations concernées par la TVA à l’encaissement et pour la gestion des montants partiels.
Les statuts recommandés utiles à l’ERP incluent notamment mise à disposition, prise en charge, suspendue, en litige, approuvée, approuvée partiellement, paiement transmis et complétée. Leur utilité dépend de vos workflows AP/AR, de vos règles de recouvrement et de votre niveau d’automatisation.
Le mapping doit associer chaque statut à un sens entrant ou sortant, un déclencheur, un champ ERP, un workflow, une action attendue, un responsable et une preuve horodatée. Il faut aussi prévoir les codes motifs, les montants concernés et les règles de reprise sur erreur.
Il faut qualifier le motif du refus, geler le recouvrement si le litige est recevable, puis décider de l’action : justification, avoir, facture rectificative ou nouvelle émission selon le cas. La décision et les preuves doivent être conservées dans la piste d’audit.
Le plan de test doit couvrir au minimum : émission conforme, rejet PA, refus acheteur, encaissement, avoir, facture rectificative, doublon, absence d’adressage et reprise sur erreur. Chaque scénario doit être validé par la finance, l’IT et le support avec une preuve exploitable.
Avant 2026, la fiabilité de vos SIRET, codes de routage et services destinataires conditionne le bon acheminement des factures électroniques entre ERP, plateformes agréées et partenaires B2B.
Le Code de commerce encadre le plafond, la preuve, le délai et la déduction d’office des pénalités logistiques. Découvrez comment qualifier, documenter et contester un avis avec des preuves WMS, TMS, EDI et POD.
Travaillez avec nos équipes pour concevoir et mettre en œuvre la Supply Chain qui accompagnera votre croissance, adaptée à vos spécificités métier.
