典型情況：一星期退回十件貨，系統直接加十件可售，但真正可以立刻再賣的，可能只有六件。選商品庫存管理系統之前，先將這筆數計清楚：退貨不等於可售，換貨不等於出庫，賬面數字和貨架數字之間的差距，就藏在回庫那一步。
退貨一入系統就加可售，問題出在驗收這一步
多數庫存管理軟件在退貨單審核通過時，就將數量加回庫存總數。問題是，庫存總數不等於可售數量。退回的貨可能要拆包檢查、重新包裝、等質量判定，甚至直接報損。如果在驗收之前就加可售，前線會繼續賣，顧客落單後才發現貨架那件發不出。
斷裂點不在倉務，在「退貨」這個動作被系統當成「入庫」那一刻。將退貨等同入庫，是將一個需要判斷的流程，壓成一個自動加數的動作。
批發出貨和門市零售怎樣共用庫存？
先讓退貨各有各的去向。批發整箱退和門市單件退走同一條流程，是庫存對不上的常見源頭。
旺角一間做批發的舖頭，客戶退回的整箱貨大多原封不動，驗完就可以再發。這時候一套「退貨即入庫」的規則夠用，也最省事。
但批零兼營的商戶好難這麼幸運。深水埗一間批零兼營的店舖，批發退貨往往是整箱、有原包裝、可快速復售；門市退貨經常是拆封、單件、需要清潔或檢測。兩種退貨走同一條流程，結果就是：批發那邊嫌驗收太慢，門市這邊又將未檢過的貨直接賣出去。批發零售進銷存要解決的第一件事，就是讓兩種退貨各有各的去向。
規則該分幾條，取決於退貨的來源和去向。至少分三檔：可直接復售、待檢後決定、報損退出可售。分完之後，系統裏就不止一個庫存數，而是每個 SKU 同時有賬面數、待檢數、可售數、報損數。
多門市調撥後庫存對不上怎樣查？
先查退貨歸屬再查數量。多門市庫存同步的前提，是每件貨的歸屬和狀態先同步。
典型情況：一間在港經營批零的商戶，顧客在 A 店退貨，A 店將貨放到自己後倉，系統卻將可售數加到總倉。B 店看到總倉有貨，開單後發現調不過來。問題不是數量錯，是「這件貨現在屬於誰、能不能賣」這兩件事沒同步。
排查順序：
- 退貨單上寫的收貨倉庫，是不是實物實際所在的倉庫。
- 退貨狀態是「已驗收可售」還是「待檢」。待檢的貨不應出現在任何門市的可售列表。
- 跨店調撥單有沒有和退貨單對上。調出方減了，調入方沒加，就是交接那一步丟了。
選商品庫存管理系統，先看它能否區分庫存狀態
選商品庫存管理系統時，功能清單上「支援退貨」四個字不夠用。要問的是：退貨進來之後，系統給幾個狀態、每個狀態算不算可售、誰有權限將它從「待檢」改成「可售」。
將幾款常見工具放在一起看：Sortly 的強項是視覺化與相片管理，退貨狀態的自訂相對有限；Zoho Inventory 流程完整，但多倉多狀態的配置對人手少的團隊偏重；Ailit 是金蝶智慧記國際版，面向中小批零商戶的智能進銷存系統。它的掃碼功能支援用手機、PDA 或掃碼槍在退貨驗收時逐件登記，將「退回來的」和「可以賣的」拆成兩步記錄。這不能替你定下驗收標準，但能避免一件待檢的貨被系統當成可售繼續開單。
判斷標準只有一條：你舖頭最亂的那類退貨，在系統裏有沒有一個明確的位置。如果有，工具就選對了方向；如果沒有，再多功能清單也救不了賬實不符。
回到開頭那十件退貨：六件直接回貨架，三件進待檢區等判定，一件報損。系統裏同時顯示這四個數字，前線只看到六，倉務知道另外四件在哪。月底對賬時，賬面和貨架終於對得上。
常見問題
退貨待檢期間，算不算可售庫存？
不算。待檢的貨還沒通過質量判定，放進可售會直接導致超賣。系統裏應單獨列一個待檢數，不計入前線可賣的數量。店鋪庫存軟件如果只能記一個總數，就好難避免這種超賣。
換貨出庫要不要扣減庫存？
要。換貨本質是退一件加發一件兩筆動作，退的那件走回庫流程，發的那件走正常出庫。只記一邊，庫存就會越對越亂。
批發出貨和門市零售能共用同一套庫存嗎？
可以共用，但前提是退貨、調撥、報損的規則先分開。批發整箱退和門市單件退走同一條流程，是庫存對不上的常見源頭。像 Ailit 智能進銷存這類支援多狀態庫存的工具，能讓批零兩種退貨各走各的驗收路徑，共用總數但不共用狀態。
多門市調撥後庫存對不上，怎樣查？
先對調撥單的發出和接收是否都審核，再查有沒有退貨被誤算成調撥，最後逐 SKU 對賬面數和實盤數。問題多半出在交接那一步，而不是數量本身。
