Facture électronique : pourquoi « valide » ne suffit pas

Un fichier arrive dans une GED, un ERP ou une API. Le validateur répond false. Que faut-il faire ensuite ? Rejeter le document ? Corriger un champ ? Extraire les données visibles du PDF ? Régénérer un XML ? Demander une information au fournisseur ? Attendre qu’une plateforme confirme la transmission ?

Le booléen ne le dit pas. Il peut recouvrir un fichier illisible, un document qui n’est pas une facture, un XML mal formé, une règle métier non respectée, des totaux incohérents, un conflit entre le PDF et l’XML, ou simplement une facture techniquement générable mais pas encore prête pour le régime de transmission visé.

Une facture peut être lisible mais non conforme, conforme mais pas prête à transmettre, réparable sans être reconstruite, ou générable immédiatement tout en nécessitant encore du travail avant transmission. Un unique booléen détruit cette information.

En bref

« Valide » n’a de sens qu’avec un objet contrôlé, une cible et une preuve.
Un diagnostic utile sépare au moins neuf niveaux : conteneur, nature, extraction, syntaxe, règles métier, cohérence, réparation, préparation à la transmission, résultat externe.
Un scan FacturX API est un diagnostic documentaire. Il ne prouve ni transmission officielle, ni acceptation par une Plateforme Agréée.
Un profil non exécuté doit rester non évalué, jamais « OK » par omission.
La conformité d’un fichier ne constitue pas une preuve de transmission.

« Valide » n’a de sens qu’avec un objet, une cible et une preuve

La Commission européenne décrit EN 16931-1 comme le modèle sémantique de la facture électronique et son ensemble de règles métier. Ce modèle peut être porté par des syntaxes XML, notamment UBL 2.1 et UN/CEFACT CII. Le registre européen des artefacts de validation publie notamment des règles et des fichiers Schematron.

La FNFE-MPE présente Factur-X comme une facture hybride : un PDF lisible pour l’humain et des données XML destinées au traitement automatisé. Cette dualité est utile, mais elle crée aussi une question supplémentaire : les deux représentations décrivent-elles réellement la même opération ?

Dire « valide » sans préciser l’objet contrôlé laisse plusieurs ambiguïtés ouvertes. A-t-on validé le conteneur PDF, l’XML embarqué, la facture source, un candidat réparé, un profil donné, une cible française ou un retour de plateforme ? Une même chaîne peut répondre positivement à une question et négativement à la suivante.

Pour la différence concrète entre socle EN16931 et contrôles France CTC, voir EN16931 validé, France CTC à corriger.

Les neuf niveaux à séparer dans un diagnostic fiable

Un système utile ne remplace pas nécessairement tout verdict global. Il conserve plutôt les dimensions qui permettent de comprendre ce verdict et de décider quoi faire.

Niveau	Question à trancher	Preuve attendue	Exemples d’états utiles
1. Lecture du conteneur	Le fichier peut-il être ouvert et ses composants parcourus ?	Type MIME, structure PDF ou XML, pièces jointes, erreurs de lecture	`lisible`, `illisible`, `limite_dépassée`
2. Identification documentaire	S’agit-il d’une facture, d’un avoir, d’un message de cycle de vie ou d’un autre objet ?	Racine XML, métadonnées, indices concordants, niveau de confiance	`facture`, `avoir`, `message_statut`, `inconnu`
3. Extraction des données	Quelles valeurs ont été trouvées et d’où viennent-elles ?	Valeur, emplacement, provenance, confiance	`structuré`, `visible`, `calculé`, `inféré`
4. Validation syntaxique	La représentation respecte-t-elle la syntaxe et la version sélectionnées ?	Schéma et règles techniques adaptés, versions identifiées	`pass`, `fail`, `non_exécuté`
5. Validation métier	Les termes et règles du profil sémantique ciblé sont-ils respectés ?	Rapport par règle, profil et cible nommés	`conforme`, `non_conforme`, `non_applicable`
6. Cohérence économique et PDF/XML	Les lignes, taxes, totaux et représentations concordent-ils ?	Réconciliation des calculs et conflits par champ	`cohérent`, `écart`, `conflit_de_représentation`
7. Réparation ou génération	Une opération déterministe peut-elle produire un candidat ?	Plan de correction, données requises, artefact candidat	`réparable`, `générable`, `entrée_humaine_requise`
8. Préparation à la transmission	Le candidat satisfait-il la cible réglementaire et le routage visés ?	Cible versionnée, mentions, adressage, plateforme, contrôles requis	`prêt`, `incomplet`, `hors_périmètre`
9. Résultat réel de transmission	Le document a-t-il été envoyé, reçu ou accepté dans le canal externe ?	Accusé, identifiant d’échange, horodatage, statut de plateforme	`non_tenté`, `envoyé`, `rejeté`, `accepté`

