Facture rejetée par une Plateforme Agréée : diagnostic Factur-X EN16931 et repair

Une facture rejetée ne doit pas déclencher une chasse aux hypothèses. Le bon réflexe est de repartir du fichier exact qui a été refusé, de le scanner, puis de séparer les problèmes en couches : PDF/A-3, XML CII, profil Factur-X, règles EN16931, données ERP.

Ce guide donne un workflow développeur pour transformer un rejet en correction reproductible.

En bref

• Ne corrigez jamais à partir d’une capture d’écran du message de rejet : récupérez le PDF ou XML exact.
• Distinguez erreur de conteneur PDF/A-3 et erreur Schematron EN16931.
• Les erreurs BR-CO-* sont souvent des effets de cascade après un calcul ou un arrondi incorrect.
• Les erreurs de champ manquant doivent être reliées à une donnée ERP, pas corrigées au hasard dans le XML.
• Une fois le correctif trouvé, ajoutez un test de non-régression sur une facture fixture.

Étape 1 : récupérer l’artefact exact

La première erreur est de diagnostiquer sur un fichier régénéré après coup. Si l’ERP produit une facture légèrement différente à chaque génération, vous pouvez perdre la cause réelle : horodatage, numéro, arrondi, ordre des lignes, métadonnées PDF.

À conserver :

• PDF envoyé ou remis à la PA ;
• XML CII extrait si disponible ;
• message de rejet brut ;
• identifiant de facture ;
• version du moteur de génération ;
• profil Factur-X attendu ;
• données ERP utilisées au moment de la génération.

Ne commencez pas par modifier le template. Commencez par figer l’entrée.

Étape 2 : scanner avant de lire le message métier

Un message de rejet peut pointer une règle finale alors que l’erreur racine est en amont.

Exemple courant :

BR-CO-15 : le total TTC ne correspond pas au total HT + TVA

La cause peut être :

• un total TVA déjà faux (BR-CO-14) ;
• une catégorie TVA absente ;
• une remise document non agrégée ;
• un arrondi appliqué au mauvais étage ;
• une ligne supprimée sans recalcul.

Le scan doit d’abord établir si le fichier est analysable. Si le XML n’est pas extrait ou si le PDF/A-3 est invalide, inutile de commencer par les règles BR-*.

Étape 3 : classer l’erreur par couche

Cette classification évite de mélanger les responsabilités. Un problème d’XMP ne doit pas finir dans la backlog “calcul TVA”. Un champ SIRET absent ne doit pas être inventé par un script XML.

Étape 4 : choisir le bon type de correction

Correction automatique

Bonne candidate si la transformation est déterministe :

• date 2026-04-28 vers 20260428 avec format="102" ;
• devise eur vers EUR ;
• namespace CII attendu ;
• métadonnées XMP cohérentes ;
• enveloppe PDF/A-3 à reconstruire ;
• AFRelationship à corriger.

Ces corrections peuvent être appliquées par /repair ou par un flux /convert selon le type de fichier.

Donnée ERP à fournir

Bonne candidate pour invoice_data JSON :

• SIRET acheteur ;
• IBAN ;
• conditions de paiement ;
• lignes de facture ;
• code de catégorie TVA ;
• motif d’exonération ;
• données d’autoliquidation BTP.

Le point clé : FacturX API peut prendre le PDF existant produit par l’ERP et recevoir les champs métier séparément au moment de l’appel. L’objectif n’est pas de forcer une réécriture complète de l’export XML.

Reprise source

Indispensable si le fichier contient une contradiction réelle :

• deux totaux incompatibles ;
• lignes manquantes ;
• catégorie TVA incohérente avec le taux ;
• facture sans numéro définitif ;
• avoir sans lien métier exploitable ;
• source PDF illisible.

Dans ce cas, la correction automatique serait dangereuse. Le bon rapport doit refuser d’inventer.

Étape 5 : revalider et ajouter une fixture

Une correction n’est terminée que si elle passe dans un test reproductible.

Exemple de fixture minimale :

curl -sS -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer $FACTURX_API_KEY" \
  -F "file=@fixtures/facture-rejet-pa-2026-04.pdf" \
  | jq '.valid, .summary'

Puis en CI :

valid=$(curl -sS -X POST "$FACTURX_API_URL/validate" \
  -H "Authorization: Bearer $FACTURX_API_KEY" \
  -F "file=@fixtures/facture-rejet-pa-2026-04.pdf" | jq -r '.valid')

test "$valid" = "true"

Une facture rejetée devient alors une non-régression. Si le moteur ERP recasse le même cas, le pipeline le voit avant que le client final ne le découvre.

Exemple de workflow complet

Sources et articles liés

• Facturation électronique et plateformes agréées
• Liste des plateformes agréées
• Catalogue des erreurs BR-* EN16931
• Champs obligatoires EN16931 / Factur-X
• Automatiser la validation Factur-X dans un pipeline CI/CD