BR-08 : Ajouter l'adresse postale du vendeur

La réponse courte

BR-08 échoue lorsque cac:AccountingSupplierParty/cac:Party n'a pas d'enfant cac:PostalAddress. Ajoutez-y l'adresse de l'entité vendeuse : au minimum cac:Country/cbc:IdentificationCode, ainsi que la rue, la ville et le code postal que contient la fiche du vendeur.

Le constat pointe vers la racine du document, et non vers la partie vendeur, puisque le contrôle est fait une fois pour tout le document. Une adresse écrite ailleurs que dans cet élément précis, comme une adresse de siège sous cac:PartyLegalEntity, laisse la règle en échec.

Ce que la règle vérifie

La règle pose une seule question : existe-t-il un cac:PostalAddress directement dans cac:AccountingSupplierParty/cac:Party ? Le contenu de l'adresse n'est pas examiné ici.

Un <cac:PostalAddress/> vide suffit à la satisfaire. Lors d'un essai, cet élément vide a été signalé à la place par BR-09, qui exige un code pays du vendeur dans l'adresse, et par PEPPOL-EN16931-R008, qui refuse les éléments vides. Une adresse contenant uniquement le code pays a passé toutes les étapes.

Aucune autre adresse ne remplace celle-ci. Lors d'un essai, une adresse dans cac:PartyLegalEntity/cac:RegistrationAddress a laissé BR-08 en échec et ajouté l'avertissement UBL-CR-185, qui signale cet élément comme hors du modèle. Les adresses de l'acheteur, du représentant fiscal et du lieu de livraison sont des groupes distincts, avec leurs propres règles.

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 :

• L'adresse du vendeur se trouve dans des paramètres de société que l'export ne lit pas, et la partie vendeur est construite uniquement à partir du nom et des identifiants.
• Le bloc d'adresse n'est écrit que si une ligne de rue est présente : une fiche vendeur avec une ville et un pays mais sans rue ne produit donc aucun cac:PostalAddress.
• Le mapping envoie l'adresse vers cac:PartyLegalEntity/cac:RegistrationAddress parce que c'est le siège social, et rien vers cac:PostalAddress.
• La facture est émise pour une filiale ou un établissement dont l'adresse n'a jamais été configurée, et le générateur omet le bloc au lieu de s'arrêter.

Comment corriger le document

1. Prenez l'adresse de l'entité vendeuse dans ses données de référence : l'entité nommée dans cac:PartyLegalEntity/cbc:RegistrationName, et non un entrepôt ou une adresse de règlement.
2. Écrivez-la sous la forme de cac:PostalAddress dans cac:AccountingSupplierParty/cac:Party, après cbc:EndpointID, cac:PartyIdentification et cac:PartyName, et avant cac:PartyTaxScheme.
3. Placez cac:Country/cbc:IdentificationCode comme dernier enfant de l'adresse, avec le code ISO 3166-1 alpha-2, par exemple GB. BR-09 l'exige et BR-CL-14 en contrôle la valeur.
4. Envoyez aussi la rue, la ville et le code postal. Le validateur accepte une adresse qui ne contient qu'un pays, mais c'est le minimum testé par les règles, pas une adresse complète.
5. Si la fiche du vendeur n'a pas d'adresse, arrêtez l'export et complétez la fiche. Ne copiez ni l'adresse de l'acheteur ni une valeur provisoire dans la partie vendeur.

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 : la partie vendeur passe directement de son adresse électronique à son régime fiscal

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment de la facture corrigée : l'adresse postale du vendeur se place entre l'adresse électronique et le régime fiscal

<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>GB123456789</cbc:CompanyID>
      <!-- tax scheme omitted from this fragment -->
    </cac:PartyTaxScheme>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

La facture corrigée comporte un cac:PostalAddress du vendeur avec rue, ville, code postal et pays GB ; la facture en échec n'a pas d'adresse du vendeur et est identique par ailleurs. BR-08 est le seul constat du document en échec. La règle sur le pays du vendeur, BR-09, reste muette, car elle s'exécute à l'intérieur de l'adresse et il n'y a pas d'adresse où l'exécuter.

Où la règle s'applique

• Un document CreditNote porte l'adresse du vendeur au même endroit. Lors d'un essai, un avoir sans cette adresse a signalé BR-08 seul, localisé à la racine CreditNote.
• L'exigence vient de la norme EN 16931 et est signalée à cette étape ; dans l'exemple enregistré, rien à l'étape Peppol n'a relevé l'absence d'adresse du vendeur.
• Une adresse mal placée parmi les enfants de cac:Party échoue à l'étape XSD avant que cette règle ne soit atteinte : lors d'un essai, l'adresse du vendeur placée après cac:PartyLegalEntity a provoqué un échec XSD, et les étapes EN 16931 et Peppol ont été ignorées.
• Lorsque les adresses des deux parties manquent, BR-08 et BR-10 sont signalés côte à côte, tous deux à la racine.

Règles liées

• BR-10 est le même contrôle de présence pour l'adresse postale de l'acheteur
• BR-CL-14 vérifie que le code pays de l'adresse est un code ISO 3166-1 valide
• BR-06 exige la raison sociale du vendeur dans la même partie
• PEPPOL-EN16931-R008 signale un élément d'adresse du vendeur 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-08 (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.