La documentation Odoo 19 avertit que pain.001.001.03, encore présent dans certains processus de virements, est déprécié en novembre 2026. Elle recommande de passer à pain.001.001.09 ou à la version explicitement demandée par la banque et la localisation du pays. Pour les directions financières belges et françaises, l’enjeu n’est donc pas seulement de changer une option : il faut prouver que la chaîne Odoo–portail bancaire accepte, exécute et rapproche le nouveau fichier.
Le format pain.001 est un message ISO 20022 d’initiation de virement. Odoo génère le fichier XML depuis un paiement groupé ; la banque applique ensuite son propre contrat, ses contrôles et son canal d’import. Un XML bien formé peut donc être refusé pour une règle métier ou une donnée incompatible.
Ce qui change, et ce qu’il ne faut pas confondre
Les guides 2025 du Conseil européen des paiements reposent sur la version ISO 20022 de 2019 et autorisent pain.001.001.09 pour l’initiation client-banque. Odoo indique que cette version est utilisée par défaut pour ses fichiers conformes SEPA. Cela ne signifie pas que chaque banque, chaque contrat EBICS ou chaque portail d’entreprise bascule au même moment.
Le jalon de novembre 2026 se combine avec une évolution de données : le Conseil européen des paiements fixe au 15 novembre 2026 la fin des adresses entièrement non structurées dans les schémas concernés, tandis que Swift annonce qu’après le 14 novembre seules les adresses structurées ou hybrides seront acceptées dans son périmètre. Ces changements sont liés à la qualité ISO 20022, mais leurs périmètres ne sont pas interchangeables. L’équipe doit confirmer les exigences exactes auprès de sa banque.
Ce qu’un client Odoo doit vérifier maintenant
- Inventorier les journaux bancaires, sociétés, banques, devises et modes de paiement qui exportent un XML.
- Relever dans chaque journal Odoo la version PAIN configurée pour les paiements sortants.
- Demander à chaque banque la version, le profil national, les règles d’adresse et la date de fin d’acceptation de l’ancien format.
- Contrôler noms légaux, IBAN, BIC lorsqu’il est requis, pays, rues, codes postaux et villes des sociétés et bénéficiaires.
- Tester séparément un paiement simple, un lot, plusieurs échéances, une communication structurée et les caractères accentués.
- Conserver les accusés, rejets et identifiants de bout en bout afin de tester le rapprochement.
Belgique et France : une norme commune, des contrats bancaires distincts
Une base Odoo multi-sociétés peut générer des paiements pour une entité belge et une entité française, mais le même réglage ne doit pas être copié sans validation. La localisation installée, le journal, la banque et le canal de transmission peuvent imposer des variantes différentes. La migration doit être pilotée par couple société–compte bancaire, pas par base Odoo entière.
Cette évolution est indépendante des calendriers de facturation électronique belge et française. Peppol, plateforme agréée, facture structurée et fichier de virement ne désignent pas le même flux. Ils partagent cependant des référentiels : une mauvaise identité juridique ou une adresse incomplète peut dégrader plusieurs processus financiers à la fois.
Configuration standard ou développement spécifique ?
Lorsque la banque accepte un format proposé par le journal Odoo, la configuration standard et un test d’acceptation peuvent suffire. Un module spécifique devient pertinent si le contrat bancaire exige une variante non disponible, des balises propriétaires ou un canal d’envoi automatisé. Avant de développer, il faut demander un guide d’implémentation et un fichier de validation à la banque : adapter l’XML sur la base d’un seul rejet crée une dette fragile.
Une implémentation de la comptabilité Odoo doit aussi prévoir la séparation des rôles : préparation du lot, contrôle, signature bancaire et rapprochement. La migration de format ne doit pas contourner les validations existantes ni affaiblir les droits d’accès Odoo.
Plan de bascule et retour arrière
Créez un jeu de paiements sans urgence opérationnelle, exportez-le dans le nouveau format et faites-le valider dans l’environnement ou le canal recommandé par la banque. Vérifiez le statut final, les frais, les références et le rapprochement dans Odoo. Fixez ensuite une date de bascule par compte, avec un responsable finance et un responsable technique.
Le retour arrière doit rester explicite et limité à une version encore acceptée par la banque. Après sa date de retrait, revenir à pain.001.001.03 n’est plus une stratégie. Le plan de continuité devient alors un paiement manuel contrôlé ou un canal bancaire alternatif autorisé, avec régularisation et rapprochement documentés.
Analyse Underside : tester le résultat bancaire, pas seulement l’export
Notre critère de réussite est un cycle complet : données validées, fichier généré, fichier accepté, paiement exécuté, retour exploitable et écriture rapprochée. Un test qui s’arrête au téléchargement du XML ne couvre ni les règles de la banque ni les conséquences comptables d’un rejet.
Nous recommandons d’intégrer ce chantier à un audit Odoo court des flux bancaires. Il permet de repérer les anciens formats, les personnalisations d’export et les coordonnées partenaires incomplètes avant que les paiements fournisseurs ou salaires deviennent urgents.
Sources officielles
- Odoo 19 — paiements SEPA et versions PAIN.
- Conseil européen des paiements — règle SCT et échéance des adresses.
- EPC — guide d’implémentation SCT client-banque 2025.
- Swift — appel à l’action ISO 20022 pour novembre 2026.
Underside accompagne les entreprises dans l’audit, la migration et l’intégration des flux financiers Odoo. Un test bancaire de bout en bout transforme un changement de format en bascule maîtrisée.