E-Commerce and ERP Integration: Stock Cannot Be Right in Two Places

The same product showing 12 units in your store, 8 on a marketplace and 5 in the warehouse is not a missing integration. It is usually an integration designed without deciding which system is allowed to be right.

The Single Source of Truth

Before building any integration, assign one owner to each data type. The owner is the only system permitted to change that data; everyone else reads it.

• Stock → ERP. The goods are in the warehouse and the warehouse's record lives in ERP. Store and marketplaces read stock from ERP and never modify it.
  
• Price → ERP. Channel-specific prices are fine, but the pricing rules belong in one place.
  
• Product data → ERP or a product information system. Technical fields such as code, unit and weight in ERP; imagery and marketing copy can live on the storefront.
  
• Orders → Channel. Orders originate in the channel and flow into ERP. ERP fulfils them; it does not alter them.
  
• Customers → ERP. Account uniqueness is maintained in ERP.
  

Details That Matter in Stock Sync

Reserved stock. Ordered but not yet dispatched. This must be deducted from sellable stock, otherwise the same item sells twice — critical on the last few units.

Safety buffer. Exposing full stock to every channel leads to overselling during sync delays. Holding a small buffer on fast-moving items is common practice.

Multiple warehouses. If you ship from more than one location, which channel draws from which warehouse must be defined. Presenting total stock as one pool breaks dispatch planning.

Sync frequency. Event-driven updates are ideal but can hit marketplace API quotas. A practical compromise: immediate for critical items, periodic for the rest.

Order Flow

• Customer matching: When the same person orders through different channels, is one account created? A matching rule on email or phone must be defined.
  
• Shipping and service charges: These must arrive in ERP as line items, or the order total will not match the invoice.
  
• Commissions and deductions: Marketplace commission recorded as a cost, otherwise channel profitability cannot be calculated.
  
• Returns and cancellations: The most frequently skipped flow. A return must restore stock and create a credit on the account.
  
• Partial shipments: Channel-side status must be updated when only part of an order ships.
  

Error Handling

Integrations fail: API timeouts, exhausted quotas, unexpected formats. What matters is not that failures never happen but that they never happen silently:

• Failed operations queue and retry automatically.
  
• After a set number of attempts, an alert is raised.
  
• Error messages are intelligible — "product code not found on marketplace", not "500 Internal Server Error".
  
[*]There is a manual intervention screen so operations can correct issues without waiting for engineering.

Channel Profitability

The real return on integration is not operational convenience but being able to see margin by channel. That requires a channel tag on every order and cost-side collection of commission, shipping, return rate and packing cost per channel.

Once that calculation exists, most companies discover their highest-revenue channel is not their most profitable one. Decisions change with that data.

In Short

In multi-channel selling the problem is not the number of channels but undefined data ownership. Assign one owner per data type, push stock one way only, and design the return and commission flows from the start.

We can design an integration that fits your channels with Mekjoy E-Commerce.