Odoo 19 documentation warns that pain.001.001.03, still present in some credit-transfer processes, is deprecated in November 2026. It advises moving to pain.001.001.09 or the version explicitly required by the bank and country localisation. For Belgian and French finance teams, this is not merely a setting change: they need evidence that the Odoo-to-bank chain accepts, executes and reconciles the new file.
pain.001 is an ISO 20022 payment-initiation message. Odoo generates the XML from a batch payment; the bank then applies its own contract, controls and import channel. A well-formed XML file can therefore still be rejected by a business rule or incompatible data.
What changes—and what should not be conflated
The European Payments Council’s 2025 guidelines are based on the 2019 ISO 20022 message version and allow pain.001.001.09 for customer-to-bank initiation. Odoo says it uses this version by default for SEPA-compliant XML files. This does not mean every bank, EBICS contract or corporate portal switches at the same time.
The November 2026 milestone also intersects with a data change: the European Payments Council sets 15 November 2026 as the end of fully unstructured addresses in the relevant schemes, while Swift says that after 14 November only structured or hybrid postal addresses will be accepted in its scope. These changes both improve ISO 20022 data, but their scopes are not interchangeable. Teams must confirm the exact requirements with their bank.
What an Odoo customer should verify now
- Inventory bank journals, companies, banks, currencies and payment methods that export XML.
- Record the PAIN version configured for outgoing payments in each Odoo bank journal.
- Ask each bank for its version, national profile, address rules and old-format end date.
- Check legal names, IBANs, BICs where required, countries, streets, postcodes and cities for companies and beneficiaries.
- Test a single payment, a batch, several due dates, structured remittance information and accented characters separately.
- Retain acknowledgements, rejections and end-to-end identifiers so reconciliation can also be tested.
Belgium and France: one standard, distinct bank contracts
A multi-company Odoo database may generate payments for Belgian and French entities, but one setting should not be copied without validation. The installed localisation, journal, bank and transmission channel may require different variants. The migration should be managed per company-and-bank-account pair, not once for the entire database.
This change is separate from Belgian and French e-invoicing schedules. Peppol, an approved platform, a structured invoice and a credit-transfer file are not the same flow. They do share master data, however: an incorrect legal identity or incomplete address can degrade several finance processes at once.
Standard configuration or custom development?
Where the bank accepts a format offered by the Odoo journal, standard configuration and an acceptance test may be enough. Custom development becomes relevant when the banking contract requires an unavailable variant, proprietary tags or an automated transmission channel. Before developing, obtain an implementation guide and validation file from the bank: adapting XML from a single rejection creates fragile technical debt.
An Odoo Accounting implementation should preserve segregation of duties between batch preparation, review, bank signature and reconciliation. A format migration must not bypass current approvals or weaken Odoo access rights.
Cutover and fallback
Create non-urgent test payments, export them in the new format and validate them through the environment or channel recommended by the bank. Check final status, fees, references and reconciliation in Odoo. Then define a cutover date per account with named finance and technical owners.
Fallback must be explicit and limited to a version the bank still accepts. After its withdrawal date, reverting to pain.001.001.03 is no longer a strategy. Continuity may instead require a controlled manual payment or an authorised alternative banking channel, followed by documented regularisation and reconciliation.
Underside analysis: test the bank outcome, not just the export
Our success criterion is a complete cycle: validated data, generated file, accepted file, executed payment, usable feedback and reconciled entry. A test that stops when the XML downloads covers neither bank rules nor the accounting consequences of rejection.
We recommend including this work in a short Odoo audit of banking flows. It exposes old formats, custom export code and incomplete partner details before supplier or payroll payments become urgent.
Official sources
- Odoo 19 — SEPA payments and PAIN versions.
- European Payments Council — SCT rulebook and address deadline.
- EPC — 2025 SCT customer-to-bank implementation guidelines.
- Swift — ISO 20022 call to action for November 2026.
Underside helps companies audit, migrate and integrate Odoo financial flows. An end-to-end bank test turns a format change into a controlled cutover.