What a stock synchronisation project actually looks like

Most stock projects do not start with technology. They start with an email from customer service: item sold, nothing left in the warehouse. Or with a sales rep correcting a stock figure by hand for the third time that week because the ERP is running behind. It costs time, it leads to awkward conversations with customers, and it makes growth riskier than it needs to be.

Stock synchronisation is not an integration you install once and then forget. It is an agreement between systems: your webshop, ERP, WMS, point of sale, marketplaces and supplier feeds all need to agree on what can still be sold. The hard part is rarely exchanging numbers. It is deciding which system is right, when a change counts, and what happens when one of the parties briefly stops responding.

The starting point for this project

Take a wholesaler with roughly 8,000 items, selling through a B2B webshop, an inside sales team taking orders by phone, and two marketplaces. The administrative stock sits in the ERP. The warehouse runs on a WMS with handheld scanners. The webshop has its own catalogue with its own stock field. Until now, that field was updated every hour from an export file out of the ERP.

An hour sounds short enough, right up until order volumes climb. A customer buys the last unit in the webshop at 10:05, while the marketplace keeps showing five units until 11:00. A rep reserves three units over the phone, but that reservation only lands in the next export. You know the outcome: overselling, credit notes, apologetic phone calls and corrections nobody planned for.

The goal of a project like this is not for every system to hold exactly the same numbers. The ERP counts differently from the WMS, and that is fine. The goal is that every sales channel uses the same sellable stock at the moment of sale. Physical stock, reserved stock, rejected stock and expected inbound stock are different figures with different jobs. Getting that distinction clear removes half the arguments on its own.

First decide who is right

In this example the ERP owns the item data and the sellable stock that goes out to the channels. The WMS leads on everything that physically happens in the warehouse: receiving, pick confirmations, counts and corrections. Those movements flow into the ERP, which processes them and calculates sellable stock from them. The webshop and the marketplaces simply receive that figure. Orders travel the other way, from channel to ERP, so a reservation takes effect straight away.

Without that split you end up with systems overwriting each other all day. A webshop that puts stock back by itself after a failed payment sends back a number the ERP does not recognise, and the next synchronisation reverses it again. An integration needs to know not only which data it may read, but above all which data it may change.

In practice we write down at least this much:

• The ERP manages items, locations, administrative stock and the sellable stock calculation.
• The WMS reports physical movements and pick statuses, and leads on those.
• The webshop displays the sellable stock it receives and reports orders back immediately.
• Marketplaces only receive the stock that may be sold there.
• The integration layer handles translation, validation, queues and error handling.

That integration layer is not an extra link for the sake of it. It stops every platform from talking directly to every other platform. With five systems that is already ten possible connections, and when something breaks you get to guess which one it was. Route everything through one layer and a change stays manageable while a fault stays traceable.

From a stock movement to a visible number

Synchronisation works best on events rather than on the clock. Once an order is paid or confirmed, sellable stock drops. Once the warehouse approves a return, the item becomes available again. Waiting for the next scheduled export is no longer realistic for an organisation selling through several channels.

A webshop order runs like this. The customer pays and the webshop sends the order straight to the integration layer. That checks item number, location, order status and available stock. If everything lines up, a reservation goes into the ERP. The ERP recalculates sellable stock and that new figure goes back to the webshop and to the marketplaces where the item is listed. When the order is picked, the WMS confirms the physical decrease and the reservation is released.

Simple on paper. The details decide whether it still holds up on a busy Monday. A customer ordering from two browser tabs at once. A payment that fails ten minutes later after all. A partial shipment. An order somebody edits by hand in the ERP. That is why every movement carries a unique ID. If the same message arrives twice, say after a timeout and a retry, stock does not drop twice.

The calculation rule needs to be settled in advance too, and it needs one home. Usually it comes down to physical stock minus hard reservations minus safety stock. For some items a channel allocation is added on top. If you sell scarce goods through three channels, you do not want each marketplace claiming the full quantity.

Not every item follows the same rule

A standard item in a fixed location is no trouble. The exceptions are where the work is. Bundles consist of separate components. Variants sometimes share a base stock. Pre-orders can be sold, but should not show up as ready to ship. Dropship items depend on a supplier feed that arrives less often and is less reliable.

Take a gift set with a bottle, a glass and packaging. The webshop sells one item, the warehouse knows three. Available stock for the set is not a counter of its own but the minimum of its components. That calculation has to live somewhere: either the ERP provides it, or the integration layer builds it. Doing it in both places is asking for discrepancies.

There is no standard answer here. With a small assortment and calm volumes, a periodic synchronisation is perfectly fine. With high order volumes, several channels or tight stock, real time or near real time quickly becomes the sensible choice. Look mainly at what a mistake costs. One oversell that ends in an apology email is a different matter from a business order with an installation appointment or a production slot attached to it.

Errors are part of the job, silent failure is not

An API is occasionally unreachable. A token expires on a Friday afternoon. An item number exists in the webshop but not in the ERP, because somebody created it there with a hyphen. These are not disasters, this is just daily operations. The integration only has to be ready for them.

So failed messages do not get thrown away. They go into a queue and are retried according to fixed rules, with increasing intervals. If it still does not work after a few attempts, an administrator or a colleague gets an alert with the order number, the item number, the error and what needs to happen next. "Error code 500" is not something the operation can act on.

On top of that, a reconciliation runs every night. It puts the sellable stock from the ERP next to what the webshop and the marketplaces are showing. Small deviations are corrected automatically. Large or recurring differences go to a person, because they almost always point at something structural: an order status that is never reported back, a wrong mapping, or a manual step that bypasses the integration.

Test with the exceptions that really happen

You do not test a stock integration by moving one item from ten to nine. Test two orders for the same last unit, a cancellation after shipping, a return that is partly rejected, a split shipment, a stock correction during picking, a bundle, and a system that goes down for ten minutes. Put people from sales, the warehouse and customer service in the room while you do it. Within fifteen minutes they will name the cases that appear in no process diagram anywhere.

Then go live in phases. Start with one product group or one channel, watch the movements for a week, measure processing time and above all read the error messages. Only expand once it runs steadily. That way you find out in time if a technically correct integration still clashes with how your team actually works.

For day to day management, a compact dashboard earns its keep: last successful synchronisation per channel, queue length, open errors, stock differences found, and the status of the connected systems. You do not need to follow every message. You only want to know when a fault is about to cost money.

What it delivers in the end

When stock is right at the moment it matters, overselling drops. But the gain is not only there. Customer service resolves fewer exceptions, the warehouse gets instructions that hold up, and your channels show information customers dare to trust. Manual correction becomes the exception again instead of a fixed part of the day.

Technology should bend to your processes, not the other way around. LJPc builds integrations and internal tools from that reality: clear ownership, short lines of communication, and a solution that is still manageable six months after go live.

So do not start with the question of which API to connect. Start with a single order and follow it all the way through: what happens to stock from the moment the customer clicks order until the warehouse ships, cancels or takes it back? Get that story straight and the technical side turns into a lot less work.