支払う前に請求書と発注・契約を突き合わせて、二重払いと過払いを止める

処理の起点を決める

支払データを作る処理の前段を起点にします。請求書を受け取った時点ではありません。

理由は2つあります。1つは、受け取った時点では発注データが基幹システムに登録されていないことがあるためです。突き合わせる相手がまだ無い状態で判定すると、全件が「発注データ無し」で止まります。 もう1つは、支払の直前でまとめて判定したほうが、二重払いの検出に有利だからです。同じ締めの中に入っている請求どうしを、同時に比べられます。

支払は月2回なので、締め日の翌営業日に、その回に含める請求書をまとめて処理します。1回あたり約300件です。

入力データを集める

この6つのうち、いちばん手間がかかるのは契約の単価表です。 多くの会社で、単価は契約書のPDFの中にしかありません。表として持っていないなら、3つ目のルールは最初から動きません。 全社分をそろえてから始めず、取引金額の上位50社だけを表にして、その範囲でルールを効かせてください。

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

請求書： 紙はスキャナで取り込みます。画像の寸法は50×50ピクセルから10,000×10,000ピクセルの間である必要があります。 抽出するテキストの最小高さは、1024×768の画像で12ピクセル（150dpiで約8ポイントのテキストに相当）です。明細の文字が小さい請求書があるので、スキャンの解像度をここから逆算して決めてください。

パスワードでロックされたPDFは、提出前にロックを解除する必要があります。 請求書にパスワードをかけて送ってくる取引先があるので、受信の窓口で解除してから保存する手順を運用に組み込みます。

支払履歴と発注データ： 基幹システムと会計システムからの取得は、データベースへの参照または日次の抽出ファイルで行います。書き込みはしません。 読むだけなので、権限の申請も通りやすくなります。

メール本文だけの請求： 添付の無い、本文に金額だけ書かれたメールは読み取りの対象外にし、最初から人の処理に回します。無理に機械に入れると、判定の信頼を落とします。

AIへ渡す前に整形する

1. 取引先の名寄せ … 請求書の社名を取引先マスタのコードに変換します。「株式会社」の位置、支店名の有無、旧社名で表記が揺れ、ここが合わないと支払履歴の照合がまるごと空振りします
2. 明細の正規化 … 品名の全角と半角、単位（本・m・式）、数量と単価の桁を整えます。「一式」の行は数量の比較ができないので、金額だけで見る扱いに分けます
3. 低信頼の項目の切り出し … pageResults の信頼度が基準を下回る項目に印を付けます。この項目は差異の判定に使わず、人の確認へ回します
4. 同一締め内の重複の先出し … 今回の処理対象の中だけで、取引先・金額が一致する組を先に洗います。同じ請求が2通届いているケースが、ここで出ます
5. 過去12か月への絞り込み … 支払履歴は全期間ではなく12か月に絞ります。それ以前の再送は実務上ほぼ無く、比較の対象を増やすと誤検知が増えます

AIに処理させる

役割を3つに分けます。ここを混ぜないことが設計の中心です。

差額の計算を生成AIにさせません。 金額の判定は必ず同じ答えが出る必要があり、計算はPythonで行います。生成AIに任せるのは、計算ではなく対応づけと説明です。

対応づけが必要なのは、請求書の品名と発注の品名が一致しないからです。発注書の「配管用炭素鋼鋼管 50A」が、請求書では「鋼管50A」と書かれます。この2つが同じ行だと判断するところに、生成AIを使います。

突合のルールは3つです。

しきい値を率と額の両方で持つ理由を、はっきりさせておきます。

率だけで持つと、少額の請求で誤検知が増えます。3,000円の請求で単価が300円ずれていれば10.0％ですが、実務上は端数処理の違いで説明が付く範囲です。これを全部止めると、止まる件数が増えすぎて確認が回りません。

額だけで持つと、大口の請求の小さなずれを見逃します。500万円の請求で単価が0.5％ずれていても、額では2万5千円です。額のしきい値が5万円なら通ってしまいますが、これが毎月続けば年間30万円になります。

だから、率が基準を超えるか、額が基準を超えるかのどちらかで止めます。 両方を満たしたときだけ止める設計にしないでください。逆になります。

指示内容を固定する

あなたは、受け取った請求書の明細を、発注データの明細行に
対応づける作業を支援する立場です。
金額の計算と、支払を止めるかどうかの判断はしません。
対応づけと、差異の説明だけを行ってください。

【厳守事項】
- 請求書と発注データに書かれていないことを補わないでください。
  「おそらく同じ品目だろう」という推測で対応づけないでください。
- 対応づけの根拠を必ず示してください。品名のどの部分が一致したか、
  数量または単位がどう対応するかを matched_on に書いてください。
- 対応する発注の行が特定できない場合は po_line_ref を null にし、
  reason に「特定できない」と書いてください。
  近そうな行を無理に選ばないでください。
- 請求書に記載がない項目は unknown_fields に項目名を入れ、
  値は null にしてください。記載がなければ不明とします。
  発注データの値で埋めないでください。
