Putting marketplace and own-warehouse stock in one table

If you sell through a marketplace and also keep stock in your own warehouse, you probably look at three different stock figures every week: the quantity in the marketplace back office, the balance in 1C or your ERP, and whatever is physically on your shelves. They rarely agree, and each person defends the one they see. The way out is to stop comparing them in three separate files and to put them side by side under the same SKU.

Three sources, three kinds of truth

Each source answers a slightly different question:

• The marketplace back office shows what the platform believes it can sell, including stock held in the platform's own warehouse.
• The ERP or 1C balance shows what your documents say you own, wherever it is.
• The physical count shows what is really on your own shelves today.

None of them is "wrong". They differ because stock is in motion: shipments on the way to the marketplace warehouse, returns that have arrived but not been processed, orders picked but not yet booked out.

Build one table, one row per SKU

Start with the SKU and add the figures in the order stock actually travels:

• SKU and product name
• ERP book quantity (total)
• counted quantity on your own shelves
• quantity shown in the marketplace back office
• quantity in transit to the marketplace, with the shipment date
• returns received but not yet processed
• difference, and a comment column

The marketplace figures come from an export you take from the back office on the same day as the count, with the date and hour in the file name. Whether anyone from outside can enter or scan in a marketplace warehouse is up to the platform and the operator. The table works without that, because it uses the platform's own report for the part you cannot touch.

The in-transit column is the one people forget. Between leaving your warehouse and being accepted by the marketplace, a shipment can take several days. During that time the goods are neither on your shelves nor in the platform's sellable quantity; only the ERP still records them. Give them their own column and in-transit goods are never mistaken for a loss.

An example with made-up numbers

Take one SKU, Bluetooth earbuds. The ERP says 200 in total. On your own shelves the count finds 96. The marketplace back office shows 84. A shipment of 20 left for the marketplace warehouse three days ago and has not been accepted yet. In the returns corner there are 6 pairs that came back from customers and are not booked anywhere.

Add it up: 96 + 84 + 20 = 200, which matches the ERP exactly. The 6 returned pairs are physical stock the books do not know about. So the real gap is not a loss at all; it is 6 pairs that should be inspected and booked back in. Without the table, a person looking only at the shelf would see 96 against 200 and report 104 missing.

Reading the pattern

Once the columns sit side by side, the same few patterns appear again and again:

1. The back office shows more than you can really deliver. This is an oversell risk. Look for returns not yet shelved and for shipments that were booked as arrived too early.
2. Counted stock is higher than the books. Check unbooked returns, receipts entered under another SKU, and duplicate SKUs.
3. Counted stock is lower than the books. Look for shipments dispatched without a document, items in the wrong bin and goods picked for orders that were cancelled.

Whenever you identify a cause, write it down with the person responsible in the comment column. On the next comparison, check first whether the known causes have gone.

Make it a routine

A one-off comparison finds problems. A weekly one stops them. Even without a full count, you can refresh the marketplace and ERP columns every week and recount only the SKUs whose gaps are growing. Keep each week's file, and you can see whether a SKU's gap was a one-off or keeps getting larger.

InventoryHub's e-commerce SKU reconciliation puts back-office stock, ERP records and physical stock in a single table, so oversell risks, returns waiting to be shelved and SKUs sitting in the wrong bin are visible before the next promotion.