Rapport scan Factur-X : comprendre erreurs BR-*, PDF/A-3, XML CII et repair

Un rapport de scan Factur-X doit accélérer une décision technique : corriger automatiquement, fournir des données ERP, ou reprendre le document à la source. Si le rapport se limite à une liste d’erreurs brutes, il oblige le développeur à refaire tout le diagnostic.

Cet article explique comment lire un rapport de scan FacturX API et comment relier chaque bloc à une action concrète dans votre intégration.

En bref

• BR-* désigne une règle métier EN16931, pas forcément une erreur de structure XML.
• Une erreur PDF/A-3 peut empêcher la reconnaissance Factur-X avant même la validation du XML.
• Le XPath pointe la zone XML en cause, mais la cause racine est souvent dans le mapping ERP.
• Le verdict “FacturX corrige” indique une correction déterministe possible.
• Le verdict “ERP complète” signifie que l’ERP doit fournir une donnée connue, idéalement via invoice_data JSON.

Les blocs importants du rapport

Un bon rapport doit répondre à ces questions dans cet ordre :

1. Le fichier est-il reconnu comme PDF Factur-X ou XML CII ?
2. Le conteneur PDF/A-3 est-il correct ?
3. Le XML embarqué est-il extrait et lisible ?
4. Le profil Factur-X déclaré est-il cohérent ?
5. Les validations XSD et Schematron passent-elles ?
6. Les erreurs restantes sont-elles réparables ?
7. Quelle action faut-il lancer ensuite ?

Le diagnostic ne doit pas seulement accumuler des erreurs. Il doit les regrouper par couche, parce qu’une erreur de conteneur PDF peut masquer des erreurs XML, et une erreur de mapping ERP peut provoquer plusieurs erreurs Schematron en cascade.

Bloc 1 : état du fichier

Le premier bloc indique la nature du fichier analysé.

Si le rapport indique un PDF sans XML, le problème n’est pas Schematron. Il faut générer ou intégrer le XML CII. Le bon article de suite est Convertir une facture PDF en Factur-X 1.08 conforme.

Bloc 2 : couche PDF/A-3

Cette couche contrôle le conteneur :

• version PDF/A ;
• métadonnées XMP ;
• pièce jointe XML ;
• relation entre PDF et XML ;
• cohérence entre le profil annoncé et l’attachement.

Une erreur ici ne signifie pas forcément que les données de facture sont mauvaises. Elle peut venir d’un pipeline PDF qui convertit d’abord en PDF/A puis ajoute l’XML ensuite, ou inversement, dans un ordre qui casse les métadonnées.

Diagnostic typique :

PDF/A-3 attendu, PDF/A-1 détecté
XML embarqué trouvé, mais relation d'attachement incohérente
Métadonnées XMP Factur-X absentes

Action : regarder si le rapport classe le cas en “FacturX corrige”. Si oui, le moteur peut souvent réenvelopper le document sans changer les montants.

Bloc 3 : profil Factur-X

Le profil définit le niveau de détail attendu dans le XML.

Un profil mal déclaré peut faire échouer une facture pourtant proche de la conformité. Exemple : le XML contient des données de niveau EN16931 mais le GuidelineID annonce un autre profil.

À lire ensuite : Erreur profil Factur-X : GuidelineSpecifiedDocumentContextParameter incorrect.

Bloc 4 : XSD vs Schematron

Le rapport distingue deux familles d’erreurs.

Un fichier peut passer XSD et échouer Schematron. C’est normal : le XSD ne sait pas vérifier que BT-112 = BT-109 + BT-110.

Quand le rapport contient des erreurs BR-*, vous êtes dans la couche Schematron. Le code donne la famille :

• BR-CO-* : cohérence des montants ;
• BR-CL-* : liste de codes ;
• BR-S-*, BR-Z-*, BR-AE-* : catégories TVA ;
• BR-* simple : règle générale ou champ obligatoire.

Bloc 5 : XPath et cause racine

Le XPath indique où la règle échoue dans le XML. Il ne dit pas toujours pourquoi.

Exemple :

{
  "id": "BR-CO-14",
  "location": "/rsm:CrossIndustryInvoice/.../ram:SpecifiedTradeSettlementHeaderMonetarySummation",
  "message": "Le total TVA doit correspondre à la somme des montants TVA par catégorie."
}

Le XPath pointe le total, mais la cause peut être ailleurs :

• une ligne affectée à la mauvaise catégorie TVA ;
• un arrondi calculé globalement au lieu d’être agrégé ;
• une remise document non rattachée à la ventilation ;
• un BT-117 oublié dans une catégorie.

La bonne méthode consiste à remonter du XPath vers les Business Terms liés. Pour les montants, utilisez le graphe décrit dans Catalogue des erreurs BR-* EN16931.

Bloc 6 : verdict de correction

Le rapport FacturX API utilise trois familles de décision.

FacturX corrige

Le moteur peut appliquer une correction déterministe :

• normalisation de date ;
• correction de séparateur décimal si autorisée ;
• ajout de structure XML non ambiguë ;
• correction de métadonnées XMP ;
• réenveloppe PDF/A-3 ;
• normalisation de devise ou namespace.

Ces corrections ne doivent pas inventer de données métier. Elles sont traçables et revalidées après modification.

ERP complète

Le document manque d’une donnée que l’ERP connaît déjà : SIRET acheteur, condition de paiement, IBAN, devise, lignes, taux TVA, identifiant de facture.

Dans FacturX API, cette donnée peut être fournie au /convert via invoice_data JSON. Ce point est important : l’ERP n’a pas forcément besoin de réécrire tout son export XML. Il peut fournir les champs business au moment de l’appel API.

Cas rare

Le fichier est trop ambigu ou trop cassé pour une correction fiable :

• montants contradictoires ;
• PDF illisible ;
• XML tronqué ;
• profil déclaré incompatible avec le contenu ;
• plusieurs corrections possibles sans source de vérité.

Dans ce cas, le rapport doit aider à localiser le problème, mais la correction doit revenir au système source ou à une intervention contrôlée.

Exemple de lecture rapide

Etat fichier        PDF enveloppe invalide
Profil             EN16931
XML extrait         Oui
XSD                 OK
Schematron          3 erreurs
Verdict             ERP complète

Interprétation :

1. Le XML existe et peut être analysé.
2. L’enveloppe PDF/A-3 doit être réparée.
3. Les erreurs Schematron restantes ne sont pas des erreurs de format.
4. L’ERP doit fournir des champs métier.
5. Le flux cible est /convert avec PDF + invoice_data JSON, puis revalidation.

Sources utiles

• Facturation électronique et plateformes agréées
• Factur-X 1.08 / ZUGFeRD 2.4, FNFE-MPE
• Champs obligatoires EN16931 / Factur-X
• Valider EN16931 / Factur-X : XSD vs Schematron