- 読み取りの信頼度が低いと印が付いた項目は、対応づけの根拠に
  使わないでください。low_confidence_used に項目名を残してください。
- 「一式」「まとめて」のように数量が数えられない行は、
  quantity_comparable を false にしてください。
- 金額、差額、差率を自分で計算しないでください。
  与えられた数値をそのまま参照してください。
- 支払を止めるべきかどうかの結論を書かないでください。

【請求書の読み取り結果（信頼度つき）】
{invoice_json}

【この取引先の発注データ（明細行）】
{purchase_order_lines}

【この取引先の契約の単価表】
{contract_price_list}

【認めている費目の一覧】
{expense_categories}

「金額を自分で計算しないでください」という指示が、この構成でいちばん重要です。 生成AIに計算させると、答えが毎回同じになる保証がありません。支払の可否に関わる数値は、必ず同じ答えが出る方法で求めます。

「近そうな行を無理に選ばない」も必須です。 対応づけを無理に作ると、本来は発注に無い行（つまり unlisted_item）が、既存の行に吸収されて消えます。検出したいものが、対応づけの親切さで消えるのがいちばん危ない失敗です。

出力形式を固定する

{
  "invoice": {
    "invoice_id": "",
    "vendor_code": "",
    "issue_date": "",
    "total": 0,
    "source_file": "",
    "low_confidence_fields": []
  },
  "lines": [
    {
      "no": 1,
      "description": "",
      "qty": 0,
      "unit_price": 0,
      "amount": 0,
      "po_line_ref": null,
      "matched_on": "",
      "quantity_comparable": true
    }
  ],
  "checks": [
    {
      "rule": "duplicate_suspect",
      "hit": true,
      "evidence": {
        "matched_payment_id": "",
        "days_apart": 0,
        "amount_diff": 0,
        "line_similarity": 0.0
      },
      "reason": ""
    }
  ],
  "decision": "pass",
  "severity": "block",
  "unknown_fields": []
}

構造化する理由は、判定の根拠を後から再現できるようにするためです。 支払を止めた判断は、取引先への支払遅延につながります。「なぜ止めたのか」を聞かれたときに、evidence の中身をそのまま示せる状態にしておきます。

evidence に数値をそのまま残します。「二重払いの疑いがあります」という文章だけでは、確認する人は結局もとのデータを開き直します。「同じ取引先へ18日前に同額の支払があり、明細の一致度は0.92」まで出ていれば、開かずに判断できます。

decision と severity を分けるのは、「止める」と「後で見る」を区別するためです。 同じ duplicate_suspect でも、明細まで一致していれば止め、金額だけの一致なら後で見る、という運用ができます。

システムへ連携する

会計システムへの書き込みは、人の解除を経たものだけにします。 止まったものは人が解除するまで渡しません。「自動で渡さない」ことを仕組みで保証してください。 運用の約束にすると、繁忙期に崩れます。

確認画面は作る価値があります。 止まったものの一覧に evidence と請求書の画像を並べておけば、1件の確認が1分から2分で終わります。基幹システムと会計システムを行き来させないことが、削減効果の大部分を作ります。

人が確認する

確認するのは、止まったものと要確認のものだけです。通ったものは見ません。

600件を全部見る運用を続けるなら、機械を入れる意味はありません。ただし、見ないと決めた以上、見なかったものが後で問題にならないかを測る必要があります（第13章）。

確認を速くするための設計を並べます。

• 止まったものを severity の順に並べる（block を上に）
• 1件の画面に、請求書の画像・読み取り結果・突合の相手（履歴または発注行）を横に並べて置く
• evidence の数値を、文章より先に見える位置に出す
• 低信頼の項目に印を付け、読み間違いの可能性を先に疑えるようにする
• 解除するときに、理由を選択肢から選ばせる（値上げの合意済み／発注の登録漏れ／端数処理／その他）
• 同じ取引先で過去に同じ理由で解除した件数を、その場に表示する

最後の1つが効きます。「この取引先は先月も同じ理由で3件解除している」と見えれば、それは個別の例外ではなく、発注データの登録が遅れているという業務の問題です。

例外に対処する

記録を残す

• 請求書の画像・PDFの原本と、読み取りの結果（信頼度を含む）
• 突合に使った支払履歴・発注データ・単価表の、その時点の値
• 3つのルールそれぞれの判定結果と evidence
• 人が解除した件と、選んだ理由
• 人が差し戻した件と、その後どうなったか
• 通した件の判定結果（人が見ていないものも全部残す）

4つ目と6つ目が、改善の材料になります。 解除の理由が「発注の登録漏れ」に偏っているなら、直すのは判定のしきい値ではなく、発注の登録の運用です。機械の精度の問題に見えるものが、業務の問題であることは珍しくありません。

6つ目を必ず残してください。 人が見なかったものを残しておかないと、後から「見逃しがあったか」を確かめる方法がなくなります。

突合に使った相手のデータも、その時点の値で残します。 発注データは後から修正されるので、半年後に「なぜこれを通したのか」を調べるとき、現在の値を見ても再現できません。