スケッチーズ
‹ 記事一覧

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

売る2026/6/26監修:恩 拓亮
店舗の長期滞留在庫の実務ガイド|型番・台数・状態を棚卸しして査定可能なリストにする

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

店舗のバックヤードに長く残るスマートフォン、タブレット、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または条件が明確な在庫です。データ・安全・所有保留を通常中古相場へ掛けません。

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

買取相場を確認する場合も、上限表示と確定査定を区別し、減額・送料・有効期限を確認します。相場が取れない機種は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日後に実績を再評価することが、在庫を安全に現金化し、同じ滞留を繰り返さない基本です。

恩 拓亮
監修
恩 拓亮株式会社SketCheese 代表

中古端末(リユース)業界で11年以上の経験を持つ株式会社SketCheese代表。中国・香港・日本のマーケット知見をもとに、取引・物流・輸出入から販売ネットワークまでを横断。越境リユース流通の実務をふまえ、本メディアの記事を監修しています。

運営者情報を見る

関連記事