Technique

Rejets Chorus Pro : erreurs Factur-X courantes et comment les corriger

Mis à jour le 10 min de lecture Par FacturX API

Les rejets Chorus Pro lors de soumissions Factur-X décryptés : codes retour, erreurs EN16931, BT-10 Buyer reference, code paiement 30 vs 58, diagnostic et corrections.

En bref

  • Chorus Pro reçoit les factures destinées au secteur public, dans les circuits historiques encore applicables ou via une plateforme agréée dans le nouveau circuit.
  • Contrôles présentés ici : identification du fournisseur, moyen de paiement, code service et engagement juridique.
  • BT-10 désigne le code service ; BT-13 porte la référence d’engagement ou de commande dans le mapping décrit ci-dessous. Leur obligation dépend du destinataire et du circuit.
  • /api/v1/validate rapporte les contrôles documentaires exécutés ; il ne simule pas une soumission Chorus.
  • /repair traite certaines corrections déterministes du XML CII et retourne du XML. Revalidez le document final après réintégration dans un PDF.

Chorus Pro est le portail de facturation B2G (business-to-government) de l’État français. Pour diagnostiquer un rejet, conservez le fichier exact, le code retour et le circuit utilisé. Une erreur de format, une donnée métier absente et un refus du destinataire n’appellent pas la même correction.

Ce guide distingue les contrôles documentaires des exigences du destinataire. Périmètre relu le 22 septembre 2026 : la description fonctionnelle AIFE distingue le nouveau circuit via PA des circuits historiques et de leur transition. Les tables de l’annexe EDI citées ci-dessous décrivent les mappings historiques CII 16B / Factur-X ; ne les transposez pas automatiquement aux flux AFNOR du nouveau circuit.

Pour le contexte général de la réforme et du pipeline de validation, voir Facturation électronique 2026 : le guide technique complet pour développeurs. Pour la mécanique des erreurs Schematron BR-*, voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*.

Si vous avez le fichier exact rejeté, commencez par le scanner : Facture rejetée par une Plateforme Agréée : workflow développeur donne le chemin diagnostic → correction → revalidation.

Comment Chorus Pro valide les factures

Un rejet peut provenir du fichier, des données nécessaires au destinataire ou des contrôles du circuit utilisé. La séquence interne exacte de traitement Chorus n’est pas déduite d’une validation locale.

Validation structurelle

Pour un document Factur-X, contrôlez le conteneur PDF/A-3, l’XML embarqué et les métadonnées. Cela ne signifie pas que tout flux reçu par Chorus Pro est un PDF Factur-X : les formats et modalités admis dépendent du circuit. Voir PDF/A-3 pour Factur-X : conformité et pièges.

Validation EN16931

Le XML doit être contrôlé contre les schémas et règles du profil visé. Un profil Factur-X allégé ne couvre pas nécessairement tout le modèle EN16931. Les erreurs du noyau BR-* sont décrites dans le Catalogue des erreurs EN16931 ; elles doivent être distinguées des règles nationales et des exigences opérationnelles du destinataire.

Contrôles métier spécifiques Chorus Pro

C’est ici que Chorus Pro se distingue d’une validation EN16931 standard. Au-delà du noyau européen, Chorus Pro applique des contrôles nationaux et opérationnels propres au flux B2G français. Ces contrôles portent notamment sur :

  • La référence acheteur (BT-10), utilisée comme clé de routage vers le service destinataire
  • Le code de moyen de paiement (BT-81), qui doit correspondre aux instruments acceptés par la comptabilité publique
  • Le type de document (BT-3), restreint à un sous-ensemble des codes UNTDID 1001
  • L’identification du fournisseur, selon le mapping historique ou France CTC du flux

L’annexe EDI historique cite plusieurs profils : MINIMUM, BASIC WL, BASIC, EN 16931 et EXTENDED. Leur admission ne garantit ni la présence des références métier ni l’acceptation de chaque version d’URN dans tout circuit. Vérifiez le profil et les spécifications applicables ; voir Profils Factur-X.

