取引先ごとの支払サイトと回収サイトの実態を毎月測って、運転資金への影響を出す

処理の起点を決める

月次の消込が終わったことを起点にします。 日付だけで動かすと、消込が遅れた月に未確定のデータを測ることになり、そのときだけ日数が実態より長く出ます。

Make では、シナリオの実行間隔を Schedule settings で決めます。既定は15分ごとで、そこから8つの型を選べます。At regular intervals（一定の間隔）／Once（1回だけ）／Daily（毎日、1日に複数回も可）／Weekdays（平日のみ）／Weekly（曜日指定）／Monthly（日付指定）／Specified dates（日時を指定）／On demand（手動またはAPIからの起動のみ）です。

この構成では Monthly で月初の数日を指定し、消込の完了を確かめる分岐を先頭に置きます。未完了なら何もせずに終わります。 完了日が月によって大きくずれる会社では、On demand にして経理が手で起動するほうが確実です。Show advanced settings の Start と End で、動く期間を区切れます。

入力データを集める

質を決めるのは、上から4番目の消込の結果です。 これが無いと、1件の請求に対する入金が1回だったのか2回だったのかが分かりません。一部入金を全額入金として数えると、日数は実態より短く出ます。

取引先マスタの締め日の登録値は、答えではなく照合の相手です。 契約書と食い違ったとき、どちらが正しいかは人が確かめます。

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

契約書は保管フォルダから取り、Gemini API に渡します。小さい文書はそのまま埋め込み、大きい文書は Files API を使うと、待ち時間が短くなり通信量も減るとされています。 実績の側は会計システムからCSVまたはAPIで取ります。取るのは金額と、4つの日付です。

起点を締め日に決めるのが、この構成でいちばん重い設計判断です。 請求書の発行日を起点にすると自社の請求業務の遅れまで取引先の遅れに見え、消込日を終点にすると経理が忙しかった月だけ日数が伸びます。

手形やでんさいで受け取っている先は、終点を「現金になった日」にします。 振り出された日で数えると資金の話として合いません。手形の期間の分だけ、運転資金は余計に必要になっています。

AIへ渡す前に整形する

1. 契約の版をそろえる … 取引先ごとに契約書を締結日の新しい順に並べ、一式をまとめて渡します
2. 取引先コードで名寄せする … 契約書は取引先名、会計システムは取引先コードで並んでいます。支店名や旧社名の違いで別の取引先になりやすいので、名寄せの一覧を持ちます
3. 除外する取引に印を付ける … 一部入金、相殺、返品、値引き、前受／前払を測定から外します
4. ページ数とサイズを確かめる … 50MBまたは1000ページが上限です。超える取引先は、条項のあるページだけに絞って渡します
5. 条項を探しやすくする … 質問を他の情報のあとに置くと性能が上がるとされています。契約書を先、指示を後ろにします
6. 金額の符号をそろえる … 売掛と買掛で符号が逆になるので、集計の前に向きをそろえます

3番目を省かないでください。 一部入金があった請求を全額入金として数えると、入金が早い取引先に見えます。 相殺で消えた請求は入金日を持たず、残せば空欄のまま平均に入ります。

AIに処理させる

させるのは、支払条件の6項目を読み取り、条番号と原文を添えることだけです。

右端の列が要です。 起算点が書かれていない契約書は珍しくありません。「たぶん締め日だろう」と埋めさせると、差の数字が静かに間違います。 読み取れない項目が1つでもあれば、その取引先は needs_review として人に回します。

いちばん起きやすいのは1行目です。 「翌月末払いなので約30日です」と書かれると、もっともらしいので通ります。しかし2月は28日で、末日が休日なら支払は翌営業日です。 原文と条番号だけを返させれば、計算はコードの中で完結します。

指示内容を固定する

あなたは財務部門で、取引先との契約書から支払条件を読み取る立場です。
渡された契約書に書かれていることだけを読み取ってください。

【読み取る6項目】
1. 締め日
2. 支払日
3. 起算点（何の日から数えるか）
4. サイトの表記（「月末締め翌月末払い」などの文言そのもの）
5. 支払手段（銀行振込／手形／でんさい）とその期間の記載
6. 条件の適用範囲（取引の区分で条件が分かれている場合の区分）

【status の選び方】
- found ....... 条文に明記されている
- not_stated .. 書かれていない
- ambiguous ... 複数の条文が別の条件を書いており、1つに決められない
迷ったときに found を選ばないでください。

【厳守事項】
- 日数を計算しないでください。「翌月末払いなので30日」のような
  換算をしないでください。日数は別の仕組みが暦から求めます。
- 書かれていない項目は not_stated にしてください。業界の慣行や
  他の項目から補って埋めないでください。特に起算点は推測しないでください。
- すべての項目に article（条番号）と quote（原文の該当部分）を
  そのまま写してください。要約しないでください。
