Le 1er septembre, toutes les entreprises assujetties à la TVA en France devront pouvoir recevoir une facture électronique par une plateforme agréée. Odoo est immatriculé.
Voilà pour le cadre officiel. Le code, lui, raconte une histoire un peu différente.
Entre le 13 et le 21 août, le dépôt public odoo/odoo a enregistré sept commits sur le module l10n_fr_pdp côté master, et six sur la branche 19.0. Six sur 19.0, c'est-à-dire sur la branche qui tourne en production chez vous. À onze jours de l'échéance, Odoo corrige encore des tracebacks et des mentions légales absentes du XML.
Ce constat n'a rien de scandaleux, tous les éditeurs sont dans la même course. Mais si vous comptez sur Odoo pour être conforme au 1er septembre, ces commits vous concernent directement.
Le module s'installe sans vous demander votre avis
Le manifeste contient une ligne qui mérite d'être lue : 'auto_install': ['l10n_fr_account']. Autrement dit, dès que la localisation comptable française est présente sur la base, l10n_fr_pdp s'installe seul. Vous ne l'activez pas, vous le constatez après coup.
Un correctif du 13 août illustre bien ce que ça implique. Son titre : « let non-accountants open invoices ». Avant lui, sur une base française, un utilisateur sans droits comptables ne pouvait plus ouvrir une facture. Le module arrive seul, la régression arrive avec lui, et la personne qui la subit n'a jamais entendu parler de facturation électronique.
C'est le genre de sujet qui remonte au support sous la forme « je ne peux plus rien voir depuis hier ».
Trois mentions obligatoires manquaient dans le XML
Le 15 août, un correctif ajoute trois notes au XML généré. Elles portent les codes PMT, PMD et AAB, et correspondent respectivement à l'indemnité forfaitaire de 40 euros pour frais de recouvrement, au taux des pénalités de retard, et à la mention d'escompte.
La règle Factur-X BR-FR-05 les impose. Sans elles, le validateur de la FNFE rejette la facture. Le bug ne touchait pas tout le monde : la fonction n'ajoutait ces notes que si l'entreprise était raccordée au proxy PDP d'Odoo. Une société française qui envoyait ses factures autrement produisait donc un XML incomplet sans le savoir.
Un point mérite votre attention au-delà du correctif lui-même. Le taux inscrit dans la note PMD est écrit en dur dans le code : 10 % par an. Il ne provient ni de vos conditions de règlement, ni de votre échéancier. Seule la note d'escompte va chercher le texte de votre condition de paiement quand un escompte est configuré.
Ce taux de 10 % reste au-dessus du plancher légal. L'arrêté du 26 juin 2026 fixe le taux d'intérêt légal entre professionnels à 2,75 % pour le second semestre, ce qui porte le minimum des pénalités à 8,25 %. De ce côté, rien à signaler.
Le sujet est ailleurs. Si vos CGV annoncent le taux de refinancement de la BCE majoré de dix points, comme le prévoit l'article L.441-10 du code de commerce à défaut de stipulation contraire, votre facture électronique affichera 10 % et vos conditions générales afficheront autre chose. Deux documents contractuels, deux chiffres différents.
À faire relire par votre expert-comptable avant le 1er septembre. Le sujet est plus juridique que technique.
Le bouton « remettre en brouillon » revient
Jusqu'au 18 août, remettre en brouillon une facture déjà transmise levait une erreur explicite qui vous renvoyait vers l'avoir. Le commit du 18 supprime ce garde-fou. Odoo autorise désormais la remise en brouillon, et crée automatiquement un flux rectificatif pour la période concernée.
Ce choix colle à la logique française du flux rectificatif. Le module gère un modèle dédié qui distingue les transmissions initiales des transmissions rectificatives, avec des périodes, un type transaction ou paiement, et un sens vente ou acquisition. Un cron quotidien génère et envoie ces flux.
Ce qui rend le commit intéressant, c'est qu'Odoo a fait exactement l'inverse quatre jours plus tôt sur Peppol. Le 14 août, un correctif interdit la remise en brouillon des factures envoyées via Peppol, au motif que les utilisateurs s'y perdaient. Deux canaux de transmission suivent donc deux règles opposées dans la même semaine.
Une précision pour éviter le malentendu. Ce qui se rectifie, ce sont les données transmises à l'administration. La facture déjà déposée sur la plateforme de votre client reste déposée. Remettre en brouillon dans Odoo ne la rappelle pas.
Un SIREN ne suffit pas à router une facture
Le 20 août, Odoo ajoute une recherche dans l'annuaire central. Vous saisissez le SIREN de votre client, Odoo interroge l'annuaire via son proxy, et vous renvoie la liste des identifiants rattachés. Chaque ligne porte trois informations : l'identifiant, la plateforme qui le dessert, et sa nature.
C'est ce pluriel qui compte. Un SIREN peut porter plusieurs entrées dans l'annuaire, une par établissement, et rien n'impose à deux établissements du même groupe d'utiliser la même plateforme. Envoyer « au client » ne veut donc pas dire grand-chose. Il faut choisir le bon routage, et c'est une donnée que personne n'a dans sa base aujourd'hui.
Cette fonction n'existe que sur master à ce jour. Sur 19.0, vous saisissez l'identifiant de routage à la main. Si vous préparez votre base de tiers en vue de septembre, l'outil de vérification n'est pas encore chez vous.
Les succursales cassaient la configuration
Celui-là nous parle particulièrement, vu le nombre de bases multi-sociétés que nous administrons. Le 19 août, un correctif livré directement sur 19.0 règle une erreur de syntaxe PostgreSQL au moment d'activer la facturation électronique sur une succursale.
Le mécanisme est limpide. La fonction cherchait les comptes clients et fournisseurs rattachés à la société. Une succursale n'a pas de comptes en propre, ils appartiennent à la société mère. La recherche renvoyait une liste vide, la requête générait un IN (), et PostgreSQL refusait. Le correctif remplace la condition in par parent_of.
Si vous avez tenté d'activer la facturation électronique sur une succursale avant le 19 août et que la sauvegarde des paramètres a planté, vous avez votre explication.
L'interopérabilité se règle encore dans les commentaires de code
Un dernier point, moins visible mais parlant. Le module contient ce commentaire à propos de l'identifiant de personnalisation des factures reçues : SuperPDP envoie seulement urn:cen.eu:en16931:2017 mais attend quand même la validation française complète.
SUPER PDP est une plateforme agréée parisienne, immatriculée depuis le 22 décembre 2025 selon le fichier de la DGFiP. Deux plateformes officiellement agréées ne s'accordent donc pas encore sur la lecture d'un champ, et le contournement vit dans un commentaire de code. Nous sommes le 21 août.
Ce n'est pas un reproche adressé à Odoo. C'est l'état réel de l'écosystème français à dix jours de l'obligation de réception.
Côté code Odoo cette semaine
En dehors du chantier français, deux commits méritent le détour pour une direction financière.
La TVA sur les encaissements arrête de polluer le journal
Le 19 août, un commit sur master change le traitement des écritures de TVA sur encaissements. Jusqu'ici, une écriture générée depuis le rapprochement bancaire ne pouvait qu'être contrepassée, jamais supprimée. Un dé-lettrage suivi d'un re-lettrage laissait donc deux écritures de plus dans le journal, et l'audit devenait vite pénible.
Odoo autorise maintenant la suppression, sauf si l'écriture est protégée par un verrou de période ou par le verrou fiscal. Comme cette suppression peut créer des trous dans la séquence du journal, un contrôle a été ajouté à la déclaration de TVA pour alerter sur les numéros manquants. Le changement vit sur master, donc pour Odoo 20.
Les RIB fournisseurs sortent du mode sudo
Le 20 août, un autre commit interdit les modifications du modèle des comptes bancaires de tiers via des commandes en sudo. Une modification de coordonnées bancaires passera désormais par les droits de l'utilisateur réel, sans contournement possible par le code appelant.
Vu la fréquence des fraudes au changement de RIB dans les PME françaises, ce durcissement discret vaut mieux qu'une note de service. Là aussi, c'est sur master pour l'instant.
Votre base Odoo doit être prête à recevoir des factures électroniques dans onze jours. Si vous voulez qu'on regarde ensemble où elle en est, écrivez-nous.
Sources
- Je consulte la liste des plateformes agréées, impots.gouv.fr, page modifiée le 19 août 2026. Lire l'article
- Commit 4d798465, l10n_fr_pdp: let non-accountants open invoices, branche 19.0, 13 août 2026. Lire l'article
- Commit 8d0b0239, l10n_fr_pdp: ensure notes are present for all FR e-invoicing, 15 août 2026. Lire l'article
- Taux de l'intérêt légal du second semestre 2026, service-public.gouv.fr. Lire l'article
- Délais de paiement entre professionnels et pénalités de retard, Entreprendre Service-Public. Lire l'article
- Commit 8425511b, l10n_fr_pdp: allow reset to draft, 18 août 2026. Lire l'article
- Commit 1bd12658, account_peppol: don't allow reset to draft for peppol invoices, 14 août 2026. Lire l'article
- Commit 5585f86f, l10n_fr_pdp: annuaire lookup, 20 août 2026. Lire l'article
- Commit 95977ec9, l10n_fr_pdp: SQL syntax error when activating PDP on a branch company, branche 19.0, 19 août 2026. Lire l'article
- Commit 026d198a, account: Don't always reverse CABA moves upon un-reconciliation, 19 août 2026. Lire l'article
- Commit 2df69365, base: disable sudo commands for bank records, 20 août 2026. Lire l'article