Overview
Running one online store is mainly a commerce challenge. Running more than 25 Shopify stores alongside Amazon channels, Odoo websites and international warehouses becomes an enterprise integration challenge. Every storefront may have its own catalogue, currency, price list, tax treatment, payment provider, fulfilment rule and customer-service process. Without a central operational system, the same product and order information becomes distributed across dozens of platforms.
Sasmar's global digital-commerce footprint shows why this architecture matters. Its broader transformation grew from an initial Odoo environment serving six companies into an enterprise platform supporting 22 companies across four regions. The case presented in the official Odoo Experience 2026 session, Choosing Odoo Over SAP: The 10-Year Transformation Journey of a Global Pharmaceutical Group, also includes more than 25 Shopify stores plus Amazon and other digital channels.
This scale does not mean every channel should operate directly inside Odoo or that every synchronization should run in real time. It means Odoo can serve as the central business layer where product, inventory, warehouse, order, accounting and reporting data converge. Connectors then exchange selected data between Odoo and each commerce platform according to controlled rules.
This article explains the architecture required for an Odoo multi-store Shopify integration at global scale. Confirmed Sasmar facts provide the case context. The detailed synchronization model represents a recommended architecture based on enterprise integration practice unless a workflow is specifically attributed to Sasmar.
Why Multiple Stores Create Fragmented Operations
A business may create separate Shopify stores for different countries, brands, languages, distributors or customer segments. Amazon adds another channel structure with marketplace-specific listings, fulfilment options, commissions and settlement reports. Odoo websites may serve markets where the organization wants native ERP-connected commerce. This channel expansion supports growth but also duplicates operational data.
Product information is often edited separately in each storefront. A price update may reach one store but not another. Inventory can appear available in two channels even though both depend on the same physical stock. Orders may enter separate spreadsheets before being re-entered into ERP. Refunds can remain in a marketplace account while the original invoice stays open in accounting. Local teams may therefore see channel activity without having a consistent global view.
The problem becomes more serious when the organization operates multiple legal companies and warehouses. A UK store may sell through one company and ship from a UK warehouse while an Australian store uses another company, currency and tax configuration. The channel name alone is not enough. Every imported order must reach the correct company, sales team, warehouse, fiscal position, price list, journal and fulfilment workflow.
A scalable multi-channel eCommerce ERP must answer five questions for every transaction:
Which external channel created the transaction?
Which Odoo company owns the sale?
Which warehouse should fulfil it?
Which financial and tax rules apply?
Which status must be returned to the channel?
If these rules are not explicit, adding new stores multiplies exceptions. If they are held in reusable configuration, a new store becomes a controlled onboarding exercise.
Sasmar's Digital-Commerce Scale
Sasmar's commerce environment sits inside a much larger enterprise transformation. The complete Sasmar transformation explains why the organization selected Odoo and how its ERP strategy developed over ten years. The 22-company Odoo architecture examines the company, security, currency, warehouse and consolidation structure behind that growth.
The digital-commerce layer adds a different kind of scale. More than 25 Shopify stores plus Amazon and other channels can generate thousands of product, customer, stock, order, payment and fulfilment events. The ERP must identify each event, validate it, process it once and retain a traceable link to its source.
The public case material confirms that Sasmar's global Odoo ecosystem connects website and eCommerce processes with sales, inventory and operations. It also reports operations across Belgium, the USA, the UK, France, Singapore and Australia. However, public materials do not document every connector, endpoint, synchronization interval or channel-specific rule. Those implementation details should therefore not be guessed. The architecture below shows how such an environment can be designed reliably.
Simple Global Commerce Architecture
flowchart LR
A["Shopify Stores"] --> O["Odoo ERP"]
M["Amazon Channels"] --> O
W["Odoo Websites"] --> O
O --> I["Inventory & Warehouses"]
O --> F["Finance & Reporting"]
The diagram is intentionally simple. In production, an integration layer normally sits between external channels and Odoo. It manages authentication, queues, retries, rate limits, mappings and logs. Odoo remains the operational system of record while Shopify and Amazon remain the systems responsible for their customer-facing channel functions.
| Data domain | Recommended source of truth | Outbound flow | Inbound flow |
|---|---|---|---|
| Core product data | Odoo | Product, SKU, attributes and approved content | Channel IDs and listing status |
| Channel prices | Odoo price lists or governed pricing service | Price and promotional rules | Rejection or update result |
| Sellable inventory | Odoo | Available quantity by channel rule | Reservation or order demand |
| Customer orders | Commerce channel then Odoo | Fulfilment, tracking and cancellation status | Order, customer, tax, discount and payment data |
| Accounting | Odoo | Financial status where required | Payment, fee, refund and settlement data |
| Channel content | Channel or PIM according to governance | Approved shared content | Channel-specific content and media references |
Odoo as the Central Product-Information Source
A global commerce operation needs one stable identity for every sellable item. In Odoo, the internal product record and SKU can provide that identity. Shopify product IDs, variant IDs, Amazon ASINs and seller SKUs are stored as external mappings rather than used as the only internal reference.
The central record can hold the product name, internal SKU, barcode, unit of measure, product category, tax category, weight, dimensions and lifecycle status. Variant attributes such as size, colour or pack format must map consistently to each channel. Country-specific descriptions, images and regulatory content may remain channel-specific when business or legal requirements differ.
Product publishing should follow a controlled state flow:
Draft product → data validation → channel eligibility → export queue → channel response → mapping saved → active listing
The connector should not publish an incomplete product merely because it exists in Odoo. Validation can require a SKU, sales price, tax category, image, weight and relevant country information before an export job is created. Once the channel accepts the item, its external identifiers must be stored against the exact Odoo company and store configuration.
This model turns Odoo into a governed product-information source without assuming that every channel must display identical content.
Connecting More Than 25 Shopify Stores
Each Shopify store should be configured as a separate connector instance. The instance holds its store URL, credentials, company, warehouse, language, currency, price list, sales team, order sequence, payment mappings, tax rules and synchronization settings. Shared connector code can then execute different rules using configuration rather than store-specific custom code.
| Store configuration | Purpose |
| Odoo company | Determines legal ownership and accounting context |
| Warehouse and route | Controls reservation and fulfilment |
| Currency and price list | Controls sales values and product-price exports |
| Fiscal position | Maps taxes and accounts for the market |
| Payment methods and journals | Supports payment and settlement reconciliation |
| Product catalogue rule | Defines which items can be published |
| Stock publication rule | Defines safety stock and sellable quantity |
| Order status mapping | Translates Shopify and Odoo workflow states |
| Synchronization schedule | Balances freshness, volume and API limits |
The connector must maintain an external ID mapping for store, product, variant, customer, order, fulfilment, transaction and refund records. An external Shopify ID is unique only within its relevant context. The integration should therefore use a composite identity such as connector instance + external object type + external ID.
Webhooks can notify Odoo about new or changed orders. Scheduled jobs should still reconcile recent records because a webhook may be delayed, duplicated or missed. The import process must be idempotent: receiving the same event twice must update or ignore the existing order rather than create a duplicate.
Connecting Amazon and Other Marketplace Channels
Amazon integration differs from Shopify because the marketplace controls more of the listing, order and settlement process. Amazon may also fulfil stock through FBA while the organization fulfils other orders directly through its warehouses. The connector must distinguish these fulfilment models.
For merchant-fulfilled orders, Odoo can receive the order, reserve stock, create a delivery and return shipment tracking. For FBA orders, fulfilment happens in Amazon's network but Odoo still needs order, fee, inventory and settlement information for operational and financial reporting. Inventory sent to Amazon can be represented through dedicated warehouse locations and transfer workflows.
Marketplace integration should map:
Seller account and marketplace to the correct Odoo company
Seller SKU and ASIN to the correct Odoo product variant
Marketplace order status to the appropriate Odoo sales workflow
Shipping services to Odoo carriers and delivery products
Amazon fees, commissions and adjustments to financial accounts
Fulfilment model to the correct warehouse or virtual location
Settlement references to payment and reconciliation records
Other marketplaces should use the same integration framework. The channel adapter may differ but product identity, queue handling, company routing, audit logs and error controls should remain standardized.
Product, Price and Currency Synchronization
Product synchronization should separate stable master data from frequently changing commercial data. Product identity and attributes may change occasionally. Prices, promotions and availability change more often and should run through independent jobs.
Odoo price lists can manage prices by company, country, customer group, currency, quantity or date range. Before exporting, the connector resolves the relevant price list and currency for the store. It must also define whether prices include tax. Rounding rules must match the channel so a converted price does not create small differences between the order total and invoice total.
Currency conversion should not be performed blindly during order import. The external order amount must be preserved in the transaction currency. Odoo can then post the receivable and recognize exchange differences using the accounting currency configuration. The imported order should retain the original item prices, discounts, shipping charge, tax and total sent by the channel.
Recommended price flow:
Odoo price rule → store and currency resolution → tax basis check → rounding → export → channel acknowledgement → audit log
Real-Time Inventory Visibility Without Overselling
Publishing physical on-hand stock is rarely safe. The quantity offered to a channel should account for reservations, outgoing deliveries, incoming policy, safety stock and quantities allocated to other channels.
A typical rule is:
Sellable quantity = forecast or available quantity - safety buffer - protected allocation
The exact formula depends on the business. Fast-moving products may need channel-level allocation. Regulated or batch-controlled products may be sellable only when a valid lot, expiry window or market approval is available. The connector should never expose these rules as a hard-coded number inside each store adapter.
Inventory updates may use event-driven jobs after relevant Odoo stock movements plus periodic full reconciliation. The event-driven job improves freshness. The full reconciliation detects missed events and corrects drift.
When an order arrives, Odoo should reserve the product in the selected warehouse before treating the item as confirmed for fulfilment. If stock is unavailable, the configured policy may place the order on hold, route it elsewhere, allow backorder or trigger a customer-service exception.
Multi-Warehouse Order Routing
Order routing determines which company and warehouse will fulfil a sale. The simplest rule assigns one warehouse to each store. A more advanced model selects a warehouse based on country, stock availability, delivery time, product restrictions, cost or fulfilment capacity.
The decision must occur before reservation and accounting documents are created. Moving an order between companies after invoicing can create tax and reconciliation problems.
Channel order → store configuration → owning company → delivery country → product eligibility → warehouse selection → stock reservation → delivery creation
If another legal company owns the available stock, the process may require an intercompany sale, purchase or transfer rather than a simple warehouse reassignment. The commerce connector should call the governed Odoo workflow instead of hiding the legal movement.
Customer and Order Synchronization
Every external order should retain the channel name, store, external order number, external customer ID, transaction references and original timestamps. These fields provide traceability for support, reconciliation and reprocessing.
Customer matching needs a clear policy. Email alone may be insufficient because marketplaces can mask addresses and one person may shop through several regional stores. A conservative approach first checks the stored channel customer mapping then applies defined matching rules. If no reliable match exists, the integration creates a new contact with the source recorded.
The order-import workflow is:
Receive a webhook or scheduled API result.
Check the connector instance and external order identity.
Reject or quarantine an event with an unknown store.
Resolve company, warehouse, currency, price list and fiscal position.
Map products, shipping, discounts, taxes and payment method.
Create or update the customer using the matching policy.
Create the sales order with original channel references.
Validate totals against the channel payload.
Confirm the order according to the store workflow.
Reserve stock and create fulfilment documents.
Create financial documents according to accounting policy.
Return fulfilment and tracking status to the channel.
An unknown SKU, unmapped tax or total mismatch should stop automated confirmation. Creating an incomplete sales order may appear convenient but transfers the error into inventory and accounting.
International Taxes and Fiscal Positions
International eCommerce cannot use one generic tax rule. The correct treatment may depend on the selling company, customer type, delivery country, tax registration, product tax category and whether the marketplace is responsible for collecting tax.
Odoo fiscal positions can map taxes and accounts for different contexts. Connector configuration should select the appropriate fiscal position from explicit order data. Imported marketplace tax must be compared with the amount Odoo calculates. A tolerance may handle permitted rounding differences but larger mismatches should enter an exception queue.
The architecture must also retain marketplace tax identifiers and transaction evidence when required. Odoo can support the accounting workflow but legal tax design must be validated by qualified advisers in each jurisdiction.
Returns, Refunds and Cancellation Workflows
Returns are not simply negative sales orders. The integration must determine whether products were shipped, received back, suitable for resale and financially refunded.
For a cancellation before shipment, Odoo can cancel or release the delivery reservation and cancel the sales order according to its state. If payment was already captured, the financial refund follows separately.
For a return after shipment, the workflow becomes:
Return request → external reference match → return authorization → reverse stock transfer → product inspection → restock or quarantine → credit note → payment refund → channel status update
The connector must make each stage idempotent. A repeated refund webhook must not create another credit note. Partial returns must preserve the exact products, quantities, taxes, shipping adjustments and refund amount.
Amazon returns may produce settlement adjustments at a different time from the physical return. Odoo should link these records without assuming they arrive in the same API response.
Payment and Accounting Reconciliation
An order marked paid in Shopify or Amazon is not the same as money reconciled in the bank. Payment providers and marketplaces deduct fees, commissions, refunds, chargebacks and currency adjustments before transferring a net settlement.
The Odoo accounting model should record the gross customer sale and then post deductions to their appropriate accounts. A clearing account can represent amounts due from a provider until the payout is received.
Customer sale → channel payment/clearing account → fees and adjustments → payout → bank statement → reconciliation
For example, a settlement may contain sales of 10,000, refunds of 500 and fees of 700 with a bank payout of 8,800. Recording only the 8,800 receipt loses the gross revenue, refund and fee detail. Settlement import should create or match the components then reconcile the net amount with the bank transaction.
Multi-currency settlements also require exchange-rate and bank-fee treatment. The system must preserve the original order currency, settlement currency and company currency so differences remain explainable.
Integration-Failure Monitoring
At 25-store scale, failures are normal operational events. Products can be missing mappings. APIs can reject a request. Credentials can expire. Rate limits can delay jobs. A channel may send a new status that the connector does not recognize. Reliability depends on detecting and resolving these events before they create business inconsistencies.
Every job should record:
Connector instance and company
Object type and internal/external identifiers
Operation and attempt number
Request time and response status
Sanitized error message
Retry state and next attempt
Responsible team and resolution note
Errors should be classified as retryable or functional. A timeout may be retried automatically with backoff. An unknown SKU requires a user to correct the mapping. An authentication failure should disable affected jobs and alert the support team. A total mismatch must be reviewed before order confirmation.
Dashboards should show queue age, failure count, retry volume, orders awaiting action, stock-sync delay and settlement exceptions by store. Alerts should be based on business impact rather than every technical warning.
API Performance and Synchronization Scheduling
Trying to synchronize every object in real time can overload both Odoo and external APIs. The schedule should reflect how quickly each data type becomes stale and how costly a delay would be.
| Synchronization | Recommended pattern | Reason |
| New orders and cancellations | Webhook plus scheduled reconciliation | Fast response with recovery for missed events |
| Inventory | Event-driven batches plus full reconciliation | Reduces overselling and corrects drift |
| Prices | Scheduled incremental export | Controlled updates without unnecessary calls |
| Product content | Queued publishing | Supports validation and large payloads |
| Fulfilment and tracking | Event-driven export | Keeps customers informed promptly |
| Settlements | Scheduled import | Follows provider reporting cycles |
| Full catalogue check | Off-peak scheduled job | Detects long-term mapping differences |
Queues should process small batches and commit progress safely. One failed record must not block every store. High-volume stores may receive separate workers or priority queues. API calls should use pagination, incremental timestamps and rate-limit awareness. Heavy catalogue jobs should run outside peak order-processing periods.
Database indexes are important for external IDs, connector instances, status, update time and queue state. Old request payloads should follow a retention policy so logs do not grow without control. Sensitive credentials and payment information must never be written into ordinary application logs.
Architecture for Adding New Stores and Countries
A scalable design makes the twenty-sixth store easier to add than the first few. New stores should use a repeatable onboarding template instead of copied custom code.
The rollout process should include:
Confirm the legal company, market and fulfilment model.
Create the connector instance and secure credentials.
Assign warehouse, routes, currency, price list and language.
Configure fiscal position, tax mapping and financial journals.
Map payment methods, carriers, fees and settlement accounts.
Define eligible products and publish a controlled test catalogue.
Test stock, price and product synchronization.
Import test orders covering normal and exceptional scenarios.
Test fulfilment, cancellation, return, refund and reconciliation flows.
Validate monitoring, retry and support ownership.
Reconcile launch-day orders, inventory and settlements.
Review performance after the first operating cycle.
Country onboarding also requires local tax, invoicing, privacy, payment and product-compliance review. These requirements should extend the standard template without changing the shared connector framework unless genuinely necessary.
Organizations planning this environment can review Browseinfo's Odoo integration services for API, eCommerce, payment and third-party integration requirements. Businesses considering a native ERP-connected storefront can also explore the Odoo eCommerce platform.
Lessons from Sasmar's Global Commerce Operations
The first lesson is that commerce scale must be supported by enterprise structure. Stores cannot be integrated reliably until company, currency, warehouse, product and accounting ownership are defined.
The second lesson is that Odoo's value is not limited to importing orders. The larger benefit comes from connecting commerce demand with inventory, fulfilment, finance and reporting. Sasmar's broader pharmaceutical supply-chain transformation shows why eCommerce must remain connected with manufacturing, purchasing, inventory and global operational control.
The third lesson is to standardize the integration framework while allowing controlled local variation. Every market may have different taxes, prices, payment providers and logistics rules. It should not have a completely different connector architecture.
The fourth lesson is that synchronization is an operational process. Monitoring, exception ownership, reconciliation and audit logs are as important as API development. A connector that works during a demonstration but cannot recover from failures is not ready for enterprise commerce.
The fifth lesson is to design for addition. Store and country configuration should remain separate from reusable connector logic. This reduces technical debt and makes future expansion safer.
Conclusion
Managing more than 25 Shopify stores, Amazon channels and Odoo websites requires a central operating model rather than a collection of point-to-point scripts. Odoo can provide that central layer by governing products, prices, inventory, companies, warehouses, orders, accounting and reporting while channel connectors manage controlled exchanges with each external platform.
The architecture succeeds when every transaction retains its source, reaches the correct company and warehouse, follows the correct tax and accounting rules and can be recovered when integration failures occur. Product publishing, inventory availability, orders, returns and settlements must form one traceable end-to-end flow.
Sasmar's decade-long transformation provides a useful enterprise context: global digital commerce did not sit outside ERP. It became part of a connected operational environment capable of expanding across companies, regions and channels.
Frequently Asked Questions
1. Can Odoo manage more than 25 Shopify stores?
Yes. Odoo can connect with multiple Shopify stores through separate connector instances. Each instance should hold its own company, warehouse, currency, price list, tax, payment and synchronization configuration while sharing a standardized integration framework.
2. How does Odoo prevent overselling across Shopify and Amazon?
Odoo can calculate sellable stock from available or forecast quantity then subtract safety buffers and protected allocations. Event-driven inventory updates and scheduled reconciliation can publish this quantity to channels. Incoming orders must reserve stock in the selected warehouse promptly.
3. Should Odoo be the source of truth for all product information?
Odoo can govern the core product identity, SKU, attributes, logistical data and commercial rules. Channel-specific descriptions, media and regulatory content may remain in the channel or a dedicated PIM when the organization requires more specialized content governance.
4. How are Shopify orders routed to the correct Odoo company?
Each Shopify connector instance maps the store to an Odoo company. During import, the integration also resolves the relevant warehouse, currency, price list, fiscal position, journal and sales workflow before confirming the order.
5. Can Odoo reconcile Amazon and Shopify payouts?
Yes. A suitable integration can import settlement details, record gross sales, refunds, fees and adjustments then match the net payout to the bank transaction. Clearing accounts help represent money due from each provider before settlement.
6. What happens if a channel sends the same order twice?
The integration should use an idempotent external identity based on connector instance, object type and external ID. A repeated event should update or ignore the existing record rather than create another sales order.
7. How should integration errors be managed?
Errors should enter a monitored queue with the store, company, object, message, attempt and resolution state recorded. Temporary errors can retry automatically while functional errors such as unknown SKUs or tax mismatches require review.
8. Is every eCommerce synchronization required to run in real time?
No. New orders, cancellations, inventory and tracking usually need fast event-driven processing. Product catalogues, prices, settlements and full reconciliations can use scheduled batches based on business urgency, volume and API limits.
