« Odoo fait-il du Factur-X ? » La réponse honnête tient en deux temps : une facture électronique se fabrique, puis se transmet, et ce sont deux chaînes de modules différentes. Celle-ci fabrique.
Cinq modules la composent : un socle européen, une couche française, et trois modules de colle qui ne font rien d'autre que relier correctement les briques entre elles.
Résumé
account_invoice_en16931 produit le fichier : Factur-X, UBL, CII, ou PDF plus UBL joint, depuis un assistant accessible sur une facture ou sur une sélection de factures. Il ajoute surtout des contrôles bloquants à la validation — une seule taxe de TVA par ligne, taxe active, montant hors taxes non négatif, règles EN 16931 sur les taux — parce qu'un fichier normé ne tolère pas ce qu'une facture PDF laissait passer.
l10n_fr_account_invoice_en16931 y ajoute la France : SIREN du vendeur et de l'acheteur, SIRET pour les échanges avec le secteur public, et surtout l'insertion automatique des mentions légales obligatoires dans le bloc de notes de la facture — pénalités de retard, indemnité forfaitaire de 40 €, absence d'escompte. Trois modules de colle complètent la chaîne sans aucune interface : l10n_fr_account_invoice_facturx (le SIRET dans le XML), account_invoice_en16931_py3o (pour les modèles de facture LibreOffice) et l10n_fr_account_tax_unece (les codes de taxe internationaux pré-remplis sur le plan comptable français).
L'essentiel
- Quatre formats de sortie : Factur-X (PDF/A-3 + CII), XML UBL, XML CII, ou PDF avec UBL en pièce jointe.
- Des contrôles bloquants à la validation : une seule TVA par ligne, taxe active, montant HT non négatif, règles EN 16931 sur les taux.
- Les mentions légales françaises insérées automatiquement dans le fichier : pénalités de retard, indemnité de 40 €, absence d'escompte, mention B2G.
- Trois modules de colle à installation automatique : ils n'ajoutent ni champ ni menu, et leur absence se voit uniquement dans le fichier produit.
l10n_fr_account_tax_unecepré-remplit les codes UNECE sur les taxes du plan comptable français — sans eux, pas de fichier valide.- Ce socle ne transmet rien : ni dépôt, ni accusé, ni cycle de vie. C'est une autre chaîne de modules.
Ce que ces modules ajoutent à l'instance
| Module | Rôle | Dépôt | Version |
|---|---|---|---|
account_invoice_en16931 | Le socle : génère le fichier, pose les contrôles | fr-einvoicing | 18.0.1.0.0 |
l10n_fr_account_invoice_en16931 | La couche France : SIREN, SIRET, mentions légales | fr-einvoicing | 18.0.1.0.0 |
l10n_fr_account_invoice_facturx | Colle : le SIRET de l'acheteur dans le XML CII | l10n-france | 18.0.x |
account_invoice_en16931_py3o | Colle : fonctionne avec les factures mises en page sous LibreOffice | fr-einvoicing | 18.0.1.0.0 |
l10n_fr_account_tax_unece | Données : les codes UNECE sur les taxes du PCG français | l10n-france | 18.0.1.0.0 |
Trois de ces cinq modules s'installent automatiquement dès que leurs deux dépendances sont présentes. C'est une mécanique propre à l'OCA qu'il faut connaître : on n'installe pas un module de colle, on installe ce qu'il relie, et il apparaît.
Aucun des cinq n'ajoute de menu. Tout se passe sur la facture, dans ses réglages, et dans le fichier produit — c'est-à-dire là où personne ne regarde avant le premier rejet.
Les quatre formats, et lequel choisir
| Format | Ce que c'est | Qui le demande |
|---|---|---|
| Factur-X | Un PDF/A-3 lisible par un humain, avec le XML CII caché dedans | Le format pivot français — le plus sûr par défaut |
| XML UBL | Un fichier purement structuré | Les plateformes et donneurs d'ordre qui l'imposent |
| XML CII | L'autre syntaxe structurée de la norme | Chorus Pro, notamment |
| PDF + UBL joint | Les deux fichiers séparés | Les échanges où le PDF doit rester autonome |
Le choix n'est pas esthétique : il dépend de ce que le destinataire sait lire. Factur-X est le bon défaut en France parce qu'il reste un PDF — le client qui n'a pas encore de plateforme l'ouvre normalement, et celui qui en a une lit le XML.
Le détail des trois syntaxes est traité côté éditorial dans Factur-X, UBL, CII : quelles différences.
Un réglage comptable choisit le format du PDF produit par défaut, un autre pointe l'URL d'un serveur de transformation XSLT, un troisième porte le motif d'exemption de TVA pour les sociétés non assujetties. Ce dernier est celui qu'on oublie : sans motif renseigné, une facture sans TVA produit un fichier refusé par les contrôles de la norme.
Les contrôles bloquants, et pourquoi ils sont une bonne nouvelle
Le module refuse de valider une facture client qui ne pourrait pas produire un fichier conforme. Quatre contrôles, tous à la validation :
- Une seule taxe de TVA par ligne. La ligne qui cumulait deux taxes passait en PDF ; elle n'a pas de représentation dans la norme.
- La taxe doit être active. Une taxe archivée qui traîne sur une facture en brouillon bloque désormais.
- Le montant hors taxes ne peut pas être négatif sur une ligne de facture.
- Les règles EN 16931 sur les taux de TVA sont vérifiées — c'est ce qui attrape les combinaisons impossibles entre catégorie de taxe et taux.
Ces blocages arrivent avant l'envoi, dans Odoo, sur une facture en brouillon. C'est très exactement le moment où une correction coûte une minute. Le même défaut découvert après transmission coûte un rejet, une relance client et un décalage d'encaissement.
La conséquence pratique, qu'il faut annoncer avant la mise en service : les premières semaines, des factures qui passaient refusent de se valider. Ce ne sont pas des régressions, ce sont des factures qui n'étaient pas conformes.
C'est le même principe que les contrôles de saisie comptable : un refus au bon moment vaut mieux qu'une correction d'écriture trois mois plus tard.
Ce que la couche française ajoute
Les identifiants
- Le SIREN du vendeur et de l'acheteur pour les sociétés françaises, inséré dans le XML.
- Le SIRET quand l'échange concerne le secteur public, lorsque le module d'annuaire est présent.
- Pour un client hors Union européenne, un identifiant de repli calculé à partir du nom du partenaire et du code pays, transcrit en caractères latins — le cas qui bloque sinon la génération.
Les mentions légales, insérées dans le fichier
C'est l'apport le plus sous-estimé du module. Les mentions obligatoires françaises sont ajoutées automatiquement au bloc de notes de la facture électronique :
- les pénalités de retard et le taux d'intérêt légal applicable,
- l'indemnité forfaitaire de 40 € pour frais de recouvrement,
- l'absence d'escompte pour paiement anticipé,
- la mention B2G quand le client est une entité publique,
- la mention « archive uniquement » pour les factures marquées comme internes.
Ces mentions ne sont pas décoratives : leur absence est sanctionnable, et elles doivent figurer dans le fichier structuré, pas seulement dans la mise en page du PDF. Le détail des obligations est traité dans les mentions obligatoires d'une facture électronique.
Un champ facture interne apparaît par ailleurs sur la fiche, modifiable seulement en brouillon et accompagné d'un bandeau d'explication : il marque les pièces qui ne doivent pas partir dans le flux réglementaire.
Les trois modules invisibles
| Module | Ce qu'il fait | Ce qu'on voit |
|---|---|---|
l10n_fr_account_invoice_facturx | Ajoute le SIRET de l'acheteur comme identifiant de partie dans le XML CII | Rien — sauf dans le fichier |
account_invoice_en16931_py3o | Permet la génération quand la facture est mise en page avec un modèle LibreOffice | Rien — le PDF sort simplement avec son XML |
l10n_fr_account_tax_unece | Pré-remplit type et catégorie UNECE sur les taxes du plan comptable français | Deux champs remplis sur chaque taxe |
Le troisième mérite une attention particulière. Les codes UNECE sont la nomenclature internationale qui dit, dans le fichier, de quelle nature est une taxe. Sans eux, le fichier est incomplet et sera refusé. Le module les écrit automatiquement sur les taxes issues du plan comptable général français — TVA collectée et déductible, intracommunautaire, export et import, immobilisation et carburant, taux zéro.
Le piège : une taxe créée à la main après l'installation n'est pas traitée. C'est le cas de toute entreprise qui a ajouté une taxe spécifique à son activité — il faut aller renseigner ses deux champs UNECE manuellement.
Le deuxième module ne concerne que les instances dont la facture est mise en page avec un modèle LibreOffice plutôt qu'avec le moteur standard d'Odoo. C'est courant chez les entreprises qui ont une maquette de facture soignée, et c'est exactement le cas où l'on découvrirait sinon, la veille de la bascule, que le XML ne s'embarque pas.
Limites connues
- Ce socle ne transmet rien. Il fabrique un fichier. Le dépôt sur une plateforme, les accusés, le cycle de vie sont le travail d'une autre chaîne de modules.
- Les contrôles bloquent des factures qui passaient avant : à annoncer aux équipes, pas à découvrir en production.
- Les taxes créées à la main n'ont pas de codes UNECE : à compléter manuellement, sinon le fichier est refusé.
- Le motif d'exemption de TVA doit être renseigné pour une société non assujettie, sinon la génération échoue.
- Un serveur de transformation XSLT peut être nécessaire selon les formats utilisés : c'est un composant d'infrastructure, pas un réglage.
- Les modules de colle s'installent seuls : leur absence ne se voit que dans le fichier produit, jamais dans une liste de modules qu'on aurait oublié de cocher.
Identité technique
| Module | Dépôt OCA | Version | Licence | Dépend de |
|---|---|---|---|---|
account_invoice_en16931 | fr-einvoicing | 18.0.1.0.0 | AGPL-3 | account_tax_unece, account_payment_unece, base_vat, intrastat_base, uom_unece |
l10n_fr_account_invoice_en16931 | fr-einvoicing | 18.0.1.0.0 | AGPL-3 | account_invoice_en16931, l10n_fr_siret_account |
account_invoice_en16931_py3o | fr-einvoicing | 18.0.1.0.0 | AGPL-3 | account_invoice_en16931, report_py3o |
l10n_fr_account_invoice_facturx | l10n-france | 18.0 | AGPL-3 | account_invoice_facturx, l10n_fr_siret |
l10n_fr_account_tax_unece | l10n-france | 18.0.1.0.0 | AGPL-3 | account_tax_unece, l10n_fr_account |
Ils complètent le module de transport l10n_fr_einvoicing, qui porte l'annuaire, les flux et le cycle de vie.
Questions fréquentes
Ces modules transmettent-ils les factures à une plateforme ?
Non. Ils fabriquent le fichier — Factur-X, UBL, CII, ou PDF avec UBL joint — et posent les contrôles de conformité. Le dépôt sur une plateforme, les accusés de réception et le suivi du cycle de vie relèvent d'une autre chaîne, autour de l10n_fr_einvoicing pour la réforme française ou de l10n_fr_chorus_account pour le secteur public.
Quel format choisir par défaut ?
Factur-X en France : c'est un PDF/A-3 avec le XML CII embarqué, donc lisible par un client qui n'a pas encore de plateforme et exploitable par celui qui en a une. L'UBL et le CII seuls se choisissent quand le destinataire — plateforme, donneur d'ordre, Chorus Pro — les impose.
Pourquoi des factures refusent-elles de se valider après installation ?
Parce que le module ajoute quatre contrôles bloquants : une seule taxe de TVA par ligne, taxe active, montant hors taxes non négatif, et respect des règles EN 16931 sur les taux. Ces factures n'étaient pas conformes avant non plus — elles passaient parce qu'un PDF ne contrôle rien. Mieux vaut le refus en brouillon que le rejet après transmission.
Mes taxes personnalisées sont-elles prises en charge ?
Pas automatiquement. l10n_fr_account_tax_unece pré-remplit les codes UNECE — type et catégorie — sur les taxes issues du plan comptable général français. Une taxe créée à la main après coup garde ces champs vides, et le fichier produit sera refusé. C'est le contrôle à faire après chaque ajout de taxe.
Que faire si notre facture est mise en page sous LibreOffice ?
Installer account_invoice_en16931_py3o, le module de colle qui permet d'embarquer le XML dans un PDF produit par le moteur de rapports LibreOffice plutôt que par le moteur standard d'Odoo. Sans lui, la mise en page personnalisée sort un PDF sans XML — un défaut qu'on découvre sinon la veille de la bascule.
Se faire accompagner
Cette chaîne est celle où une erreur ne se voit pas : le PDF a l'air normal, et c'est le fichier caché dedans qui est refusé trois jours plus tard par la plateforme du client. Les deux points qui coûtent le plus en reprise sont toujours les mêmes — des taxes sans codes UNECE, et des mentions légales absentes du fichier structuré.
Nous validons donc la génération sur un échantillon réel de vos factures — un client français, un intracommunautaire, un hors UE, un avoir — avant d'activer quoi que ce soit en production. Voir notre accompagnement sur la facture électronique ou demander un rappel.
Pour aller plus loin
- l10n_fr_einvoicing : l'annuaire, les flux et le cycle de vie
- Chorus Pro : facturer le secteur public depuis Odoo
- Factur-X, UBL, CII : quelles différences
En résumé
Cinq modules pour fabriquer le fichier : un socle européen qui produit quatre formats et pose quatre contrôles bloquants, une couche française qui insère identifiants et mentions légales, et trois modules de colle qu'on n'installe pas — ils apparaissent. Ce qu'ils ne font pas : transmettre. Parlons de votre passage à la facture électronique.
