Factur-X : générable maintenant n’est pas prêt à transmettre

Une équipe importe une facture dans son ERP. Les données économiques sont suffisamment complètes pour produire un candidat Factur-X. Pourtant, l’adresse électronique de l’acheteur reste à confirmer, une mention liée aux conditions de paiement doit être ajoutée et aucune plateforme agréée n’a encore reçu le document.

Faut-il bloquer la génération ? Non, pas automatiquement. Faut-il annoncer que la facture est prête pour la réforme française ou déjà transmise ? Non plus.

Ces deux réponses ne sont pas contradictoires. Elles décrivent des étapes différentes. Un document peut être générable maintenant, encore incomplet pour la cible française de septembre, non routé et jamais transmis. Une architecture qui fusionne ces états fait généralement l’une de ces deux erreurs : elle immobilise un flux techniquement exploitable, ou elle transforme une possibilité locale en promesse réglementaire qu’elle ne peut pas prouver.

Dans Pourquoi valider une facture électronique ne se résume pas à « valide / invalide », nous distinguions neuf niveaux de diagnostic. Ici, la question devient plus opérationnelle : qu’est-ce qui empêche réellement de générer, et qu’est-ce qui appartient aux étapes suivantes ?

En bref

• Quatre gates distinctes : source comprise, candidat générable/généré, préparation France et routage, transmission externe.
• « Générable maintenant » ne prouve ni préparation France 2026, ni routage, ni dépôt, ni acceptation.
• Six repères de préparation (BT-23, BT-34, BT-49, PMT, PMD, AAB) ne sont ni la liste légale exhaustive, ni six champs manuels, ni six erreurs, ni six blocages de génération.
• Un diagnostic documentaire et une transformation documentaire restent distincts de la transmission officielle.
• FacturX API n’est pas une Plateforme Agréée et ne revendique pas d’acceptation fiscale finale.

Les quatre gates à ne pas fusionner

Une chaîne fiable devrait prendre quatre décisions séparées. Chacune possède son objet, ses bloqueurs et sa preuve.

Cette séparation protège deux vérités contraires mais compatibles : un flux peut encore produire un candidat local utile, tout en restant incomplet pour la cible, le routage ou la transmission. Un candidat ne doit jamais être confondu avec un simple badge logique : le fichier doit exister et être revalidé.

Ce qui bloque la génération, et ce qui ne la bloque pas

La décision « peut-on générer maintenant ? » ne devrait gouverner qu’une seule question : peut-on lancer maintenant l’opération qui matérialisera un candidat ?

Un blocage de génération est justifié lorsqu’un obstacle rend cette opération impossible ou dangereusement ambiguë : la source n’est pas une facture, des données économiques indispensables sont introuvables, deux valeurs essentielles se contredisent sans règle de résolution, ou le système ne connaît pas le profil qu’il est censé produire.

À l’inverse, une exigence nécessaire avant transmission ne devrait pas désactiver la génération locale par défaut. Elle peut conserver un état incomplet dans la gate France ou routage, avec son action propre, tout en laissant la génération exécutable.

Il faut donc distinguer quatre propositions :

Confondre ces quatre propositions revient à faire passer une capacité, un artefact, une préparation et un événement externe pour une seule vérité.

Une interface de décision fiable devrait donc nommer ces verbes séparément, sans les fusionner dans un badge unique :

• diagnostic (comprendre la source) ;
• transformation (matérialiser un candidat lorsque le contrat de génération le permet) ;
• profil non exécuté restant non évalué, jamais « conforme par défaut » ;
• transmission / acceptation uniquement avec preuve d’un acteur externe.

Ce modèle de décision n’est pas une promesse runtime figée d’un parcours public précis : il décrit ce qu’il faut exiger d’une architecture documentaire avant d’automatiser.

Six repères du modèle de préparation, pas six champs manuels

Le calendrier légal maintient le démarrage au 1er septembre 2026 : toutes les entreprises doivent pouvoir recevoir des factures électroniques ; les grandes entreprises et les ETI doivent également émettre à cette date, tandis que l’obligation d’émission des PME et microentreprises intervient au plus tard le 1er septembre 2027. L’émission, la transmission et la réception dans le champ de l’article 289 bis du CGI s’effectuent en recourant à une plateforme agréée. Voir le guide pratique de démarrage de la DGFiP et l’article 289 bis du CGI.

