販売奨励金・リベートの支払額を、契約の条件と販売実績から検算する

処理の起点を決める

起点は2つあり、動く頻度がまったく違います。1つ目は、契約フォルダへのPDFの保存です。 契約書と覚書のどちらも同じフォルダに入れ、保存をきっかけに条件の読み取りが動きます。覚書を別の場所に置かないでください。 率を改定した覚書がフォルダの外にあると、条件テーブルは改定前のまま毎月の計算に使われ続けます。

2つ目は、締め日の翌営業日に動く毎月の精算です。 Make では「毎月の日付を指定」を選びます。既定の15分ごとのままにしないでください。 月に1度で足りる処理が1日に96回走ります。

取引先からの請求が届く時期はばらばらです。 1日のうちに複数の時刻を登録し、届いた請求だけを突き合わせます。届いていない行は hold のまま置きます。

入力データを集める

いちばん下の2つを軽く見ないでください。 請求が無いまま自社の計算だけで払うと払いすぎが検知されず、過去の精算履歴が無いと同じ期間を二度精算します。

取引先マスタの締め日も同じです。 自社が月末、取引先が20日という組み合わせは珍しくなく、この1項目が無いだけで毎月「原因不明の差異」が出続けます。

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

契約書は、奨励金に関係する条・別表だけを切り出してから渡します。 容量の問題というより、関係のない条項を渡すと、支払条件や解除の条項から数字を拾ってしまうからです。

実績、返品、値引、商品の区分、締め日は、販売管理システムと各マスタから読み取るだけです。書き込みません。 実績は「取引先 × 商品 × 計上日」の明細で取ります。取引先ごとの合計では、後から対象商品で絞り込めません。 請求は金額と対象期間だけを拾えば足ります。

AIへ渡す前に整形する

1. 契約の版をそろえる … 日付の新しい覚書が優先ですが、条ごとに効力が違うことがあります
2. ページ番号と条番号を振る … 根拠を書かせるために、番号が読める状態にします
3. 奨励金の条・別表を切り出す … 支払条件、解除、秘密保持などの条項は渡しません
4. 実績の締め日をそろえる … 取引先マスタの締め日で期間を切ります。自社の月次のまま渡さないでください
5. 単位をそろえる … 契約書が「台」で、実績が「ケース」のことがあります。 税抜と税込も同じです
6. 返品と値引を元の売上に紐づける … 返品日ではなく、元の売上の計上日で期間に入れます
7. 対象商品の区分を付ける … どの型式が新製品かを、日付付きで持ちます
8. 精算済みの範囲を引く … 前回までに精算した期間と重なる部分を除きます。二重計上を止めるためのもので、遡及適用で過去の期間を計算し直すときも、すでに払った金額を引いた差額だけを立てます

4番と5番が、差異の主な出どころです。 契約書の読み取りをいくら正確にしても、この2つがずれていれば金額は合いません。前処理で直せるものを、AIの精度の問題として扱わないでください。

AIに処理させる

させるのは、契約書の文章を条件テーブルの1行に直すことだけです。 1行に入れるのは次の9項目で、1本の契約に条件が複数あれば、その数だけ行を作ります。設計で効くのは、読み取れなかったときの扱いのほうです。

表の項目を埋めることが目的ではありません。埋まらない項目を、埋まらないまま人に渡すことが目的です。 読み取れなかった1行は担当者が10分で確かめられますが、推測で埋まった1行は誰も確かめません。

1行目が、この記事全体の前提です。 「では今月はいくらですか」と聞けば金額は返ってきますが、桁が1つ落ちていてもそれらしく見えます。

指示内容を固定する

あなたは、販売奨励金（リベート）の契約書から支払条件を読み取り、
機械が計算できる表に直す係です。金額の計算はしないでください。

【やること】
契約書の販売奨励金の条件を、条件の単位ごとに1行として書き出してください。
1本の契約に条件が複数あれば、その数だけ行を作ります。

【1行に入れる項目】
- target_products: 対象の商品・ブランド・型式。契約書の書き方をそのまま写す
- period_from / period_to: 条件が適用される販売期間
- basis: 率をかける基準。quantity（数量）か amount（金額）か
- tiers: 階段状の率。下限・上限・率を段の数だけ並べる
- deductions: 控除するもの（返品、値引、運賃、他の奨励金など）
- cap: 支払額の上限。記述が無ければ null
- payment_timing: 支払の時期（毎月、四半期ごと、年1回など）
- effective_from: この条件が効力を持つ日
- retroactive_from: 遡って適用する定めがあればその起算日。無ければ null

【根拠】どの行にも source を付けてください。
- page: ページ番号　article: 条番号・別表番号（例：第7条第2項、別表2）
- quote: 根拠にした原文を、変えずにそのまま写す

【status の選び方】
- ok: 契約書の記述だけで値が決まる
- needs_review: 記述はあるが、値が一つに決まらない
- not_found: その項目についての記述が見当たらない
迷ったときに ok を選ばないでください。

【厳守事項】
- 金額を計算しないでください。率を数量や金額に掛けないでください。
  ここでの仕事は、計算に使う条件を書き出すことだけです。
- 率を丸めないでください。「3.5％」を「3％」や「4％」に直さないでください。
- 書かれていない項目を、他の条件から類推して埋めないでください。
  上限の記述が無ければ cap は null です。0 を入れないでください。
- 「別途協議のうえ決定する」「前年実績を勘案し」のように値が一つに決まらない
  書き方は needs_review にし、それらしい数字を置かないでください。
- 「主力商品」とだけ書かれていて型式が分からない場合や、期間の記述が無い
  場合も needs_review です。対象商品を広げないでください。
