Have you ever watched a company grow so quickly that its technology could no longer keep up?
Sales increase. A new country becomes important. Someone creates another legal entity because the business needs it. Then comes a warehouse, another logistics provider, Amazon, Shopify and an accounting system somewhere else. Spreadsheets fill the gaps.
Individually, every decision makes sense. A few years later, answering one question becomes surprisingly difficult:
Where exactly is our stock, who owns it and what is its real cost?
That is approximately where this project started. We eventually connected five legal entities, up to 12 warehouses and seven third-party logistics providers through Odoo. Getting there involved much more uncertainty, testing and rework than that sentence suggests.
A normal website inquiry, followed by some less ordinary answers
The client contacted us through our website. They had a business they wanted to automate with Odoo. At first, it sounded like a familiar request.
Then we started asking questions. How many companies? Five. How many warehouses? That depended on how we counted them. Where did they sell? Amazon and Shopify. Who fulfilled the orders? Several different 3PL providers. Where was accounting? Xero.
The answers were reasonable. Taken together, they described a much more demanding project.
The company sells physical products internationally. We cannot disclose the product category or the client’s identity because of our confidentiality agreement. I can say that the product itself is interesting, and working with the team gave us a close view of how ambitious entrepreneurs build an international business.
Commercially, they had already crossed borders. Their internal systems had grown in pieces: Airtable, DEXT, Excel, spreadsheets and Claude with MCP, with limited integration between them. Different tools helped different people get their work done. They did not add up to one consistent operational model.
Our job was to understand that model and make it work as a system. The project case study records the delivered scope. This is the story of what it took to get there.
Before we could configure Odoo, we had to understand the company
Some of the hardest work happened before serious development started.
Procurement knew how goods were purchased. The ecommerce team understood Amazon and Shopify. Warehouse operations knew what happened to the products. Finance saw the legal entities, costs and transactions. Each perspective was useful. None of them, on its own, described the whole business.
We kept returning to a basic question: what actually happens between deciding to buy a product and the final customer receiving it?
That question led to a lot of conversations. Sometimes one answer produced five more questions. Sometimes two employees described the same process differently. Sometimes an operation that sounded simple involved three companies and two warehouses.
We underestimated how much work it would take to join those perspectives together. Configuring a process before understanding it would only have made the misunderstanding more systematic.
This is the less visible part of Odoo implementation. It also explains why, in our article on choosing an Odoo ERP consultant, we put so much emphasis on business understanding and communication. Knowing where a setting lives is useful. Knowing what that setting needs to represent takes another kind of work.
The stock was in one place. Its owner was another question.
Five legal entities are not five copies of the same company. They buy, sell and transfer inventory between themselves. One company may own the goods, another may be responsible for a market, and a warehouse may store stock for several group companies at once.
A product can sit on the same shelf while its legal ownership changes. Later it may be sold to a final customer through Shopify. Physical location, ownership and the sales channel all matter, but they describe different things.
Once we added the logistics network, the problem became a matrix: company × warehouse × product × ownership × sales channel × replenishment.
And it did not sit still. Goods arrived, moved, were repacked, transferred and sold. New purchases had to replenish stock in different parts of the world. During busy periods, all of those processes moved quickly.
We configured the companies and warehouse structure in one Odoo Enterprise database. We also worked on intercompany transactions so employees would not have to reproduce every operation manually across several companies.
The cost consequences made this especially important. An incorrect intercompany purchase can distort stock valuation. That affects cost of goods sold, which then affects the profitability figures management sees. What looked like an ERP configuration detail could change the answer to “Are we making money on this?”
“Seven APIs. We will just connect them.”
Warehouse integrations consumed a very large amount of time.
The client worked with seven different 3PL operators. Each had its own processes, warehouse arrangements and technology. We developed seven connectors, but the number alone says little about the work.
Some documentation was good. Some existed but did not quite describe how the API behaved. In other cases, useful public information was scarce. We had to contact people directly and ask technical questions that an online guide could not answer.
At the beginning, “just connect the warehouse API” still sounded like a manageable phrase. It became less reassuring as the project continued.
We underestimated parts of this work. An API connection that looked straightforward could reveal another dependency or an unexpected response once we tested the real process. Some integrations took considerably longer than we had expected.
There is nothing especially photogenic about waiting for an answer to an API question or investigating why a documented response differs from a real one. But those were important parts of delivering the system.
What had to happen after a customer clicked “Buy”
Consider a Shopify order. Odoo receives it and determines which warehouse should fulfill it. Our integration layer selects the appropriate 3PL connector and sends the fulfillment information: the order, customer, delivery address, products, quantities and the other details that provider needs.
The warehouse responds. We check that the order is still in the expected state, process the delivery in Odoo and return fulfillment information to ecommerce.
Orders, statuses and delivery reference numbers now move through these integrations in real time. That lets the ecommerce side receive the information coming back from fulfillment, rather than leaving the warehouse’s update isolated in its own system.
Written down, the process looks tidy. Now repeat it across several legal entities, different warehouses and APIs, with thousands of orders moving through the business.
At that scale, a small synchronization problem can multiply quickly. We needed more than proof that a test order could reach a warehouse. We needed the response to belong to the correct process and the correct order state.
That distinction accounted for a considerable amount of the testing and rework.
The routing layer gave the connectors a common job
We did not want seven completely isolated integrations, each making its own decisions about the business.
Instead, we created a common routing layer. Odoo knows which warehouse must fulfill an order. The router determines which connector handles the request. The connector deals with the particular provider’s API.
That division made the system easier to maintain. It gave us a consistent way to direct requests without putting every provider’s differences into the central operational process.
The difficult part was getting those very different providers to participate in that process consistently. A shared router does not make inconsistent APIs disappear. It gives their differences a defined place to live.
This is the kind of work behind our Odoo integration projects: deciding how systems cooperate, then making the individual connections support that decision.
Amazon and Shopify brought their own round of rework
Amazon FBA, Amazon FBM and Shopify were part of the same operating environment. Multiple companies, accounts, warehouses and fulfillment routes made their configuration more involved than connecting a single shop.
Every mapping mattered. The wrong company could mean the wrong accounting transaction. The wrong warehouse could mean the wrong delivery. The wrong product could turn an apparently successful synchronization into an inventory problem.
For Shopify, we used the VentorTech connector. It still needed configuration around this client’s companies and warehouses. Having a connector did not remove the need to understand those relationships.
We configured the integrations, tested them, changed them and tested again. We prepared for production, found another edge case and repeated part of the configuration.
This happened more than once. It was not always pleasant. Sometimes we were wrong about an assumption; sometimes a limitation only became clear during production-scale testing. In either case, we had to change the work.
Eventually, the operational picture started making sense
There was a point when the system began to look like the business we had been trying to understand.
Odoo knew which companies and warehouses existed, where the stock was and who owned it. Orders had a source and a fulfillment route. Purchasing, replenishment, warehouse transfers, production and packaging belonged to the same operational picture. Intercompany trade and product costs were represented in that model.
That was a major milestone. It was also more useful than a list of installed modules.
We trained employees on purchasing, replenishment, warehouse operations, stock transfers and intercompany processes. The people doing the work needed to operate the new structure independently, not wait for us to interpret it for them.
For readers new to the platform, our Odoo ERP overview explains its applications and implementation choices. This project made the practical point very clear to us: the applications become useful when they reflect a business people can actually recognize.
Then we reached accounting. And the project became difficult again.
Accounting was another project inside the project
Knowing where the products are is only part of the story. The CFO also needs numbers that make sense across the group.
We worked with finance on the chart of accounts, revenue, cost of goods sold, analytical dimensions, sales channels, intercompany transactions and profitability. We aligned the configuration with the client’s accounting policies and set up analytical accounting and consolidated management reporting.
The difficult connection was between physical movement and financial meaning. “Goods moved between two warehouses” is not a complete explanation. Who owned them before and after? At what cost? Was there an intercompany sale? Which entity generated the revenue, and which channel should carry the cost?
These questions needed agreement with finance. We could not solve them by choosing whichever configuration was quickest to implement.
This was demanding work. It was also where the operational model had to prove that it could support management decisions, not only warehouse transactions.
The Xero connector we expected to save us time
The client already used Xero for statutory accounting. Odoo was becoming the central operational system while important accounting information still lived elsewhere. Historically, that information reached Odoo irregularly.
We bought an existing Xero connector from Odoo Apps, expecting it to save development time.
Instead, it became another development task.
It may have been sufficient for a simpler environment. Our requirements included vendor bills, bank transactions, accounting entries and synchronization into the right legal entities across five companies. The ready-made connector did not cover enough of those scenarios.
So we modified it. Then we modified it more. What we had expected to configure became a substantial piece of development.
That was frustrating. We had made an assumption about how much work a purchased integration would remove, and reality did not support it. A connector’s screenshots cannot tell you whether it is ready for your particular architecture.
We are not naming that supplier here. The useful lesson is about the fit between a connector and the actual requirements, not about turning one implementation experience into a verdict on a vendor.
The resulting integration brings accounting transactions, vendor bills, bank transactions and other relevant accounting data into the corresponding Odoo companies. It improved consistency between operational information and the accounting records in Xero. Getting there took much more effort than the initial purchase suggested.
We did not get every decision right the first time
Looking back, I do not want to make this sound like a sequence of well-planned steps that happened neatly in order.
We underestimated tasks. Some integrations took longer than expected. We changed decisions, repeated configuration and rebuilt parts of the system. At certain points, the project was exhausting.
It would be easy to leave those parts out and describe the finished architecture. But that would hide much of what the project taught us.
Understanding the business was work. Discovering where an existing connector stopped being useful was work. Making several providers behave consistently was work. So was admitting that an earlier decision needed to change.
The valuable experience came from gradually making a complicated operating model understandable enough to run through one coherent system.
Where we are now, and what is still ahead
Today, the company has a centralized Odoo environment connecting its international operations. It has better visibility of stock quantities and movements across five legal entities and up to 12 warehouses, connected ecommerce and 3PL processes, product costing and management reporting.
The direction is to make Odoo the primary source of operational information. External systems should either receive information from it or return the specialized information they manage. We want fewer isolated tools and a clearer relationship between the systems that remain.
Xero still handles statutory accounting. Moving the remaining financial processes directly into Odoo is a potential next phase, and it would be a separate project. We have not completed that migration.
If it goes ahead, operations and accounting could share the same primary system, with analytics and external services connected to it. There is more work ahead before we can describe that as the current reality.
Would I do it again?
This project gave us difficult weeks, integrations that did not behave as expected and tasks that took much longer than planned. We had to rethink decisions and rebuild parts of the system.
I am still glad we had the opportunity to work on it.
It is unusual to see such a complex international business from the inside, and to help turn its accumulated processes into a consistent operational system. We learned a great deal from the work and from the people who understood different parts of the company.
We are grateful to the client for trusting us through that process.
And yes, despite everything, I would happily take on a project like this again.