When you sell the same goods across several shops, each admin keeps its own count and never learns about a sale in the other. There are three fixes: split the stock permanently between shops (simple, but you sell less), reconcile counts through a system that sits above them (most reliable), or hold a buffer and sort out differences by hand (works up to a few dozen orders a month). What matters most is whether reconciliation runs in real time or in batches — batch transfer leaves a window in which you can sell something that is already gone.
Why counts drift apart at all
Each shop is a separate system with its own database. When a customer buys a unit on the Slovak domain, the Czech admin does not know — unless something tells it. With one domain there is nothing to solve. With the second domain the first discrepancy appears; with the fourth it is a daily matter.
The discrepancy does not show up immediately. It shows up when a customer orders the last unit on a domain that never learned it was sold — which is the moment you have to write and cancel their order. That is the most expensive point in the whole chain: you paid for the visit and the conversion, and instead of revenue you have an unhappy customer.
Option 1: split the stock permanently
The simplest fix. Out of a hundred units you allocate forty to the Slovak domain, thirty to Czech, twenty to Polish and ten to international. Each shop has its own stock and they never collide.
The downside is obvious: when the Slovak allocation sells out while the Polish one sits idle, you lose Slovak sales even though you have the goods. For slow-moving stock that is acceptable. For seasonal or fast-moving stock it means a real loss.
Option 2: a system above the shops that reconciles counts
A system sits above your shops and holds one true count. A sale anywhere reduces availability everywhere, so the goods can be offered in full quantity on every domain at once.
Two things matter here, and they are worth asking about before price: how fast a change propagates, and what happens when a connection drops. Batch transfer — say every fifteen minutes — leaves a window in which you can sell what is already gone. Transfer triggered by a shop event (a webhook) all but closes that window.
The second thing is movement origin. A system that records only "count went from 40 to 39" will not help you when a discrepancy appears. One that records "−1 sale on the CZ domain, order #4718" lets you trace it in a minute.
Option 3: a buffer and manual checking
You hold a buffer — never releasing the last three units for sale, for example — and handle differences by hand. This works at dozens of orders a month with zero tooling cost.
It stops working when the manual checking takes more time than a tool costs. You can work out the threshold: minutes a day spent checking counts, multiplied by your hourly rate.
What to ask when choosing a tool
- Does a change propagate immediately (webhook) or in batches? If batches, how often?
- Is the ORIGIN of each movement recorded, or only the new value?
- What happens when the connection to one shop drops — does everything stop, or just that one?
- Can you set a buffer that is never released for sale?
- Can you see which products drift the most — that is, where the real problem is?
- Does it handle product variants, or only the parent product?
How MitoOps handles it
MitoOps holds one count for all connected shops and updates it from shop events, not from a nightly import. Movement history records the origin of every change — a sale, a manual edit, or automatic reconciliation between shops — so a discrepancy can be traced after the fact.
Shoptet and WooCommerce are connected; Shopify and PrestaShop are in progress. The stock reconciliation module runs in production across four shops in four countries.