Stock Not Updating on the Marketplace: Six Causes in Order

Stock failing to reach a marketplace is the most expensive fault in multi-channel selling. It ends in cancellations, a falling seller score and sometimes a restricted channel. The good news is that the cause is almost always one of six things, and going through them in order finds it in minutes.

The order below is not arbitrary. It runs from most to least common; start at the top. But there is one step before the list, and in most cases it halves the search.

Narrow the scope first

How many products and how many channels the problem touches almost tells you the cause on its own. Start with two questions: one product or many? One channel or all of them?

• One product, one channel: matching, or a rejection specific to that listing. Look at causes one and two.
• One product, every channel: the problem is on the product side. A stock record, a reserved quantity or a product-level rule is involved. Look at causes five and six.
• Every product, one channel: that channel's connection or permissions. Look at causes three and four.
• Every product, every channel: the stock source is not being read at all; do not go looking on the channel side.

Narrowing like this takes ten seconds and saves you from hours of searching on the wrong side.

1. The product may not be matched to a listing

If there is no target, there is no send. Matching is built through SKU and barcode. An unmatched product appears to exist in your panel but has no counterpart on the channel.

Check: what is the product's matching state, and is it bound at variant level? On an item with colours and sizes, the parent may be matched while the variants are not. Some sizes then update and others do not, which makes the picture confusing. How to build variant structure is covered in variant management and the colour-size matrix, and the keys used for matching in matching products by SKU and barcode.

Matching is not something you set once and forget. The bond can break when a listing is reopened on the channel, when a barcode is corrected, or when a product is moved to another card. That is why the list of unmatched products should stay in front of you.

2. The row sent may have been rejected

This is the most overlooked cause. The update is sent, the marketplace rejects the row, and if nothing tells you, your panel looks healthy.

Rejections usually come from: a listing that is passive or awaiting approval, a price outside the range the marketplace accepts, a barcode already bound to another listing, or an empty mandatory category attribute. Everything on the approval side is the subject of listing not approved; while a listing waits for approval, stock updates are not accepted either.

Check: what was the result of the last send? A sound setup shows not only what it sent but whether what it sent was accepted. If there is no list of rejected rows, you are simply not seeing this information, and that single gap turns every cause below into guesswork.

3. The connection may have stopped silently

An integration stopping is not loud. It raises nothing, the screen does not change, only data stops flowing. A stoppage unnoticed for three days means three days of wrong stock.

Check: when did data last arrive from this channel? Every channel's last run should be tracked, and a channel that stays quiet for a long time should raise an alert. Without one, you learn about the stoppage from a customer complaint.

To tell whether the stoppage is the channel's or yours, look at whether another channel is still flowing at the same moment. If all of them are quiet, the cause is on your side; if only one is quiet, move on to that channel's permissions.

4. Permission or access details may have lapsed

When access details are renewed on the marketplace side, or the permission scope changes, a connection can keep reading while it stops writing. Orders arrive, stock does not leave. This is the most misleading picture of all, because the integration looks like it is working.

Check: are write operations succeeding too, or is only reading working? The same picture appears when permissions on the seller account are narrowed, or when the user who created the connection is deactivated.

5. Reserved and blocked stock may not be accounted for

If 10 units show in the warehouse and 4 are allocated to pending orders, 6 should go to the channel, not 10. A setup that does not deduct reserved stock publishes inflated quantities continuously and makes cancellations inevitable.

Check: is the quantity going out raw stock, or net stock with pending orders deducted? Where the number comes from matters too: if the stock record has gone negative or count discrepancies have accumulated, the figure reaching the channel is already wrong. That is a separate subject, covered in stock counts and negative inventory errors.

6. A channel-level rule may be in force

Some setups deliberately limit what is exposed to a channel: a portion of total stock, a specific warehouse, or withdrawal below a threshold. These are rules rather than faults, but when forgotten they look exactly like faults.

Check: is there a stock rule defined for this product and this channel? Which warehouses are opened to which channel is the subject of multi-warehouse stock management. Rules changed temporarily during a sales event and never changed back are a common case, discussed in stock and pricing during sales events.

Stock goes out, but the wrong quantity goes out

This one sits outside the six and moves more quietly. The send succeeds, there are no rejected rows, the channel is flowing; only the number is wrong. It has three causes, all of them continuations of the list above: the wrong set of warehouses is exposed to the channel, reserved quantities are not deducted, or a forgotten channel rule is in force.

The symptom is recognisable: the quantity on the channel is always short of, or over, what you expect by the same amount. The gap is not random, it is a constant offset. When you see a constant offset, do not look at the connection, look at the rule.

Follow the order, do not guess

These six cover nearly every case in practice. Following the order matters: if you skip the second and jump to the fourth, you will change permissions without ever seeing the rejected-row list and believe you fixed it.

Once you find the fault, one verification remains: seeing that the corrected quantity actually reached the channel. Confirm what the channel accepted, not what you sent.

The durable fix is not hunting faults one by one but making faults visible: a list of unmatched products, a list of rejected rows, and last-run time per channel. With those three on screen, the order above presents itself. Why stock should be governed from a single pool is covered in inventory sync and overselling, and how to be warned before you run out in low stock alerts and days of cover.

In Bulutegra the single stock pool is read from the ERP and sent to the connected channels; the system health screen shows the status of every send, listing rejected rows with their reason. Unmatched items and those with missing barcodes are gathered in the quality tab, channel monitoring runs continuously, and a channel that goes quiet raises an alert. The whole panel is described on the Why Bulutegra? page, or you can request a demo.