Inventory synchronisation: four stock figures, one source of truth

Inventory synchronisation breaks for the same reason almost every time: two systems both believe they own the answer to how many units are available. The shop deducts a unit when the order is placed, the ERP only when the goods leave the warehouse, and a marketplace shows whatever it was told at the last data exchange. Underneath sits a second problem nobody names out loud: those systems count different things, even though the field is called “stock” in each of them. Before you pick a tool, decide which stock figure you mean.

Four different stock figures that everyone calls by one word

A warehouse holds four different numbers — physical stock, reserved stock, available stock and goods in transit — and confusing them, rather than a broken integration, is behind most overselling. Separating them is the cheapest change you can make: no new system, no new vendor.

• Physical stock is the number of units on the shelf right now. It matches your stocktake and what the warehouse operator sees. Consequence: push this figure to the shop and you sell goods already assigned to somebody else’s order.
• Reserved stock is units physically present but allocated to specific orders, dispatch documents or picking tasks. Consequence: a reservation does not reduce physical stock, so a system that cannot see reservations overstates availability until the goods are released.
• Available stock is physical stock minus reservations — the only number a customer should ever see. Consequence: if your shop, Allegro and Amazon all pull physical stock instead, each of them sells the same unit independently of the others.
• Goods in transit is units ordered from a supplier or moving between warehouses, not yet booked in on a document. Consequence: adding them to available stock turns your shop into a pre-order shop the customer was never told about — the order is accepted, the dispatch waits for the delivery.

So the question that settles most rollout arguments is this: which of those four numbers does the customer see on the product page? The same discipline — one entity, one definition, one owner — returns in every system integration project; stock is where its absence shows up fastest, because it costs you a cancelled order.

Inventory synchronisation starts with one question: which system is the source of truth

The source of truth should be the system in which the document that changes the quantity is created — in practice the ERP or a WMS, never the shop. A source of truth is the one system allowed to write a value, while the rest only read it. A WMS, the software that directs the physical work of the warehouse, usually talks to the ERP over an integration bus or an API: a picking task goes out from ERP to WMS, a completion confirmation comes back.

Operationally that means three things. Nobody edits stock by hand in the shop admin — the next update overwrites it anyway. Every correction goes in as a document in the source system. And when the shop and the ERP disagree, the default assumption is that the shop is stale.

Webhooks or scheduled polling — when is each one enough

Webhooks are needed wherever a reaction in seconds matters; scheduled polling is enough when you sell through one channel and stock does not move in single units. A webhook is a model in which the system announces a change itself, the moment it happens. Polling is the opposite: the second system asks, at a set interval, what changed since last time.

The difference is purely operational. With polling there is always a window between two cycles in which the shop sells against an out-of-date number. Sell through several channels at once — your own shop plus Allegro, Amazon, eBay, Kaufland or Empik — and that window multiplies by the number of channels, because each treats the last unit as available independently of the rest. A webhook closes the window but has its own weakness: the notification may not arrive if the receiver is unresponsive. So in practice you combine the two — notifications as changes happen, plus one full reconciliation of every stock figure a day, outside peak hours.

The transport varies — REST, SOAP, GraphQL, message queues, or SFTP file transfer in older deployments — and so does authentication. As the owner you need one answer: does the vendor support change notifications at all, or is asking on a schedule the only option. When the answer is that there is no interface at all, what remains is the ladder described in connecting a system without an API, from scheduled SFTP files down to reading stock levels off the screen. Whether to build on a ready-made automation platform or write the integration yourself is a separate decision, unpacked in the piece on choosing between Make, n8n and a custom integration.

What happens when two systems change the same record at once

The write that arrives later wins — and that is the problem, because “later” does not mean “more correct”. The classic case: a warehouse operator corrects stock after a stocktake at 14:02, the integration pushes to the shop a value it read at 14:00, and the fresh correction is undone. Nobody spots the error, because no system reported a failure — the old number simply stands.

Three rules sort this out, and they belong in the requirements before anyone writes code:

• every field has one write direction, and a write from the other side is rejected, not “merged”;
• every message carries a timestamp and its own identifier, so an older message cannot overwrite a newer one and the same message delivered twice does not change stock twice;
• where the other system allows it, send the operation (“deduct one unit”) rather than an absolute value (“set it to seven”), because an operation survives a race between two simultaneous changes.

Marketplace reservations and the safety buffer — a plaster, not architecture

A safety buffer means deliberately understating the stock shown in your sales channels, so you have time to react before the last unit is sold twice. It works, but it treats a symptom rather than a cause, and it carries a price you pay every day.

Marketplaces such as Allegro or Amazon have their own moment of blocking stock and their own delay in passing the order to your ERP. For those few minutes the unit is already sold in one channel while the others still show it as available. A buffer covers that window with a reserve instead of shortening it.

The cost is easy to work out against your own catalogue: on slow-moving lines with one or two units in stock, the reserve means part of the range never appears as available at all. A buffer is justified as a temporary measure — for the rollout period, on the fastest-moving lines, with an agreed switch-off date. If you still need it a year later, the real problem, the definition of stock or the exchange frequency, was never solved.

The sync map: one table to hand your vendor

Before anyone starts building, write out every entity on one row: what, in which direction, how often, who owns it, and what happens on conflict. Below is a typical layout for a shop selling through several channels.

You can fill that table in yourself, without a vendor, and it decides half the cost of the project — the more entities and channels, the more edge cases; the same logic drives mobile app development cost. If you would rather turn it into a document to talk from, describe your systems and sales channels and we come back with the map filled in. When sales documents join the entity list, KSeF integration for your own system — the Polish e-invoicing rules binding companies that operate in Poland — is a separate topic.

What to require from a stock integration before you sign it off

An integration with no logs, no dead letter queue and no alert to a named person is unfinished, however well it behaves on launch day. These parts decide what happens on a bad day.

• Logs you can replay an event from — what was sent, when, in which direction and with what result, retained for a period agreed up front.
• A dead letter queue is a list of messages that could not be delivered; without it a failed stock update disappears and nobody finds out.
• Retries with a growing interval and an attempt limit, so a brief outage needs no manual intervention and a permanent one does not loop forever.
• An alert to a human, sent to a specific address or channel, triggered by a threshold you set — for example stock not refreshing for an agreed length of time.
• A named process owner, not “IT”: one person who reads the alerts and may pause sales on sensitive lines.

Ask one question before you sign the contract, not after. Some older warehouse systems on the Polish market — the ones a company operating in Poland is most likely to already run — have no public, supported interface, and an integration wired straight into the database breaks at the vendor’s next update, at which point stock stops updating with no error message at all.