Sur cette page
La réponse courte
BR-04 échoue lorsque la racine du document n'a pas de code de type renseigné : pas de cbc:InvoiceTypeCode dans un document Invoice, pas de cbc:CreditNoteTypeCode dans un document CreditNote, ou un élément vide. Ajoutez l'élément avec le code du type de document que vous envoyez, 380 pour une facture commerciale ou 381 pour un avoir.
Le schéma UBL considère le code de type comme facultatif : l'étape XSD passe donc sans lui, et cette règle EN 16931 est la première à le signaler.
Ce que la règle vérifie
La règle s'exécute une fois par document, sur la racine. Elle est satisfaite lorsque l'un des deux éléments de code de type placés directement sous la racine contient autre chose que des espaces.
Un élément absent ne donne que BR-04, comme dans l'exemple enregistré, car les règles de listes de codes n'ont aucun élément à contrôler. Lors d'un essai, un élément vide ou ne contenant que des espaces a donné quatre constats : BR-04, BR-CL-01, la règle Peppol sur le code de type pour cette racine (PEPPOL-EN16931-P0100 ou PEPPOL-EN16931-P0101) et PEPPOL-EN16931-R008.
La règle ne juge pas la valeur. Tout texte non vide la satisfait ; savoir si le code est autorisé revient à BR-CL-01 et aux règles de profil Peppol.
| Terme | Signification | Élément UBL |
|---|---|---|
| BT-3 | Code de type de facture | cbc:InvoiceTypeCode (cbc:CreditNoteTypeCode in a credit note) |
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 :
- Le mapping a été conçu pour un format où le type de message détermine le type de document, et rien ne renseigne l'élément UBL.
- Le code de type est rempli à partir d'une valeur de configuration absente dans cet environnement, et le sérialiseur omet l'élément.
- Un modèle d'avoir a été dérivé du modèle de facture, et l'instruction qui écrit le code de type de facture a été supprimée sans ajouter
cbc:CreditNoteTypeCodeà sa place.
Comment corriger le document
- Déterminez ce qu'est le document sur le plan commercial et choisissez le code dans la liste Peppol pour cet élément racine :
380pour une facture ordinaire,381pour un avoir ordinaire. - Produisez
cbc:InvoiceTypeCodeà sa position dans le schéma : aprèscbc:IssueDateetcbc:DueDate, avant les éventuelscbc:Note,cbc:TaxPointDateetcbc:DocumentCurrencyCode. Placé aprèscbc:DocumentCurrencyCode, il a échoué à l'étape XSD lors d'un essai. - Pour un document
CreditNote, produisez plutôtcbc:CreditNoteTypeCode; le nom d'élément de la facture n'y est pas valide. - Faites du code une sortie obligatoire du mapping, afin qu'une valeur manquante arrête l'export au lieu de faire disparaître l'élément sans avertissement.
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 : l'en-tête passe directement de la date d'échéance à la devise
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<!-- no cbc:InvoiceTypeCode in the failing document -->
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>Fragment de la facture corrigée : 380, facture commerciale, entre la date d'échéance et la devise
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>La facture corrigée contient <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> entre la date d'échéance et le code de devise ; la facture en échec n'a aucun élément de code de type. Le document en échec ne signale que BR-04. Faute d'élément, ni BR-CL-01 ni PEPPOL-EN16931-P0100 n'ont de valeur à contrôler, et l'étape Peppol passe.
Ce que le validateur a signalé
- La facture en erreur signale BR-04. Le document corrigé passe toutes les étapes de validation sans constat.Télécharger le XML en erreurTélécharger le XML corrigé
Enregistré avec phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, le moteur du validateur gratuit, sur des données synthétiques. Un résultat enregistré est une preuve de non-régression pour ces documents ; ce n'est pas une certification.
Où la règle s'applique
- S'applique aux documents UBL
InvoiceetCreditNote. Lors d'un essai, un avoir sanscbc:CreditNoteTypeCodea signalé cette règle et a lui aussi passé l'étape XSD. - Le constat vient de l'étape EN 16931. Peppol n'a pas de règle de présence propre pour le code de type.
- Une fois l'élément présent, sa valeur est contrôlée par
BR-CL-01par rapport à la liste EN 16931, et parPEPPOL-EN16931-P0100ouPEPPOL-EN16931-P0101par rapport à la liste Peppol, plus restreinte.
Règles liées
- BR-CL-01 contrôle la valeur du code de type par rapport aux listes EN 16931 une fois qu'il est présent
- PEPPOL-EN16931-P0100 limite les codes de type de facture à la liste Peppol
- PEPPOL-EN16931-P0101 limite les codes de type d'avoir à la liste Peppol
- PEPPOL-EN16931-R008 s'ajoute à cette règle lorsque l'élément de code de type est présent mais vide
- 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-24.
La définition officielle de BR-04 (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.