Odoo Factur-X XRechnung Peppol : diagnostiquer et corriger les erreurs de validation EN16931

Odoo est un ERP complet dont l’architecture modulaire couvre nativement la facturation électronique. Depuis la version 16, il embarque le support Factur-X via le module account_edi_facturx et le support UBL/CII pour Peppol via le module account_edi_ubl_cii. Mais un export qui fonctionne dans Odoo ne garantit pas un fichier conforme EN16931 — et les PDP rejetteront toute facture qui échoue à la validation Schematron.

Cet article couvre l’architecture EDI d’Odoo, les erreurs de validation les plus fréquentes dans ses exports Factur-X et Peppol, et le workflow de correction à appliquer avant d’envoyer une facture en production.

Pour le contexte général de la validation EN16931, voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*. Pour le mapping des champs obligatoires, voir Champs obligatoires EN16931 : cartographie et mapping ERP.

Architecture EDI d’Odoo

Odoo structure sa facturation électronique autour du modèle account.edi.format, qui fournit le framework abstrait pour les formats EDI. Chaque format concret est implémenté par un module spécifique.

Les modules clés

Le module account_edi_facturx est activé par défaut sur les bases de données françaises. Il génère un fichier PDF contenant un XML CII D22B embarqué — c’est le PDF hybride qui constitue une facture Factur-X valide.

Le module account_edi_ubl_cii gère les exports UBL 2.1 destinés au réseau Peppol. Peppol BIS Billing 3.0 utilise la syntaxe UBL 2.1 et non CII — il est important de ne pas confondre les deux formats, même s’ils partagent le même modèle sémantique EN16931. Pour les différences structurelles, voir Factur-X vs UBL vs CII : quel format choisir.

Comment Odoo génère le XML Factur-X

Le processus de génération suit ces étapes dans le code Odoo :

1. La facture est confirmée dans Comptabilité > Factures clients > Confirmer
2. Le module account_edi_facturx construit le XML CII à partir des champs de la facture (account.move) et des données de la société (res.company) et du partenaire (res.partner)
3. Le XML est embarqué dans le PDF via le mécanisme PDF/A-3 (pièce jointe au format XML)
4. Le profil Factur-X est déterminé automatiquement selon les données présentes — EN16931 si suffisamment de champs sont renseignés, sinon MINIMUM ou BASIC

Le choix automatique du profil est une source d’erreur courante : Odoo peut générer un profil MINIMUM alors que la PDP exige EN16931 ou supérieur.

Erreurs fréquentes et corrections

1. SIRET/SIREN manquant (BT-30)

Erreur : BR-CO-26 — aucun identifiant vendeur parmi BT-29, BT-30 et BT-31.

BT-30 est l’identifiant légal du vendeur. En France, c’est le SIRET (14 chiffres) ou le SIREN (9 chiffres). Odoo stocke cette donnée dans le champ siret du modèle res.company, mais ce champ n’est renseigné que si l’utilisateur l’a saisi explicitement.

Où configurer dans Odoo :

1. Paramètres > Sociétés > Votre société
2. Onglet Informations générales
3. Champ SIRET (ou Numéro d’identification de la société selon la localisation)
4. Saisir le SIRET complet à 14 chiffres sans espaces

Le XML généré doit contenir :

<ram:SellerTradeParty>
  <ram:Name>Ma Société SAS</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0002">12345678901234</ram:ID>
  </ram:SpecifiedLegalOrganization>
</ram:SellerTradeParty>

Le schemeID="0002" correspond au code ICD pour SIRENE/SIREN dans la liste ISO 6523. Si Odoo génère le XML sans cet attribut, la validation Schematron échouera sur les règles qui vérifient la présence d’un identifiant vendeur qualifié.

Attention : BT-30 (identifiant légal = SIRET) et BT-31 (numéro TVA = FR + 11 chiffres) sont deux champs distincts. La règle BR-CO-26 exige au moins l’un des deux, mais les PDP françaises attendent généralement les deux pour le routage. Voir Champs obligatoires EN16931 : cartographie et mapping ERP pour le détail des cardinalités.

2. Format de TVA incorrect (BT-31)