Points de contrôle des rejets

BT-10 — Buyer reference manquant

Le code service est un point de contrôle à distinguer du numéro d’engagement.

Dans la norme EN16931, BT-10 (Buyer reference) a une cardinalité 0..1 — il est optionnel. Un XML Factur-X parfaitement conforme EN16931 peut ne pas contenir de BT-10 et passer la validation Schematron sans erreur.

Dans le mapping CII/Factur-X historique, Chorus Pro utilise BT-10 pour le code service du destinataire. L’exigence d’un code service et celle d’un numéro d’engagement sont deux paramètres distincts à vérifier dans l’annuaire du destinataire.

BT-10 porte le code service. BT-13 porte la référence d’engagement ou de commande via BuyerOrderReferencedDocument/IssuerAssignedID ; une référence de marché/contrat relève de BT-12. Source : annexe EDI, mapping CII pp. 139–140. Les valeurs ci-dessous sont fictives : utilisez celles communiquées par le destinataire.

Correction dans le XML CII :

<ram:ApplicableHeaderTradeAgreement>
  <!-- BT-10 : code service si requis par le destinataire -->
  <ram:BuyerReference>SERVICE-EXEMPLE</ram:BuyerReference>
  <!-- ... autres éléments de l’accord, selon leur ordre XSD ... -->
  <!-- BT-13 : engagement / commande, distinct du code service -->
  <ram:BuyerOrderReferencedDocument>
    <ram:IssuerAssignedID>EJ-2026-00042</ram:IssuerAssignedID>
  </ram:BuyerOrderReferencedDocument>
</ram:ApplicableHeaderTradeAgreement>

Piège : une valeur vide ou générique comme « N/A » ne remplace pas une référence métier. Vérifiez le code service et l’engagement séparément, selon les exigences du destinataire.

BT-81 — Code de moyen de paiement incorrect

Le champ BT-81 (Payment means type code) utilise les codes UNTDID 4461. La norme EN16931 accepte un large éventail de ces codes, mais Chorus Pro n’en reconnaît qu’un sous-ensemble adapté à la comptabilité publique.

Dans l’annexe EDI historique, S2.05, p. 166, la liste comprend 01, 10, 20, 30, 31, 42, 48, 49, 97, ainsi que 58 et 59 pour CII 16B / Factur-X. Cette liste doit être distinguée de celle du profil utilisé dans le nouveau circuit. Les exemples ci-dessous ne constituent pas une garantie d’acceptation.

CodeSignificationNotes
30VirementÀ choisir si ce moyen décrit le paiement réel
42Paiement sur compte bancairePas un code réservé aux comptes du Trésor
48Paiement par carteCarte bancaire
49PrélèvementAutorisé par Chorus Pro
58Virement SEPACII 16B / Factur-X uniquement
59Prélèvement SEPACII 16B / Factur-X uniquement
97CompensationAutorisé par Chorus Pro

Erreurs fréquentes :

  • Instrument non défini : S2.05 cite 01. Il est donc incorrect de déclarer ce code systématiquement rejeté ; vérifiez la valeur attendue par le format et le circuit concernés.
  • Codes hors périmètre : une valeur d’une liste générale UNTDID n’est pas nécessairement admise par le profil ou le circuit destinataire.

Correction : choisissez le code correspondant au paiement réel, par exemple 30 pour un virement ou 58 pour un virement SEPA lorsque ce code est admis par le circuit :

<ram:SpecifiedTradeSettlementPaymentMeans>
  <!-- BT-81 : 30 = virement, 58 = SEPA -->
  <ram:TypeCode>30</ram:TypeCode>
</ram:SpecifiedTradeSettlementPaymentMeans>

BT-3 — Code type de document incorrect

BT-3 (Invoice type code) utilise les codes UNTDID 1001. Le standard EN16931 en accepte plusieurs, mais Chorus Pro restreint en pratique les codes acceptés.

