Every business selling online eventually oversells something. The customer pays, the confirmation goes out, and then somebody discovers the last one went out of the trade counter an hour earlier.

That is a stock integration problem, and it has a specific structure.

Decide which system holds the truth

This is the whole thing, and it is a business decision rather than a technical one.

If your shop keeps its own stock count and your warehouse system keeps another, they will disagree. Not might — will. Goods are received, damaged, returned, counted and sold in person, and each event updates one system and not the other.

Nominate one system as authoritative. Usually the one closest to the physical stock: a warehouse or inventory system if you have one, the accounting system if it manages stock, the shop only if the shop is the only channel.

Everything else reads from it and never writes its own figure.

Two systems that both believe they own the stock number will diverge. There is no synchronisation clever enough to fix an ownership problem.

The four events that must flow

Stock level changes, downwards

When an order is placed online, the master system must know. When an item is sold at the counter, the shop must know.

Speed matters in proportion to how thin your stock is. One of an item and three sales channels needs near-immediate updates. Two hundred of an item can wait ten minutes.

Stock level changes, upwards

Deliveries received, returns restocked, stock counts corrected. These usually happen in the master system and must reach the shop, or you will fail to sell things you actually have — the quieter and more expensive failure.

Orders into fulfilment

A paid order needs to reach whoever picks it, with everything required: items, quantities, delivery address, service level, and any notes. If somebody is retyping orders into a warehouse system, that is both a cost and a source of errors.

Dispatch back to the customer

When it ships, the shop needs to know so the order status updates and a tracking email goes out. Missing this generates the single most common customer service enquiry.

Reservation, and the race for the last item

Two customers, one item left, both in checkout. Whoever's payment completes first should get it, and the other must be told before they pay.

The workable approach is a reservation held while the customer is in checkout, released automatically if payment fails or the session expires. It is not perfect and it prevents most double-sales.

Decide too what happens when you do oversell, because occasionally you will. Contact the customer quickly, offer a genuine choice, and be honest. Customers forgive an error handled well and remember one handled badly.

Where multi-channel gets hard

Selling on your own site plus a marketplace plus a physical shop multiplies the problem. Each channel wants its own stock figure and each updates at a different speed.

Two practical measures help:

Buffer stock. Publish slightly fewer than you hold, so a synchronisation lag does not cause an oversell. It costs you a little availability and it prevents cancellations.

Channel allocation. For scarce lines, reserve quantities per channel rather than exposing the same units everywhere.

What a robust integration includes

The difference between one that works and one that causes constant reconciliation is entirely in the failure handling:

  • Retries. Network failures are routine, and a failed update must be retried rather than lost.
  • A queue for what could not be processed. An order referencing a product code the warehouse does not recognise goes somewhere a person will see it.
  • Alerts. If synchronisation has been failing for six hours, somebody needs to know before customers do.
  • Repeat protection. The same dispatch notification arriving twice must not decrement stock twice.
  • A reconciliation report. A daily comparison of the two systems, flagging differences. This catches the slow drift nothing else will.

These are described more generally in how systems talk to each other, and they are what you are actually paying for.

Getting the product data right first

Integration fails on data more often than on code. Before connecting anything:

Ensure every product has a single consistent code used in both systems. Duplicated or inconsistent codes are the most common cause of integration failure, and they are much cheaper to fix beforehand.

Agree how variants map. A shop's size and colour combinations must correspond to distinct warehouse codes.

Decide how bundles and kits are handled, because a bundle sold online may need to decrement three separate stock lines.

When not to integrate

If you dispatch ten orders a week from a small stockroom, a person updating figures is cheaper and more reliable than an integration nobody maintains. Integration earns its cost through volume, multiple channels or thin stock — the argument in when not to automate.

Our integration team connects shops to stock and accounting systems for UK businesses, with reconciliation reporting included. Start a conversation.