Un scanner Factur-X utile ne doit pas seulement dire “valide” ou “invalide”. Avant qu’un éditeur ERP remette un document à la Plateforme Agréée choisie par son client, il doit savoir si l’erreur vient du conteneur PDF/A-3, du XML CII, d’une règle EN16931, d’un champ métier manquant, ou d’un cas réellement bloquant.
Le scanner gratuit de FacturX API sert à faire ce tri rapidement : déposer un PDF ou XML, obtenir un diagnostic lisible, puis savoir si FacturX API peut corriger le document, si des données réellement manquantes doivent être fournies au chemin indiqué par le diagnostic, ou si le fichier doit être repris plus en amont.
En bref
- La réforme impose un échange via des Plateformes Agréées à partir du 1er septembre 2026 selon le calendrier officiel.
- Factur-X combine un PDF lisible et un XML structuré. Les profils partiels ne couvrent pas tout EN16931 ; chaque contrôle doit être rattaché au profil testé.
- Un contrôle sérieux doit couvrir PDF/A-3, XML embarqué, profil Factur-X, XSD, Schematron, cohérence des montants et métadonnées XMP.
- Le diagnostic doit séparer les erreurs réparables automatiquement des données métier à fournir par l’ERP.
- Pour un éditeur ERP, ce scan est un preflight : il se place avant la remise du document à la PA du client final.
Pourquoi scanner avant la Plateforme Agréée
Une PA (ex-PDP) a un rôle central dans la réforme : elle assure l’échange des factures électroniques et la transmission des données attendues à l’administration. La page officielle impots.gouv.fr précise qu’une plateforme agréée est habilitée à assurer les fonctionnalités prévues par la réforme : émission, réception, transmission des données de factures, transactions et paiements.
Mais une PA n’est pas votre moteur de correction ERP. Si un document est non conforme, le flux peut être bloqué, rejeté ou mis en anomalie. Pour un éditeur ERP ou un intégrateur, le bon réflexe est donc de contrôler le document avant cette étape.
Le scan doit répondre à trois questions opérationnelles :
| Question | Décision attendue |
|---|---|
| Le document est-il techniquement exploitable ? | PDF/A-3 lisible, XML embarqué, namespaces corrects |
| Le contenu est-il conforme EN16931 ? | XSD + Schematron, règles BR-* sans erreur bloquante |
| Quelle action est justifiée ? | Correction XML couverte, complément ciblé, reconstruction depuis une facture JSON complète ou reprise à la source |
Les 7 contrôles à lancer
1. Présence du XML Factur-X
Un PDF peut ressembler à une facture Factur-X sans embarquer de XML CII exploitable. Le premier contrôle consiste à vérifier que le PDF contient bien une pièce jointe structurée, généralement nommée factur-x.xml ou zugferd-invoice.xml.
Si le XML est absent, il ne s’agit pas encore d’une facture Factur-X opérationnelle. Le diagnostic typique est No Factur-X XML found.
À lire ensuite : « No Factur-X XML found » : votre PDF n’embarque pas de XML CII détectable.
2. Conformité du conteneur PDF/A-3
Factur-X repose sur un conteneur PDF/A-3 parce que cette variante autorise l’intégration d’un fichier XML dans un PDF lisible. Un PDF/A-1 ou PDF/A-2 peut être archivable, mais il n’est pas le bon conteneur pour une facture hybride Factur-X.
Les erreurs fréquentes :
pdfaid:partdifférent de3- profil PDF/A incorrect ou absent
- polices non embarquées
- métadonnées XMP désynchronisées après conversion
- pièce jointe présente mais non déclarée correctement
À lire ensuite : PDF/A-3 pour Factur-X : checklist de conformité et pièges courants.
3. Déclaration XMP et AFRelationship
Le PDF doit déclarer correctement la relation entre la facture lisible et le XML embarqué. Un AFRelationship incohérent peut faire échouer la reconnaissance Factur-X même si le XML existe.
Le scan doit donc vérifier :
- la présence des métadonnées XMP Factur-X / ZUGFeRD ;
- le niveau de conformité annoncé ;
- la cohérence entre le profil annoncé et le XML réel ;
- la relation d’attachement du XML.
Quand cette couche échoue, le problème est souvent réparable sans toucher aux montants ni aux champs métier. Dans FacturX API, ces transformations du conteneur passent par /convert ; /repair reste un traitement XML en entrée et en sortie.
4. Version et profil Factur-X
La dernière publication FNFE-MPE / FeRD et sa date d’application figurent dans le repère versionné ci-dessus. Le scanner doit identifier le profil et la version réellement déclarés. Une mention de la seule série 1.09 ne suffit pas à conclure que la dernière révision publiée est exécutée.
Profils courants :
| Profil | Usage typique |
|---|---|
| MINIMUM | Données minimales, faible automatisation |
| BASIC WL | Données d’en-tête sans lignes |
| BASIC | Données structurées simples |
| EN16931 | Profil cible pour B2B France |
| EXTENDED | Cas plus riches, au-delà du noyau EN16931 |
Pour un éditeur ERP sectoriel, le profil EN16931 est souvent le point d’arrivée naturel : il transporte les données nécessaires à l’automatisation sans forcer tous les cas avancés du profil EXTENDED.
À lire ensuite : Profils Factur-X : MINIMUM → EXTENDED.
5. Validation XSD du XML CII
Le XSD vérifie la forme du XML : éléments, ordre, cardinalité, types, namespaces. C’est une étape nécessaire, mais insuffisante.
Un XML XSD-valide peut encore être refusé par Schematron si les montants ne sont pas cohérents ou si une règle métier conditionnelle échoue. C’est pour cette raison qu’un scanner Factur-X sérieux ne doit jamais s’arrêter au XSD.
Exemples d’erreurs de forme :
- namespace CII obsolète ;
- élément dans le mauvais ordre ;
- date au mauvais format ;
- montant avec virgule au lieu d’un point ;
- XML UBL envoyé dans un pipeline CII.
6. Validation Schematron EN16931
Schematron contrôle les règles métier EN16931 : cohérence des totaux, catégories TVA, champs conditionnels, listes de codes.
Les familles d’erreurs les plus utiles à remonter :
| Famille | Exemple | Cause probable |
|---|---|---|
BR-CO-* | BR-CO-14, BR-CO-15 | Calculs ou arrondis incohérents |
BR-CL-* | code devise, pays, unité | liste de codes non respectée |
BR-S-* | TVA standard | taux ou ventilation TVA incorrects |
BR-AE-* | autoliquidation | taux ou motif d’exonération absent |
BR-* | champs obligatoires | mapping ERP incomplet |
À lire ensuite : Valider EN16931 / Factur-X : XSD vs Schematron.
7. Classification de la correction
Le dernier contrôle est le plus important pour l’expérience utilisateur : que faire après le diagnostic ?
Le diagnostic doit expliquer l’action possible et ses conditions :
| Verdict | Sens opérationnel |
|---|---|
| Correction déterministe | /repair pour les transformations XML couvertes ; /convert pour reconstruire le conteneur PDF/XML, avec revalidation |
| Complément ciblé | Fournir une donnée réellement manquante au chemin invoice_patch, seller_context ou buyer_context indiqué par le diagnostic |
| Reconstruction complète | Fournir une facture entière via invoice_data ; le rendu PDF provient alors du JSON, sans analyse du PDF transmis |
| Vérification manuelle | Identifier précisément l’ambiguïté à résoudre dans le système source |
Cette distinction évite de demander une facture JSON complète pour un simple complément, ou de traiter invoice_data comme un patch partiel. Les données déjà établies par le diagnostic ne doivent pas être redemandées.
Ce qu’un scan ne doit pas promettre
Un scan ne remplace pas la PA et ne donne pas une certification légale. Il décrit les contrôles réellement exécutés. France CTC est un périmètre distinct à examiner lorsqu’il s’applique ; un contrôle non évalué ne constitue pas une réussite.
Formulations prudentes :
- “contrôles EN16931 exécutés avec succès”, uniquement si le rapport le démontre ;
- “diagnostic avant remise à votre Plateforme Agréée” ;
- “erreurs BR-* identifiées” ;
- “corrections possibles listées”.
Formulations à éviter :
- “facture certifiée” ;
- “gestion de la réception” sans préciser le rôle de la PA ;
- promesse d’archivage légal ou de transmission officielle.
Sources officielles utiles
- Facturation électronique entre entreprises, calendrier officiel
- Facturation électronique et plateformes agréées
- Liste des plateformes agréées
- Dernière publication Factur-X / ZUGFeRD, FNFE-MPE
Continuer la lecture
Articles liés
Facture rejetée par une Plateforme Agréée : workflow développeur pour diagnostiquer, réparer et revalider
Un workflow en 5 étapes pour traiter une facture Factur-X rejetée : récupérer le fichier exact, scanner, isoler PDF/A-3 vs XML CII, corriger, revalider et automatiser.
Lire l’article →Lire un rapport de scan Factur-X : BR-*, PDF/A-3, XML CII et corrections possibles
Comment interpréter un rapport de scan Factur-X : erreurs BR-*, problèmes PDF/A-3, XML CII, XMP, verdicts FacturX corrige, ERP complète et cas rare.
Lire l’article →XP Z12-012 / 013 / 014 et scan Factur-X : ce qu'un diagnostic Dolibarr peut mesurer
Les trois libellés AFNOR XP Z12 qu'un éditeur affiche vs un contrôle de fichier (PDF/A-3, XML, BR-*). Complément du diagnostic module Dolibarr — pas un substitut PA.
Lire l’article →Étape suivante recommandée
Vous voulez vérifier une facture avant qu'elle bloque plus loin ?
Voici ce que vous allez obtenir :
- Diagnostic PDF/A-3 et XML CII
- Règles BR-* lisibles
- Verdict réparation vs données ERP à fournir
- Lien direct vers l'automatisation API si le cas se répète