# 店舗の長期滞留在庫の実務ガイド｜型番・台数・状態を棚卸しして査定可能なリストにする

店舗のバックヤードに長く残るスマートフォン、タブレット、PCは、「売れなかった在庫」だけではありません。返品、修理待ち、委託品、取り置き、データ未消去、電池異常、別店舗在庫が混ざっていることがあります。合計台数だけを査定先へ渡すと、所有権、品質、売却可能数が不明で低い条件になりやすくなります。

滞留在庫の改善は、一括値下げから始めません。現物を一台ずつ識別し、所有、状態、データ、安全、取得・入庫・最終確認日をそろえ、販売可能、修理、業者売却、部品、適正処理へ分けます。本稿では、店舗責任者、在庫、経理、情報システム、買取担当が30日で査定可能なリストを作る方法を整理します。

最初に「滞留」の基準を決める

単に入庫から90日で滞留とすると、季節品、修理待ち、予約品を混ぜます。複数の時間を分けます。

  • •received_at：店舗・倉庫へ到着した日
  • •available_at：販売可能になった日
  • •last_inspected_at：最後に状態確認した日
  • •last_price_changed_at：最後の価格更新日
  • •reserved_until：取り置き期限
  • •return_due_at：委託・リース等の返却期限

販売可能になってから30・60・90・180日などの帯を作り、カテゴリ・価格帯に応じ基準を調整します。データ・安全・修理保留の時間を「販売滞留」として担当者評価へ混ぜません。

棚卸し前に所有と処分権限を確認する

現物が店舗にあっても、自社所有とは限りません。委託販売、返品受付、修理預かり、下取り取消、他店舗移動中、リース品を区別します。

確認項目は次です。

  • •ownership_type・owner_organization
  • •仕入・委託・預かり・返品の根拠
  • •契約・注文・買取番号
  • •売却・値下げ・移動できる権限
  • •返却・保管・通知期限
  • •担当部門・承認者

不明品を自社在庫として売却せず、識別保留へ置きます。帳簿上の取得原価だけで所有権を断定せず、契約・受渡し証拠を確認します。

現物を一台ずつ識別する

SKU在庫数だけでは、同じ型番内の品質・ロック・修理差を追えません。内部asset_idを付け、メーカー番号と結びます。

  • •asset_id
  • •serial・IMEI等
  • •メーカー・製品・モデル番号
  • •容量・色・地域仕様
  • •SIM・通信・ロック
  • •店舗・棚・箱
  • •取得元・案件

ラベルが読めない端末には仮IDを付け、判明後も仮履歴を残します。同じ番号の重複、別端末への貼替え、一覧だけにある端末を差異として止めます。

帳簿・システム・現物の三点を照合する

POS、在庫管理、会計、修理台帳、現物の数が一致するかを確認します。一覧を現物数へ上書きして一致させず、差の発生区間を調べます。

差異区分は次です。

  • •現物あり・システムなし
  • •システムあり・現物なし
  • •型番・容量・色・個体番号違い
  • •店舗・棚・状態の違い
  • •二重登録・二重計上
  • •委託・預かり・返品の誤分類

差異には責任者、期限、証拠、解決コードを持たせます。金額調整だけで原因を閉じません。

データ・アカウント・安全を販売評価より先に確認する

電源が入り外観が良くても、データ残存、アカウント、MDM、膨張、発熱があれば通常販売へ進めません。

個人情報保護委員会のデータの消去に関する注意喚起を参照し、消去方式、対象ID、成否、実行者、証明を結びます。初期設定画面だけで完了にしません。

状態を次へ分けます。

  • •DATA_HOLD：消去・アカウント・管理未確認
  • •SAFETY_HOLD：膨張・発熱・焼損・浸水等
  • •IDENTITY_HOLD：所有・個体不一致
  • •INSPECTION_PENDING：通常検査待ち
  • •SALEABLE：販売条件を承認済み

