Integration debt is any connection between systems that runs on a person instead of a pipe, and it grows faster than your ERP license cost. Map your data flows, name one system of record per data type, and connect orders and stock first.
Integration debt doesn’t show up as one dramatic failure. It shows up as a slow tax on every order, paid in staff hours and customer trust.
Three months after go-live, the ERP is technically running. And someone on the ops team is still opening a spreadsheet every morning to check which Shopify orders came in overnight, because the ERP doesn’t see them yet. Inventory in the marketplace dashboard doesn’t match what’s in the warehouse, so a percentage of orders get cancelled after the customer already paid. The accountant closes the month by manually matching payout deposits against orders, because nobody connected the two.
Nobody calls this a failed project. It’s not broken, exactly. It’s just that the ERP purchase solved the part everyone budgeted for, and left the part that touches customers directly running on manual effort. That gap has a name, and it doesn’t go away on its own: integration debt. Multiply it across a few sales channels and a growing order volume, and what looked like minor operational friction in month one can start eating a growing share of a staff week by month six.
Integration debt is any connection between systems that runs on a person instead of a pipe: someone re-typing an order, someone eyeballing a stock count, someone reconciling two spreadsheets before a deadline. It’s invisible in a demo, because a demo runs on one order at a time.
It’s easy to miss at the contract stage, partly because of how Odoo itself is built. The Sales, Inventory, and Accounting apps are separate modules built to work together, and this overview of Odoo’s retail and ecommerce modules walks through what each one does. That native integration is genuinely one of Odoo’s strengths, and it quietly sets an expectation that connecting to the outside world will work the same way. It doesn’t. A storefront, a marketplace, a 3PL, and a payment processor all sit outside that app graph, and nothing about Odoo’s internal automation carries over to them automatically.
The part that catches businesses off guard is that this cost doesn’t stay flat. Software licensing is often priced by seat or plan rather than by order, so it barely moves between 50 orders a day and 500. Manual reconciliation is not like that. It scales at least in step with volume, and it tends to grow faster as channels are added, because more channels means more places for two numbers to quietly stop agreeing with each other.
Integration debt collects in the same five places regardless of industry: orders, stock across channels, fulfilment and 3PL handoffs, accounting, and catalog data. Each one fails differently, so it helps to look at them separately.
Orders. Without a live sync, someone has to manually re-create every Shopify or marketplace order as an actual Sales Order in Odoo, because until that happens Odoo has no record of it, no reserved stock, and no invoice.
Stock across channels. Odoo tracks quantity on hand by warehouse and location, and Shopify tracks inventory by location too. If a Shopify sale doesn’t decrement the Odoo number the moment it happens, Odoo’s own inventory reports become wrong, not just the storefront, and the business sells things it doesn’t have. That’s a cancelled order, a refund, and on marketplaces that score sellers on cancellations, a ding to seller performance metrics that can affect future visibility. The same failure shows up from the warehouse side in multichannel inventory management problems and solutions.
Fulfilment and 3PL. A warehouse or third-party logistics provider that doesn’t automatically know what to pack ends up working from a manually updated pick list, which is where wrong items, wrong addresses, and missed shipping deadlines come from.
Accounting: payouts, commissions, refunds. Odoo’s Accounting app can match a bank statement line against an invoice, but only if that invoice already exists and matches. Marketplace and payment processor payouts rarely map cleanly to individual orders on their own, so someone in finance ends up creating and matching entries by hand every month, and refunds are the line item most likely to get lost in that process.
Catalog data. Price, stock status, and product descriptions drift apart across channels when they’re maintained separately. Customers see one price at checkout and another on the product page, and support ends up fielding complaints that have nothing to do with the product itself.
None of these shows up as a single dramatic failure. They show up as a slow tax on every order, paid in staff hours and customer trust, and the tax rate goes up every time a new sales channel gets added without a matching connection to go with it.
Manual reconciliation cost grows with order volume and channel count rather than with software licenses, so a process that fits inside a slow Monday morning at low volume can fill every day of the week at higher volume.
Here is an illustrative example, not a benchmark. Assume a business that sells on Shopify and one marketplace, ships 120 orders a day, and spends two minutes of manual handling per order on re-keying and stock checks, plus 30 minutes a day matching payouts to orders. That is 240 minutes of handling plus 30 minutes of matching, or 4.5 staff hours a day. Double the volume to 240 orders a day and the per-order handling alone reaches 8 hours a day, which is a full-time role that was never written into anyone’s job description. The example assumes payout matching stays flat when volume doubles, which is generous, because more orders and channels usually mean more payouts to match. The exact numbers will differ for every business, but the shape holds: the work scales with orders while the license bill does not.
The company that contributed this article, an Odoo integration specialist, says the pattern is consistent across its Odoo rollouts for ecommerce and distribution businesses, even when the exact numbers vary by client. In its experience, manual order and stock reconciliation takes a real chunk of a team’s week before automation and drops sharply once orders and inventory are synced. There is usually a fairly predictable order volume where the manual process stops holding up, and by the time a business has connected its main sales channels, integrations often represent a meaningful share of the total ERP project budget even though they’re rarely priced in from the start. Treat these as the contributor’s observations rather than independently measured figures.
Below that volume threshold, a spreadsheet and a diligent staff member can usually absorb the gaps. Above it, the same process generates more errors than a person can catch, and the business finds out about problems from customers instead of from its own reporting. The threshold moves with order value and channel mix: a business selling high-ticket furniture has a different breaking point than one selling accessories at high volume. The pattern tends to show up the same way each time. Reconciliation that used to fit inside a slow Monday morning starts spilling into every day of the week, an oversold item goes from a rare apology email to a recurring one, and somewhere along the way keeping the systems in sync quietly becomes someone’s real job, even though it was never written into anyone’s.
Fix integration debt in this order: map the data flows, assign one system of record per data type, sequence by customer impact, decide connector versus custom build per connection, and monitor for silent failures from day one.
The mistake most businesses make is buying connectors the same way they bought the ERP itself: one purchasing decision at a time, under deadline pressure, without a map of how the pieces are meant to fit together. Tools get selected based on what’s available or what a vendor is pushing that quarter, rather than what the business actually needs connected first. A better approach starts before any tool gets selected:
This is usually the point where it’s worth bringing in a team that specialises in Odoo integrations to sequence the work, rather than treating each connector as its own isolated purchase. The contributor of this article is one such team; other Odoo implementation partners and an in-house developer who owns the integration roadmap are others. What matters is that one person or team owns the sequence.
Done in this order, each step also makes the next one cheaper. A clean data flow map turns connector selection from a guess into a checklist. A clearly assigned system of record turns a sync error from a mystery that eats an afternoon into a fix that takes five minutes, because everyone already agrees which system is right when two numbers disagree. For the monitoring step in particular, the integration readiness checklist for Shopify brands treats sync alerts with the same discipline as site uptime.
Use an off-the-shelf connector for the standard flow, such as a new order coming in and being created in Odoo, and plan for custom work only where your process falls outside it.
Odoo’s own app store has ready-made connectors for popular storefront platforms, and they’re usually fine for the standard case. Where they tend to fall short is everything around that standard case: partial shipments, split payments, multi-warehouse routing, and marketplace-specific fee structures. A genuinely non-standard business process usually doesn’t fit an off-the-shelf connector, and forcing it tends to cost more than building it properly.
Business model mismatch is one of the four patterns that make an ERP integration that runs but still fails the business: a connector built around a single warehouse and simple pricing syncs one aggregated stock number while the business actually runs three locations.
A practical test is to list each connection and write down the three most common exceptions in that flow. If the connector handles them, buy it. If your team would have to work around any of them every week, price the custom build before you sign, because a workaround that repeats weekly is a recurring cost that never shows up on an invoice.
The gaps that matter depend on your order volume and channel count: a single-channel business can often absorb them with a spreadsheet, while a multichannel business should connect orders and stock first.
If you ship a few dozen orders a day on one channel, a careful person with a spreadsheet can still absorb most of this. The useful move at that stage is to write down the manual steps now, so you know exactly what to automate first when a second channel arrives.
Once you sell on a storefront and at least one marketplace, orders and stock are the first two connections worth paying for, because overselling shows up as cancellations and refunds the customer can see. At higher volume, or with 3PLs and multiple warehouses in the picture, add fulfilment routing and payout reconciliation, and give every connection a named owner. Sync alerts belong on every connection from day one, at any volume.
If you aren’t running Odoo, the sequencing logic still applies; only the connector choices change.
Ask five questions before you sign: which integrations are in scope, who owns each connection after go-live, what happens when a sync fails silently, whether each data type has one system of record, and what order volume the setup is built to handle.
Most of this gets decided, or left undecided, before the ERP contract is even signed. First, which integrations are actually included in this scope, and which are assumed to happen later? Second, who owns each connection after go-live: the implementation partner, an in-house team, or nobody in particular? Third, what happens when a sync fails silently, and is there monitoring, or does the business find out from a customer complaint? Fourth, for each data type, is there one clear system of record, or will two systems both claim to be correct? Fifth, what order volume is this setup actually built to handle before it needs to be revisited?
None of these questions requires a technical background. They just require asking them before the contract is signed instead of after the second oversold order. A contractor who can answer them clearly has usually done this before. One who can’t is asking the business to find out the hard way, after launch.
Integration debt is any connection between systems that runs on a person instead of an automated sync. In an ERP project it usually means someone re-types storefront or marketplace orders into the ERP, checks stock counts by eye, or matches payouts to orders by hand. It is easy to miss at the contract stage because modules inside one platform, such as Odoo’s Sales, Inventory, and Accounting apps, are built to work together, while outside systems like storefronts, marketplaces, 3PLs, and payment processors are not connected automatically. The cost grows with order volume and channel count rather than with software licenses, which is why it often goes unbudgeted at the start.
Your ERP still needs manual work after go-live because go-live usually covers the ERP’s internal apps, not the connections to your sales channels, warehouse partners, and payment processors. Those connections were often scoped as a later phase or assumed to work like the internal ones. Until each one is automated, a person fills the gap by re-creating orders, correcting stock counts, or matching payouts to invoices. The fix is to list every manual step between your channels and the ERP, name the data type each one carries, and connect the ones that touch customers first, which are usually orders and stock.
Connect orders and stock first, because that is where overselling, cancellations, and refunds come from. Sequence the rest by how visible the failure is to a customer: fulfilment and 3PL handoffs next, then catalog data, then accounting reconciliation. Accounting is painful and rarely the thing a customer notices, so it can usually wait until the first two connections are stable, unless a filing or close deadline forces it forward. Before connecting anything, name one system of record per data type, such as the ERP’s warehouse data for inventory counts, so that every other system reads from it and none of them overwrites it.
An app store connector is usually enough for the standard flow, such as a new storefront order being created in the ERP, but it often falls short on exceptions. Partial shipments, split payments, multi-warehouse routing, and marketplace-specific fee structures are the usual gaps. Decide per connection rather than as a blanket policy: list the three most common exceptions in each flow, check whether the connector handles them, and price a custom build if your team would work around any of them every week. A workaround that repeats weekly is a recurring cost that never appears on an invoice.
Set up alerts that notify a named person whenever an order, stock update, or payout fails to sync, and make sure failed syncs retry automatically. Without them, the business learns about problems from customer complaints, which is the most expensive way to find out. Assign an owner to every connection, review the failed sync log on a schedule, and test the alerting during a high-volume period before you rely on it. Alert coverage belongs in the integration scope from the start, not after the first missed order.