Erreur : validation du format de SpecifiedTaxRegistration/ram:ID — le numéro de TVA n’est pas au format attendu.

Le numéro de TVA intracommunautaire français suit le format FR + 2 chiffres clé + 9 chiffres SIREN, soit 13 caractères au total (préfixe compris). Odoo stocke cette valeur dans res.company.vat.

Erreurs courantes :

Où corriger : Paramètres > Sociétés > Votre société, champ Numéro de TVA. Odoo v16+ valide le format à la saisie, mais les bases migrées depuis des versions antérieures peuvent contenir des valeurs non conformes.

Le XML attendu :

<ram:SpecifiedTaxRegistration>
  <ram:ID schemeID="VA">FR12345678901</ram:ID>
</ram:SpecifiedTaxRegistration>

3. Code EAS manquant ou incorrect

Erreur : PEPPOL-COMMON-R040 ou erreur XSD sur EndpointID/@schemeID — identifiant GLN invalide ou code EAS absent.

La règle PEPPOL-COMMON-R040 vérifie spécifiquement la validité d’un identifiant GLN (Global Location Number) lorsque le scheme 0088 est utilisé. Ce n’est pas une règle de présence d’EAS en général — elle contrôle que le GLN fourni est bien un identifiant à 13 chiffres conforme. Pour les erreurs de code EAS absent ou invalide, d’autres règles Peppol ou des erreurs XSD s’appliquent.

Le code EAS identifie le type d’adresse électronique utilisé pour le routage sur le réseau Peppol. Il est requis sur les éléments EndpointID du vendeur et de l’acheteur dans les exports UBL Peppol. En contexte Factur-X CII, l’équivalent est l’identifiant électronique du destinataire.

Les codes EAS les plus utilisés en France :

Où configurer dans Odoo :

Pour le réseau Peppol, l’identifiant électronique du partenaire se configure dans la fiche du partenaire :

1. Contacts > Partenaire > Modifier
2. Onglet Comptabilité (ou Ventes et achats selon la version)
3. Section Informations EDI ou Peppol
4. Renseigner l’identifiant Peppol avec le bon code EAS

Exemple de XML UBL avec EAS :

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0009">12345678901234</cbc:EndpointID>
    <cac:PartyName>
      <cbc:Name>Client SARL</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingCustomerParty>

Si le schemeID est absent ou contient un code non reconnu par le réseau Peppol, la facture sera rejetée au point d’accès avant même d’atteindre le destinataire.

4. PEPPOL-EN16931-R010 — Référence acheteur manquante (BT-10)

Erreur : PEPPOL-EN16931-R010 — “A Peppol invoice shall have a buyer reference (BT-10) or a purchase order reference (BT-13).”

C’est l’une des erreurs Peppol les plus fréquentes dans Odoo. BT-10 (Buyer reference) est une référence attribuée par l’acheteur pour identifier la commande ou le marché. Son caractère obligatoire dépend du cadre d’échange, pas du noyau EN16931 (où BT-10 est 0..1). Sur le réseau Peppol BIS Billing 3.0, BT-10 ou BT-13 est requis pour le routage et la réconciliation côté destinataire. De même, Chorus Pro exige BT-10 pour le routage B2G. En dehors de ces cadres, BT-10 reste optionnel.

Où configurer dans Odoo :

1. Comptabilité > Factures clients > Modifier la facture
2. Champ Référence du paiement ou Référence client dans l’onglet Autre info
3. Saisir la référence communiquée par le client (bon de commande, numéro de marché, etc.)

Le XML UBL doit contenir :

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

En CII (Factur-X), l’équivalent est :

<ram:ApplicableHeaderTradeAgreement>
  <ram:BuyerReference>PO-2026-00142</ram:BuyerReference>
</ram:ApplicableHeaderTradeAgreement>

Si le client ne fournit aucune référence, une pratique courante est d’utiliser le numéro SIRET du destinataire ou la mention “NA” — mais vérifier avec la PDP ou le point d’accès Peppol que cette valeur par défaut est acceptée.

5. Erreurs d’arrondis sur les montants (BR-CO-*)