停止解除には再検査、根拠、承認者を必要にします。安全隔離品を値下げ・現状品として通常棚へ戻しません。

品質を一文字ではなく査定項目へ分ける

A・B・Cだけでは、査定先の基準へ変換できません。元の観測事実を記録します。

  • •画面・フレーム・背面・カメラ
  • •電源・充電・通信・音・カメラ
  • •生体認証・センサー・ボタン
  • •電池容量・回数・発熱
  • •修理・交換部品・非純正部品
  • •水濡れ・焼損・変形
  • •付属品・箱・保証
  • •未確認項目と理由

写真は固定方向、照明、背景、距離で撮り、asset_idへ結びます。汚れと傷を分け、清掃前後を記録します。

SKUマスターと表記ゆれを整える

同じ端末が「Phone 14 128」「Phone14/128GB」「A2881」と別SKUなら、在庫・相場・査定が分かれます。

製品マスターには次を持たせます。

  • •canonical_product_id
  • •ブランド・正式名称
  • •モデル番号・地域仕様
  • •容量・メモリ・色
  • •発売時期・カテゴリ
  • •別名・旧SKU・バーコード
  • •適合する付属品・部品

不明な表記を最も似た機種へ自動確定せず、候補と確信度を出し、人が型番を確認します。価格差の大きい容量・地域仕様を名称だけで統合しません。

滞留原因を在庫ごとに分類する

「売れない」でまとめず、原因コードを付けます。

  • •PRICE：市場・競合に対し価格が高い
  • •DISCOVERY：画像・名称・カテゴリ・検索の問題
  • •CONDITION：品質・電池・保証が需要に合わない
  • •LOCK：データ・アカウント・管理制限
  • •REPAIR：修理・部品・再検査待ち
  • •OWNERSHIP：所有・委託・返品が不明
  • •LOCATION：別棚・店舗・在庫同期の問題
  • •DEMAND：機種・仕様への需要が低い
  • •PROCESS：承認・撮影・出品・価格更新の滞留

一台に主原因と副原因を付け、その他の比率が高ければ辞書を見直します。原因別の対策期限と担当を決めます。

原価と回収可能額を分けて見る

取得原価が高くても、市場が下がれば回収額は下がります。原価へ合わせて価格を維持すると滞留費が増えます。一方、相場だけで値下げし、委託品や保証費を無視してはいけません。

在庫ごとに次を持ちます。

  • •acquisition_cost：取得原価
  • •carrying_cost：保管・資金・棚・管理
  • •rework_cost：清掃・消去・修理・撮影
  • •expected_sale_net：小売の予想手取り
  • •expected_wholesale_net：業者売却の予想手取り
  • •return・repair・recycle_net：他経路の手取り・費用
  • •uncertainty：未確認・価格幅

帳簿評価・税務処理は経理・専門家と確認し、業務上の回収見込みと混同しません。

価格比較は販売可能な同条件へそろえる

相場へ照合するのはSALEABLEまたは条件が明確な在庫です。データ・安全・所有保留を通常中古相場へ掛けません。

同じ型番、容量、地域仕様、状態、保証、数量、税送料、基準日時をそろえます。出品価格と成約・買取を分けます。

[買取相場を確認する](/kaitori-search)場合も、上限表示と確定査定を区別し、減額・送料・有効期限を確認します。相場が取れない機種は0円へせず、類似機種の差と不確実性を示します。

処分経路を五つに分ける

一括値下げではなく、条件に応じ経路を選びます。

店舗・オンラインで継続販売

画像、名称、価格、保証を改善し、見直し期限を決めます。期限後も売れなければ次経路へ移します。

業者・大口売却

同一条件をロット化し、減額・送料・返送を含む手取りで比較します。所有・データ・安全を確認した品だけにします。

修理・再生

修理費、成功率、再検査、販売価格、保証費を比較します。原価を回収するためだけに採算の悪い修理を続けません。

部品再利用

