12 E-Commerce operators share how they scale operations. → Get the ERP Playbook.
12 E-Commerce operators share how they scale operations.
Multichannel Integration in E-commerce: Why Connected Sales Channels Still Don't Mean Connected Operations
Multichannel Integration in E-commerce: Why Connected Sales Channels Still Don't Mean Connected Operations
Adding another sales channel is rarely a major technical challenge anymore. Shopify, Amazon, other marketplaces, a third-party logistics provider and the finance stack can all be connected.
And yet, this is what day-to-day operations still look like in many growing e-commerce businesses: orders arrive in one place, but customer service checks their status across several systems. Inventory figures do not match. Returns need manual follow-up. At month-end, finance has to piece together revenue, fees, stock movements and refunds.
The channels are connected. The work isn't.
A working multichannel integration does more than move product data, inventory and orders between systems. It connects every sale to the operational and financial process behind it: from the order and its fulfillment to the return and the actual cost of goods sold.
The right architecture depends less on the number of channels than on the operating model behind them.
TL;DR
A multichannel integration is robust when sales from every channel move through one reliable shared process. That includes product data and pricing, inventory, orders and payments, fulfillment, returns, finance and inventory valuation.
A connector may be exactly the right solution. Other businesses need Shopify as a hub, marketplace middleware, an ERP as the operational backbone, or a combination of these. But that decision should only be made once the real process is understood.
What multichannel integration means in e-commerce
Multichannel simply means selling through more than one channel: your own online store, Amazon, other marketplaces, social commerce or a B2B sales operation.
Integration is meant to stop the relevant information from living in separate worlds. At a basic level, that means product data, prices, availability, orders and status updates. For the operation to work end to end, it also needs to cover fulfillment, returns, payments, stock movements and finance.
Omnichannel puts the emphasis somewhere else. It is primarily concerned with creating a consistent customer experience across touchpoints. This article focuses on the operational side: how do you process sales from different channels reliably, without teams having to rebuild the full story every day?
The happy path tells you very little
The order import is visible and easy to test. An order is placed on Amazon, appears shortly afterwards in the store, inventory system or ERP, and earns a green tick in the project plan.
For the business, the work is only just beginning.
In an initial call, one business owner described his live system roughly like this: as long as an order moves through in a perfectly straight line, everything works. The moment a customer wants to remove one item or change a quantity, the postings become unclear and hardly anyone on the team knows how to move the order forward cleanly.
That is where the quality of an integration shows. Not in the perfect standard order, but in the normal deviations from it.
Is the product mapped correctly? Is it really available? Who fulfills the order? Do shipping status and tracking come back? What happens with a partial shipment, an order change or a return? How are marketplace payouts, fees and refunds reconciled? What inventory value left the business with the sale?
When the systems cannot answer these questions, people become the integration layer. They export lists, reconcile statuses, chase information in Slack or email, and maintain the same data more than once.
I call these setups “human APIs.” At low volumes, they can work surprisingly well for a surprisingly long time. Two people coordinate informally, an Excel file tracks the important exceptions, and someone knows which number to trust when the systems disagree.
Add more volume, more people or more channels, and the pragmatic workaround becomes a bottleneck.
Complexity is not determined by the number of channels
A business with one Shopify store, a third-party logistics provider and a specialist accounting tool can have a very lean order-to-cash process. The order is passed to the 3PL, shipped there and then processed for accounting. If the assortment is manageable, exceptions are rare and a small team owns the flow, this architecture may be entirely sufficient.
At the other end of the spectrum is a business with several stores, five marketplaces, an additional B2B operation, its own warehouse, FBA inventory and in-house accounting. The channels are not the only thing that differs. There are several fulfillment routes, inventory types, pricing logics, payment flows and areas of responsibility.
Two channels with different operating models can therefore be more complex than five channels whose orders are always handled in the same way.
The first architecture question is not: how many sales channels do you have?
It is: what has to happen after each sale — and who owns that part of the process?
Adding another sales channel is rarely a major technical challenge anymore. Shopify, Amazon, other marketplaces, a third-party logistics provider and the finance stack can all be connected.
And yet, this is what day-to-day operations still look like in many growing e-commerce businesses: orders arrive in one place, but customer service checks their status across several systems. Inventory figures do not match. Returns need manual follow-up. At month-end, finance has to piece together revenue, fees, stock movements and refunds.
The channels are connected. The work isn't.
A working multichannel integration does more than move product data, inventory and orders between systems. It connects every sale to the operational and financial process behind it: from the order and its fulfillment to the return and the actual cost of goods sold.
The right architecture depends less on the number of channels than on the operating model behind them.
TL;DR
A multichannel integration is robust when sales from every channel move through one reliable shared process. That includes product data and pricing, inventory, orders and payments, fulfillment, returns, finance and inventory valuation.
A connector may be exactly the right solution. Other businesses need Shopify as a hub, marketplace middleware, an ERP as the operational backbone, or a combination of these. But that decision should only be made once the real process is understood.
What multichannel integration means in e-commerce
Multichannel simply means selling through more than one channel: your own online store, Amazon, other marketplaces, social commerce or a B2B sales operation.
Integration is meant to stop the relevant information from living in separate worlds. At a basic level, that means product data, prices, availability, orders and status updates. For the operation to work end to end, it also needs to cover fulfillment, returns, payments, stock movements and finance.
Omnichannel puts the emphasis somewhere else. It is primarily concerned with creating a consistent customer experience across touchpoints. This article focuses on the operational side: how do you process sales from different channels reliably, without teams having to rebuild the full story every day?
The happy path tells you very little
The order import is visible and easy to test. An order is placed on Amazon, appears shortly afterwards in the store, inventory system or ERP, and earns a green tick in the project plan.
For the business, the work is only just beginning.
In an initial call, one business owner described his live system roughly like this: as long as an order moves through in a perfectly straight line, everything works. The moment a customer wants to remove one item or change a quantity, the postings become unclear and hardly anyone on the team knows how to move the order forward cleanly.
That is where the quality of an integration shows. Not in the perfect standard order, but in the normal deviations from it.
Is the product mapped correctly? Is it really available? Who fulfills the order? Do shipping status and tracking come back? What happens with a partial shipment, an order change or a return? How are marketplace payouts, fees and refunds reconciled? What inventory value left the business with the sale?
When the systems cannot answer these questions, people become the integration layer. They export lists, reconcile statuses, chase information in Slack or email, and maintain the same data more than once.
I call these setups “human APIs.” At low volumes, they can work surprisingly well for a surprisingly long time. Two people coordinate informally, an Excel file tracks the important exceptions, and someone knows which number to trust when the systems disagree.
Add more volume, more people or more channels, and the pragmatic workaround becomes a bottleneck.
Complexity is not determined by the number of channels
A business with one Shopify store, a third-party logistics provider and a specialist accounting tool can have a very lean order-to-cash process. The order is passed to the 3PL, shipped there and then processed for accounting. If the assortment is manageable, exceptions are rare and a small team owns the flow, this architecture may be entirely sufficient.
At the other end of the spectrum is a business with several stores, five marketplaces, an additional B2B operation, its own warehouse, FBA inventory and in-house accounting. The channels are not the only thing that differs. There are several fulfillment routes, inventory types, pricing logics, payment flows and areas of responsibility.
Two channels with different operating models can therefore be more complex than five channels whose orders are always handled in the same way.
The first architecture question is not: how many sales channels do you have?
It is: what has to happen after each sale — and who owns that part of the process?
Hol dir das E-Commerce-ERP-Playbook
Hol dir das E-Commerce-ERP-Playbook
Ein strukturierter Leitfaden für die wichtigsten ERP-Entscheidung im wachsenden E-Commerce (+60 Seiten, 12 Expertinnen).
Ein strukturierter Leitfaden für die wichtigsten ERP-Entscheidung im wachsenden E-Commerce (+60 Seiten, 12 Expertinnen).
Mit Erfahrungen von Expert*innen, die täglich ERP, Ops & Zahlen verantworten.
Hol dir das E-Commerce-ERP-Playbook
Ein strukturierter Leitfaden für die wichtigsten ERP-Entscheidung im wachsenden E-Commerce (+60 Seiten, 12 Expertinnen).
Mit Erfahrungen von Expert*innen, die täglich ERP, Ops & Zahlen verantworten.
Six areas that need to work together
1. Product data, listings and pricing
A product needs a clear identity across all systems. Variants, bundles, country-specific assortments, different SKUs and channel-specific prices make that complicated quickly.
Not every piece of information has to be maintained in the same system. Product copy and images may live in the store or a PIM, while the ERP manages purchasing, inventory and valuation. What matters is that every type of information has one authoritative source and that changes are passed on in a controlled way.
2. Inventory and availability
“Inventory” is not one unambiguous number. Stock may sit in your own warehouse, with a 3PL, across several FBA locations, with a contract manufacturer or in transit. Some of it may already be reserved, damaged or deliberately allocated to a specific sales channel.
In one project, the B2C and B2B teams were competing for the same physical inventory. Because the logistics provider did not support the required reservation logic, identical products were assigned artificial, separate SKUs. When a B2B order came in, stock first had to be reversed and then reassigned.
The need behind the setup was understandable: both teams wanted planning certainty. But the solution made inventory harder to understand and depended heavily on the knowledge of individual employees.
Before recreating a setup like that in the ERP, it is worth asking whether clear allocation rules, a different reservation logic or a change at the logistics provider would solve the problem more cleanly.
3. Orders, payments and exceptions
An imported order needs to contain enough information to be processed without being entered again. Depending on the channel, that includes customer data, billing and delivery addresses, line items, taxes, discounts, payment status and shipping method.
In one e-commerce project, B2B customer data was maintained across several Google Sheets and personal inboxes. Orders then had to be recreated manually in Shopify because Shopify was the only system with a native connection to the external logistics provider. After shipment, the invoice was created separately again. Payment status lived in accounting and was not directly visible to the sales team.
None of the systems was useless on its own. But the full transaction had to be reconstructed at every step.
In the target process, the customer and order are created once. The order is passed to the logistics provider. Its shipping confirmation triggers the invoice and the downstream accounting processes. Sales and operations can see in one place what was quoted, delivered, invoiced and paid.
4. Fulfillment and status feedback
Integration is not a one-way street. With a 3PL, sending the order is not enough. Shipping confirmation, tracking, inventory changes, goods receipts and return information all need to come back.
If goods are moved from the external warehouse to Amazon to replenish FBA or Prime inventory, that also changes available stock. These transfers need to remain traceable across the ERP, the logistics provider and Amazon.
This is why the fulfillment model shapes the architecture more than the raw channel count. With an in-house warehouse, the business controls picking, packing and shipping itself. With a 3PL, information has to move reliably in and out of an external process. With FBA, Amazon handles much of the execution, but creates its own inventory, statuses, fees and return flows. In mixed models, these variants run in parallel.
5. Returns and refunds
Returns are not an edge case. They are part of the normal order-to-cash process.
A return changes at least four things: the order, the payment, the physical inventory and the financial valuation. The item may be sellable again, damaged or need to be written off. A partial return affects different line items and amounts than a full cancellation.
If the marketplace knows about the refund, the warehouse records the condition of the item in another system, and finance posts the correction manually later, the return exists in several places — but has not been processed end to end.
6. Finance, inventory value and channel profitability
The financial feedback loop is not the final export to accounting. It is part of the integration architecture.
A marketplace payout is not simply revenue. Fees, refunds, discounts and delayed payments need to be allocated correctly. To calculate a meaningful margin, you also need the value of the goods sold.
Knowing which channel generated how much revenue is not the same as knowing its profitability. You need to trace which inventory left through that channel and what that inventory was worth at the time. Purchase prices, exchange rates, freight and customs duties can all change that value.
Before the project, PURISH had only one sales channel connected at a system level. Today, eight technically separate channel setups are represented in one shared structure, including Shopify, B2B, several marketplaces and Amazon FBA in Europe and the US.
For the annual close, inventory data previously had to be assembled from several systems and spreadsheets over a period of weeks. During the implementation, determining year-end inventory still took around one week. Today, the current inventory value can be calculated within minutes.
The real improvement is not only the faster close. Because stock movements and product values come together, PURISH can see where inventory is located, through which channel it was sold and where the corresponding cost of goods sold arises.
Three truths instead of one system for everything
An end-to-end architecture does not mean every team has to work in the same tool or that every specialist application needs to be removed.
But it does need clear truths.
Where does the customer truth live? Where is the inventory truth? Where is the valuation truth? Which system decides whether an order has been paid? Where can the business see what inventory is currently inbound?
In one discovery, a person had effectively become the human interface between several teams because they kept the critical information up to date across multiple spreadsheets. The problem was not a lack of effort. There was simply no place where the relevant information was both reliable and accessible to everyone.
A spreadsheet can be a useful analysis or planning tool. It should not permanently carry the responsibility of connecting core systems and business functions.
Six areas that need to work together
1. Product data, listings and pricing
A product needs a clear identity across all systems. Variants, bundles, country-specific assortments, different SKUs and channel-specific prices make that complicated quickly.
Not every piece of information has to be maintained in the same system. Product copy and images may live in the store or a PIM, while the ERP manages purchasing, inventory and valuation. What matters is that every type of information has one authoritative source and that changes are passed on in a controlled way.
2. Inventory and availability
“Inventory” is not one unambiguous number. Stock may sit in your own warehouse, with a 3PL, across several FBA locations, with a contract manufacturer or in transit. Some of it may already be reserved, damaged or deliberately allocated to a specific sales channel.
In one project, the B2C and B2B teams were competing for the same physical inventory. Because the logistics provider did not support the required reservation logic, identical products were assigned artificial, separate SKUs. When a B2B order came in, stock first had to be reversed and then reassigned.
The need behind the setup was understandable: both teams wanted planning certainty. But the solution made inventory harder to understand and depended heavily on the knowledge of individual employees.
Before recreating a setup like that in the ERP, it is worth asking whether clear allocation rules, a different reservation logic or a change at the logistics provider would solve the problem more cleanly.
3. Orders, payments and exceptions
An imported order needs to contain enough information to be processed without being entered again. Depending on the channel, that includes customer data, billing and delivery addresses, line items, taxes, discounts, payment status and shipping method.
In one e-commerce project, B2B customer data was maintained across several Google Sheets and personal inboxes. Orders then had to be recreated manually in Shopify because Shopify was the only system with a native connection to the external logistics provider. After shipment, the invoice was created separately again. Payment status lived in accounting and was not directly visible to the sales team.
None of the systems was useless on its own. But the full transaction had to be reconstructed at every step.
In the target process, the customer and order are created once. The order is passed to the logistics provider. Its shipping confirmation triggers the invoice and the downstream accounting processes. Sales and operations can see in one place what was quoted, delivered, invoiced and paid.
4. Fulfillment and status feedback
Integration is not a one-way street. With a 3PL, sending the order is not enough. Shipping confirmation, tracking, inventory changes, goods receipts and return information all need to come back.
If goods are moved from the external warehouse to Amazon to replenish FBA or Prime inventory, that also changes available stock. These transfers need to remain traceable across the ERP, the logistics provider and Amazon.
This is why the fulfillment model shapes the architecture more than the raw channel count. With an in-house warehouse, the business controls picking, packing and shipping itself. With a 3PL, information has to move reliably in and out of an external process. With FBA, Amazon handles much of the execution, but creates its own inventory, statuses, fees and return flows. In mixed models, these variants run in parallel.
5. Returns and refunds
Returns are not an edge case. They are part of the normal order-to-cash process.
A return changes at least four things: the order, the payment, the physical inventory and the financial valuation. The item may be sellable again, damaged or need to be written off. A partial return affects different line items and amounts than a full cancellation.
If the marketplace knows about the refund, the warehouse records the condition of the item in another system, and finance posts the correction manually later, the return exists in several places — but has not been processed end to end.
6. Finance, inventory value and channel profitability
The financial feedback loop is not the final export to accounting. It is part of the integration architecture.
A marketplace payout is not simply revenue. Fees, refunds, discounts and delayed payments need to be allocated correctly. To calculate a meaningful margin, you also need the value of the goods sold.
Knowing which channel generated how much revenue is not the same as knowing its profitability. You need to trace which inventory left through that channel and what that inventory was worth at the time. Purchase prices, exchange rates, freight and customs duties can all change that value.
Before the project, PURISH had only one sales channel connected at a system level. Today, eight technically separate channel setups are represented in one shared structure, including Shopify, B2B, several marketplaces and Amazon FBA in Europe and the US.
For the annual close, inventory data previously had to be assembled from several systems and spreadsheets over a period of weeks. During the implementation, determining year-end inventory still took around one week. Today, the current inventory value can be calculated within minutes.
The real improvement is not only the faster close. Because stock movements and product values come together, PURISH can see where inventory is located, through which channel it was sold and where the corresponding cost of goods sold arises.
Three truths instead of one system for everything
An end-to-end architecture does not mean every team has to work in the same tool or that every specialist application needs to be removed.
But it does need clear truths.
Where does the customer truth live? Where is the inventory truth? Where is the valuation truth? Which system decides whether an order has been paid? Where can the business see what inventory is currently inbound?
In one discovery, a person had effectively become the human interface between several teams because they kept the critical information up to date across multiple spreadsheets. The problem was not a lack of effort. There was simply no place where the relevant information was both reliable and accessible to everyone.
A spreadsheet can be a useful analysis or planning tool. It should not permanently carry the responsibility of connecting core systems and business functions.
Hol dir das E-Commerce-ERP-Playbook
Ein strukturierter Leitfaden für die wichtigsten ERP-Entscheidung im wachsenden E-Commerce (+60 Seiten, 12 Expertinnen).
Mit Erfahrungen von Expert*innen, die täglich ERP, Ops & Zahlen verantworten.
When the apparent integration problem is somewhere else entirely
Not every break that becomes visible at a sales channel is a channel problem.
At a lighting manufacturer we work with, Shopify itself worked as a sales channel. The existing ERP was also used for shipping and billing. The real bottleneck started after the order.
Production was managed through a home-built dashboard and a great deal of manual knowledge. Reliable inventory, clearly guided manufacturing steps and a simple user experience were missing. At the same time, the business brings in many new seasonal workers.
The key task was therefore not to connect Shopify more deeply. The production process needed to be structured so that employees at each station could see what to do next and new colleagues could become productive quickly.
The example shows the wrong sequence behind many integration projects: teams start discussing interfaces before they have clarified which process actually needs to be stabilized.
Which integration architecture fits when
Direct integration
Best fit when: a clear, stable data flow needs to be automated and there are few exceptions.
Becomes risky when: several processes, systems and edge cases converge in the same flow.
Shopify as the hub
Best fit when: Shopify is the operational center and orders from different channels are handled in largely the same way.
Becomes risky when: purchasing, B2B, FBA, multiple inventory pools and detailed inventory valuation become more important.
Marketplace middleware
Best fit when: managing listings, prices and onboarding across many marketplaces is a job in its own right.
Becomes risky when: it turns into another data hub without clear ownership.
ERP-centered or hybrid architecture
Best fit when: sales, purchasing, inventory, fulfillment and finance are tightly interdependent.
Becomes risky when: the scope grows unnecessarily or specialist systems are replaced without a good reason.
None of these models is inherently superior. The right question is not: which architecture looks the most modern? It is: what is the smallest architecture that can reliably carry the full relevant process?
How to derive the right architecture
That is why I never start a discovery by looking at the interface list. We take a real order and follow it from the sale through to its financial valuation.
1. Map the real flow
Where are the product, price and order created? Where does availability come from? Who owns fulfillment, invoicing and payment?
2. Walk through the normal exceptions
Order change, partial shipment, cancellation, return, damaged goods, invoice discrepancy. An architecture that can only handle the happy path is not robust.
3. Define system ownership
Product data, inventory, orders, payments and inventory value each need an authoritative source. Not necessarily the same system — but a clear decision.
4. Involve finance early
How are revenue, fees, refunds and cost of goods sold allocated to a channel? Which information needs to be available for the month-end close?
5. Build the smallest sensible scope
Only now should you decide whether one interface is enough or whether you need a hub, middleware, an ERP or a hybrid setup. The first scope should carry the relevant end-to-end process, not every feature you might ever want.
Self-check: are your sales channels really integrated?
Orders arrive centrally, but still need to be checked, completed or recreated on a regular basis.
The process only works as long as no customer changes their order.
Inventory figures differ between the store, marketplace, warehouse and ERP.
Reliable status and inventory updates are missing after orders are passed to the warehouse, 3PL or FBA.
Customer service has to open several systems to understand one order.
Cancellations, partial shipments or returns are handled outside the standard process.
Excel, Slack, email or manual exports act as permanent bridges between core systems.
It is unclear which system owns product data, inventory, orders, payments or inventory value.
Finance cannot reliably bring together revenue, fees, returns and cost of goods sold by channel.
Every new sales channel creates permanent manual work or new special rules.
If you answer yes to several of these points, it is worth looking at the full process. The answer does not automatically have to be a new ERP or a major transformation project. Sometimes a well-designed interface is enough. Sometimes ownership or data logic needs to be clarified. And sometimes the existing architecture has genuinely been outgrown by the operating model.
Conclusion: integration does not end with the order import
Sales channels are not integrated just because data moves between them.
They are integrated when every sale remains traceable as one connected transaction: with clear product data, reliable availability, an executable order, complete fulfillment feedback, properly processed returns and robust financial valuation.
The right architecture can be very simple. It can also combine several specialist systems with an ERP. What matters is not how modern the architecture diagram looks.
What matters is whether another channel can create more business without forcing the organization to rebuild the process around it every time.
If you are not sure where your setup is actually breaking, the most useful next step is not a premature tool comparison. In our Discovery Assessment, we follow a real order from the sale through stock movement and finance. We make manual handoffs, missing feedback loops and unclear system ownership visible, then derive a target architecture and the smallest sensible implementation scope.
Frequently asked questions about multichannel integration
What does multichannel integration in e-commerce include?
A complete multichannel integration connects product data, prices, inventory, orders and status information across several sales channels. For an end-to-end operation, it also needs to cover fulfillment, returns, payments, stock movements and finance.
How can you tell that a multichannel integration is incomplete?
Orders may be transferred successfully, but employees still have to update statuses, reconcile inventory, assign returns manually or consolidate financial data from several systems.
When is a simple interface enough?
A simple interface is enough when it automates a clearly defined, stable process, there are few exceptions and the systems involved have unambiguous roles. It does not need to do as much as possible; it needs to cover the relevant data flow reliably.
What is the difference between multichannel and omnichannel?
Multichannel means selling through several channels. Omnichannel also emphasizes a consistent customer experience across touchpoints. Operationally, both require reliable data and process flows between the systems involved.
Which system should be the source of truth in a multichannel architecture?
That depends on the information. The store or PIM may own product content, while the ERP owns inventory, stock movements and financial valuation. What matters is that one authoritative source is defined for every relevant type of information.
What role does the fulfillment model play?
An in-house warehouse, a 3PL and FBA create different responsibilities and data flows. The fulfillment model therefore often has a greater impact on the right architecture than the number of sales channels alone.
Why should finance be involved early?
Without connecting revenue, fees, returns and inventory values, the real profitability of a channel remains unclear. When finance requirements are considered only at the end, manual reconciliation and slow month-end closes are common.
Does an ERP need to replace every other system?
No. An ERP can own the operational and financial process while Shopify, a PIM, marketplace software and other specialist tools retain clear roles. The key is unambiguous ownership and reliable handoffs.
When the apparent integration problem is somewhere else entirely
Not every break that becomes visible at a sales channel is a channel problem.
At a lighting manufacturer we work with, Shopify itself worked as a sales channel. The existing ERP was also used for shipping and billing. The real bottleneck started after the order.
Production was managed through a home-built dashboard and a great deal of manual knowledge. Reliable inventory, clearly guided manufacturing steps and a simple user experience were missing. At the same time, the business brings in many new seasonal workers.
The key task was therefore not to connect Shopify more deeply. The production process needed to be structured so that employees at each station could see what to do next and new colleagues could become productive quickly.
The example shows the wrong sequence behind many integration projects: teams start discussing interfaces before they have clarified which process actually needs to be stabilized.
Which integration architecture fits when
Direct integration
Best fit when: a clear, stable data flow needs to be automated and there are few exceptions.
Becomes risky when: several processes, systems and edge cases converge in the same flow.
Shopify as the hub
Best fit when: Shopify is the operational center and orders from different channels are handled in largely the same way.
Becomes risky when: purchasing, B2B, FBA, multiple inventory pools and detailed inventory valuation become more important.
Marketplace middleware
Best fit when: managing listings, prices and onboarding across many marketplaces is a job in its own right.
Becomes risky when: it turns into another data hub without clear ownership.
ERP-centered or hybrid architecture
Best fit when: sales, purchasing, inventory, fulfillment and finance are tightly interdependent.
Becomes risky when: the scope grows unnecessarily or specialist systems are replaced without a good reason.
None of these models is inherently superior. The right question is not: which architecture looks the most modern? It is: what is the smallest architecture that can reliably carry the full relevant process?
How to derive the right architecture
That is why I never start a discovery by looking at the interface list. We take a real order and follow it from the sale through to its financial valuation.
1. Map the real flow
Where are the product, price and order created? Where does availability come from? Who owns fulfillment, invoicing and payment?
2. Walk through the normal exceptions
Order change, partial shipment, cancellation, return, damaged goods, invoice discrepancy. An architecture that can only handle the happy path is not robust.
3. Define system ownership
Product data, inventory, orders, payments and inventory value each need an authoritative source. Not necessarily the same system — but a clear decision.
4. Involve finance early
How are revenue, fees, refunds and cost of goods sold allocated to a channel? Which information needs to be available for the month-end close?
5. Build the smallest sensible scope
Only now should you decide whether one interface is enough or whether you need a hub, middleware, an ERP or a hybrid setup. The first scope should carry the relevant end-to-end process, not every feature you might ever want.
Self-check: are your sales channels really integrated?
Orders arrive centrally, but still need to be checked, completed or recreated on a regular basis.
The process only works as long as no customer changes their order.
Inventory figures differ between the store, marketplace, warehouse and ERP.
Reliable status and inventory updates are missing after orders are passed to the warehouse, 3PL or FBA.
Customer service has to open several systems to understand one order.
Cancellations, partial shipments or returns are handled outside the standard process.
Excel, Slack, email or manual exports act as permanent bridges between core systems.
It is unclear which system owns product data, inventory, orders, payments or inventory value.
Finance cannot reliably bring together revenue, fees, returns and cost of goods sold by channel.
Every new sales channel creates permanent manual work or new special rules.
If you answer yes to several of these points, it is worth looking at the full process. The answer does not automatically have to be a new ERP or a major transformation project. Sometimes a well-designed interface is enough. Sometimes ownership or data logic needs to be clarified. And sometimes the existing architecture has genuinely been outgrown by the operating model.
Conclusion: integration does not end with the order import
Sales channels are not integrated just because data moves between them.
They are integrated when every sale remains traceable as one connected transaction: with clear product data, reliable availability, an executable order, complete fulfillment feedback, properly processed returns and robust financial valuation.
The right architecture can be very simple. It can also combine several specialist systems with an ERP. What matters is not how modern the architecture diagram looks.
What matters is whether another channel can create more business without forcing the organization to rebuild the process around it every time.
If you are not sure where your setup is actually breaking, the most useful next step is not a premature tool comparison. In our Discovery Assessment, we follow a real order from the sale through stock movement and finance. We make manual handoffs, missing feedback loops and unclear system ownership visible, then derive a target architecture and the smallest sensible implementation scope.
Frequently asked questions about multichannel integration
What does multichannel integration in e-commerce include?
A complete multichannel integration connects product data, prices, inventory, orders and status information across several sales channels. For an end-to-end operation, it also needs to cover fulfillment, returns, payments, stock movements and finance.
How can you tell that a multichannel integration is incomplete?
Orders may be transferred successfully, but employees still have to update statuses, reconcile inventory, assign returns manually or consolidate financial data from several systems.
When is a simple interface enough?
A simple interface is enough when it automates a clearly defined, stable process, there are few exceptions and the systems involved have unambiguous roles. It does not need to do as much as possible; it needs to cover the relevant data flow reliably.
What is the difference between multichannel and omnichannel?
Multichannel means selling through several channels. Omnichannel also emphasizes a consistent customer experience across touchpoints. Operationally, both require reliable data and process flows between the systems involved.
Which system should be the source of truth in a multichannel architecture?
That depends on the information. The store or PIM may own product content, while the ERP owns inventory, stock movements and financial valuation. What matters is that one authoritative source is defined for every relevant type of information.
What role does the fulfillment model play?
An in-house warehouse, a 3PL and FBA create different responsibilities and data flows. The fulfillment model therefore often has a greater impact on the right architecture than the number of sales channels alone.
Why should finance be involved early?
Without connecting revenue, fees, returns and inventory values, the real profitability of a channel remains unclear. When finance requirements are considered only at the end, manual reconciliation and slow month-end closes are common.
Does an ERP need to replace every other system?
No. An ERP can own the operational and financial process while Shopify, a PIM, marketplace software and other specialist tools retain clear roles. The key is unambiguous ownership and reliable handoffs.
More articles
How to Start an ERP Project Successfully: 9 Decisions That Need to Be Made Before Implementation
Switching ERP from weclapp, Xentral or JTL to Odoo: How companies migrate cleanly (process, risks and common mistakes)
ERP Implementation: 7 Risks That Make Projects Fail (and How to Spot Them Early)
Best-of-Breed vs. Best-of-Suite in Mid-Market: HubSpot vs. Odoo in a Reality Check
Controlling ERP in E-Commerce: How to Scale Without Losing Financial Control
Customer Service ERP: How to Integrate Service, ERP and Logistics Properly
E-Commerce Accounting ERP: When 60,000 Monthly Bookings Break Your System
E-Commerce Logistics & ERP: Why Fulfillment Becomes Structural at Scale
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH
Made with🫀in Berlin © 2026 bobco GmbH