- quote は要約せず、原文をそのまま写してください。原文に無い言葉を入れないこと。
- 改定前の条件テーブルは、変わった箇所を見つけるための参考です。
  そこの値を、契約書の記述の代わりに使わないでください。
- 販売奨励金の契約でなければ、行を作らず document_type に書いてください。

【契約書】{contract_pdf}
【この取引先のコード】{partner_code}
【改定前の条件テーブル】{current_terms}

「率を丸めない」を明記しないと丸まります。 3.5％や2.75％のような端数のある率は、読み取りの途中で切りのよい数字に寄ります。毎月の支払額に0.5ポイントの差が乗り続けても、誰も気づきません。

「上限が無ければ null、0 を入れない」も必ず書いてください。 欄がある以上、何かを入れようとします。0 が入ると上限が0円という意味になり、その取引先への支払が全部止まります。 逆に、上限があるのに読み落とせば払いすぎです。無いことと0であることを、同じ欄で区別させます。

出力形式を固定する

条件テーブルは、次の形のJSONで受け取ります。

{
  "contract_id": "", "partner_code": "", "document_type": "rebate_agreement",
  "terms": [
    {
      "term_id": "",
      "target_products": [""],
      "period_from": "", "period_to": "",
      "basis": "quantity | amount",
      "tiers": [ { "from": 0, "to": null, "rate": 0 } ],
      "deductions": [""],
      "cap": null,
      "payment_timing": "monthly | quarterly | annual | other",
      "effective_from": "",
      "retroactive_from": null,
      "status": "ok | needs_review | not_found",
      "source": { "page": 0, "article": "", "quote": "" }
    }
  ],
  "unresolved": [ { "point": "", "reason": "", "source": {} } ]
}

構造化出力を使う理由は2つあります。

1つ目は、null を正しく書けることです。 すべての項目を required にすることが求められ、値が無いことがある項目は null との組み合わせ（例："type": ["number", "null"]）で表します。 これが、上限の無いことと0であることを分ける仕組みです。

2つ目は、後段が読みやすいことです。 ルートはオブジェクトである必要があり、additionalProperties は false にします。 決めた欄以外が増えず、required なキーの欠落も enum に無い値も心配しなくてよいからです。

返ってこないことも設計に入れます。 拒否されると refusal の欄が入り、出力の上限で切れると response.status が incomplete、incomplete_details.reason が max_output_tokens になります。長い別表で起きやすいので、条ごとに分けて投げ直します。

計算結果は Python が次の形で書き出します。AIを通しません。

{
  "partner_code": "", "term_id": "", "terms_version": "",
  "period": { "from": "", "to": "" },
  "base_amount": 0,
  "applied_tier": { "from": 0, "to": 0, "rate": 0 },
  "deducted": 0, "capped": false,
  "calculated_amount": 0, "claimed_amount": 0, "difference": 0,
  "reason_code": "cutoff | return | unit | scope | period | cap | retro | unknown",
  "verdict": "match | review | hold"
}

terms_version は、どの版の条件で計算したかを残すためのものです。 版が無いと、条件が改定されたときに遡って直す範囲が決まりません。

システムへ連携する

差異に付ける理由コードは、次の順に当てます。順番に意味があります。

cutoff と return を先に当てるのは、この2つが圧倒的に多いからです。 先に契約の読み違いを疑うと、契約書を読み直す時間だけが増えます。理由を機械が先に1つに絞ると、④の2分が短くなります。

人が確認する

人が見る場所は3つです。それ以外は開きません。

1. 条件テーブルの承認 … 契約ごとに1回、改定時にもう1回。行と source の quote を並べて読み、 原文に無い言葉が quote に入っていたら作り直します
2. 差異のある行の確認 … verdict が review か hold の行だけを開きます。理由コードが合っていなければ unknown に戻します
3. 支払額の承認 … 支払の実行は必ず人が承認します。 自動で支払データを作りません

1番を飛ばすと、この構成は成り立ちません。 条件テーブルが間違っていれば、毎月その間違いで計算され続けます。契約ごとに1回きちんと見れば、あとは機械が同じ条件で回します。

3番は「承認ボタンを押すだけ」にしないでください。 画面に条件テーブルの版、当てた段、控除額、上限の適用を並べ、何にもとづく金額かが読める状態にします。

目標は、120件をならして1件3分の確認と1分の承認です。 開くのは2割前後という想定で、それより多い月は、needs_review が残っているか、前処理の単位がそろっていません。

例外に対処する

上から3行目が、いちばん間違えやすいところです。 遡及適用のときに過去の精算行を書き換えると、すでに払った金額との対応が分からなくなります。 過去の行を残して差額だけを新しい行にすれば、どの版の条件でいくら足りなかったのかが後から読めます。

請求が届かない分を「たぶんこの金額だろう」で払うのも避けてください。 その金額が翌年の基準になります。

記録を残す

• 契約書PDFと、そこから切り出した条・別表の範囲
• 条件テーブルの版ごとの全文と、source（ページ・条番号・原文）
• 人が条件テーブルを直した記録 … どの項目を、何から何に変えたか
• 計算に使った実績のスナップショット（取引先 × 商品 × 計上日）
• 計算結果、理由コード、当てた段、控除額、上限の適用の有無
• 承認した人と日時、承認の画面に表示されていた内容
• 遡及適用の記録 … どの期間を、どの版の条件で計算し直したか

条件テーブルの版と実績のスナップショットは対になっています。 「どの条件で」と「どの実績で」の両方が無いと、金額を再現できません。取引先に根拠を見せてほしいと言われたときに出すのは、この2つです。