配送業者の運賃請求を出荷実績と運賃表に突き合わせて過払いを見つける

処理の起点を決める

所定フォルダへのファイル配置、または月2回の定時実行を起点にします。締め日が15日と月末に分かれるため、月6日と21日の朝に走らせます。

Make のシナリオはスケジュール設定で実行のタイミングを指定します。既定は15分ごとで、分単位の間隔指定のほか Daily、Weekly、Monthly（月の指定日）、On demand から選べます。最小の間隔は契約プランによります。今回は Monthly の指定日で足ります。

ポータルからのダウンロードは自動化しません。 認証があり、自動ログインが利用規約に触れないかの確認が要るためです。

入力データを集める

運賃表マスタと項目対応表は、この構成の前提になる自社データです。

データの取得方法を決める

CSVの請求明細： そのまま読み込みます。まず「明細をCSVで出せますか」と業者に聞いてください。 CSVで受け取れれば、OCRの工程が丸ごと消えます。

PDFの請求明細： OCRに回します。Google Document AI の Invoice parser は、ヘッダー項目と明細行の両方を抽出すると公式のプロセッサ一覧に記載があります。ただし運賃の明細は請求書の様式ではなく、数千行の一覧表であることが多いため、請求書向けのモデルが合うとは限りません。表構造の読み取りに向いた Form Parser や Layout Parser、自社の様式で学習させる Custom Extractor も候補です。自社の明細で実測してください。

出荷実績： WMSからCSVエクスポートするか、APIで取得します。送り状番号を必ず含めてください。 これが無いと突合が成立しません。

AIへ渡す前に整形する

1. 項目名の対応づけ … 業者ごとに列名が違い、「サイズ」と「規格」が同じ意味だったり、「手数料」の中身が違ったりします。対応表を作り、表に無い列だけAIに候補を出させます。確定は人が行い、対応表に追記します
2. 送り状番号の正規化 … ハイフン、前ゼロ、半角と全角が混ざります。数字だけを取り出して比較します
3. 対象期間の切り出し … 締め日が業者ごとに違い、請求の基準も「発送日」と「着荷日」があります。 着荷日基準では月末に出した荷物が翌月の請求に載るため、締め期間だけを読むと月境の行が全部「実績なし」になります。出荷実績は前後1か月を含めて読み込みます
4. 金額の型をそろえる … カンマ入りの文字列を数値に直し、税込か税抜かを業者ごとに確認します
5. 運賃表の版の選択 … 請求日ではなく出荷日で版を選びます。 改定日をまたぐ月は、同じ請求書の中に2つの版が混在します

AIに処理させる

AIにさせないことは4つです。金額の計算（あるべき運賃も差額もプログラムが出す）、区分の判定（サイズ区分や地域区分を住所や品名から推測させない）、運賃改定の内容の推測、過大請求の断定です。

燃料サーチャージは推測の対象にしやすいので、特に注意してください。 トラック運送では、国土交通省が令和2年4月に告示した「標準的な運賃」の一部として、令和5年3月に燃料サーチャージの算出方法等が告示されています。ただしこれは、事業者が事業を持続するための参考として示されたものです。自社の契約でどの基準価格・改定時期が適用されるかは、契約書と改定通知にしか書かれていません。 改定通知が届いたら物流部が新しい版として登録します。この登録を人の作業として残すことが安全装置になります。

指示内容を固定する

あなたは荷主企業の物流担当を支援する担当者です。
運賃の請求明細と出荷実績の突合結果を渡します。
差異のある行に、原因の候補を付けて分類してください。

【厳守事項】
- 金額、重量、個数を計算し直さず、値をそのまま引き継いでください。
- 「過大請求」と断定せず、自社の出荷データ側の誤りである
  可能性を必ず併記してください。
- 原因は出力スキーマの候補から選び、当てはまらなければ
  "unknown" とし、判断できない理由を書いてください。
- 運賃表に無い単価や改定内容を推測せず、該当する単価が無い行は
  needs_master_update に入れてください。
