Inventory Sync: How to Stop Overselling Across Channels

Inventory sync means the real quantity in your warehouse appears on every channel you sell on, at the same time and with the same value. When a unit sells on Amazon, the stock on eBay, Etsy, Walmart and your own store drops by one immediately. When that flow breaks, you get overselling: you sell a unit you no longer have, cancel the order, and your seller metrics take the hit. This article explains how overselling happens, which delays cause it, and how a single stock pool solves it.

How overselling actually happens

A scene every multi-channel seller recognizes: Friday evening, one pair of shoes left in size 38. At 9:40 pm an order comes in from Amazon. The warehouse lead will arrive in the morning, open the Amazon portal and zero the stock elsewhere. But at 10:15 pm an eBay order lands for the same size. Saturday morning: two orders, one product.

The result is a cancellation for one customer, a higher cancellation rate on one channel, and probably a negative review. Whatever the product costs, this is where the bill is paid. Marketplaces use cancellation rate as a seller performance metric; past a threshold, visibility drops and some promotions close. Thresholds change, so check each marketplace's current seller agreement.

Overselling has one precondition: a gap between a sale on one channel and its reflection on the others. If that gap is hours (manual updates), risk is high. Minutes, lower. Seconds, and it practically disappears.

Where the delay comes from

Four sources show up most often:

• Manual updates: logging into each portal to correct stock. Fails outside working hours and on busy days.
• Scheduled XML reads: the marketplace or integrator reads your feed at intervals. The longer the interval, the wider the gap. See XML integration.
• Separate stock per channel: splitting 10 units into five channels, two each. One channel sells out while another sits on units, so you lose sales; merging them back by hand causes overselling.
• Two systems writing the same field: if the old integrator and the new one both push stock to a channel, nobody knows who had the last word.

At Bulutegra the fourth problem is solved by the ownership flag. For every product × channel pair there is exactly one answer to "does Bulutegra manage this channel, or an external system?" If Bulutegra does not own it, it does not write there, so two systems never collide during a transition.

What a single stock pool is

A single stock pool keeps the real quantity in one place, and every channel reads that value. There is no per-channel stock; there is a pool, and every channel sees all of it.

The flow:

1. The master source (ERP, storefront or XML feed) provides the current quantity, say 10.
2. All channels receive 10.
3. One sells on Amazon. The order reaches Bulutegra; the pool becomes 9.
4. eBay, Etsy, Walmart and your store receive 9, within seconds.
5. The order is written to the ERP with customer, line items, carrier and payment details; the ERP sees 9 as well.

If you want to hold back a share for one channel (say, the last 2 units for your own store), you put a rule on top of the pool. The principle does not change: there is one true stock.

Splitting stock per channel does not prevent overselling; it only increases lost sales. What prevents overselling is how fast a sale reaches the other channels.

Which system is the master depends on the business. If you run Shopify or WooCommerce, the catalog comes from there; if you run SAP, Logo, Mikro or Nebim V3, the ERP has the last word on stock. With several warehouses, the pool can be managed per location; see multi-warehouse stock management.

What changes on sale days

On big promotion days order velocity multiplies. Even a one-minute delay matters. Two common situations:

• Three channels order the same product in the same minute. The pool processes each order in sequence; once it hits zero, the remaining channels get zero. Manual management has no such ordering.
• A marketplace API slows down or stops responding. Bulutegra monitors channel connections continuously; a channel that goes quiet raises an alert and a notification on your phone. You learn "that channel has not accepted stock for two hours" now, not in the evening.

For pre-sale preparation, see stock and price management during campaigns.

Stock on returns and cancellations

A mistake discussed less than overselling but just as common lives in the returns flow. If you add a unit back to stock the moment a return request is opened, it can be sold before it reaches the warehouse, or while it arrives damaged. The correct order:

1. A return request is opened; stock is untouched.
2. The item arrives, is scanned by barcode and accepted.
3. The accepted quantity is added to the pool; all channels get the new value.

Bulutegra's customer returns portal (login by e-mail and order code) and barcode-based warehouse receiving keep this order. On a cancellation, the unit never left the warehouse, so it returns to the pool instantly. Details in marketplace returns management.

Checklist before switching sync on

Completing this list before enabling stock sync prevents most first-week errors:

• Does every product have a barcode? Missing barcodes match wrongly, and one product's stock is written to another. See matching products by SKU and barcode.
• Is there one master source? If both the ERP and the store produce stock, is it written down which one wins?
• Is the old integrator still writing? Has it been switched off per channel?
• Are ownership flags set? Which channels does Bulutegra not manage?
• Is the shadow mode period agreed? The system reads only for one to two weeks and shows the stock it would write; you compare against a warehouse count. See shadow mode integration testing.
• Which channel gets write access first? Least risky first, then the others.
• What is the low-stock threshold? Set it per product if you want alerts on the last few units. See low stock and days of stock.

How it works with Bulutegra

At Bulutegra the single stock pool is the default. The master catalog comes from Shopify, WooCommerce, ikas, Ticimax, T-Soft, İdeasoft or XML; orders arrive from Amazon, eBay, Etsy, Walmart, Trendyol and more than 24 marketplaces; every order updates the pool and the remaining quantity is written everywhere. Orders pass to Nebim V3, Logo, Mikro or SAP automatically. Ownership flags, shadow mode and channel-by-channel handover keep two systems from colliding during the transition. Low-stock alerts and the days-of-stock report sit in the same Integration Panel, and channel monitoring runs continuously. See Why Bulutegra? for the full setup.

To see the stock flow with your own catalog, request a demo.