I have built and maintain a large number of Odoo integrations: CRM, point-of-sale systems, banks, payment providers, delivery, HR, fiscalisation, e-invoicing and customer verification.
What follows is not a list of logos, but the actual work.
What an Odoo integration is, and why a connector is not an Excel export
An Odoo connector is a module that talks to an external service over its API: it pulls data, turns it into Odoo documents (orders, invoices, payments, stock moves) and pushes statuses back. Unlike a manual import, a connector runs either on a schedule (cron) or instantly on an event (webhook), logs every request, and can retry whatever failed the first time.
The real difference is where the logic lives. A manual export gives you a table. A connector immediately produces a confirmed order, a posted invoice, a reconciled payment and a booked cost of goods.
That is why most of the work in Odoo integration development is not HTTP requests — it is accounting. The technical part can be done in a week; the question is always which accounts, journals and analytics the data lands in.
Odoo integration with CRM: KeyCRM and others
KeyCRM is a widely used CRM in Ukrainian e-commerce, and the usual scenario looks like this: orders are taken in the CRM, while stock, money and cost of goods have to live in Odoo.
I built a connector that runs in two modes at once: a webhook for instant events and a scheduled sync as insurance in case a webhook never arrives. The key part is not downloading the order but mapping statuses: the CRM status decides what happens in Odoo — a draft quotation, a confirmed order with invoice and payment, posted stock moves, or a full cancellation of the chain. Plus separate mapping tables for warehouses, payment types, expense accounts and package types.
The same approach works for any CRM — Pipedrive, HubSpot, Salesforce, Zoho or an in-house system: the only question is how well the API is documented.
Odoo integration with POS and cash register systems: Dotykačka
For a chain of retail outlets I substantially extended an existing integration with the Dotykačka Cloud API v2. Each location is described by its own record with its own token, warehouse, analytic account and dedicated cash and bank journals. One of the “clouds” is flagged as master: only it may update the shared product catalogue, so locations do not overwrite one another.
Products and receipts arrive through webhooks, payment types map onto Odoo payment methods, and revenue lands on the analytics of the specific location. This is exactly the part people underestimate: exchanging the data is simple, splitting cash, card and delivery correctly across journals is not.
Odoo integration with banks: automated bank statements
A large block of work on its own — importing and automatically reconciling bank statements: online bank feeds — Plaid among the services I have worked with — statement import from files, back-filling history from before the sync was switched on, and setting up reconciliation models so the accountant does not match every payment by hand. I have experience with bank statements and accounting specifics across several jurisdictions — Ukraine, Poland, the USA, Canada, Switzerland, Bulgaria and Estonia.
Odoo integration with payment providers: Payoneer, Authorize.Net, Przelewy24, Fiserv, Splitit
For mass payouts to contractors I built a module on the Payoneer Mass Payouts API: a two-step flow (reserve the payout with a fee calculation, then confirm), the ability to approve selected lines rather than the whole batch, a cron polling statuses, and handling of the MFA challenge.
I have also built an Authorize.Net transaction module, a connector for Przelewy24 and for Fiserv acquiring.
Splitit — instalments as an Odoo payment provider
Splitit lets a customer split a payment into instalments using the credit card they already have: the amount is held against the card limit and drawn down gradually, with no separate loan application. For a shop it is a way to raise the average order value without adding paperwork for the buyer.
I built a dedicated Splitit payment provider module for Odoo: it adds Splitit to the payment methods on the website and in the customer portal, handles the authorisation and subsequent captures, and returns the transaction status to the order and the invoice. The module is available for free on Odoo Appssection.
One subtlety shared by every instalment scheme: the order stops being paid in a single moment. So before go-live you have to agree when revenue is recognised and how those orders appear in receivables — otherwise reconciliation with the provider falls apart in the second month.
Reconciling marketplace and delivery aggregator payouts
Money from delivery aggregators and acquirers is a story of its own. A restaurant or shop sells 10,000 and receives 8,700 in the bank: the difference is commission, and it has to become an expense rather than a “lost” receivable.
I built a payout reconciliation wizard: it takes the payout file, splits it into customer amounts and commission, finds the matching invoices and reconciles them — one line per counterparty, so the accountant sees every payment rather than a single collapsed figure.
Mass payments in the USA: NACHA / ACH
The standard Odoo module generates a NACHA file, but not always in the shape a particular bank accepts. My extension adds addenda (05) records to the file — the field that carries the payment reference, without which the recipient has no idea what the money is for. The module US Payment NACHA – Addenda Extension is available for free on Odoo Appssection.
KSeF: electronic invoicing in Poland
KSeF (Krajowy System e-Faktur) is mandatory for Polish companies. I extended the existing Odoo–KSeF integration module (Odoo 19, on top of the standard Polish localisation), adding what it was missing:
- visualisation of the invoice data — so the document can be read by a human rather than only as XML;
- correction invoices — precisely where Polish rules do not match Odoo’s mechanics: a correction can be negative or positive, it requires a dedicated correction table, a correct reference to the document being corrected, and a choice of correction type;
- correct submission of those documents to KSeF.
Extending existing connectors: OpenCart, QuickBooks, Fiscadoo
Not every project starts from scratch. Often a connector already exists — bought on Odoo Apps or left behind by a previous developer — and it covers maybe sixty per cent of what is needed. Extending it is usually cheaper than writing your own, but only after looking at how it is built inside: sometimes the rework costs more than a rewrite.
Odoo integration with OpenCart
A typical scenario for a shop that does not want to move off its existing storefront: the shop window stays on OpenCart while products, orders, stock and money live in Odoo. I substantially extended an existing connector — base versions usually manage to move a product and an order, but not the part the integration exists for: accurate stock, prices, correct statuses and the accounting side of the order.
Odoo integration with QuickBooks
For companies whose bookkeeping has historically lived in QuickBooks while operations move into Odoo. Here too I significantly extended an existing connector. The difficulty is never the data exchange itself but the mapping: accounts, taxes, partners, and which document counts as the source of truth in each system.
Fiscadoo: fiscal printers and terminals
Fiscadoo connects Odoo to fiscal printers and payment terminals. Here I fixed an existing connector: by default every receipt was printed as “Gotówka” regardless of how the customer actually paid, so fiscal reporting drifted away from the bank. After the fix, the payment method chosen in the payment wizard reaches the fiscal receipt.
Odoo integration with HR systems and payroll: PeopleForce
From the PeopleForce HR system I pull employees and their payment details straight into the Odoo employee record, so payroll batches are built without copying bank details by hand.
Around this sits a full payroll circuit in Odoo: rate and percentage grids, quarterly bonuses, deductions and manual adjustments, per-employee reports, sending documents for signature through Odoo Sign, building batch payments, and a payment request portal (an employee submits a request, it goes through approval with comments and becomes a vendor bill). That last one — Payment Request — is also published on Odoo Apps.
Odoo integration with Google Sheets and Excel
Not every process should be moved into the Odoo interface straight away. Often a department already works in Google Sheets, and building a connector is faster than retraining people.
My module works through a Google service account and loads orders, leads, transactions and payroll input from spreadsheets, while import errors go into a dedicated problem log — with the row and the reason, rather than a silent skip.
Odoo integration with TMS and logistics: Roserocket
Roserocket is a transport management system used by American carriers. The connector authenticates over OAuth2, caches the token and refreshes it automatically, after which TMS data is available inside Odoo. Together with the rest of the modules this closes the chain “freight order → driver → payout”.
Odoo integration with Sumsub: customer verification (KYC/AML)
If your business is required to verify counterparties — financial services, payments, marketplaces, working with contractors abroad — the verification itself lives in a separate service while the decisions are made in Odoo. I built a Sumsub connector: the counterparty’s data goes off for checking, and the status and result come back into the partner record. The manager sees inside Odoo who can be worked with and who cannot.
Exchange rates and multi-currency
For Polish companies Odoo pulls NBP rates through the standard localisation — no development needed. There is a nuance here that people often “fix” by mistake: NBP publishes the previous working day’s rate, so Odoo stores it under the following date — which is exactly what Article 31a of the Polish VAT act requires. That shift is not a bug, and it should be left alone.
What it costs to build and maintain an Odoo integration
The honest answer: an integration is not a one-off job. External APIs change response formats, tokens expire, services introduce new rate limits. So every connector I build gets three things: logging of outgoing requests, operations that can be repeated without duplicating documents, and automated tests on response parsing. It is the boring part that pays for itself at six o’clock on a Friday evening when someone has to work out why a payout did not go through.
I work hourly (Time & Materials) — you pay for hours actually worked, not for a package half of which you do not need. A mid-complexity integration is typically a few dozen hours of development plus modest monthly maintenance.
Ready-made Odoo modules on Odoo Apps
Part of my work is published openly and can be installed for free: my modules on Odoo Apps. Among them Payment Request, US Payment NACHA – Addenda Extension and Splitit Acquirer.
Need an Odoo integration?
If a connector already exists but you cannot trust the data, start with a technical audit: the most common cause of discrepancies is the architecture of the integration itself.
If your service is not on this list, that is not a problem: most integrations follow the same pattern, and the only questions are how well the API is documented and how complex the accounting side is. I have also worked with Nova Poshta for delivery and Checkbox for Ukrainian fiscalisation. I work remotely, in English or Ukrainian.
The cheapest way to size the work is a short consultation: we look at your process and decide what genuinely needs synchronising and what is better left alone. The full list of what I do in Odoo is in Odoo Services; pricing and formats of cooperation are in the Shop section.
Frequently asked questions about Odoo integrations
How long does it take to build an Odoo connector?
A simple one-way sync starts at a week. A full two-way connector with the accounting side (order, invoice, payment, stock) is usually 3–6 weeks.
Can Odoo be integrated with a system that has no API?
Often yes — through file exports, Google Sheets, email or the database. I assess that during the consultation.
Does the integration work on Odoo Community?
Yes, most integrations do not depend on the edition. I know Community, but most of my work has been on Enterprise, so it is worth checking up front whether the logic you need relies on Enterprise features.
What happens when an external service changes its API?
That is why every connector ships with logging, automated tests and repeatable operations — the change is visible immediately, not a quarter later in a balance discrepancy.
Can you take over an integration written by another developer?
Yes. I audit the existing code and come back with a verdict: what to keep, what to rewrite and what the risks are.
Odoo Integration with CRM, Banks and Payment Systems