BR-CL-01 : Utiliser un code de type de document autorisé

La réponse courte

BR-CL-01 échoue lorsque le code de type de document ne fait pas partie du sous-ensemble de UNTDID 1001 qu'EN 16931 autorise pour ce type de document. Envoyez le code qui décrit ce qu'est le document : 380 pour une facture commerciale dans cbc:InvoiceTypeCode, 381 pour un avoir dans cbc:CreditNoteTypeCode, ou un autre code de la liste lorsqu'il s'applique réellement.

Il y a deux listes, une par élément. Un code de la liste des avoirs dans une Invoice, ou l'inverse, échoue même si le code lui-même est une vraie valeur UNTDID 1001.

Ce que la règle vérifie

La règle s'exécute sur cbc:InvoiceTypeCode et sur cbc:CreditNoteTypeCode, et contrôle chacun par rapport à sa propre liste : codes de type de facture pour le premier, codes de type d'avoir pour le second. 381 dans une Invoice échoue, tout comme 380 dans un CreditNote.

Les espaces autour de la valeur sont ignorés ; 380 entouré d'espaces passe. Pour le reste, la correspondance est exacte et porte sur un seul code, donc 0380 et 380 380 échouent.

Un élément vide échoue à cette règle et est aussi signalé par BR-04, par la règle Peppol sur le code de type et par PEPPOL-EN16931-R008. Un document sans aucun élément de code de type n'atteint pas cette règle : UBL rend l'élément facultatif, l'étape XSD passe donc, et BR-04 signale le code manquant.

Peppol restreint encore le choix. PEPPOL-EN16931-P0100 pour les factures et PEPPOL-EN16931-P0101 pour les avoirs n'acceptent qu'une partie de la liste EN 16931, si bien qu'un code peut passer BR-CL-01 et échouer quand même à l'étape Peppol : c'est le cas de 130 et 202 dans une Invoice, et de 261 dans un CreditNote. À l'inverse, 999, 0380 et un 381 placé dans une Invoice échouent aux deux étapes.

Comment une intégration en arrive là

Causes possibles, déduites de la forme de la règle et non d'une utilisation mesurée :

• Un type de document interne, comme INV, 1 ou un code comptable, est écrit dans l'élément sans conversion.
• Le système source modélise les avoirs comme des factures d'un autre type, et le mapping place 381 dans une racine Invoice.
• Le code a été pris dans la liste UNTDID 1001 complète, qui couvre aussi les commandes, les avis d'expédition et d'autres documents qui ne sont pas des factures, par exemple 220.
• La valeur est formatée comme un nombre avec des zéros de remplissage, ce qui donne 0380.
• Aucune valeur par défaut n'a été définie et le générateur produit un élément vide.

Comment corriger le document

1. Décidez d'abord ce qu'est le document en termes métier : facture, avoir, facture rectificative, facture d'acompte, etc. Le code en découle ; ce n'est pas un choix libre.
2. Convertissez le type interne en code au moyen d'une table explicite, et limitez la table aux codes qui passent à la fois BR-CL-01 et la règle Peppol de l'élément racine que vous envoyez.
3. Si le document est un avoir, construisez un CreditNote avec cbc:CreditNoteTypeCode. C'est un autre élément racine, avec ses propres noms de ligne et de quantité, et non un code remplacé dans une Invoice. Ne réétiquetez pas un avoir en 380 pour faire disparaître l'erreur.
4. Émettez le code sous forme de chaîne simple, sans remplissage ni zéros de tête.

Valider votre facture corrigée

Avant et après

Ce sont des extraits, pas des documents complets. Les documents synthétiques complets dont ils proviennent sont liés ci-dessous.

Fragment de la facture en échec : 999 n'est pas un code de type de facture UNTDID 1001

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>999</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Fragment de la facture corrigée : 380, facture commerciale

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>

Seul cbc:InvoiceTypeCode diffère : 999 dans le fichier en échec, 380 dans le fichier corrigé. Le document en échec signale aussi PEPPOL-EN16931-P0100, la restriction Peppol sur les codes de type de facture : Peppol autorise moins de codes qu'EN 16931, et 999 ne figure sur aucune des deux listes. Chaque étape émet un constat pour le même élément, et un code accepté par Peppol élimine les deux.

Où la règle s'applique

• S'applique à UBL Invoice par cbc:InvoiceTypeCode et à CreditNote par cbc:CreditNoteTypeCode, avec une liste différente pour chacun. Un CreditNote avec 999 ou 380 signale BR-CL-01 avec PEPPOL-EN16931-P0101.
• Certains codes sont soumis à d'autres conditions Peppol au-delà des deux listes. 384 sur la facture de test britannique passe BR-CL-01 et PEPPOL-EN16931-P0100 et signale PEPPOL-EN16931-P0112.
• Les listes sont celles figées dans les artefacts EN 16931 1.3.16 et Peppol BIS Billing 3.0.21. Consultez la liste de codes Peppol de la version que vous ciblez plutôt que de vous fier à la liste EN 16931, plus large.

Règles liées

• BR-CL-04 est le contrôle de liste de codes pour la devise du document, l'élément d'en-tête suivant
• BR-CL-23 contrôle les codes d'unité des quantités par rapport à leur liste de codes
• BR-02 exige le numéro de facture, un autre champ d'en-tête obligatoire
• Parcourir toutes les règles de la référence
• Contexte (en anglais) : Understanding EN 16931 validation errors

Portée et source

Rédigé pour Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, tel qu'appliqué aux documents Invoice et CreditNote en UBL 2.1. D'autres profils, syntaxes et versions peuvent définir cet identifiant autrement. Version du catalogue d'aide 2026-09-24.1 : source vérifiée le 2026-09-24, explication mise à jour le 2026-09-20.

La définition officielle de BR-CL-01 (en anglais) contient le texte normatif et le test. Cette page en est notre explication, pas une copie.

Cette aide ne modifie pas le verdict du moteur. Corriger ce constat ne signifie pas que le document passe toutes les étapes de validation, et la validation ne certifie pas la conformité juridique ou fiscale et ne transmet aucun document via Peppol.