平台超卖背后，库存数据通常出在哪几环

平台上显示还有 40 件，订单下了十几单，仓库却发现货架上只有 25 件，剩下的订单只能取消。很多人的第一反应是“平台同步慢了”，于是反复手动改库存数，今天改，明天又超卖。其实超卖很少是单点故障，它几乎总是库存数据链条上的某一环断了。顺着这条链一环一环查，比反复调数字管用得多。

先弄清数字是怎么传到平台的

可售数量从货架走到商品页，要经过几站：

1. 货架上实际有多少件。
2. 账面（1C、Excel 或 ERP）记了多少件，减去已经预留的。
3. 平台后台显示多少件，这个数是手动改的、表格上传的，还是自动同步的。
4. 同一批货有没有同时在别的渠道卖，比如 Telegram 群、批发市场的柜台。

任何一站的数字比前一站“乐观”，就会超卖。不同平台的同步方式不一样，先弄清您用的是哪一种、多久更新一次，再往下查。

如果平台数量是靠上传库存表更新的，那么每次上传的数字只是一张“快照”：从上传的那一刻到下一次上传之间，您在别的渠道卖掉的货，平台是看不到的。快照间隔越长，超卖的窗口就越大，这一点在促销期间尤其明显。

常见的六个断点

• 退货还没上架，却已经算库存。包裹一到仓库就加回可售数量，实际上还没检验，货可能是坏的，也可能还堆在退货区。
• 编码重复。同一款商品有两个 SKU，货放在其中一个下面，另一个页面照样接单。
• 调拨没入账。发往平台仓的货，有的仓库在发出时就记入对方库存，有的等对方验收才记。在途的几天里，两边的数字都不准。
• 已拣未出的订单。货已经从货架上拿走，订单还没出库，账面上仍然显示有货。
• 线下渠道没记账。在 Telegram 里成交、在市场柜台卖掉的货，没有及时从同一份库存里扣掉。
• 组合装与单品。一个套装由三个单品组成，卖了一套，三个单品的库存没有减。

排查的顺序

不用一口气查所有商品，先抓最痛的地方：

1. 把最近一个月取消次数最多的 20 个 SKU 列出来。
2. 每个 SKU 做一行，写四列：货架实盘、账面、平台显示、在途。
3. 对着上面六个断点，给每一行标一个最可能的原因。
4. 按原因归类，同一类原因的一起处理。

假设一款蓝牙耳机，平台显示 40 件，账面也是 40 件，货架上实盘 25 件。差出来的 15 件，一查发现：9 件在 Telegram 群里卖掉了，只记在聊天里，没有登记；4 件放在退货区，还没检验；2 件属于一个套装，套装卖出时没有扣减。三个原因，三种处理方式，如果只是把平台数字手动改成 25，下周同样的情况还会再来一遍。

先加缓冲，再慢慢修

在原因全部查清之前，可以对卖得最快的 SKU 临时设置一个安全缓冲，让平台显示的数量等于可售数量减去 2 或 3 件。这是权宜之计，不是办法。它能换来几周的时间，用来把每一个断点逐个修好，缓冲量也应该随着数据变准而逐步减少。

让问题不再回来

• 退货设定明确的状态，只有“可重新上架”才增加可售数量。
• 每个 SKU 只用一个编码，有重复的要先合并。
• 调拨在发出时就开单，并在途时单独记录。
• 所有渠道的订单都要登记到同一份库存里，哪怕是在聊天里谈成的。
• 每周挑销量最大的 20 个 SKU，把货架实盘和平台数量比一次。
• 指定一个人对“平台数量与实物一致”负责。出现超卖时由他牵头查原因，而不是在客服、仓库和运营之间互相推。

超卖是库存数据质量的一个“症状”，治本要靠数据，而不是靠平台。InventoryHub 的电商 SKU 对账服务，把平台后台库存、ERP 账面和自有仓实物放进同一张表，帮您找出有超卖风险、退货未上架以及错放货位的 SKU。