![Stock Synchronisation Across Sales Channels — How to Avoid Drift [2026]](https://informatix.com.pl/og/en/stock-synchronization-across-channels.png?v=1793094231)
Stock synchronisation across sales channels is where multi-channel selling most often falls apart: the store shows 5 units, Allegro sells 3, Amazon knows about none, and a customer buys a product that is not physically available. The fix is not “faster syncing” — it is three elements: one source of truth, a safety buffer and reconciliation with alerts.
KEY: Stock should flow event-driven (webhook/queue in near real time) from one source of truth, reduced by a per-product safety buffer. Synchronisation alone is not enough — you also need reconciliation comparing stock across channels and an alert when drift exceeds a threshold.
Why stock levels drift apart
Drift has four typical sources that overlap
Order race condition. Two orders from different channels sell the last item in the same second, because both saw stock “1”. Without a buffer and reservation, this is a matter of time, not bad luck.
Synchronisation lag. Stock updated on a schedule (every 15 minutes, hourly) always leaves a window where channels show stale data. The longer the window, the more phantom sales.
API and network errors. A marketplace call never arrived, a response was lost, a rate limit rejected an update. Without a retry queue, every such error leaves permanent drift.
Manual edits. Someone corrected stock directly in a marketplace panel, outside the integration. The system does not know and will either overwrite the change on the next sync or leave drift if the edit went the other way.
One source of truth — the foundation everything rests on
Before synchronising anything, decide which system owns stock. In practice it is the ERP (Subiekt, Comarch, enova365, SAP) or the store warehouse. The rules are simple:
- All channels read stock from the source of truth; no channel modifies stock directly.
- A sale in any channel decrements stock in the source of truth immediately (event-driven), not on the next import.
- Manual corrections happen only in the source of truth — with a change log, so it is traceable who changed what and why.
Two systems that both “know” stock, with neither owning it, is not a synchronisation problem — it is an architecture problem. No sync will fix it.
The safety buffer — the cheapest insurance against complaints
The buffer is the number of units you subtract from the stock published to external channels. The store has 5 units, you list 4 on Allegro — the last unit covers the order race and corrections.
Configure the buffer per product (or per group), not globally
- Bestsellers and fast movers: buffer 1–2 units — protects against double-selling at little cost.
- Slow movers: buffer 0–1 — freezing units of a product that sells once a quarter is needless cost.
- One-off items (uniques): buffer 0, but with immediate reservation on order.
The buffer does not replace fast synchronisation — it complements it. Even with event-driven sync, a few-second window remains where two channels can sell the same unit.
Stock reservation on order intake
When a marketplace order arrives, the system should reserve immediately: decrement stock in the source of truth and push the new level to the other channels. Order matters — reservation first, order confirmation to the marketplace second.
Reservation works both ways: when an order is cancelled or returned, stock goes back into the pool (with buffer adjustment). Without automatic release, the team starts handling things by hand again.
Event-driven vs scheduled sync
| Approach | How it works | Pros | Cons |
|---|---|---|---|
| Scheduled (cron, every X minutes) | Cyclic stock import/export | Simple, fault tolerant | Window of stale data, poor for fast movers |
| Event-driven (webhook + queue) | Every change triggers an update | Near real time | Needs a retry queue and idempotency |
| Hybrid (events + reconciliation) | Events live, full comparison cyclically | Highest consistency | Most design work |
In practice the hybrid wins: stock flows event-driven (marketplace webhook plus a queue for channel updates), and an hourly or daily reconciliation report compares stock between the source of truth and the channels. Drift above a threshold raises an alert — instead of waiting for a complaint.
Reconciliation and alerts — turning complaints into tickets
Reconciliation systematically compares stock: source of truth vs every channel. The result should land in a log and raise an alert in two situations:
- Drift exceeds the threshold (e.g. difference larger than buffer + 1) — something broke in the flow.
- A channel stops responding or returns consistently wrong data — an API or rate-limit problem.
From our deliveries: while drift is discovered through customer complaints, the average detection time is days. After alerts were introduced — under an hour. That is the difference between fighting fires and running inspections. More on the reliability layer in our guide to resilient API and webhook integrations.
Implementation step by step
- Inventory channels and systems. Who actually owns stock today, who modifies it, where the manual workarounds are.
- Choose the source of truth. ERP or store warehouse — documented, not kept in someone’s head.
- Design the flow. Events, retry queue, per-product buffers, reservation on order intake.
- Reconciliation. A comparison report + alert thresholds + a person responsible for reacting.
- Edge-case testing. Cancellations after reservation, returns, discontinued products, bulk orders.
- Post-launch monitoring. Alerts, event log, periodic review of drift and API response times.
What it costs
Stock synchronisation within a hub integration: usually part of hub setup (100–1,000 PLN/mo plus implementation). A dedicated sync with queues, buffers and reconciliation: 4,000–15,000 PLN net depending on channels and systems. Maintenance: from 400 PLN net per month. For reference: a single complaint from selling an unavailable item costs you return logistics, support time and a lost customer — with a few such events per month, the integration pays back within a quarter.
Case study: stock drift eliminated in 6 weeks
In our omnichannel integration case study we describe a PrestaShop store selling on Allegro and Amazon where stock drifted between channels and the team verified every order by hand. After per-product buffers, reservation on order intake and drift alerts: selling unavailable goods dropped to zero, drift detection went from days to an hour, and order handling time fell by 40%.
To put your stock in order, see the e-commerce and API integrations service — or get in touch; the flow audit is free.
Frequently asked questions
How often should stock levels sync between channels?
Stock should flow event-driven — every change triggers updates of the other channels through a webhook or queue. On top of that, run full reconciliation hourly (high turnover) or daily (low turnover). A “every 15 minutes” schedule is a minimum, not a goal — at high turnover the stale window generates complaints.
What should we do when stock drifts between Allegro and the store?
Establish one source of truth for stock (usually the store warehouse or ERP), publish stock reduced by a buffer on Allegro, reserve items immediately on order intake and run a reconciliation report with an alert above a threshold. Also check whether anyone edits stock directly in the Allegro panel — manual edits outside the integration are the most common hidden cause of drift.
How does a stock safety buffer work?
The buffer is the number of units you subtract from the stock visible in an external channel. The store has 5 units, Allegro sees 4 — the last unit covers double-selling within the sync window. Configure per product: 1–2 units for bestsellers, 0–1 for slow movers, 0 with reservation for uniques.
Do two sales channels require stock synchronisation?
Yes — even two channels (a store plus one marketplace) need shared stock, otherwise you will eventually sell the same unit twice. With two channels a simple module or hub is usually enough; a dedicated integration starts paying off at 3+ channels or with custom logic.
How much does stock synchronisation with marketplaces cost?
- Within a hub: setup cost (part of hub implementation, 100–1,000 PLN/mo plus setup). A dedicated sync with queues, buffers and reconciliation: 4,000–15,000 PLN net depending on channels and systems. Maintenance from 400 PLN net per month.
Why do stock levels revert to old values after syncing?
Most often because two systems both consider themselves authoritative — the ERP overwrites the store, the store overwrites the ERP, and values bounce. The second cause is a missing change log: without a record of who modified stock and when, you cannot tell which system restored the old value. Fix: one source of truth plus a full audit log of stock changes.
Sources and further reading
- Case study: omnichannel sales integration — how stock drift was eliminated
- Omnichannel integration — what it is and how to implement it — the model in depth
- Duplicate orders in integrations — idempotency and queues
- Marketplace integration — channel integration models
- Wholesale and dropshipping integration — supplier stock and buffers