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

En bref

• Odoo 18 regroupe des exports Factur-X/CII, Peppol BIS3/UBL et XRechnung/UBL dans account_edi_ubl_cii. Vérifier la version et les modules installés ; les indications ci-dessous ne décrivent pas toutes les versions d’Odoo.
• Lire le profil effectivement déclaré dans le XML et le comparer au profil demandé par le destinataire. L’exporteur CII 18.0 consulté déclare EXTENDED ; ne pas supposer une sélection automatique MINIMUM/BASIC/EN16931 selon les champs saisis.
• BR-CO-26 exige au moins un identifiant vendeur parmi BT-29, BT-30 et BT-31, pas spécifiquement un SIRET. Les exigences France CTC et le routage doivent être vérifiés séparément.
• Pour Peppol BIS Billing 3.0 : l’adresse électronique de l’acheteur (BT-49) est obligatoire ; son schemeID est un identifiant de schéma EAS. Règle PEPPOL-EN16931-R010.
• Validation pré-envoi systématique via /api/v1/validate (Factur-X FR) ou un validateur UBL BIS3 (Peppol). Un échec aux contrôles attendus peut conduire à un rejet à la réception.

Odoo est un ERP complet dont l’architecture modulaire couvre nativement la facturation électronique. La disponibilité des formats, les champs et les menus dépendent de la version, des modules et des localisations installés. Mais un export qui fonctionne dans Odoo ne prouve pas qu’il passe les contrôles EN16931 attendus. Un échec Schematron augmente le risque de rejet documentaire, sans permettre à FacturX API de prédire le verdict final d’une PA.

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

Les repères de cette section proviennent de la documentation Odoo 18 et du module officiel account_edi_ubl_cii 18.0, consultés le 22 septembre 2026.

Les modules et formats

Le module account_edi_ubl_cii fournit notamment les exports Factur-X/CII, Peppol BIS Billing 3.0/UBL 2.1 et XRechnung/UBL. Le format choisi pour le client et les modules installés déterminent le flux disponible. Un module de transmission Peppol et un générateur de XML n’assurent pas la même fonction.

Ne pas confondre les syntaxes : Factur-X vs UBL vs CII détaille leurs structures. Un PDF contenant un XML ne prouve pas à lui seul la conformité Factur-X : le conteneur, le schéma et les règles applicables restent à contrôler.

Comment vérifier l’export Factur-X

1. Vérifier le format électronique sélectionné pour le client dans la version installée.
2. Générer l’export depuis le flux d’envoi de la facture et récupérer le fichier effectivement produit.
3. Lire le GuidelineID du XML et identifier le profil et la version à valider.
4. Comparer ce profil aux exigences du destinataire avant transmission.

L’exporteur CII Odoo 18.0 consulté déclare EXTENDED. Ce constat ne prouve pas le comportement d’une autre version ou d’un connecteur personnalisé ; il ne justifie pas d’annoncer un choix automatique MINIMUM/BASIC/EN16931 selon les données présentes.

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 ; BT-29 est son identifiant commercial et BT-31 son identifiant TVA. BR-CO-26 accepte au moins un de ces trois identifiants. Vérifier séparément les exigences du profil France applicable et le mapping de la localisation Odoo.

Où configurer dans Odoo :

1. Paramètres > Sociétés > Votre société
2. Onglet Informations générales
3. Identifier le champ d’identification légale utilisé par la localisation installée
4. Vérifier l’identifiant réellement exporté et son schéma : SIREN/0002 et SIRET/0009 ne sont pas interchangeables

Extrait illustratif d’un identifiant légal SIREN ; les chiffres ci-dessous ne sont pas une identité vérifiée :

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

Dans la liste ICD, 0002 désigne SIRENE/SIREN et 0009 SIRET. Ne pas associer 0002 à un numéro de quatorze chiffres. L’obligation et la forme du schéma dépendent du champ et du profil ; BR-CO-26 ne rend pas universellement obligatoire un SIRET qualifié.