Le tableau ci-dessous décrit six repères techniques d’un modèle de préparation souvent suivis pour anticiper septembre : BT-23, BT-34, BT-49, PMT, PMD et AAB. Ce n’est pas la liste exhaustive des obligations françaises, pas six erreurs, pas six champs que l’utilisateur devrait systématiquement saisir, et pas six blocages de génération. Les quatre nouvelles mentions légales du ministère restent la référence publique pour le découpage réglementaire des mentions (voir plus bas).

La norme expérimentale XP Z12-012 publiée sur impots.gouv.fr relie BT-23 au cadre de facturation, BT-34 et BT-49 aux adresses électroniques du vendeur et de l’acheteur lorsque la facture doit être transmise avec des statuts de cycle de vie, et PMT, PMD, AAB à trois notes portant respectivement sur l’indemnité forfaitaire de recouvrement, les pénalités de retard et l’escompte ou son absence. Les formulations du tableau sont des repères de préparation, pas une lecture réglementaire exhaustive.

Ces six identités ne doivent pas être confondues avec les quatre nouvelles mentions légales présentées par le ministère de l’Économie pour le 1er septembre 2026 : Siren du client, catégorie de l’opération, option de paiement de la TVA sur les débits le cas échéant et adresse de livraison lorsqu’elle diffère de l’adresse de facturation. Les deux listes répondent à des découpages différents. Les fusionner ou présenter les six comme un inventaire légal complet serait trompeur. Voir la fiche officielle du ministère.

Une exigence n’est pas une action utilisateur

Pour chaque identité, le système devrait stocker séparément quatre informations : son applicabilité à la cible, son état de satisfaction, le mode de résolution et son impact sur la génération.

Une obligation de septembre peut donc être :

• déjà satisfaite, sans aucune action ;
• réparable automatiquement, à partir d’une source autoritative ou d’une règle déterministe ;
• à confirmer, lorsque le système possède une proposition crédible mais pas la preuve suffisante ;
• à choisir, lorsqu’une décision métier entre plusieurs valeurs valides appartient à l’entreprise ;
• réellement absente, lorsqu’aucune extraction, donnée maître, règle ou référentiel ne permet de la récupérer ;
• ou totalement distincte d’une recommandation optionnelle, qui ne doit jamais dupliquer une identité obligatoire.

Une même identité ne devrait apparaître qu’une fois dans le contrat décisionnel. Par exemple, PMD ne peut pas être simultanément classée « exigence septembre » et « amélioration optionnelle ». Son caractère requis pour la cible est une propriété ; son état et son action en sont d’autres.

Un enregistrement conceptuel pourrait ressembler à ceci :

{
  "id": "BT-23",
  "target": "FR_SEPT_2026",
  "requiredForTarget": true,
  "state": "to_confirm",
  "resolution": "business_confirmation",
  "blocksGeneration": false
}

Il s’agit d’une recommandation d’architecture, pas d’un contrat d’endpoint figé. Le point important est le modèle de décision : l’exigence reste visible pour la préparation France sans transformer automatiquement la génération en échec.

Trois décisions concrètes, trois vérités différentes

1. La source suffit pour générer, mais le routage reste ouvert

Prenons un cas synthétique : lignes, taxes, parties et conditions de paiement sont exploitables. Le cadre de facturation peut être déterminé avec une confiance suffisante, et les notes de paiement proviennent de données maîtres validées. En revanche, l’adresse électronique de l’acheteur n’est pas encore résolue.

La bonne décision est : génération exécutable, candidat à matérialiser et valider, préparation de routage incomplète, transmission non tentée. Désactiver la génération à cause de BT-49 ferait perdre un résultat utile. Déclarer la facture « prête à transmettre » ignorerait un manque réel.

2. Une correction déterministe ne justifie pas un formulaire

Un second cas synthétique présente un défaut de précision que le moteur peut corriger sans modifier l’intention économique, avec un journal de transformation. La correction doit produire un nouveau candidat et un nouveau rapport de validation. Elle ne devrait pas devenir une question adressée à la DAF simplement parce qu’une règle a échoué.

Les exigences de septembre restent visibles, mais chacune reçoit la bonne action : « déjà satisfaite », « corrigée automatiquement », « à confirmer » ou « à renseigner ». Le nombre d’exigences ne devient pas le nombre de champs affichés.

3. Un candidat prêt n’est pas un accusé de plateforme

Même si le candidat satisfait les contrôles ciblés et si les adresses de facturation électronique sont connues, la transmission reste un événement externe. Une solution compatible non immatriculée ne peut pas s’attribuer le rôle d’une plateforme agréée ; l’administration précise qu’elle n’est pas autorisée, à elle seule, à transmettre les factures aux plateformes des clients ou à recevoir les factures pour leur compte. Voir la documentation DGFiP sur les plateformes agréées.