親端末と部品へ別IDを付け、由来、適合、安全、検査を追います。データを保持する部品は消去・破壊条件を確認します。

適正処理・資源回収

環境省の小型家電リサイクル関連情報も参照し、適用制度、委託先、地域条件に従います。売却不可を一般廃棄物へ混ぜず、所有とデータを確認します。

ロット化は悪い在庫を隠すために使わない

業者売却では、同一機種・品質をまとめると比較しやすくなります。低需要品を混ぜる場合も、構成を開示します。

ロットには次を持たせます。

  • •lot_id・作成版・基準日時
  • •個体一覧・数量・品質構成
  • •データ・安全・ロック状態
  • •写真・検査方法・標本
  • •付属品・保証・修理
  • •出荷場所・時期・送料
  • •数量・品質差の精算

ロット作成後に個体を入れ替える場合、退出・追加履歴を残し、査定先が見た版と確定版を照合します。

具体例：300台の滞留在庫を分岐する

棚卸しで300台を確認したとします。

状態・経路台数一台当たり予想手取り・費用
小売継続80台28,000円
業者売却120台20,000円
修理後販売40台手取り24,000円－修理6,000円
部品再利用20台8,000円
安全・データ保留15台未確定
所有・識別差25台未確定

確定経路260台の予想回収は、2,240,000円＋2,400,000円＋720,000円＋160,000円＝5,520,000円です。保留40台を0円や平均単価へ置き換えません。

30日後の判断

小売継続80台のうち20台しか売れず、残60台の相場が一台2,000円下がった場合、追加保管・値下げと業者売却を再比較します。最初の計画を守るために滞留を延ばしません。

修理の分岐

40台の修理成功率が70％なら、成功28台と失敗12台を分けて期待手取りを計算します。失敗品の部品・処理費と再検査・保証費を含めます。

査定結果と入金を個体へ照合する

業者売却120台の結果を「平均20,000円」で一括記録すると、どの品質・欠陥が減額されたか分かりません。査定先から個体別に、判定、単価、減額コード、買取不可、証拠、確定日を受け取ります。

出荷一覧、査定受領、確定買取、返送を分けます。120台発送して、118台買取、1台返送、1台識別保留なら、売却数を120へ合わせません。箱・個体・査定先IDを照合し、保留責任者と期限を設定します。

入金では、個体・ランク別小計、税、送料、手数料、返送費、相殺を確認します。入金額に合わせて査定単価を上書きせず、差異ケースで元請求・明細・銀行記録を照合します。

査定結果を滞留原因へ戻します。画面傷の減額が多ければ写真・品質判定、ロック不可が多ければ消去・管理解除、型番違いが多ければSKU登録を改善します。単に査定先が厳しいと決めつけません。

店舗間移動で滞留を隠さない

在庫を別店舗へ移すと、元店舗の滞留日数がリセットされるシステムがあります。received_atを店舗到着日、first_available_atを全社で最初に販売可能になった日として分けます。

移動判断には、受入店舗の需要、同一SKU在庫、棚容量、物流費、販売期限を使います。売れない端末を順番に移すだけでは全社滞留は減りません。

移動時にはasset_id、from・to、箱、担当、日時、状態を記録します。到着後に品質・データ・安全を再確認し、輸送破損や箱差を分けます。移動中在庫を両店舗の販売可能数へ二重計上しません。

値下げ実験は対照と期限を持つ

同一SKUを一斉値下げすると、価格の効果と季節・店舗差を分けられません。数量が十分な場合、店舗・期間・表示を限定し、旧価格と比較します。

実験では、閲覧、問い合わせ、販売、粗利、返品、他SKUへの影響を測ります。値下げで販売数が増えても、保証・返品を含む手取りが悪化していないか確認します。

一度の結果を全機種へ適用せず、価格帯、品質、地域を分けます。実験終了日を決め、売れ残りを旧価格へ機械的に戻すのか、業者売却へ移すのかを事前に決めます。

