SSolarc Labs

Validation Factur-X

Validation Factur-X : contrôler le PDF, le XML et le profil

Valider Factur-X demande davantage que d’ouvrir un PDF. Il faut prouver que le document contient bien les données structurées attendues, identifier le profil, exécuter les contrôles de structure et de règles, puis regarder si les mêmes défauts se répètent dans la production de l’ERP. Une facture isolée peut masquer un défaut de mapping systémique qui n’apparaît qu’à l’échelle du corpus.

Revu le 2026-08-30•Sources officielles DGFiP

01

Étape 1 : vérifier qu’il s’agit réellement d’un document Factur-X

Commencez par la nature du fichier et l’existence du XML embarqué. Rejetez la tentation de traiter un PDF sans données structurées comme un équivalent. La détection doit rester stricte, notamment face aux fichiers endommagés, aux pièces jointes inattendues ou aux profils déclarés de manière incohérente. La recette doit conserver le hash du fichier original pour que le résultat reste rattaché à l’entrée testée.

  • Présence du XML structuré attendu.
  • Détection explicite du profil et des métadonnées nécessaires.
  • Empreinte SHA-256 de l’entrée avant toute interprétation.

02

Étape 2 : structure et règles applicables

Une validation robuste distingue au moins la structure XML des règles sémantiques ou de profil. Si une couche nécessaire n’a pas été exécutée, le résultat ne doit pas être présenté comme clair. Cette approche fail-closed évite un faux positif lorsque le moteur Schematron, une ressource de règles ou une dépendance de validation est absente. Le rapport doit montrer quelle couche a réellement été exécutée.

  • XSD : structure syntaxique attendue.
  • Schematron et règles : contraintes de profil et de métier applicables.
  • État `not_run` visible lorsqu’une couche requise n’a pas été exécutée.

03

Étape 3 : passer du fichier au problème de source

Après la validation document par document, regroupez les findings par règle, terme métier et système source. Si le même identifiant client manque sur vingt factures, l’action utile est de corriger le mapping ERP plutôt que de traiter vingt lignes séparément. Le re-test doit ensuite comparer les blockers résolus, inchangés et nouveaux sans écraser la preuve initiale. C’est cette boucle qui transforme un validateur en outil de recette de cutover.

  • Clusteriser les erreurs récurrentes.
  • Relier le finding au champ ou mapping source quand l’information existe.
  • Conserver l’état avant/après correction pour l’hypercare.

Étape suivante

Passer du guide à une vérification concrète.

InvoiceBatch FR reste un preflight technique de corpus : il ne remplace pas votre ERP ou votre Plateforme Agréée et ne constitue ni une certification ni une preuve de transmission.

Voir un pack de preuves synthétique (EN)

Sources officielles

Ces sources cadrent les affirmations réglementaires de cette page. Les contrats et API d’une PA réelle doivent en plus être vérifiés auprès du fournisseur concerné.