The scenario is always the same. An order arrives on Saturday evening through the online store. The customer pays, gets a confirmation, waits. On Monday morning someone opens the web orders and finds the item was sold in the shop on Friday afternoon. Now you have to call, apologise, refund.
It is not the shop assistant's fault; they did their job. It is not the customer's fault. It comes from a structural situation: two systems each keep their own count of the same physical stock, and nothing links them.
As long as that holds, overselling is not an incident. It is a mathematical consequence, and it will happen again with every spike in traffic.
The principle: a single source of truth
The founding rule fits in one sentence: stock is owned by one system, and every channel reads from it.
That system is the management system, not the store. This is not a technical preference but a logical one: physical stock moves in the shop, in the warehouse, at goods-in, on returns and during counts. The online store only sees a fraction of those movements. It is a sales channel, not a stock ledger.
┌──────────────────┐
│ G-stock stock │ ← single source of truth
└────────┬─────────┘
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Online store Shop Marketplace
Once that decision is made, every other one becomes easy. Until it is made, no technical setting will fix the problem.
What flows, and in which direction
An e-commerce synchronisation is not one stream. It is four distinct flows, with different directions and frequencies.
| Data | Direction | Frequency |
|---|---|---|
| Product records and prices | Management → Store | On every change |
| Available quantities | Management → Store | Real time |
| Orders | Store → Management | Real time |
| Shipping status | Management → Store | On every change |
The two middle rows tolerate no delay. The other two can wait a few minutes with no consequence. Making that distinction avoids over-engineering the whole thing: you spend effort where lag is expensive.
Stopping overselling for good
Three mechanisms, deployed together. On its own, each one lets cases slip through.
Reserved stock. As soon as a web order is recorded, the quantity is reserved in the management system — before picking even starts. Without reservation, the same unit stays sellable for the whole processing window.
Buffer stock. You do not publish the full quantity online. On a reference with three units left, you show two. The buffer absorbs stock variances, breakage and simultaneous in-store sales. Set it per product family: high on items that sell fast in store, zero on online-only references.
Event-driven synchronisation. Every stock movement pushes the new quantity to the store immediately, instead of waiting for the next cycle. Syncing every fifteen minutes leaves a fifteen-minute window in which two customers can buy the same last unit.
Decisions to make before plugging anything in
Settle these four points before installing the connector. Discovering them in production is expensive.
The shared identifier. Every product must carry the same unique reference on both sides. It is the key that ties the two catalogues together. A web catalogue built with free-form references will have to be reworked line by line — almost always the heaviest task in the project.
Who owns the price. If price comes from the management system, any change made in the store admin will be overwritten on the next cycle. Say this clearly to the web team, or expect long misunderstandings.
How web discounts and promotions are handled. Should a promotion created on the store side flow back into management so margin stays accurate? Usually yes, and it is rarely planned for at the start.
Multi-warehouse selling. If you hold stock in several places, which one serves the store? A dedicated warehouse, the sum of all, or a subset? Publishing the sum of all warehouses without fast transfer capability produces delivery times you cannot honour.
A rollout that does not break anything
- Clean the catalogue. Unique references, duplicates removed, consistent units. This step is not optional: synchronisation propagates a dirty catalogue faster than a team can fix it.
- Align both catalogues on the shared identifier and check for orphans on each side.
- Connect read-only. The system pulls web orders but does not yet push stock. Compare for a week.
- Enable the stock flow on one product family, not the whole catalogue.
- Extend gradually, watching variances after each extension.
- Lower the buffers once confidence is established.
Step 3 is the one people skip out of impatience, and it is the one that exposes catalogue inconsistencies at zero cost.
Warning signals to watch
Three indicators, checked weekly for the first two months: the number of web orders cancelled for unavailability, the gap between quantity shown online and real stock, and the delay between an order and its arrival in the management system.
If the first does not fall, the buffer is too small or the sync too slow. If the second grows, a stock movement is escaping the system — usually returns or breakage, rarely recorded in real time.
Where the software fits
A good synchronisation goes unnoticed. You measure it by the fact that nobody, on Monday morning, opens a file to check what was sold where.
G-stock holds the reference stock and publishes it to WooCommerce, Shopify and Magento, with reservation on order, a buffer configurable per family, real-time order retrieval and shipping status sent back. The same flows are reachable through the API for a custom platform.