外部倉庫・3PLの入荷実績を検収日の根拠にするときの条件— 契約・WMS項目・不一致処理

1. 根拠にできる条件（4要件）

1-1. 契約上の受領代理

3PL契約または発注基本契約に、倉庫での入荷確認を発注者の受領・検収とみなす条項があること。
条項が無い状態でWMS日付を起算に使うと、後から取引先が「未納品」と主張する余地が残ります。

1-2. 検品プロセスの定義

WMS上のステータスが「入荷予定」「入荷完了」「検品完了」「保留」のどれを検収相当とするかを定義書に固定します。
単なる棚卸スキャンと検収合格を同一視しないことが前提です。

1-3. データ連携の改ざん耐性

WMSから台帳へ連携するCSVまたはAPIに、伝票番号、行ID、数量、タイムスタンプ、連携バッチIDが含まれ、再送時に idempotent であること。
手入力で倉庫担当が日付を書き戻せるUIだけでは根拠になりません。

1-4. 不一致時の停止ルール

発注数量と入荷数量が一致しない行は検収日を自動確定せず、保留ステータスで60日起算を止めるルールがあること。
検収基準の社内合意は検収基準の決め方と整合させてください。

2. 契約条項チェックリスト

2-1. 3PL委託契約

入荷検品の範囲、不良品の通知期限、過不足の報告義務、データ提供形式、ログ保持期間を条文化します。
損害賠償上限条項だけが厚く、検品義務が薄い契約は起算根拠に向きません。

2-2. 仕入先との発注条件

仕入先への発注書に、納品先が3PL倉庫であること、倉庫入荷日を納品日とみなすか、を明記します。
納品書・電子納品記録の形式は検収・受領と電子納品の起算の整理と突合します。

2-3. SLAと遅延通知

WMS連携遅延が24時間を超えた場合、検収日確定を止めて手動確認に切り替えるSLAを3PLと合意します。
連携停止中に起算だけ進むと、取引先との紛争時に説明不能になります。

3. WMSから取る必須項目

inbound_id, po_reference, sku, qty_ordered, qty_received, qty_rejected, received_at, inspected_at, status, warehouse_code, carrier_tracking, lot_serial, exception_code, wms_export_batch_id。
received_at と inspected_at は別列のまま台帳へ取り込み、起算に使う日付列は inspected_at 非NULLのみとするのが安全です。

3-1. 部分入荷

複数回入荷する発注は inbound_id 単位で行を分け、po_id あたりの検収日は最終検品完了行の inspected_at を採用するか、行単位起算にするかを事前に決めます。
行単位起算の方が60日管理は正確ですが、経理の支払単位とズレやすいです。

3-2. 返品・再入荷

返品後の再入荷は新しい inbound_id を発行し、古い検収日を上書きしません。
上書きは監査ログ上の改ざんと見なされるため、訂正行を追加する設計にします。

4. 不一致・例外の処理

4-1. 数量差異

qty_received が qty_ordered を下回る場合、exception_code=SHORTAGE で台帳を保留し、仕入先へ差異通知を送った日時を別列に残します。
差異解消まで payment_due を計算しないルールをシステムで強制します。

4-2. 品質不良

qty_rejected が正の行は検収不合格として、合格分だけを部分検収します。
部分検収時の支払金額連動は記載事項テンプレートの数量・単価列と同じ丸め規則を適用します。

4-3. 3PLと仕入先の主張が割れる

WMSと仕入先納品書が食い違う場合、60日起算は止めたまま、写真付き棚卸または第三者カウントをトリガーに再確定します。
トリカク（torikaku） では保留フラグ付き案件をダッシュボードで一覧化できますが、仲裁手順は社内規程に書いてください。

5. 台帳への反映フロー

5-1. 自動確定の条件式

status=INSPECTED_OK かつ exception_code が空 かつ qty_received=qty_ordered のとき alone inspected_at を検収日にコピーします。
それ以外は manual_review キューへ回し、起算日列は NULL のままにします。

5-2. 60日ダッシュボード

3PL連携案件は「検収日未確定」タグを付け、60日KPIダッシュボードで通常案件と分けて表示します。
未確定案件を通常の残日数グラフに混ぜると、偽の余裕が見えます。

5-3. 監査用エクスポート

監査時は po_id ごとに WMS raw 行、台帳確定行、契約条項PDFへのリンクをセットで出力できるようにします。
エクスポートに wms_export_batch_id を含め、どの連携で確定したかを後から追跡します。

6. 業種別の注意点

6-1. 食品・ロット管理

賞味期限と lot_serial が WMS必須項目に入る業種は、検収日よりロット単位の起算を優先するかを契約で決めます。
ロット拒否後に別ロットで再入荷した場合、inbound_id を分けないと起算が上書きされます。

6-2. 越境EC・返品センター

返品センター経由の入荷は「再販可能検品」と「廃棄」のステータスを分け、廃棄行を検収対象外にします。
再販可能になった時点の inspected_at だけを台帳へ反映する二段階が安全です。

6-3. 期末在庫の突合

期末に WMS在庫と台帳上の検収済未払いを突合し、保留案件が在庫計上に含まれていないか確認します。
会計上の在庫計上日と検収日を一致させるかは経理ポリシー次第ですが、台帳側の日付は WMS raw と説明可能である必要があります。

6-4. 温度帯・危険物の例外

冷蔵・冷凍・危険物は入荷スキャンと検品完了の間に温度ログ確認を挟み、ログ欠落時は inspected_at を確定しません。
温度逸脱が契約上の拒収事由なら、exception_code=TEMP_FAIL として60日起算を止めます。

よくある質問

Q. 入荷スキャン日をそのまま使ってはいけませんか

検品前スキャンは物理的な「荷下ろし」であって検収ではないケースが多いです。
契約とWMSステータス定義で検品完了を明示しない限り、起算根拠には弱いです。

Q. 複数3PLを使う場合は

倉庫コードごとにステータス定義表を持ち、定義が異なる倉庫を同じ自動確定式に載せないでください。
統一したい場合は3PL契約改定が先です。

Q. API連携とCSVどちらがよいですか

APIの方が遅延は少ないです。
どちらでも batch_id と行ハッシュを残せれば根拠強度は同じです。

Q. フリーランス新法の書面交付と関係しますか

検収日根拠とは別軸です。
書面交付の記録は電子契約サービス対応側で欠落がないか別途確認してください。

Q. 保留案件が長期化したら

30日超の保留はエスカレーションし、仕入先・3PL・購買の三者会議を設定します。
起算停止が続くこと自体を取引先へ説明するテンプレを用意しておくと交渉が進みます。

Q. 3PLが検品完了ステータスを後から訂正した

訂正は新しい wms_export_batch_id として取り込み、旧行は取消フラグを立てます。
検収日の上書きは監査上問題になるため、訂正理由コードを必須にしてください。

まとめ

• 受領代理条項・検品定義・連携ログ・不一致停止の4要件を満たす
• received_at と inspected_at を分け、合格行だけ自動確定する
• WMS必須項目と batch_id で後追い説明を可能にする
• 数量差異・不良は保留で60日起算を止める
• 3PL案件はダッシュボード上で未確定タグを分離表示する

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。