---
type: "Article"
title: "Cancelling an order due to out-of-stock items? eMAG, Trendyol and your online store"
description: "How to synchronise stock between eMAG, Trendyol and your store and avoid overselling and cancellations. Models, frequency and good practices."
resource: "https://harta.agency/en/marketplace-stock-synchronization/"
tags: ["oms", "baza-wiedzy"]
lang: "en"
status: "stable"
generated:
  by: "process:harta-okf/1.0"
  at: "2026-10-08T07:00:00+00:00"
sources:
  - resource: "https://harta.agency/en/marketplace-stock-synchronization/"
    last_modified: "2026-10-08"
stale_after: "2027-10-08"
---

# Streszczenie
How to synchronise stock between eMAG, Trendyol and your store and avoid overselling and cancellations. Models, frequency and good practices.

# Treść
**You sell the same goods in several places at once - on eMAG, on Trendyol and in your own store - but you only have one warehouse. When stock levels drift apart between channels, overselling, cancelled orders and a falling account rating follow. Synchronising stock across multichannel selling is not a luxury, it is a condition for keeping your account healthy. We show how synchronisation models work, how to choose the frequency and how to avoid conflicts before they grow into a real problem.**

### Table of contents

1. [Why do drifting stock levels hurt?](#dlaczego-boli)
2. [Stock synchronisation models](#modele)
3. [Synchronisation frequency and conflicts](#czestotliwosc)
4. [Good practices in multichannel synchronisation](#dobre-praktyki)
5. [Frequently asked questions](#faq)

## Why do drifting stock levels hurt?

Picture the last unit of a product on the shelf. A customer on eMAG sees it, a customer on Trendyol sees it and a customer in your store sees it - and any of them can buy it in the same minute. If the channels do not know about each other, you will sell one item three times over. That is **overselling**, and it is the most expensive consequence of missing synchronisation.

The consequences do not stop at one unhappy customer. Drifting stock sets off a whole cascade:

- **Cancelled orders** - if you have nothing to fulfil the sale with, you have to cancel. On a marketplace, a cancellation caused by the seller is one of the worst signals you can send the platform.
- **A falling rating and account health** - platforms track cancellation and delay rates. A high level of cancellations lowers your score, pushes your offer down in results and, in extreme cases, leads to account restrictions. How to monitor these metrics on eMAG is covered in our piece on [eMAG account rating and health](https://harta.agency/rating-i-kondycja-konta-emag/).
- **Losing the Buy Box and visibility** - an offer with a history of cancellations loses to competitors even at the same price.
- **Handling cost** - every cancellation means time spent explaining to the customer, refunding payment and risking a negative review that stays on the account for a long time.

The opposite problem is quieter but just as real. When you understate available stock on every channel out of caution, so as not to sell too much, **you lose sales** - the goods sit in the warehouse while the listing says "unavailable". Good synchronisation means finding the balance between these two scenarios: sell everything you have, but never more.

## Stock synchronisation models

Stock synchronisation always rests on the same principle: there has to be a **single source of truth** about availability from which all channels draw their numbers. What differs between models is where that source sits and how it divides available goods between channels.

### A central warehouse (single source of truth)

The cleanest model: one system - most often an OMS or an integrator - holds the current stock of every SKU and pushes it to all channels. The store and the marketplaces have no independent numbers of their own; they are only "displays" of what the central warehouse shows. If you have not implemented such a system yet, it is worth starting by understanding [what an OMS order management system is](https://harta.agency/co-to-jest-oms-order-management-system/) and what role it plays in multichannel selling.

The advantage is simple logic: there is one stock figure, so there is nothing to argue about. The challenge is speed - the figure has to reach the channels fast enough that two parallel sales do not overlap.

### Safety buffers

A buffer (stock buffer) is a deliberate reserve you do not put up for sale. If you have 10 units and set the buffer to 2, the channels see 8. Those two units are a cushion against synchronisation delays and against sales that overlap in the window between updates.

- **Percentage or unit buffer** - a fixed number of units or a percentage of stock. A percentage scales better for fast-moving products.
- **Buffer per channel** - a channel with slower synchronisation or more parallel orders can be given a bigger cushion.
- **The cost of a buffer** - the bigger the buffer, the lower the risk of overselling, but the more goods are "frozen" and not being sold. It is a conscious trade-off, not a "set and forget" configuration.

### Channel priorities and dedicated pools

When goods are scarce and channels are several, you have to decide who comes first. Two strategies apply here: **channel priority** (at low stock, goods "go" to the most important channel first) and **dedicated pools** (you split stock rigidly, for instance part for the store, part for eMAG, part for [selling on Trendyol in the Romanian market](https://harta.agency/trendyol/)). The table below compares the three approaches.ModelHow it worksWhen it fitsShared pool + bufferAll channels see the same stock minus the bufferThe default choice - maximises sales of the whole stockChannel priorityAt low stock the order of channels decidesWhen one channel is clearly more important by marginDedicated poolsStock split rigidly between channelsLimited products, contracts, guaranteed availability

In practice the shared pool with a buffer is used most often, while dedicated pools are reserved for products that simply must not run out on a particular channel.

## Synchronisation frequency and conflicts

The key question is: how quickly after a sale on one channel do the other channels learn about the new stock level? The longer that window, the greater the risk that someone buys goods you no longer have in the meantime.

There are two main update mechanisms:

- **Interval-based (polling)** - the system queries the channels every so often and pushes new stock levels. Simple and predictable, but between one cycle and the next there is a "blind window".
- **Event-based (webhook / near real time)** - the channel reports a sale the moment it happens, and the system immediately corrects stock everywhere else. This closes the blind window almost to zero, but requires a stable integration and error handling.

The real frequency depends on each platform's API limits - you cannot query it as often as you like. The specific intervals and limits differ between eMAG, Trendyol and your store platform, and they do change.

A separate topic is **write conflicts**, that is, situations where two events try to change the same stock figure at the same moment. The most common cases and how to defuse them:

- **A race between two sales** - two orders for the same goods within the synchronisation window. The fix: a safety buffer and queued updates instead of "last write wins" overwriting.
- **Manual correction versus automation** - a warehouse worker corrects the stock figure at the very moment synchronisation overwrites it. The fix: a single source of truth and a clear rule that manual changes go only through the central warehouse.
- **Returns and restocking** - goods come back and must return to the pool. The fix: automatic recognition of the return in the same system that deducts stock on sale.
- **Integration failure** - a channel has not confirmed the update. The fix: retries and an alert when stock is not confirmed after several attempts.

## Good practices in multichannel synchronisation

Stock synchronisation is not a one-off setting but a process that has to be designed and monitored. Below is the list of principles that in practice most often separate accounts without overselling from those firefighting every week.

- **One source of truth for stock** - choose a single system (an OMS or an integrator) to hold stock, and do not let any channel keep an independent number of its own.
- **Consistent SKUs and offer mapping** - the same product has to be unambiguously linked between the store, eMAG and Trendyol. Without clean SKU mapping, synchronisation updates the wrong listings.
- **A buffer matched to turnover** - larger for bestsellers with many parallel orders, smaller for slow-moving items.
- **Event-based updates wherever possible** - the closer to real time, the smaller the blind window for overselling.
- **Monitoring and alerts** - a notification when stock drops below a threshold, when synchronisation stops confirming changes or when a cancellation for lack of stock appears.
- **A queue instead of overwriting** - updates processed in order, so that two parallel changes do not cancel each other out.
- **Returns logic in the same system** - returned goods go back into the pool automatically, with no manual re-entry.

The technical layer of this puzzle is most often delivered through an integrator or a dedicated script. What such an integration looks like in practice, using a popular tool as an example, is shown in our piece on [integrating BaseLinker with eMAG](https://harta.agency/integracja-baselinker-z-emag/). Whatever tool you choose, the principle stays the same: stock is counted in one place and the channels merely reflect it.

## Frequently asked questions

### How do you synchronise stock between eMAG, Trendyol and your store?
You need a single source of truth for stock - an OMS or integrator that holds the current level of every product and pushes it to all channels. The channels then have no independent numbers of their own, they only reflect the central warehouse. On top of that you add a safety buffer and monitoring to close the window for overselling.

### What is overselling and how do you avoid it?
Overselling means selling the same goods on several channels at once, when stock has not had time to update. You avoid it with a single source of truth, a safety buffer and the fastest possible updates, ideally event-based.

### How often should stock be updated on marketplaces?
The rule is simple: as often as the given platform's API allows, aiming for close to real time. The actual frequency depends on each channel's limits and does change over time.

### Does a safety buffer not mean lost sales?
A buffer freezes part of your stock, so in theory yes - but it is a conscious trade-off. Better to sell a few units fewer than to collect cancellations that lower your account rating and push your offers down the results. A buffer is calibrated to turnover and synchronisation speed, not set once and forgotten.

### Is a WooCommerce or Shopify store enough for synchronisation?
The store is one of the channels, but it rarely makes a good central source of truth for all multichannel selling. With three channels an OMS layer or an integrator that sits above the store and the marketplaces and steers stock for all of them at once usually works better.

## Take the next step

If overselling and cancellations keep coming back, it is a sign that your stock should rest on one automated source of truth. See how we approach [OMS automation and implementation](https://harta.agency/automatyzacja-optymalizacja-i-wdrozenia-oms/), or [write to us](https://harta.agency/kontakt/) - we will analyse your set of channels and propose a synchronisation model matched to your turnover and your platforms' limits.

# Kategorie
- Automatyzacja i OMS
- Baza wiedzy

# Źródło
https://harta.agency/en/marketplace-stock-synchronization/