Périmètre historique : S2.04 de l’annexe EDI, p. 166 liste 380, 382, 383, 384, 385 et 386 pour les factures, et 381 pour l’avoir. CII 16B / Factur-X ajoutent 389 et 261 dans ce tableau. Cette liste n’est pas une autorisation générale pour tous les circuits de la réforme.

Choisissez le type qui décrit l’opération réelle et vérifiez son admission par le circuit. Ne remplacez pas arbitrairement un avoir par le code facture 380 pour éviter un rejet.

BT-30 — SIRET vendeur manquant ou incorrect

L’identification du fournisseur dépend du circuit. Historique CII 16B / Factur-X : le mapping place l’identifiant du fournisseur sous SpecifiedLegalOrganization/ID et S2.13 admet 0002 ou 0009 pour un SIRET. France CTC : distinguez le SIREN légal en BT-30 (0002) du SIRET d’établissement en BT-29 (0009). Ce sont deux conventions de contexte différent, pas deux exemples interchangeables.

Vérifiez le numéro transmis, son schéma et les données du destinataire dans le référentiel concerné. Un contrôle de format local ne prouve ni l’existence ni le statut administratif d’un établissement. Ne déduisez pas un rejet automatique d’une simple fermeture ou d’un test de clé sans identifier la règle du circuit.

<!-- Historique Chorus CII/Factur-X : fragment pédagogique, SIRET fictif -->
<ram:SpecifiedLegalOrganization>
  <ram:ID schemeID="0009">12345678901234</ram:ID>
</ram:SpecifiedLegalOrganization>
<!-- France CTC : fragments sous SellerTradeParty, valeurs fictives -->
<!-- BT-29 : établissement -->
<ram:GlobalID schemeID="0009">12345678901234</ram:GlobalID>
<!-- BT-30 : entreprise -->
<ram:SpecifiedLegalOrganization>
  <ram:ID schemeID="0002">123456789</ram:ID>
</ram:SpecifiedLegalOrganization>

Sources : annexe EDI historique, pp. 139 et 167 et artefacts France RFE FNFE-MPE. Les chiffres d’exemple ne sont pas des identités vérifiées ; ces fragments ne sont pas des factures complètes validées.

Pour la vérification d’un SIRET via l’API SIRENE et le mapping vers les champs Factur-X, voir API annuaire et routage SIRET.

Profil Factur-X insuffisant pour le flux B2G

Le profil MINIMUM ne contient pas de lignes de facture, pas de ventilation TVA détaillée, pas d’informations de paiement. Ces informations peuvent être nécessaires selon le circuit et les besoins du destinataire.

Ne limitez pas MINIMUM au cadre A9 : A9 désigne un cadre de sous-traitance, pas un synonyme de PES Facture. La liste historique S2.20 ne fonde pas une règle universelle « EN16931 ou supérieur pour tout B2G ». Un profil EN16931 donne un cadre de données complet, mais ne renseigne pas automatiquement le code service ou l’engagement attendu.

Si votre facture est rejetée pour insuffisance de données, vérifiez le profil déclaré dans le GuidelineID du XML et assurez-vous qu’il correspond au contenu réellement présent. Pour la matrice de choix, voir Profils Factur-X : MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED.

Diagnostic systématique d’un rejet

Quand une facture est rejetée par Chorus Pro, le réflexe de “corriger à l’aveugle” est le pire ennemi. Chaque correction non diagnostiquée risque d’introduire une nouvelle erreur. Voici un workflow en trois étapes.

Etape 1 : valider en amont avant soumission

Une validation préalable peut détecter des erreurs XSD ou Schematron avant soumission. Elle ne couvre pas à elle seule les exigences métier du destinataire ni ses décisions de traitement.

Le rapport peut fournir les règles en échec et des localisations, selon le contrôle exécuté. Vérifiez aussi les contrôles non évalués et leur cause ; l’absence d’erreur affichée ne prouve pas que tout le périmètre attendu a été contrôlé.

Etape 2 : lire le motif de rejet Chorus Pro