- 覚書や変更合意で書き換えられている項目は、新しいほうを value に入れ、
  supersedes に書き換えられた側の条番号と締結日を入れてください。
  どちらが新しいか決められない場合は ambiguous にしてください。
- 差が大きいか、条件が不利か、交渉すべきかを書かないでください。
- 支払条件の定めが見当たらない場合は、項目を作らず
  review_reason にその旨を書いてください。

【契約書】{contract_documents}
【この取引先の区分】{partner_side}
上の契約書について、6項目を読み取ってください。

「日数を計算しないでください」を最初に置いているのは、放っておくと必ず計算するからです。 支払条件を読めと言われれば、日数に直すのが自然な答え方です。禁じるのは、換算という行為そのものです。

契約書を先に、指示を後ろに置いています。 長い文脈では質問を他の情報のあとに置くほうが性能が上がるとされているためで、最後の1行はそのために置いています。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "partner_code": "",
  "partner_name": "",
  "side": "receivable | payable",
  "contract_documents": [
    { "title": "", "executed_on": "" }
  ],
  "terms": [
    { "item": "closing_day",
      "value": "",
      "status": "found | not_stated | ambiguous",
      "article": "",
      "quote": "",
      "supersedes": [] }
  ],
  "payment_method": {
    "type": "bank_transfer | promissory_note | densai | unknown",
    "period_text": "",
    "status": "found | not_stated | ambiguous",
    "article": "",
    "quote": ""
  },
  "scope": "",
  "review_reason": ""
}

terms にはこの形の要素を4つ並べます。item は closing_day ／ payment_day ／ start_point ／ site_text です。日数の欄がどこにもないことが、この形のいちばんの特徴です。

Gemini API の構造化出力では、response_format に text 型のオブジェクトを指定し、その mime_type を application/json として、schema にJSONスキーマを書きます。enum を使えば status の値を3つに限定でき、required で欄の欠けを防げます。 ただし、非常に大きい、あるいは深く入れ子になったスキーマは拒否されることがあるとされています。構文として正しいJSONが返る一方、中身の妥当性は自分で検証する必要があります。 スキーマを上の1階層分に留め、status と article と quote がそろっているかを Python 側でもう一度確かめます。

article と quote を必ず持たせるのは、確認を速くするためです。契約書のPDFを開かなくても、どの条を根拠にしたかが読めます。

システムへ連携する

取引先マスタへ書き戻しません。 登録値が契約書と違っていたときに自動で直すと、「ずれていた」という発見そのものが記録に残りません。

Python が出すのは取引先ごとに1行の集計です。契約上の日数、実際の日数（加重平均）、その差、対象件数、除外件数、根拠の条番号を並べます。この1行が、人が読む単位です。

人が確認する

人が開くのは needs_review と gap のものだけです。 ok のものは一覧で社数と差の分布を流し見ます。全件の根拠を読む設計では、第10章の8.0時間に収まりません。

1. needs_review を先に見る … 起算点が書かれていない、覚書の前後が決まらない、契約書が見つからない。多くは保管の問題です
2. gap の根拠を確かめる … article と quote を読み、契約上の日数が正しく求められているかを見ます。おかしければ、条文の読み取りか暦の扱いのどちらかです
3. 除外した取引を確かめる … 除外が多い取引先は、平均が少ない件数で作られています。対象の半分を切っていたら、その数字は使いません
4. 一覧を確定して渡す … 財務責任者・営業・購買へ渡します。条件を変える交渉をするかどうかは、渡した先が決めます

4番目の線を越えないでください。 この構成が出すのは、差が何日あるかと、その根拠になった条文までで、「この取引先と交渉すべき」とは書きません。 条件は力関係で決まっており、差が大きいこと自体は、交渉が通ることを意味しません。

目標は、120件をならして1件4分です。 開くのは2割前後という想定です。

例外に対処する

上から3行が全体の大半を占めます。 どれも契約書の保管と記載の問題で、判定の精度を上げても減りません。 初月は needs_review が3割を超えることも想定しておきます。

記録を残す

• 読み取りに使った契約書のファイル名と締結日、版を決めた根拠
• AIが返したJSONの全文（terms、payment_method、article、quote）
• 除外した取引の一覧と、除外の理由の区分（一部入金／相殺／返品／値引き／前受・前払）
• 契約上の日数と実際の日数の計算に使った日付の組み合わせ
• 人が判定を覆した記録 … どの取引先の、どの項目を、何に変えたか
• 運転資金の概算に使った前提の値と、その月の対象取引額

3つ目を軽く見ないでください。 除外の理由が残っていないと、翌月に日数が動いたときに、取引先が変わったのか除外の仕方が変わったのかが分かりません。

最後の行は、概算をやり直すために要ります。 前提を変えたときに過去の月も引き直せなければ、時系列で並べても意味がありません。