Les termes exacts peuvent varier d’un système à l’autre. L’invariant important est que l’échec d’un niveau ne réécrive pas silencieusement les autres. Un problème de routage ne rend pas le PDF illisible. Un XML syntaxiquement correct ne prouve pas que les totaux sont cohérents. Un candidat généré ne prouve pas qu’il a été transmis.

Quand un profil n’a pas été exécuté, le rapport doit le dire explicitement : non évalué, avec la cause. Ce n’est ni un succès, ni un échec inventé.

Trois exemples qui montrent pourquoi le booléen échoue

1. Le fichier est lisible, mais ce n’est pas une facture

Un message XML de cycle de vie associé à une facture peut être parfaitement lisible. Il ne doit pourtant pas passer dans une chaîne de validation de facture ni dans un convertisseur PDF. L’action utile est de valider le message, de le rapprocher de la bonne facture, puis d’appliquer éventuellement le statut métier.

Un verdict unique invalide masque la nature de l’objet. Pire, un moteur centré uniquement sur la facture peut inventer des « champs manquants », demander un PDF ou proposer une génération sans rapport avec le besoin réel. Le bon diagnostic ressemble plutôt à : conteneur lisible, objet identifié comme message de cycle de vie, validation facture non applicable, rapprochement requis.

2. Le PDF et l’XML sont exploitables, mais ils se contredisent

Dans une facture hybride, le rendu visible et les données structurées embarquées peuvent fournir des informations exploitables tout en décrivant des opérations différentes. Pris séparément, chacun paraît utile. Ensemble, ils forment un conflit majeur.

Le système ne doit ni choisir silencieusement l’XML parce qu’il est structuré, ni choisir automatiquement le PDF parce qu’il est visible. Il doit comparer les champs, exposer leur provenance et déterminer l’opération la moins destructive : conserver la représentation fiable, neutraliser ou remplacer la représentation erronée, puis produire et revalider un candidat cohérent.

Le statut utile n’est donc pas simplement invalide. Il ressemble à : hybride détecté, conflit PDF/XML, source récupérable, réparation possible, candidat non encore matérialisé.

3. Un candidat peut être générable sans être prêt à transmettre

Génération générale, préparation au régime français, routage et transmission sont des axes distincts. Des informations requises pour l’adressage ou pour une cible particulière peuvent rester à résoudre sans empêcher automatiquement la production locale d’un candidat techniquement exploitable.

Le système devrait alors annoncer deux vérités simultanées : génération possible maintenant et transmission non prête ou non tentée. Cela évite deux erreurs opposées : bloquer inutilement un flux de conversion, ou faire croire qu’un fichier généré a déjà franchi les contrôles et les étapes externes.

Cette séparation est développée dans « Générable maintenant » ne veut pas dire « prêt à transmettre ».

Passer d’un validateur à un moteur de décision

Une réponse API peut rester compacte tout en préservant les états essentiels. L’exemple suivant est conceptuel ; il illustre la séparation des preuves, pas un contrat d’endpoint figé.

{
  "artifact": { "kind": "hybrid_pdf", "readable": true },
  "document": { "kind": "invoice", "confidence": "high" },
  "source_validation": { "syntax": "pass", "business": "fail" },
  "consistency": { "pdf_xml": "conflict" },
  "resolution": { "repairable": true, "user_input_required": false },
  "candidate": { "state": "not_generated" },
  "target": { "france_regime": "incomplete", "routing": "unresolved" },
  "transmission": { "state": "not_attempted" }
}

Cette structure répond à trois besoins.

D’abord, elle nomme l’artefact contrôlé. La source, le préflight, le candidat généré et le document transmis ne sont pas interchangeables. Un candidat ne devrait être déclaré « généré » que s’il existe réellement, avec un identifiant, une empreinte, un rapport de validation propre et, lorsqu’une transformation a eu lieu, un journal des données conservées, modifiées et omises.

Ensuite, elle associe chaque constat à une preuve et à une action. Une règle technique n’est pas automatiquement une tâche utilisateur. Avant de demander une valeur, le moteur doit vérifier si elle est déjà présente dans le PDF, dans l’XML, dans une donnée maître, ou si elle peut être calculée ou corrigée de manière déterministe.

Enfin, elle distingue FAIL, NOT_RUN et NOT_APPLICABLE. Une validation non exécutée faute de sélecteur de version n’est pas un succès. À l’inverse, une validation de facture peut être non applicable à un message de statut sans rendre ce message illisible ou inutile.