Erreurs : BR-CO-10, BR-CO-13, BR-CO-14, BR-CO-15, BR-CO-17 — incohérences arithmétiques.

Les règles BR-CO-* vérifient la cohérence mathématique entre les montants de la facture. Un écart d’un centime suffit à déclencher un rejet. Odoo peut introduire des divergences d’arrondis dans plusieurs situations :

• Lignes avec remises en pourcentage : Odoo calcule la remise par ligne puis arrondit, alors que Schematron vérifie la somme des arrondis. L’écart cumulatif peut dépasser la tolérance.
• TVA multi-taux : quand une facture contient des lignes à 20% et des lignes à 5.5%, les arrondis par ventilation TVA peuvent diverger du total.
• Devise à 0 décimales : les devises sans centimes (JPY, CLP) amplifient les écarts.

Diagnostic : exporter le XML, extraire les montants clés et vérifier manuellement :

BT-106 (LineTotalAmount)     = somme des BT-131 (montants nets de ligne)
BT-109 (TaxBasisTotalAmount) = BT-106 + charges document - remises document
BT-110 (TaxTotalAmount)      = somme des BT-117 (TVA par catégorie)
BT-112 (GrandTotalAmount)    = BT-109 + BT-110
BT-115 (DuePayableAmount)    = BT-112 - BT-113 (acomptes) - BT-114 (arrondis)

Correction dans Odoo :

1. Paramètres > Comptabilité > Devise : vérifier que la précision de la devise est à 2 décimales pour EUR
2. Vérifier les règles d’arrondi dans Paramètres > Comptabilité > Paramètres par défaut
3. Pour les cas persistants, vérifier le code du module account_edi_facturx — Odoo corrige régulièrement ces écarts dans les mises à jour mineures

Pour la liste complète des règles BR-CO-* et leur logique, voir Catalogue des erreurs BR-*.

6. Moyen de paiement manquant (BT-81)

Erreur : absence du noeud SpecifiedTradeSettlementPaymentMeans dans le XML CII, ou code TypeCode absent.

BT-81 (Payment means type code) identifie le moyen de paiement par un code UNTDID 4461. Odoo stocke les modes de paiement dans le modèle account.payment.method, mais le mapping vers les codes normalisés n’est pas toujours complet.

Les codes les plus courants :

Où configurer dans Odoo :

1. Comptabilité > Configuration > Modes de paiement
2. Vérifier que le mode de paiement utilisé sur la facture est bien mappé à un code UNTDID 4461 valide
3. Sur la facture : onglet Autre info > Méthode de paiement, sélectionner le mode de paiement correct

Le XML attendu :

<ram:SpecifiedTradeSettlementPaymentMeans>
  <ram:TypeCode>58</ram:TypeCode>
  <ram:PayeePartyCreditorFinancialAccount>
    <ram:IBANID>FR7630006000011234567890189</ram:IBANID>
  </ram:PayeePartyCreditorFinancialAccount>
</ram:SpecifiedTradeSettlementPaymentMeans>

Si un virement est spécifié (codes 30, 31, 42, 58), l’IBAN (BT-84) devient conditionnel obligatoire. Vérifier que le compte bancaire de la société est renseigné dans Paramètres > Sociétés > Comptes bancaires.

Spécificités XRechnung (partenaires allemands)

XRechnung est le CIUS (Core Invoice Usage Specification) allemand de la norme EN16931. Il ajoute des contraintes supplémentaires par rapport au profil EN16931 de base, identifiées par le préfixe BR-DE-*. Ces règles sont spécifiques à l’Allemagne et ne s’appliquent pas aux factures destinées à des partenaires français.

Si vous exportez des factures depuis Odoo vers des administrations ou entreprises allemandes, les règles suivantes s’ajoutent :

BR-DE-01 — Contact vendeur obligatoire

XRechnung exige un point de contact sur le vendeur (BG-6) avec au minimum un email (BT-43) ou un téléphone (BT-42). Odoo ne renseigne pas systématiquement ces champs dans le XML.

Correction : Paramètres > Sociétés > Votre société, vérifier que le champ Email et/ou Téléphone est renseigné. Le module l10n_de_xrechnung les mappe automatiquement vers le XML si présents.

