Stock Synchronisation and Marketplace Integration in E-Commerce
The core problem in multichannel selling
The core problem is selling the same stock in several places. When your own site, marketplaces and physical stores all draw on one warehouse, simultaneous orders in two channels can sell an item you do not have. Overselling is not only a cancellation cost; on marketplaces it also lowers your seller performance score.
Three approaches that prevent overselling
- Per-channel allocation: part of the stock is reserved for each channel. Simplest to implement, but unused stock in one channel cannot move to another.
- Safety buffer: a fixed quantity is deducted from central stock before publishing. Fast to deploy, but loses sales on low-stock items.
- Central reservation: a reservation is created against central stock at order time. Most accurate, but requires the integration to run close to real time.
A common practical answer is reservation for fast-moving items and a buffer for slow movers.
Accept synchronisation delay; do not hide it
No integration is instantaneous. The right approach is not to chase zero delay but to measure and bound it: track the average and worst-case delay of stock updates and raise an alert when a threshold is exceeded. Update frequency should also rise as stock falls — a ten-minute delay is harmless on an item with 500 units and harmful on one with three.
Order to invoice
After an order is taken the chain runs through stock reservation, payment verification, shipping and invoicing. E-document obligations apply at the invoicing step, and matching the invoice number to the order number is mandatory for returns and reconciliation. On marketplace orders, who is responsible for issuing the invoice varies by channel contract, so this belongs in the data model as a per-channel setting.
Operation keys prevent retried transfers from creating duplicate orders; see the [API integration guide](/en/blog/api-integration-guide).
Returns belong in the data model
A return is not the deletion of an order; it is a separate record with its own lifecycle: requested → approved → received → inspected → accepted or rejected → refunded. Partial returns must be modelled at line level. A status field should also distinguish whether the returned item goes back into sellable stock or not — damaged, opened, unsellable. Without that distinction, stock accuracy degrades with every return.
Do not flatten marketplace differences
Each marketplace has its own category tree, mandatory attribute set, commission structure and shipping rules. Reducing product data to a single "title plus description" cannot satisfy per-channel requirements. The right structure is a rich central product model with a mapping defined per channel.
Frequently asked questions
Should stock be held centrally in the ERP?
Yes. The ERP should be the single source of truth and channels should be fed from it. Channels managing independent stock counters make reconciliation impossible.
How should price differentiation be managed?
Per-channel price lists and commission-inclusive calculation belong in one place. Marketplace commission and shipping cost change channel profitability, so the same product may legitimately carry different prices per channel — as a deliberate decision rather than a side effect of manual updates.
Should store stock be exposed to online sales?
It can be, but reliable store counting is a precondition. Publishing store stock while count accuracy is low is the most frequent cause of overselling. Stock accuracy on the store side is covered in our [retail POS guide](/en/blog/retail-pos-guide).