Sur cette page
La réponse courte
PEPPOL-EN16931-P0112 échoue lorsque cbc:InvoiceTypeCode vaut 326 ou 384 et que le vendeur et l'acheteur ne sont pas tous deux en Allemagne. Les deux codes figurent sur la liste Peppol des types de facture, mais cette règle les réserve aux factures intérieures allemandes. Entre toutes les autres parties, envoyez une facture ordinaire, 380, et corrigez une facture antérieure par un avoir plutôt que par une facture rectificative.
Ce qui compte comme l'Allemagne est décidé par la seule adresse postale. La règle lit le code de pays de l'adresse postale du vendeur et de celle de l'acheteur, sans espaces de bord et en majuscules, et les deux doivent valoir DE. Les identifiants TVA, un représentant fiscal et l'adresse de livraison ne jouent aucun rôle.
Ce que la règle vérifie
La règle s'exécute sur cbc:InvoiceTypeCode, en supprime les espaces de bord et échoue pour 326 ou 384 sauf si les deux codes de pays des adresses postales valent DE. Tout autre code est laissé à PEPPOL-EN16931-P0100 ; lors d'un essai, 326 entouré d'espaces a encore été signalé ici.
Une seule partie allemande ne suffit pas. Lors d'un essai, 384 a échoué avec l'adresse du vendeur déplacée à Berlin et l'acheteur resté à Londres, de même qu'avec un vendeur à Londres portant l'identifiant TVA DE123456789 et vendant à un acheteur à Munich.
L'inverse vaut aussi : avec les deux adresses postales en Allemagne, 384 a réussi cette règle lors d'un essai, bien que l'identifiant TVA du vendeur commence par GB.
Les minuscules comptent ici comme allemandes, car le code de pays est d'abord mis en majuscules. Lors d'un essai, de dans les deux adresses a satisfait cette règle, tandis que BR-CL-14 a rejeté les deux codes.
Deux adresses allemandes activent aussi les règles nationales allemandes, qui utilisent le même test. Lors d'un essai, l'exemple enregistré déplacé à Berlin et Munich avec 384 a réussi cette règle et fait apparaître DE-R-001 (instructions de paiement), DE-R-002 (contact du vendeur) et l'avertissement DE-R-026 (une référence à la facture corrigée).
| Terme | Signification | Élément UBL |
|---|---|---|
| BT-3 | Code de type de facture | cbc:InvoiceTypeCode |
| BT-40 | Code de pays du vendeur | cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode |
| BT-55 | Code de pays de l'acheteur | cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode |
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 :
- Une intégration conçue pour des clients allemands, où les deux codes sont utilisés, est réutilisée pour des clients d'autres pays.
- Les corrections sont envoyées comme nouvelle facture codée
384au lieu d'un avoir suivi, si nécessaire, d'une nouvelle facture. - La facturation par acomptes ou à l'avancement est codée
326, facture partielle, pour des clients hors d'Allemagne. - Les parties sont allemandes dans le système de gestion, mais une adresse écrite dans la facture ne l'est pas, par exemple celle d'un siège à l'étranger.
Comment corriger le document
- Regardez les codes de pays que la facture porte réellement dans les deux groupes
cac:PostalAddress. Si les deux parties sont en Allemagne et qu'une adresse dit autre chose, corrigez l'adresse. - Sinon, choisissez un autre code de type. Une facture partielle ou d'acompte peut partir en
380, facture commerciale. Pour une correction, envoyez un avoir,381, sur la facture d'origine, puis une nouvelle facture si un montant reste dû. - Faites référence à la facture corrigée dans
cac:BillingReference/cac:InvoiceDocumentReference, sur l'avoir ou sur la nouvelle facture. - Si les deux parties sont en Allemagne et que vous gardez
326ou384, respectez aussi les règles nationales allemandes. Lors d'un essai, l'exemple à Berlin et Munich a réussi toutes les étapes dès qu'il a eu un moyen de paiement, un contact du vendeur et unecac:BillingReference.
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 : code de type 384 entre un vendeur et un acheteur au Royaume-Uni
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
<!-- currency and buyer reference omitted from this fragment -->
<cac:AccountingSupplierParty>
<cac:Party>
<!-- electronic address omitted from this fragment -->
<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>
<!-- tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<!-- electronic address omitted from this fragment -->
<cac:PostalAddress>
<cbc:StreetName>2 Example Street</cbc:StreetName>
<cbc:CityName>London</cbc:CityName>
<cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<!-- legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingCustomerParty>Fragment de la facture corrigée : code de type 380 pour les deux mêmes parties
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- currency and buyer reference omitted from this fragment -->
<cac:AccountingSupplierParty>
<cac:Party>
<!-- electronic address omitted from this fragment -->
<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>
<!-- tax scheme and legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<!-- electronic address omitted from this fragment -->
<cac:PostalAddress>
<cbc:StreetName>2 Example Street</cbc:StreetName>
<cbc:CityName>London</cbc:CityName>
<cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>GB</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<!-- legal entity omitted from this fragment -->
</cac:Party>
</cac:AccountingCustomerParty>Seul cbc:InvoiceTypeCode diffère : 384 dans la facture en échec, 380 dans la facture corrigée, les deux parties restant en GB. Le document en échec ne signale que cette règle ; BR-CL-01 et PEPPOL-EN16931-P0100 réussissent, car 384 figure sur leurs deux listes. Le recodage convient à cet exemple, qui est une facture ordinaire ; une vraie correction hors d'Allemagne passe par un avoir.
Ce que le validateur a signalé
- La facture en erreur signale PEPPOL-EN16931-P0112. 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 uniquement à UBL
Invoice, puisque la règle litcbc:InvoiceTypeCode. Un avoir ne peut pas du tout utiliser384: lors d'un essai, uncbc:CreditNoteTypeCodevalant384a été rejeté parBR-CL-01etPEPPOL-EN16931-P0101. - Signalée par l'étape Peppol. EN 16931 ne connaît pas cette condition, et les deux codes réussissent
BR-CL-01quelles que soient les parties. - Le test d'une facture allemande est celui qu'utilisent les règles nationales allemandes pour s'activer. Une facture qui réussit cette règle avec
326ou384est donc toujours contrôlée aussi par ces règles.
Règles liées
- PEPPOL-EN16931-P0100 contrôle le code de type de facture par rapport à la liste Peppol avant que cette règle ne restreigne deux de ses codes
- BR-CL-01 accepte 326 et 384 pour toutes les parties dans l'étape EN 16931
- BR-CL-14 contrôle les codes de pays des adresses postales qui décident si les deux parties sont allemandes
- PEPPOL-EN16931-P0101 tient les avoirs à leur propre liste de codes de type
- Parcourir toutes les règles de la référence
- Contexte (en anglais) : How Peppol invoice validation actually works
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-28.1 : source vérifiée le 2026-09-28, explication mise à jour le 2026-09-28.
La définition officielle de PEPPOL-EN16931-P0112 (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.