- 突合できなかった行は、原因を推測せず unmatched に分けてください。
- 同じ原因の行はまとめ、件数と差額の合計を入れてください。
- 照会文の下書きは4行以内にし、事実の確認だけを書いてください。

【突合結果（差異のある行）】
{diff_rows}

【適用した運賃表の版】
{tariff_version}

「過大請求と断定しない」「自社側の誤りの可能性を併記する」の2行が最も重要です。 ここを外すと、自社の登録ミスを業者へ照会する事故が起きます。一度それをやると次から業者の対応が慎重になります。

出力形式を固定する

差異の一覧を表計算ソフトの行に落とすため、自由文では扱えません。Gemini API には、response_format に mime_type と JSON Schema を指定して出力形式を固定する構造化出力の機能があります。

{
  "groups": [
    {
      "carrier": "",
      "origin_site": "",
      "cause_candidate": "size_class | area_class | weight_class | redelivery | accessorial | fuel_surcharge | tariff_version | own_data_error | actual_cost | unknown",
      "row_count": 0,
      "difference_total": "",
      "direction": "billed_higher | billed_lower",
      "own_side_possibility": "",
      "carrier_side_possibility": "",
      "inquiry_draft": ""
    }
  ],
  "unmatched": [
    { "tracking_number": "", "side": "billing_only | shipment_only", "reason": "" }
  ],
  "needs_master_update": []
}

difference_total は、プログラムが計算した値を文字列として引き継がせます。数値として再出力させると、桁を落とした値が返ることがあります。 own_side_possibility と carrier_side_possibility を分けているのは、どちらの誤りか分からない状態を構造として残すためです。

システムへ連携する

差異の一覧はスプレッドシートに書き出します。列は、原因の候補、業者、拠点、件数、差額の合計、自社側の可能性、業者側の可能性、担当者の判断、照会の結果です。

担当者の判断を書く列を必ず作ってください。 「自社側の誤り」「業者へ照会」「正常」の3択にします。この列が翌月の入力になります。前月に「正常」とした組み合わせは、翌月はその旨を添えて表示します。そうしないと、毎月必ず出る正常な差異（チャーター便の実費精算など）が上位に居座ります。

支払データへの書き戻しはしません。 支払いを止めるか減額して払うかは、業者との関係を含む判断です。

人が確認する

差異の付いた行は、原因の候補ごとにまとめた単位で人が全件を確認します。 見るのは3点です。

1. その差異が自社側の誤りではないか … 出荷データのサイズ登録、キャンセルの反映漏れを先に疑います。ここを飛ばして照会しないでください
2. 適用した運賃表の版が正しいか … 差異が特定の日付から一斉に出ていれば、版の選択を疑います
3. 照会文の内容 … 送信前に必ず読みます。返金の要求は人が判断して書き足します

突合できなかった行は、差異の行より先に見ます。 請求にあって出荷実績に無い行は、他社の荷物が混ざっているか、自社の出荷登録が漏れているかのどちらかで、金額の差異より重い話です。

例外に対処する

記録を残す

• 請求明細の原本と、突合結果の全件（差異が無かった行も含む）
• 適用した運賃表の版のIDと、AIが付けた原因の候補
• 担当者の判断（自社側の誤り／業者へ照会／正常）と、照会の結果

最後の行が、成果を測る唯一の材料です。 「照会した120行のうち、業者が修正したのは40行、自社の登録ミスが60行、契約どおりが20行」と分かって初めて、価値が数字になります。

電子データで受け取った請求明細は、電子帳簿保存法の電子取引に当たります。国税庁の一問一答では、見読可能装置の備付け、検索機能の確保、真実性を確保するための措置が必要とされています。検索機能は、日付や取引金額などの主要な記録項目を条件にできること、日付と金額は範囲を指定できること、二以上の記録項目を組み合わせられることの3点です。自社の保存方法が要件を満たすかは顧問税理士に確認してください。