For years, Odoo’s payment documentation treated SEPA and ISO 20022 as though they were interchangeable terms. They aren’t. SEPA is a payment scheme — a set of rules governing euro-denominated transfers within the European Economic Area. ISO 20022 is the messaging standard that SEPA happens to use, but it extends far beyond Europe and far beyond euros. Conflating the two created real confusion for finance teams trying to configure cross-border payments or understand why certain options were available in some contexts but not others. Odoo has now drawn a hard line between them, and the resulting clarity changes how batch payments work in practice.
The overhaul separates SEPA credit transfers and direct debits — which operate under the European Payments Council’s rulebook — from the broader ISO 20022 PAIN (Payment Initiation) format that banks worldwide accept for payment file generation. This isn’t just a documentation cleanup. The separation surfaces in the software itself: SEPA-specific workflows now have their own configuration paths, while ISO 20022 PAIN payments get capabilities that SEPA deliberately excludes. The most significant of these new capabilities is charge bearer control.
Charge Bearer Options Change the Economics of International Payments
Starting with version 18.2, Odoo introduces four charge bearer options for ISO 20022 payment files: BEN (beneficiary bears all charges), OUR (sender bears all charges), SHA (charges are shared between sender and beneficiary), and SLEV (charges follow the service level agreement between the banks). These four codes — defined in the ISO 20022 specification itself — determine who pays the banking fees on a cross-border transfer, and their absence from Odoo until now was a genuine gap for companies processing non-SEPA international payments.
The reason SEPA never needed these options is instructive. Within the SEPA zone, the charge bearer is always SHA by default — it’s baked into the scheme rules. But once you step outside the euro zone or use ISO 20022 for non-SEPA transfers, the question of who pays the intermediary bank fees becomes a negotiation between trading partners. A supplier in Switzerland might insist on OUR terms so they receive the full invoiced amount. A treasury team managing dozens of international vendors needs the flexibility to set different charge bearer codes per payment or per vendor. Odoo now supports this at the batch payment level, embedding the charge bearer instruction directly in the generated PAIN XML file.
Swiss Localization and the Quiet Removal of Reconciliation References
Alongside the SEPA/ISO 20022 separation, Odoo has expanded its Swiss localization for payment processing. Switzerland occupies an unusual position in European payments — it’s not in the EU, doesn’t use the euro as its primary currency, but its banking system is deeply integrated with ISO 20022 standards through SIX Group’s payment infrastructure. The new documentation and configuration paths reflect Swiss-specific payment formats, QR-IBAN handling, and the particular PAIN message versions that Swiss banks expect. For companies operating across the EU-Switzerland border, this eliminates a layer of manual configuration that previously required consulting external guides.
Two other changes deserve attention, even though they’re easier to overlook. First, batch payment files now explicitly link back to their source journals in the accounting module. This sounds minor, but it closes a traceability gap that auditors regularly flagged — the ability to trace a generated payment file back to the journal that produced it, without relying on timestamps or file naming conventions. Second, Odoo has renamed the “Print” action for SEPA mandates to “Send & Print,” reflecting what the action actually does in modern workflows where mandates are transmitted electronically rather than printed on paper.
What Version 19 Removes — and Why It Matters
Perhaps the most consequential change is what Odoo has taken away. Version 19 removes reconciliation references for batch payments entirely. These references previously allowed payment files to carry reconciliation data that receiving banks could use to auto-match incoming payments against open invoices. In theory, this was elegant. In practice, bank support for reconciliation references in batch payment files was inconsistent enough that the feature created more confusion than it resolved. Some banks ignored the references. Others interpreted them differently. Finance teams spent time configuring references that ultimately had no effect on the receiving end.
By removing the feature, Odoo is making an opinionated choice: batch payment reconciliation should happen inside the ERP, not through metadata embedded in payment files. Combined with the AI-driven reconciliation engine introduced elsewhere in Odoo 19, this suggests a deliberate shift in philosophy — the system that generates the payment shouldn’t also try to instruct the receiving bank on how to process it. Whether that bet pays off depends on how quickly banks adopt their own AI-matching capabilities, but for now, it simplifies the payment generation pipeline and removes a source of false confidence in end-to-end reconciliation.