Les conséquences techniques et business d’un mauvais verdict

Pour un éditeur ERP ou un intégrateur GED, un faux négatif crée de la ressaisie, des exceptions manuelles et des tickets support. Un document récupérable quitte le flux automatique alors qu’une réparation ciblée aurait suffi. À grande échelle, ce sont des délais de traitement, des coûts d’exploitation et parfois des retards de paiement.

Un faux positif est plus dangereux encore. Un fichier peut être annoncé « prêt » alors que ses totaux sont incohérents, que le candidat n’a jamais été matérialisé ou que le PDF et l’XML divergent. La chaîne aval reçoit alors une confiance que les preuves ne justifient pas.

Pour une direction financière, la bonne question n’est donc pas seulement « quel est le taux de factures valides ? », mais aussi : combien sont réparables automatiquement, combien exigent une vraie décision humaine, combien disposent d’un candidat revalidé, combien sont prêtes pour la cible choisie et combien ont effectivement reçu un statut externe ?

France 2026 : conformité du document et transmission restent deux étapes

Le calendrier officiel prévoit la réception des factures électroniques pour toutes les entreprises au 1er septembre 2026, l’émission à cette date pour les grandes entreprises et les ETI, puis au 1er septembre 2027 pour les PME, TPE et microentreprises. L’AIFE récapitule ce calendrier.

Le ministère de l’Économie précise qu’une facture électronique doit respecter une forme normée, porter ses données obligatoires dans les champs prévus et être transmise par une plateforme agréée. Le code général des impôts prévoit lui aussi le recours à une plateforme agréée pour l’émission, la transmission et la réception des factures concernées.

Il en découle une règle de conception simple : la conformité du fichier ne constitue pas une preuve de transmission. Le routage peut ne pas être résolu, l’envoi peut ne pas avoir été tenté, ou une plateforme peut retourner un rejet. Seul un événement externe traçable permet d’affirmer le résultat réel du transport ou du traitement.

FacturX API se positionne comme brique de préparation documentaire : scan, conversion, réparation et validation du document avant remise au flux officiel. Ce n’est pas une Plateforme Agréée, et ce n’est pas à lui seul le logiciel de transmission réglementaire. Voir FacturX API n’est pas une Plateforme Agréée.

Ce qu’un diagnostic public doit montrer

Un parcours public de scan utile est un diagnostic documentaire, pas une acceptation fiscale finale. Le modèle de rapport à exiger inclut au minimum :

nommer l’artefact contrôlé (PDF Factur-X, XML CII, autre) ;
séparer les couches réellement exécutées des profils non évalués ;
rattacher chaque erreur au document, pas à une transmission inventée ;
indiquer si une correction documentaire, une donnée métier ou une reprise source est pertinente ;
refuser de revendiquer un dépôt, une réception ou une acceptation PA sans preuve externe.

Ce modèle de lecture aide à évaluer un rapport. Il ne doit pas être lu comme l’attestation que chaque surface publique expose déjà tous ces axes de façon identique. Pour un guide de lecture concret, voir Lire un rapport de scan Factur-X.

Les questions à poser avant de choisir une API de validation

Demandez au fournisseur ou à l’équipe produit :

quel objet est validé ;
quelle syntaxe, version, profil et cible sont utilisés ;
comment les données PDF et XML sont rapprochées ;
quels statuts distinguent blocage, avertissement, non-exécution et non-applicabilité ;
comment une réparation produit un candidat vérifiable ;
quelle preuve sépare « prêt à transmettre » de « réellement transmis ».

Une bonne API ne doit pas seulement énumérer des erreurs. Elle doit préserver le contexte, expliquer la preuve, proposer la prochaine action utile et refuser de revendiquer les étapes qu’elle n’a pas exécutées.

Sources officielles

Commission européenne — Compliance with eInvoicing standard
Commission européenne — Required syntaxes
Commission européenne — Relevant tools
FNFE-MPE — Factur-X
Ministère de l’Économie — Tout savoir sur la facturation électronique pour les entreprises
AIFE — Facturation électronique interentreprises
Légifrance — Article 289 bis du CGI
Légifrance — Article 91 de la loi n° 2023-1322 du 29 décembre 2023

Le calendrier et la codification juridique doivent être revérifiés au moment de la lecture, car ce cadre évolue.

Vous voulez un diagnostic documentaire, pas un simple vrai / faux ?

Voici ce que vous allez obtenir :

Scan = diagnostic documentaire, pas transmission officielle
Profils exécutés vs non évalués explicitement
Erreurs rattachées au document et à la prochaine action utile
Aucune promesse d’acceptation PA ou de conformité fiscale finale

Scanner un document Créer une clé API