Le statut doit rester not_attempted tant qu’aucune tentative n’a eu lieu. Après l’envoi, des états comme « déposé », « rejeté », « reçu » ou « accepté » doivent être rattachés à une preuve externe, et non déduits d’une validation locale.

Pourquoi cette séparation accélère réellement les projets

Pour un éditeur, les quatre gates permettent de lancer les conversions exploitables sans attendre que chaque client ait finalisé son routage. Pour une DAF, elles donnent un pilotage honnête : combien de sources sont compréhensibles, combien de candidats existent, combien satisfont la cible, combien disposent d’un routage et combien ont un statut externe prouvé.

Elles réduisent aussi le travail manuel. Une règle technique ne devient une tâche utilisateur que si la donnée est réellement absente, non calculable, non récupérable et que l’utilisateur est bien l’autorité compétente. Tout le reste relève d’une extraction, d’une réparation, d’un choix assisté ou d’une confirmation ciblée.

Enfin, elles protègent la promesse commerciale. « Nous pouvons produire un candidat maintenant » est une capacité locale vérifiable. « Cette facture est prête France 2026 » exige une cible et des règles versionnées. « Elle a été transmise et acceptée » exige une preuve émise hors du validateur.

Le guide pratique de démarrage de la DGFiP recommande d’ailleurs aux entreprises soumises à l’émission de ne pas attendre que tout leur périmètre soit stabilisé : les flux déjà prêts doivent entrer dans le circuit. Cette progressivité opérationnelle renforce l’intérêt d’états séparés ; elle ne dispense évidemment pas de satisfaire les obligations applicables au flux effectivement transmis.

Ce qu’il faut demander à une API ou à un logiciel de gestion

Avant de choisir un système, demandez-lui de montrer précisément :

1. la règle qui décide si la génération est exécutable, sans y mélanger les exigences de transmission ;
2. l’artefact produit lorsque la génération est annoncée, avec son empreinte et son rapport ;
3. les six repères de préparation, chacun présent une seule fois avec état, provenance et action ;
4. la distinction entre donnée absente, correction automatique, choix métier et confirmation ;
5. la preuve qui autorise chaque statut de routage ou de transmission.

Une démonstration qui s’arrête à un badge vert ou à un bouton actif ne répond pas à ces questions.

Positionnement FacturX API — sans promesse runtime non prouvée

FacturX API se positionne comme brique de préparation documentaire, pas comme Plateforme Agréée ni canal de transmission officielle. Voir FacturX API n’est pas une Plateforme Agréée.

Dans le vocabulaire produit utile à retenir :

• un scan public est un diagnostic documentaire, pas une transmission ni une acceptation PA ;
• une conversion vise une transformation documentaire lorsque les données et le contrat le permettent ;
• un profil ou une couche non exécutée doit rester non évaluée, jamais « OK » par omission ;
• aucun statut de dépôt, réception ou acceptation ne doit être déduit d’une seule validation locale.

Les sections ci-dessus décrivent un modèle de décision à exiger d’une architecture. Elles ne constituent pas une attestation que chaque séparation, chaque repère septembre ou chaque preuve de candidat est déjà exposée de façon identique sur toutes les surfaces publiques déployées. Avant d’automatiser un flux critique, demandez une démonstration bornée aux cas et aux preuves réellement disponibles.

Pour le détail EN16931 vs France CTC, voir EN16931 validé, France CTC à corriger.

Sources officielles

• DGFiP — Guide pratique de démarrage au 1er septembre 2026
• DGFiP — Foire aux questions — Je découvre la facturation électronique
• Légifrance — Article 289 bis du CGI
• Ministère de l’Économie — Tout savoir sur la facturation électronique pour les entreprises
• DGFiP / AFNOR — Factures — norme AFNOR / XP Z12-012
• DGFiP — Facturation électronique et plateformes agréées
• AIFE — Facturation électronique interentreprises
• FNFE-MPE — Ressources

Le calendrier, les liens et les versions de règles doivent être revérifiés au moment de la lecture.

Articles liés

• Réparer ou reconstruire une facture électronique
• PDF et XML embarqué se contredisent : quelle représentation croire ?
• Un candidat généré sans fichier, hash, diff ni omissions explicites n’est pas une preuve
• Pourquoi valider une facture électronique ne se résume pas à « valide / invalide »
• EN16931 validé, France CTC à corriger
• FacturX API n’est pas une Plateforme Agréée
• Convertir une facture PDF en Factur-X
• Checklist développeur facturation électronique septembre 2026