週次レビューは在庫総額だけで終えない

週次では次を確認します。

  • •30・60・90・180日帯の台数と回収見込
  • •所有・識別・データ・安全保留
  • •出品待ち、写真待ち、承認待ち
  • •値下げ・移動・業者査定・修理の進捗
  • •見込手取りと確定手取りの差
  • •未解決差と次回期限
  • •新たに滞留帯へ入ったSKUと原因

滞留総額が減っても、低価格で処分しただけか、在庫差を帳簿から消しただけかを確認します。販売・売却・返却・処理の根拠イベントへ戻れることを条件にします。

担当者評価は、滞留台数の減少だけでなく、個体一致、保留解決、手取り予測精度、再発率を含めます。保留を無理にSALEABLEへ変える動機を作りません。

次回入荷・買取へ原因を戻す

滞留改善は在庫処分で終わりません。機種、容量、色、品質、価格、店舗、仕入元ごとに原因を集計し、次回の仕入・買取上限・配分へ反映します。

例えば、特定容量が90日超へ偏るなら、単価だけでなく顧客需要、価格差、代替機種を確認します。特定仕入元でロック・品質差が多いなら、受入検査と精算条件を見直します。

過去の滞留を根拠に新しい機種を一律拒否せず、母数、期間、市場環境を示します。仕入条件を変えた後は、同じKPIで再測定し、改善が在庫日数と手取りへ表れたか確認します。

30日改善計画

1〜7日

  • •滞留基準、対象店舗、責任者を決める
  • •所有・契約・現物を照合する
  • •asset_idとSKUマスターを整える
  • •データ・安全・識別を隔離する

8〜14日

  • •品質・電池・修理・付属品を記録する
  • •固定条件で写真を撮る
  • •滞留原因と処分候補を付ける
  • •原価・追加費・予想手取りをそろえる

15〜21日

  • •小売改善、業者査定、修理、部品を比較する
  • •ロットと個体一覧を版管理する
  • •標準・悲観の回収額を承認する
  • •担当・期限・停止条件を決める

22〜30日

  • •承認経路へ移動・出品・発送する
  • •受領・査定・修理結果を個体へ戻す
  • •保留と未解決差を再確認する
  • •次回30日の価格・処分期限を設定する

棚卸し・査定チェックリスト

  • •[ ] 滞留を販売可能日から定義した
  • •[ ] 所有・委託・預かり・返却を区別した
  • •[ ] 一台ごとにasset_idとメーカー番号がある
  • •[ ] 帳簿・システム・現物の差を残した
  • •[ ] データ・安全・識別を通常在庫から止めた
  • •[ ] 品質を元の観測項目で記録した
  • •[ ] SKU表記ゆれを製品マスターへ統合した
  • •[ ] 滞留原因に担当・期限がある
  • •[ ] 原価と回収可能額を分けた
  • •[ ] 同条件の相場・査定を使った
  • •[ ] 小売・業者・修理・部品・回収を比較した
  • •[ ] ロット構成と版を開示した
  • •[ ] 保留品を平均単価へ含めない
  • •[ ] 査定・修理・売却結果を個体へ戻す
  • •[ ] 30日後の再判断日を設定した

まとめ：滞留在庫は値下げ前に、売却できる個体へ戻す

店舗の長期滞留在庫は、棚の合計台数では改善できません。所有、個体、製品、データ、安全、品質、時点をそろえ、販売可能と保留を分けます。

帳簿・システム・現物の差を上書きせず、滞留原因へ担当と期限を付けます。取得原価と現在の回収可能額を分け、小売、業者売却、修理、部品、適正処理を総手取りとリスクで比較します。

300台の例では、確定経路260台の回収見込みを5,520,000円と計算し、所有・安全・データ保留40台を未確定として残しました。平均単価で埋めず、30日後に実績を再評価することが、在庫を安全に現金化し、同じ滞留を繰り返さない基本です。