BR-DE-02 — Email acheteur obligatoire

Le destinataire doit également avoir un email dans sa fiche contact.

Correction : Contacts > Partenaire, renseigner le champ Email.

BR-DE-15 — Leitweg-ID obligatoire

Pour les factures B2G en Allemagne, la Leitweg-ID (identifiant de routage administratif) est obligatoire dans BT-10 (Buyer reference). C’est l’équivalent fonctionnel du code service dans Chorus Pro pour la France.

Correction : saisir la Leitweg-ID dans le champ Référence client de la facture Odoo. Le format type est XX-YYYYYY-ZZ où XX est le Land, YYYYYY l’unité administrative, et ZZ un suffixe de contrôle.

Règles BR-DE-* vs règles BR-* du socle

Il est important de ne pas confondre les deux jeux de règles :

Note sur les règles BR-FR-* : les règles préfixées BR-FR-* ne sont pas des codes officiels de la norme EN16931 (CEN TC 434). Elles désignent des contrôles spécifiques au cadre français, définis par les CIUS nationales (Core Invoice Usage Specifications) ou les PDP. Leur application dépend du contexte réglementaire français et non du socle européen.

Une erreur BR-DE-* dans un export destiné à la France est un faux positif : elle résulte de l’application du mauvais jeu de règles. Vérifier que le profil de validation correspond au pays destinataire.

Spécificités Peppol BIS Billing 3.0

Le réseau Peppol utilise UBL 2.1 comme syntaxe de transport, avec des règles additionnelles définies dans le profil BIS Billing 3.0. Si vous envoyez des factures via un point d’accès Peppol, les validations suivantes s’ajoutent à celles du socle EN16931.

Règles Peppol les plus fréquemment échouées dans Odoo

CustomizationID et ProfileID

Le réseau Peppol exige deux identifiants dans l’en-tête UBL :

<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>

Le module account_edi_ubl_cii d’Odoo génère ces valeurs automatiquement. Si elles sont absentes ou incorrectes, vérifier que le module est à jour et que le format EDI Peppol est bien activé dans Paramètres > Comptabilité > Facturation électronique.

Conversion CII vers UBL

Odoo génère nativement du CII pour Factur-X et de l’UBL pour Peppol. Si vous devez envoyer un document Factur-X à un destinataire Peppol, une conversion CII vers UBL est nécessaire. Cette conversion n’est pas triviale : les namespaces, la structure des noeuds et les identifiants de profil diffèrent complètement entre les deux syntaxes.

Ne tentez pas de convertir manuellement un XML CII en UBL — utilisez le module Odoo adapté (account_edi_ubl_cii pour Peppol) ou un outil de conversion validé. Pour les différences structurelles entre CII et UBL, voir Factur-X vs UBL vs CII : quel format choisir.

Valider les exports Odoo avec l’API FacturX

Le workflow de validation optimal consiste à intercepter le fichier généré par Odoo et le valider avant envoi au destinataire ou à la PDP.

Extraction du fichier depuis Odoo

Pour récupérer le PDF Factur-X généré par Odoo :

1. Comptabilité > Factures clients > sélectionner la facture
2. Imprimer > Factures ou utiliser le bouton Envoyer et Imprimer
3. Le PDF téléchargé contient le XML CII embarqué

Pour l’export UBL Peppol, le fichier XML est disponible dans les pièces jointes de la facture (Pièces jointes > fichier .xml).

Validation via l’API

curl -X POST https://facturxapi.com/api/v1/validate \
  -H "X-API-Key: votre-cle-api" \
  -F "[email protected]"

Réponse type pour une facture avec SIRET manquant :

{
  "valid": false,
  "profile": "EN16931",
  "errors": [
    {
      "id": "BR-CO-26",
      "type": "error",
      "message": "Au moins un identifiant vendeur doit être présent (BT-29, BT-30 ou BT-31).",
      "location": "/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement"
    }
  ],
  "warnings": [],
  "pdfConformance": {
    "valid": true,
    "standard": "PDF/A-3b"
  }
}

Le champ id correspond à l’identifiant de règle EN16931, ce qui permet de localiser directement la correction à appliquer dans Odoo.

