Overselling rarely comes from a missing integration - most often it comes from two systems both believing they own the truth about stock. Inventory sync means picking one place where the unit count is true, and making sure every other system - the store, Allegro (Poland’s biggest marketplace), the wholesaler, the warehouse software - only reads it and never overwrites it. When that setup is right, a sold unit disappears from every channel within a minute. When it is wrong, once a week you call a customer to say the item is not actually there.
Below I lay out the decisions in order: who should hold the stock figure, how often to push it out, where the usual traps sit, and how to check whether your sync works before a customer checks it for you.
What “inventory sync” actually means
Inventory sync is the automatic movement of information about available units between systems that sell or store goods. It consists of two separate streams:
- Stock going down - from the warehouse to the sales channels. When 3 units are left in the warehouse, the store and Allegro should both show 3, not 7.
- Reservations going up - from the channels to the warehouse. When somebody buys in the store, the warehouse has to find out before somebody else buys the same thing on the marketplace.
Most of the failures I fix are not a missing first stream, but a delayed second one: the store pulls stock every hour, but marketplace orders only land in the warehouse in the evening - and all day long you are selling goods that are already gone.
One source of truth - the only decision that really matters
The source of truth is the system whose number is binding and that nobody else overwrites. There must be exactly one. Three setups make sense:
| Setup | Who holds the real stock figure | Who it suits | Main risk |
|---|---|---|---|
| The store as the hub | WooCommerce | One sales channel, own warehouse, up to a few hundred SKUs | Adding a marketplace means rebuilding this |
| An integrator as the hub | BaseLinker (a Polish multichannel order and stock integrator) or similar | Store plus marketplaces, shipping from your own warehouse | Vendor dependency, cost grows with order volume |
| ERP or WMS as the hub | Subiekt, Comarch, enova (Polish ERP systems), a warehouse system | A warehouse with procedures, several staff, production or kitting | Longer and more expensive rollout, needs a solid middle layer |
The recommendation I give most often: if you sell in several channels and keep the warehouse yourself, let the integrator be the source of truth. If you already run a warehouse and accounting system that goods-in and goods-out staff work in every day, that system wins, and the integrator is only a translator between it and the channels (how to wire an ERP to a store).
What never to do: two-way stock sync between systems that can both change it. That is not an integration, it is a lottery - when changes collide, the one saved later wins, not the one that is true.
Where overselling really comes from
Overselling means selling a unit that physically does not exist. The causes, most frequent first:
- Sync running too rarely - pushing stock once an hour on a product that moves several units a day is an invitation to a collision during a promotion
- No reservation at order placement - stock only drops once the order is paid or packed, and in the meantime the item still shows as available
- Marketplace orders pulled late - the classic symptom of a situation where BaseLinker is not pulling orders on time
- SKU drift - the same product has one code in the store, another at the wholesaler and another on Allegro, so the sync hits thin air
- Manual corrections in the store admin - somebody “fixes” a stock figure, the integrator overwrites it on the next run, and the warehouse worker is convinced the job is done
- Returns and cancellations - goods go back into stock automatically, even though the item is sitting damaged in a box in the back room
- Wholesaler stock treated as certain - a file six hours old is not a stock level, it is a forecast
Point 4 looks harmless and is often the most expensive. Before any integration starts, you clean up the codes: one product, one SKU, identical everywhere - on big catalogues usually alongside a proper product import and export.
Bundles, variants and assembled products
A bundle is a product with no stock of its own - its availability follows from the stock of its components. This is where most stores fall over, because by default a bundle is treated like any other item with its own counter. Set up correctly, it works like this:
- bundle availability = the largest number of complete sets you can assemble from the components
- selling a bundle deducts stock from each component separately
- selling a component on its own lowers bundle availability in every channel
Variants (size, colour, capacity) have the same problem on a smaller scale: stock has to sit on the variant, not on the parent product. If variants only change the price while stock sits on the parent, the sync will never add up.
How often to sync and what buffer to set
There is no single right frequency - it all depends on turnover. The ranges that work in practice:
| Situation | Sensible frequency | Safety buffer |
|---|---|---|
| Unique item, one unit | Immediately, event-driven | None, but reserve at order placement |
| Fast-moving, many channels | Event-driven plus a control run every fifteen minutes or so | 1-2 units per SKU |
| Slow-moving, own warehouse | Hourly is enough | Usually unnecessary |
| Wholesaler stock or dropshipping | As often as the wholesaler refreshes the file | Hide items below a threshold, e.g. 2-3 units |
A safety buffer is an artificially lowered stock figure: you have 5, you show 3. It costs a little sales, but it saves you from cancelling an order on Allegro, and there a seller-fault cancellation hurts twice - once through the customer, once through your account rating (marketplace quality metrics change from time to time, so it is worth reviewing them periodically).
Somebody else’s warehouse - dropshipping, WMS and fulfilment
With dropshipping you do not have stock, you have information about somebody else’s stock. Buffers then have to be bigger, products running down to zero should drop out of the offer instead of showing as “available to order”, and the age of the supplier’s file has to be counted honestly: with fast turnover the risk of overselling is always there, technology only reduces it. Pulling and mapping the data itself I described in the piece on XML product imports from wholesalers.
An external warehouse (fulfilment) or your own WMS works the same way - a system that knows not only how many units you have but where they sit. The warehouse becomes the source of truth, and your systems only receive its messages, including shipping confirmations and tracking numbers flowing back to the channels.
Rollout step by step
- Decide the source of truth and write it down in one sentence, e.g. “the integrator holds stock, the store only displays it”
- Clean up SKUs - one code per product and variant, identical across every system
- Turn on stock at variant level, not on parent products
- Set reservation at order placement, not at payment, plus an automatic release after a set time for unpaid orders
- Map out bundles and their components before you switch the sync on
- Set frequency and buffers per the table above, separately for turnover groups
- Block manual stock editing outside the source of truth - that is the only way the rule survives contact with a team
- Launch on one category, watch it for a day, and only then switch on the rest of the catalogue
Step 8 is non-negotiable. A sync switched on across the whole catalogue at once can zero out your entire offer in minutes if the SKU mapping has a hole in it.
How to check whether your sync really works
The test takes fifteen minutes and you can run it yourself:
- Pick a product available in every channel and note the stock figure in each of them
- Place a test order in the store and watch the clock: how long before the figure drops on Allegro
- Do the same in the other direction - an order from the marketplace, then check the store and the warehouse
- Cancel the test order and check whether the unit came back into stock everywhere
- Change a stock figure manually in the store and check whether the integrator overwrites it (it should, if it is the source of truth)
If any of these tests gives you a “no idea”, you do not have a sync, you have a habit. It is also worth switching on an alert for stock dropping below zero - that is the first sign of a leak, before a customer spots it.
How I approach this with clients
I start with a free diagnosis: I look at the catalogue, the channels, the current integrations and the path an order takes from click to warehouse release. Usually an hour is enough to see whether fixing settings and mapping will do, or whether a middle layer has to be written because the systems refuse to talk to each other directly. For bigger work - a custom WooCommerce module, an integration with a warehouse system, or rebuilding the bundle logic - you get a written quote before the start; projects like this usually land in the 5,000-10,000 PLN net range (Polish market rates). Keeping an eye on the whole setup afterwards can go into ongoing support, because integrations do not break on launch day, they break on the third API update.
Frequently asked questions
Does BaseLinker keep stock levels in order on its own? Yes, but only when it is the sole system changing them. It pushes stock to the store and the marketplaces and deducts units on orders, but it will not fix SKU drift or manual corrections made in the store. Setting it as the source of truth and blocking editing elsewhere is the condition for this to work.
Why do stock levels in my store differ from Allegro? The most common reasons are marketplace orders being pulled late, different product codes in the two places, or no reservation at order placement. Start by comparing SKUs for a few products that are drifting apart. If the codes match, the problem is in the frequency or the direction of the sync.
Can WooCommerce be connected to a warehouse system without an integrator? It can, through a direct integration with the warehouse system’s API, and the monthly running cost is often lower. It makes sense with one sales channel and a stable system on the other side. With several marketplaces, an off-the-shelf integrator usually wins, because it absorbs the API changes in each of them.
How long does an inventory sync rollout take? With a tidy catalogue and standard systems it is usually a few working days including testing. The time goes not into the technology but into sorting out codes and mapping bundles - with a neglected catalogue that stage takes longer than connecting the systems.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.