Erreurs de validation Peppol BIS courantes : pourquoi une facture Peppol est rejetée et comment la corriger

Par evoicely · Dernière vérification le 21 octobre 2026

Une facture Peppol BIS Billing 3.0 est contrôlée selon deux ensembles de règles : les règles de la norme EN 16931 (identifiants commençant par BR-) et les règles propres à OpenPeppol (identifiants commençant par PEPPOL-). La plupart des erreurs Peppol signifient soit qu'un champ propre à Peppol manque ou est mal formé, soit que les totaux ne tombent pas juste. Celles que l'on rencontre le plus avec de l'UBL généré à partir de factures Stripe sont PEPPOL-EN16931-R008 (un élément vide), R010 et R020 (pas d'adresse électronique), PEPPOL-COMMON-R043 (un numéro d'entreprise belge au mauvais format), R003 (ni référence acheteur ni référence de commande), R001/R007 (processus métier), ainsi que les règles sur les totaux et la TVA BR-CO-10, BR-CO-15, BR-S-08 et BR-AE-10. Chaque section ci-dessous donne le texte officiel de la règle, la raison pour laquelle elle se déclenche et le XML qui la satisfait. Pour voir quelles règles votre propre fichier enfreint, chargez-le dans notre validateur gratuit.

Tableau récapitulatif

Règle	Ce qui manque ou est incorrect
PEPPOL-EN16931-R008	Un élément vide
R020, R010, BR-62/63, CL008	Adresse électronique (identifiant Peppol) du vendeur ou de l'acheteur
PEPPOL-COMMON-R043, R040	Un numéro d'entreprise belge ou un GLN qui échoue au contrôle de format
PEPPOL-EN16931-R003	Ni référence acheteur, ni référence de commande
R001, R007, R004	Identifiant du processus métier ou de la spécification
PEPPOL-EN16931-R002	Plus d'une note de facture
BR-CO-10, -13, -15, R120	Totaux de ligne et de document qui ne tombent pas juste
BR-S-08, BR-S-09, BR-CO-17	Ventilation de la TVA qui ignore une remise
BR-AE-10, BR-AE-02	Autoliquidation sans motif ou sans numéro de TVA de l'acheteur
BR-CL-23, R051	Codes d'unité et de devise

Toutes ces règles sont des erreurs, marquées fatal dans les fichiers de règles, et les points d'accès Peppol valident les factures avant de les envoyer : un fichier qui en contient une seule ne partira pas. Les textes des règles sont cités, en anglais comme dans les messages d'erreur, d'après les règles Peppol BIS Billing 3.0 (en anglais ; version 3.0.21, applicable depuis le 17 août 2026) et les règles EN 16931 pour UBL (en anglais ; 1.3.16, issues des artefacts de validation EN 16931). Dans les fichiers de règles, chaque message commence par l'identifiant de la règle entre crochets, par exemple [BR-CO-15]- ; nous omettons ce préfixe. Les extraits XML proviennent d'une seule facture fictive complète, d'un vendeur belge à un client belge, qui passe toutes ces règles. Chaque variante défectueuse a été vérifiée : elle déclenche bien la règle indiquée. Pour savoir comment ces ensembles de règles s'articulent et comment les appliquer, voir How to validate a Peppol BIS 3.0 invoice (en anglais).

PEPPOL-EN16931-R008 : éléments vides

Document MUST not contain empty elements. Peppol rejette tout élément sans contenu ni enfants, et un élément qui ne contient que des espaces compte aussi comme vide. C'est l'erreur Peppol la plus fréquente avec les générateurs faits maison : un modèle écrit tous les champs, et quand la valeur Stripe est nulle (un mémo absent, un client sans numéro de téléphone, une carte sans marque), on obtient quelque chose comme :

<cbc:Note></cbc:Note>
<cbc:NetworkID> </cbc:NetworkID>

La correction se fait dans le générateur : omettez un élément quand il n'a pas de valeur, et omettez son parent quand tous ses enfants ont disparu. L'emplacement indiqué dans l'erreur (par exemple …/CardAccount/NetworkID) vous dit quel élément était vide. Si l'élément est obligatoire, un élément vide ne satisfait pas non plus l'exigence : vous obtiendrez en plus la règle du champ manquant.

PEPPOL-EN16931-R020 et R010 : adresses électroniques

Seller electronic address MUST be provided (R020) et Buyer electronic address MUST be provided (R010). L'EN 16931 les rend facultatives ; Peppol rend les deux obligatoires, car ce sont les identifiants Peppol sur lesquels le réseau achemine les documents. Celle du vendeur est le BT-34, celle de l'acheteur le BT-49, toutes deux sous forme de cbc:EndpointID au début de cac:Party :

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0208">0765432146</cbc:EndpointID>
    <cac:PostalAddress>
    ...

Stripe n'a pas de champ pour l'identifiant Peppol : il doit donc venir de vos propres paramètres (pour le vendeur) et des métadonnées du client ou d'une recherche dans l'annuaire (pour l'acheteur). Trois erreurs voisines apparaissent quand l'élément est présent mais que son schéma ne va pas :

BR-62 / BR-63 : The Seller electronic address (BT-34) shall have a Scheme identifier (BR-63 pour l'acheteur). L'attribut schemeID manque.
PEPPOL-EN16931-CL008 : Electronic address identifier scheme must be from the codelist "Electronic Address Identifier Scheme". Le schéma ne figure pas dans la liste de codes EAS (en anglais) telle que Peppol l'utilise. Une cause fréquente est EM (e-mail), que XRechnung accepte mais pas Peppol : une adresse e-mail ne peut pas servir d'identifiant Peppol.

Les schémas courants sont 0208 (numéro d'entreprise belge), 9925 (numéro de TVA belge, écrit avec le préfixe BE), 0106 (numéro KvK néerlandais), 0088 (GLN) et 9930 (numéro de TVA allemand). L'identifiant ne sert que si le destinataire est réellement enregistré sous cet identifiant sur Peppol ; la validation ne peut pas le vérifier, votre point d'accès si.

PEPPOL-COMMON-R043 et R040 : contrôles de format des identifiants

PEPPOL-COMMON-R043 : Belgian enterprise number MUST be stated in the correct format. Dès que le schéma 0208 est utilisé (dans une adresse électronique, un identifiant de partie ou un numéro d'immatriculation légale), la valeur doit compter exactement dix chiffres, dont les deux derniers sont les chiffres de contrôle modulo 97 des huit premiers. Trois choses la font échouer :

Le préfixe BE : BE0765432146 est le format du numéro de TVA. Avec le schéma 0208, écrivez 0765432146, ou utilisez le schéma 9925 pour le numéro de TVA avec préfixe.
Des points ou des espaces, tels qu'on imprime souvent les numéros d'entreprise : 0765.432.146.
Une faute de frappe, que les chiffres de contrôle détectent : 0765432147 échoue, 0765432146 passe.

<cbc:EndpointID schemeID="0208">0765432146</cbc:EndpointID>

Si vous prenez le numéro dans le numéro fiscal d'un client Stripe (type eu_vat, valeur BE0765432146), retirez le préfixe du pays et toute ponctuation avant de l'utiliser comme identifiant 0208. Peppol prévoit des contrôles semblables pour d'autres schémas nationaux ; PEPPOL-COMMON-R040 (GLN must have a valid format according to GS1 rules) est celui du schéma 0088, dont le 13^e chiffre est un chiffre de contrôle GS1.

La version 3.0.21 ajoute des contrôles de format pour les identifiants néerlandais, sous forme d'avertissements. Vous pouvez les rencontrer sur des factures adressées à des clients aux Pays-Bas :

PEPPOL-COMMON-R054 : Dutch Chamber of Commerce (KVK) numbers (0106) MUST be stated in the correct format (12345678). Huit chiffres, sans espaces.
PEPPOL-COMMON-R056-2 : Dutch VAT numbers MUST have the format (NL123456789B12). Cette règle contrôle tout numéro de TVA commençant par NL, y compris celui de l'acheteur (BT-48) : un numéro saisi avec des espaces ou des points, ou sans son suffixe du type B01, la déclenche. Écrivez-le sans ponctuation.

La version comprend aussi R055, R056-1 et R057 pour les schémas néerlandais 0190, 9944 et 0217.

PEPPOL-EN16931-R003 : ni référence acheteur ni référence de commande

A buyer reference or purchase order reference MUST be provided. Peppol exige au moins l'une des deux, la référence acheteur (BT-10) ou la référence du bon de commande (BT-13), pour que l'acheteur puisse rapprocher la facture d'un élément de son côté. Stripe n'a de champ ni pour l'une ni pour l'autre : un générateur a donc besoin d'une valeur par défaut. Si le client vous a donné un numéro de bon de commande, utilisez-le comme référence de commande ; sinon, une référence acheteur comme son numéro de client ou le nom d'un contact suffit :

<cbc:BuyerReference>PO-2026-118</cbc:BuyerReference>

Ou, comme référence de commande (elle vient après cac:InvoicePeriod, avant les parties) :

<cac:OrderReference>
  <cbc:ID>PO-2026-118</cbc:ID>
</cac:OrderReference>

PEPPOL-EN16931-R001, R007 et R004 : identifiants de processus et de spécification

R001 : Business process MUST be provided.
R007 : Business process MUST have an approved identifier.
R004 : Specification identifier MUST begin with the value urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 and follow the format rules for the identifier.

Toute facture Peppol BIS commence par ces deux lignes. Le profil (BT-23) pour la facturation est le processus 01 :

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

Un ProfileID absent donne R001 et R007 ensemble. Depuis la version 3.0.21, R007 n'accepte plus qu'une liste fixe de profils approuvés, et non plus n'importe quelle valeur de la bonne forme ; pour la facturation ordinaire, c'est celui ci-dessus. Une cause fréquente de R007 est d'y écrire la version de la BIS, …poacc:billing:3.0, au lieu du numéro de processus. R004 se déclenche quand les règles Peppol sont appliquées à un fichier qui porte un autre identifiant de spécification, par exemple celui de l'EN 16931 seule ou d'une XRechnung ; les points d'accès appliquent les règles Peppol à tout ce qu'ils envoient. Depuis la 3.0.21, elle rejette aussi un identifiant qui commence correctement mais contient :: quelque part après, signe d'une extension mal raccordée. Les validateurs qui choisissent les règles d'après l'identifiant de spécification, comme le nôtre, contrôlent un tel fichier selon la norme qu'il indique : ils n'afficheront donc pas R004. Si un fichier destiné à Peppol est signalé comme « EN 16931 » ou « XRechnung », regardez d'abord le CustomizationID.

PEPPOL-EN16931-R002 : plus d'une note

No more than one note is allowed on document level, unless both the buyer and seller are German organizations. L'UBL autorise plusieurs éléments cbc:Note ; Peppol n'en autorise qu'un. Une facture Stripe a deux champs de texte libre qui atterrissent ici, le mémo (description) et le pied de page (footer). Réunissez-les en une seule note :

<cbc:Note>Thank you! Questions? billing@voorbeeld.example</cbc:Note>

La note se place juste après cbc:InvoiceTypeCode ; ailleurs, le schéma XML la rejette.

BR-CO-10, BR-CO-13, BR-CO-15 et PEPPOL-EN16931-R120 : totaux

BR-CO-10 : Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
BR-CO-13 : Invoice total amount without VAT (BT-109) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).
BR-CO-15 : Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
PEPPOL-EN16931-R120 : Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount.

Les totaux du document sont contrôlés au centime près. Ils cassent quand certains montants sont copiés de Stripe (son subtotal, sa tax et son total) et que d'autres sont recalculés par le générateur, avec un autre arrondi ou sans la remise. Calculez chaque total à partir des lignes et de la ventilation de la TVA que vous écrivez réellement :

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="EUR">49.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="EUR">49.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="EUR">59.29</cbc:TaxInclusiveAmount>
  <cbc:PrepaidAmount currencyID="EUR">59.29</cbc:PrepaidAmount>
  <cbc:PayableAmount currencyID="EUR">0.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Ici, le client a déjà payé par carte : le montant payé (BT-113) est égal au total et le montant à payer (BT-115) est de 0.

R120 est le contrôle Peppol au niveau de la ligne : quantité × prix doit donner le montant de la ligne. Il se déclenche sur les lignes de prorata de Stripe et les ajustements similaires, où le montant de la ligne est une fraction du prix de l'abonnement. Indiquez comme prix le montant propre de la ligne divisé par sa quantité, et non le prix catalogue de l'abonnement. R120 tolère un petit écart d'arrondi ; les règles de niveau document ci-dessus, non.

BR-S-08, BR-S-09 et BR-CO-17 : ventilation de la TVA avec une remise

BR-S-08 : For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) …

La cause habituelle est un coupon Stripe. Si la remise est écrite comme une remise au niveau du document, la base imposable de la ventilation de la TVA doit être le montant après remise. Une ventilation qui affiche encore les 49.00 non remisés reçoit BR-S-08 et, comme sa TVA ne correspond plus à base imposable × taux, BR-S-09 et BR-CO-17 en plus. Pour un coupon de 20 % sur un abonnement à 49 € avec la TVA belge à 21 % :

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>Coupon LAUNCH20</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="EUR">9.80</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>21</cbc:Percent>
    <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">8.23</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="EUR">39.20</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="EUR">8.23</cbc:TaxAmount>
    ...

Les totaux sont alors de 49.00 (lignes), 9.80 (AllowanceTotalAmount), 39.20 hors TVA et 47.43 TVA comprise. Avec plusieurs taux de TVA, donnez à chaque remise le taux des lignes auxquelles elle s'applique et écrivez une ventilation par taux.

BR-AE-10 et BR-AE-02 : autoliquidation

Pour une vente à une entreprise d'un autre pays de l'UE en autoliquidation, la catégorie de TVA est AE avec un taux de 0, sur les lignes et dans la ventilation.

BR-AE-10 : A VAT breakdown (BG-23) with VAT Category code (BT-118) "Reverse charge" shall have a VAT exemption reason code (BT-121), meaning "Reverse charge" or the VAT exemption reason text (BT-120) "Reverse charge" (or the equivalent standard text in another language).
BR-AE-02 : une facture comportant des lignes en autoliquidation doit contenir le numéro de TVA du vendeur (BT-31), son identifiant d'enregistrement fiscal (BT-32) ou le numéro de TVA de son représentant fiscal (BT-63), et le numéro de TVA de l'acheteur (BT-48) ou son numéro d'immatriculation légale (BT-47).

Dans Stripe, c'est un client dont tax_exempt vaut reverse ; le numéro de TVA de l'acheteur vient des customer_tax_ids de la facture. Si le client n'a pas de numéro fiscal dans Stripe, BR-AE-02 se déclenche. La catégorie de la ventilation :

<cac:TaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cbc:Percent>0</cbc:Percent>
  <cbc:TaxExemptionReasonCode>VATEX-EU-AE</cbc:TaxExemptionReasonCode>
  <cbc:TaxExemptionReason>Reverse charge</cbc:TaxExemptionReason>
  <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:TaxCategory>

Indiquez le motif uniquement dans la ventilation, pas sur les lignes : dans cac:ClassifiedTaxCategory, il donne les avertissements UBL-CR-600 et UBL-CR-601. Savoir si l'autoliquidation s'applique à une vente est une question fiscale ; les règles vérifient seulement que la facture est cohérente une fois que vous avez tranché.

BR-CL-23 et PEPPOL-EN16931-R051 : codes d'unité et de devise

BR-CL-23 : Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension. Stripe n'a pas d'unité de mesure, et des mots comme month ou pcs ne sont pas des codes. Utilisez C62 (« un ») pour un abonnement ou une licence compté à l'unité, MON pour une quantité en mois, HUR pour des heures.
PEPPOL-EN16931-R051 : All currencyID attributes must have the same value as the invoice currency code (BT-5), except for the invoice total VAT amount in accounting currency (BT-111). Stripe écrit les devises en minuscules (eur) ; dans le XML, elles doivent être en majuscules (EUR), identiques sur chaque montant. Un code en minuscules déclenche aussi BR-CL-03 et PEPPOL-EN16931-CL007.

<cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">49.00</cbc:LineExtensionAmount>

Vérifier votre correction

Corrigez un groupe d'erreurs à la fois, puis vérifiez à nouveau : un élément parent manquant peut masquer des erreurs dans ses enfants, et le contrôle du schéma XML échoue en premier si les éléments ne sont pas dans le bon ordre. Notre validateur applique les règles EN 16931 et Peppol BIS 3.0, liste chaque résultat avec son emplacement dans le document et affiche la facture sous une forme lisible.

Guides associés

How to validate a Peppol BIS 3.0 invoice (en anglais) : les ensembles de règles et comment les appliquer.
L'obligation Peppol en Belgique pour les entreprises qui facturent avec Stripe.
Mapping a Stripe invoice to EN 16931 (en anglais) : d'où vient chaque champ dans Stripe.
Common XRechnung validation errors (en anglais) : les règles allemandes BR-DE.

Où evoicely intervient

Vérifiez votre facture Peppol pour ces erreurs, gratuitement et sans inscription. evoicely envoie via Peppol les factures et notes de crédit Stripe des entreprises belges, contrôlées selon ces règles avant leur envoi, et les transforme en XRechnung et ZUGFeRD pour les clients allemands. Commencez maintenant : c'est gratuit pour 10 factures électroniques par mois.

Ceci est une information générale, pas un conseil juridique ou fiscal. Passer les règles de validation ne tranche pas des questions comme le traitement TVA applicable ; vérifiez ce qui s'applique à votre entreprise avec votre comptable ou conseiller fiscal.