Odoo banking and accounting integrations
Banking, in production
Cemseal runs ICICI banking integration on its Odoo install: token issue, redemption, and reconciliation against bank status, with the voucher layer hardened after the first version proved too trusting.
The first version of any voucher system trusts the callback. That is the assumption that costs money. A redemption can succeed at the bank and never report back, and if the voucher’s state depends on hearing about it, you now have value sitting in two places. Each voucher holds its own state, redemption is idempotent, and the daily reconciliation pass raises the gap rather than a support ticket doing it three days later.
- Bank
- ICICI, India
- Scope
- Token issue, redemption, voucher state hardening, scheduled reconciliation
- Runs on
- Odoo Community, alongside e-invoicing and e-way bill filing on the same install
- Credentials
- Yours, held with the bank. We configure against them and never hold them.
- Availability
- Built to order. Not a published module.
Two-way accounting sync
A Norwegian accounting platform and Odoo, each authoritative on different fields, writing to each other in both directions. Customers, invoices, payments and ledger entries move continuously. There is no monthly export ritual and no spreadsheet holding the difference.
The API took a week. The project was the other question: when the two systems disagree about a value, which one wins, and how would anyone know it happened? Field ownership is settled in writing before any code is written, and the sync refuses to overwrite a field it does not own. A reconciliation pass compares both ledgers daily and raises the delta. It has not had to be run by hand.
- Platform
- PowerOffice Go, Norway
- Direction
- Two-way. Customers, invoices, payments, ledger entries.
- Delivered for
- A Norwegian partner. End client under NDA.
- Control
- Daily reconciliation pass with delta reporting
- Availability
- Built to order
Where the invoice has to leave the building
Peppol runs in production on the same Norwegian engagement. Invoices leave Odoo in the network format and reach the buyer’s access point without a manual upload step, and a validation failure surfaces against the invoice that caused it rather than in an email from a service provider two days later.
Statutory e-invoicing is the part of this category with a deadline attached, and the regimes do not resemble each other. India files IRNs through a Suvidha Provider. Zambia posts to a virtual sales data controller. Peppol transmits over a four-corner network. Each gets its own page here rather than a shared paragraph, because the useful answer is country-specific.
What holds across all three
Every integration in this category is judged the same way, which is not on whether it connects. It is on whether the number in Odoo and the number at the counterparty still agree at month end, and on whether anyone finds out promptly when they don’t.
So the shape is consistent. Field ownership settled before code. Idempotent writes, because every write is assumed to arrive twice. A reconciliation job on a schedule that raises the delta rather than absorbing it. Failed messages land in a queue you can inspect instead of a log line that scrolled past.
What we don’t do
Resell bank or platform access, hold your credentials, or build against a screen-scrape where the counterparty offers no API and no file interface. We also won’t take on a statutory integration without sandbox access from the authority, because a compliance system that has only ever been exercised with real documents is one nobody has actually tested.
We have delivered 20+ integrations across 12+ active geographies. Banking, accounting and e-invoicing stay bespoke; payments are the part of the category we have published.
Which two systems have stopped agreeing?
Bring the counterparty, the field that keeps drifting, and what the mismatch costs when it happens. We can usually tell you in one reply whether that is an integration problem or a process one.