Attention : identité légale, TVA et adresse de routage sont distinctes. La présence de BT-30 ou BT-31 ne prouve pas le routage PA. Voir Champs obligatoires EN16931 : cartographie et mapping ERP pour distinguer les champs.

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-R003 — Référence acheteur ou référence de commande manquante (BT-10 ou BT-13)

Erreur : PEPPOL-EN16931-R003 — “A buyer reference or purchase order reference MUST be provided.”

R003 accepte BT-10 ou BT-13. BT-10 est une référence de routage interne attribuée par l’acheteur ; BT-13 identifie sa commande. Une référence de marché relève de BT-12. Ces données ne sont pas interchangeables avec la référence de paiement.

Des contraintes supplémentaires peuvent s’appliquer : DE-R-015 exige BT-10 lorsque vendeur et acheteur sont allemands. Pour Chorus Pro, consulter le paramétrage de la structure et du service dans l’annuaire : code service et engagement dépendent du destinataire, pas du seul caractère B2G.

Dans Odoo, localiser le champ utilisé par le connecteur installé, puis contrôler l’export. En CII 18.0, la référence acheteur provient du champ dédié lorsqu’il existe, sinon de la référence du partenaire commercial ; la commande utilise un autre mapping. Ne pas utiliser « Référence du paiement » comme correction universelle de BT-10.

Exemples UBL alternatifs, à remplir avec les références réelles communiquées par l’acheteur :

<!-- BT-10 : référence de routage interne acheteur -->
<cbc:BuyerReference>SERVICE-ACHATS</cbc:BuyerReference>

<!-- BT-13 : référence de commande acheteur -->
<cac:OrderReference>
  <cbc:ID>PO-2026-00142</cbc:ID>
</cac:OrderReference>

En CII, BT-10 se trouve dans ApplicableHeaderTradeAgreement/BuyerReference. Ne pas inventer une référence NA ou un SIRET de substitution pour faire passer le contrôle ; demander la référence attendue au destinataire.

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

Erreurs : BR-CO-10, BR-CO-13, BR-CO-14, BR-CO-15, BR-CO-16, 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 peut déclencher un diagnostic selon la règle et sa tolérance ; il n’existe pas une tolérance unique pour toutes ces règles. 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 = BT-112 − BT-113 + BT-114
       (TTC)   (acomptes) (arrondi)

BR-CO-16 ajoute l’arrondi : 100,00 − 20,00 + 0,03 = 80,03 EUR.

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 mapping et la version du module EDI installé, puis revalider un export représentatif

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 identifie le moyen de paiement par un code UNTDID 4461. Sa présence dépend du profil et du groupe de paiement applicable. Le mapping Odoo dépend du générateur et du contexte de paiement ; il ne correspond pas à un menu universel de sélection de code UNTDID.

Les codes les plus courants :

Où configurer dans Odoo :

1. Identifier le mode de règlement et, si nécessaire, le mandat et le compte bancaire de la facture.
2. Examiner le mapping de l’exporteur installé ; ne pas déduire le code XML du seul libellé affiché.
3. Exporter puis vérifier TypeCode et les informations bancaires associées dans le XML.

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), le compte de paiement vendeur BT-84 (IBAN ou identifiant propriétaire pour les comptes hors zone IBAN) 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 un CIUS allemand de la norme EN16931. Selon KoSIT, la spécification 3.0.2 reste applicable au 22 septembre 2026 ; XRechnung 4.0 est une préversion. Choisir le profil convenu pour l’échange, pas uniquement le pays du destinataire.

BR-DE-1 — Instructions de paiement

BR-DE-1 impose le groupe BG-16. Contrôler le moyen de paiement exporté et les informations requises pour ce moyen.

BR-DE-2 — Contact vendeur

BR-DE-2 impose le groupe BG-6 ; BR-DE-5, BR-DE-6 et BR-DE-7 exigent respectivement le point de contact, son téléphone et son email. Ce n’est ni une alternative « email ou téléphone », ni une obligation d’email acheteur attribuable à BR-DE-2. Renseigner les données réelles du contact vendeur, puis vérifier leur export.