Quand le rejet provient de Chorus Pro, le portail fournit un motif. Ce motif peut être :

  • Une erreur technique (format PDF, XML invalide) — indique un problème structurel
  • Une erreur fonctionnelle (champ manquant, valeur incorrecte) — indique un contrôle métier Chorus Pro non satisfait
  • Un rejet de service (référence inconnue, engagement non trouvé) — indique un problème de données métier, pas de format

Distinguer ces trois catégories oriente immédiatement le diagnostic vers la bonne couche.

Etape 3 : croiser avec le catalogue BR-*

Si le rejet concerne une règle EN16931, identifiez le code BR-* correspondant dans le Catalogue des erreurs BR-* EN16931. Chaque entrée documente la cause racine, un exemple XML invalide, et la correction à appliquer.

Si le rejet concerne un contrôle propre au circuit Chorus, identifiez son référentiel. Il ne se confond pas avec une règle du noyau EN16931 ; certains contrôles nationaux peuvent eux aussi être implémentés en Schematron et porter un code BR-FR.

Pour certaines erreurs de format du XML CII, Repair peut proposer une correction déterministe. Il retourne du XML ; revalidez le document final après réintégration dans un PDF. Les données métier manquantes doivent provenir de l’ERP ou du destinataire.

Validation EN16931 pure vs validation Chorus Pro

Cette distinction est fondamentale et source de confusion fréquente.

EN16931 est le noyau européen de facturation électronique. Ses règles (BR-*) définissent le socle sémantique commun indépendamment du pays ou du portail destinataire. Un XML conforme EN16931 satisfait le noyau de validation, mais chaque réseau (Peppol, Chorus Pro, SDI…) peut ajouter ses propres contraintes CIUS ou opérationnelles.

France CTC et Chorus Pro ajoutent des exigences de profil, de circuit et de destinataire. Elles ne sont pas interchangeables :

AspectNoyau EN16931Circuit destinataire
RéférencesBT-10 et BT-13 sont distinctsCode service et engagement selon les exigences du destinataire
BT-81Liste applicable et règles conditionnelles du moyen de paiementVérifier la liste du circuit historique ou du nouveau flux
IdentificationBT-29, BT-30 et BT-31 ont des fonctions distinctesNe pas confondre SIRET historique Chorus avec SIREN/SIRET France CTC
ProfilLes profils Factur-X partiels ne sont pas équivalents au modèle complet EN16931Vérifier profil, version et données métier nécessaires
RésultatPreuve des contrôles documentaires exécutésUn diagnostic ne garantit pas l’intégration ou l’acceptation par Chorus ou une PA

Les artefacts France RFE et la description fonctionnelle AIFE documentent des périmètres supplémentaires. Leur publication ne prouve pas qu’un outil les a exécutés. Un XML peut réussir des contrôles EN16931 et être rejeté pour une exigence métier du destinataire.

Checklist avant soumission Chorus Pro

Avant de soumettre une facture Factur-X à Chorus Pro, vérifiez systématiquement :

  • PDF/A-3 : le conteneur est conforme, le XML CII est correctement embarqué
  • Profil et circuit : version, format et profil admis par le circuit concerné
  • Références : BT-10 code service et BT-13 engagement/commande, chacun si requis
  • Identifiants : numéro réel, champ et schéma adaptés au circuit historique ou France CTC
  • BT-81 : code correspondant au paiement réel et admis par le circuit
  • BT-3 : code adapté à la nature réelle du document et admis par le circuit
  • Validation documentaire : contrôles nécessaires exécutés, erreurs bloquantes traitées ; aucune acceptation PA déduite
  • Cohérence XMP/XML : le profil déclaré dans les métadonnées XMP correspond au GuidelineID

Erreurs fréquentes et fiches de diagnostic

Les 22 fiches unitaires : catalogue complet des erreurs BR-*.

Et maintenant ?

Tester ma facture maintenant →

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer VOTRE_CLE" \
  -F "file=@./facture.pdf"

Clé Sandbox : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois. Le scanner public reste gratuit et séparé du quota API. Obtenir une clé API.

Ressources

#chorus-pro #factur-x #B2G #rejet #EN16931 #plateforme-agréée #validation