Intégration dans un pipeline automatisé

Pour les déploiements à volume, automatiser la validation dans le flux de facturation :

1. Odoo génère la facture via le workflow standard
2. Un webhook ou un cron récupère le PDF/XML généré
3. L’API FacturX valide le fichier et retourne le rapport
4. Si des erreurs sont détectées : la facture est marquée en erreur dans Odoo, l’équipe comptable est notifiée
5. Si la validation passe : la facture est envoyée à la PDP ou au point d’accès Peppol

Cette boucle de validation évite les rejets en production et permet d’identifier les problèmes de configuration avant qu’ils n’affectent le flux de trésorerie.

Workflow de débogage : export, validation, correction, re-export

Quand une facture Odoo échoue à la validation, suivre ce processus systématique :

Étape 1 — Exporter le fichier

Télécharger le PDF (Factur-X) ou le XML (UBL/Peppol) depuis la facture Odoo.

Étape 2 — Valider

Envoyer le fichier à l’API FacturX. Le rapport distingue trois niveaux : conformité PDF/A-3, validation XSD, et validation Schematron. Les erreurs Schematron sont les plus fréquentes et les plus informatives.

Étape 3 — Identifier la source dans Odoo

Chaque erreur pointe vers un BT (Business Term). La correspondance BT vers champ Odoo :

Étape 4 — Corriger dans Odoo

Appliquer la correction dans la configuration ou les données de la société/partenaire. Pour les factures déjà confirmées, il peut être nécessaire de les remettre en brouillon (Bouton “Remettre en brouillon”) avant de modifier les données et de re-confirmer.

Étape 5 — Re-exporter et re-valider

Après correction, générer à nouveau le PDF/XML et re-valider via l’API. Itérer jusqu’à obtenir un rapport sans erreur.

Étape 6 — Valider un lot représentatif

Ne pas se contenter d’une seule facture. Tester un échantillon couvrant les cas de figure de votre activité : facture avec TVA standard, avec TVA à taux réduit, avoir, facture multi-devises, facture avec remise globale.

Checklist de configuration Odoo pour la conformité

CONFIGURATION ODOO — FACTUR-X / PEPPOL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Société (Paramètres > Sociétés)
☐ Nom de la société — non vide
☐ SIRET — 14 chiffres, sans espaces
☐ Numéro TVA — FR + 11 chiffres, sans espaces
☐ Adresse complète — rue, ville, code postal, pays
☐ Email et téléphone — requis pour XRechnung
☐ Compte bancaire — IBAN renseigné

Modules EDI (Paramètres > Comptabilité > Facturation électronique)
☐ account_edi_facturx — activé pour Factur-X
☐ account_edi_ubl_cii — activé pour Peppol
☐ l10n_de_xrechnung — activé si export Allemagne

Partenaires (Contacts)
☐ Nom — non vide
☐ Adresse complète — rue, ville, code postal, pays
☐ Identifiant Peppol + code EAS — si réseau Peppol
☐ SIRET/TVA — pour le routage PDP

Factures
☐ Mode de paiement — avec code UNTDID 4461 valide
☐ Référence client (BT-10) — obligatoire pour Peppol
☐ Date d'échéance — recommandé
☐ Profil Factur-X — EN16931 minimum pour les PDP

Ressources

• Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — comprendre les deux niveaux de validation
• Facturation électronique 2026 : le guide technique complet — calendrier, architecture PDP, pipeline
• Champs obligatoires EN16931 : cartographie et mapping ERP — tous les BT obligatoires et leur XPath
• Factur-X vs UBL vs CII : quel format choisir — quand utiliser CII vs UBL
• Catalogue des erreurs BR-* — référence exhaustive des règles Schematron

La conformité EN16931 dans Odoo repose sur la configuration correcte des identifiants légaux, des modes de paiement et des références partenaires. Le module Factur-X génère un XML techniquement valide en XSD, mais les règles Schematron et les contraintes Peppol/XRechnung exigent des données que seule une configuration complète peut fournir. Valider systématiquement avant l’envoi en production est le seul moyen d’éviter les rejets.