BR-DE-15 — Référence acheteur

BR-DE-15 impose BT-10. Utiliser la Leitweg-ID réelle lorsque le destinataire administratif la demande ; toutes les références BT-10, notamment en B2B, ne sont pas des Leitweg-ID. Vérifier le champ et le mapping du connecteur installé avant export.

Ces règles et la note relative à BT-10 figurent dans la spécification XRechnung 3.0.2.

Règles de socle et profils d’échange

Une règle BR-DE dans un flux français mérite une vérification du profil sélectionné ; elle n’est pas automatiquement un faux positif. Distinguer profil déclaré, cible demandée, pack exécuté et exigences du destinataire. Les règles France CTC ne sont pas les règles du socle européen et leur exécution ne prouve pas une acceptation PA.

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

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://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer votre-cle-api" \
  -F "file=@./facture-odoo.pdf"

Pour un diagnostic BR-CO-26, rechercher l’absence de l’ensemble des identifiants BT-29, BT-30 et BT-31, pas seulement celle du SIRET. Le rapport unifié de /validate expose issues, stages et les informations de cible : lire les identifiants de règles, leur sévérité et les contrôles effectivement exécutés. Un contrôle non exécuté ne vaut pas validation.

Cet endpoint documente les entrées Factur-X PDF et XML CII standalone. Pour un export UBL Peppol, utiliser un validateur prenant explicitement en charge UBL et le profil BIS3 convenu ; ne pas déduire cette prise en charge de celle de CII.

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. Le validateur adapté au format et au profil contrôle 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 les contrôles requis sont exécutés et satisfaits : poursuivre le circuit de transmission prévu, puis traiter le retour réel du destinataire ou de la PA

Cette boucle permet de détecter les erreurs couvertes avant transmission. Elle ne garantit pas l’acceptation par le destinataire ou la PA.

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

Pour Factur-X PDF ou CII standalone, utiliser l’API FacturX et lire les contrôles XSD/Schematron effectivement exécutés. Les contrôles PDF/A-3 concernent le conteneur PDF, pas le XML standalone. Pour UBL, utiliser le validateur UBL et le profil convenu.

É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 revalider avec le validateur adapté. Vérifier aussi les avertissements et contrôles non exécutés ; l’absence d’erreur seule ne prouve pas que toute la cible a été contrôlée.

É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)
☐ Modules et version installés identifiés
☐ Odoo 18 : account_edi_ubl_cii pour les exports CII/UBL concernés
☐ Format du client et profil d’échange vérifiés dans le XML

Partenaires (Contacts)
☐ Nom — non vide
☐ Adresse complète — rue, ville, code postal, pays
☐ Identifiant Peppol + code EAS — si réseau Peppol
☐ Identité légale, TVA et adresse de routage — vérifiées séparément

Factures
☐ Mode de paiement — avec code UNTDID 4461 valide
☐ BT-10 ou BT-13 — R003 Peppol ; vérifier les exigences nationales supplémentaires
☐ Si montant à payer positif : échéance ou conditions de paiement
☐ Profil Factur-X — conforme au cadre d’échange demandé

Erreurs fréquentes et fiches de diagnostic

• schemeID SIREN/SIRET — distinguer SIREN/0002, SIRET/0009 et champ exporté
• Profil GuidelineID — MINIMUM livré au lieu d’EN16931
• PDF/A-3 conformance — conteneur PDF/A-3 mal formé
• BR-CO-15 — Total TTC — écarts d’arrondi sur devises
• BR-S-05 — TVA Standard taux obligatoire — taux manquant en catégorie S

Les 22 fiches unitaires : catalogue complet des erreurs BR-*.

Et maintenant ?

curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer VOTRE_CLE" \
  -F "file=@./facture.pdf"

Clé Sandbox : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois. Le scanner public reste gratuit et séparé du quota API. Obtenir une clé API.

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 PA, 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. L’export doit être contrôlé avec son schéma, son profil et ses données réelles. La validation avant transmission réduit les erreurs couvertes ; l’acceptation du destinataire et de la PA reste une étape distincte.