広告会社が広告主へ請求する前に、媒体ごとの出稿実績・媒体からの請求・契約の手数料率を突き合わせ、請求額の食い違いと請求漏れを洗い出す

処理の起点を決める

媒体ごとの受付フォルダにファイルが追加されたことを起点にします。 媒体のデータは月初の数日にばらばらに届くので、届いた媒体から順に並べ、3つがそろった広告主×媒体から判定に進めます。 全部がそろうのを待つ形にすると、検算に使える3日が削られます。

もう一つの起点は、月初の第3営業日の朝の定時実行です。 この時点で3つがそろっていない広告主×媒体を一覧にし、どのデータが足りないかを運用と経理の担当に知らせます。Google 広告では、月ごとの請求書による支払の場合、毎月の初めから5営業日以内に請求書がメールで届くとされています。媒体の請求がそろう日を媒体ごとに表に持ち、待つべきものと催促すべきものを分けます。

処理の済んだファイルは、処理済みのフォルダへ移します。 移すのは読み込みが成功したときだけにします。同じ月の同じ媒体のファイルが2回置かれたときは、新しいほうで置き換え、置き換えた記録を残します。

入力データを集める

質を決めるのは、広告主の対応表と契約の条件の表です。 対応表が無ければ、媒体の側のアカウントを広告主にそろえられず、並べる段階で止まります。 契約の条件の表の「調整の扱い」の列は、媒体からのクレジットを広告主に返すのか、手数料の計算の前に引くのかを書く欄で、ここが空だと判定が unknown ばかりになります。

特約の文は、表の列にそのまま入れます。 「動画の媒体は手数料15％」「月の媒体費が50万円未満の月は最低手数料10万円」のような決まりは、列に分けきれないものが必ず残ります。 文のまま持たせ、判定のときにAIに読ませます。

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

管理画面の実績は、請求の正確な額の代わりにはなりません。 Google 広告のヘルプでは、キャンペーンの画面と請求の画面の費用が違うのは、無効なクリックのクレジット、配信の超過のクレジット、クレジットの調整によるもので、最も正確な費用は請求の画面を見るようにとされています。調整は反映に時間がかかるともされています。この構成では、広告主への請求の基礎を媒体の請求の側に置き、実績は差の理由を確かめる材料に使います。

媒体の請求をキャンペーン別に分けられない場合があります。 Google 広告のヘルプでは、キャンペーンごとに別の明細書を受け取ることはできないとされています。1つの媒体のアカウントに複数の広告主のキャンペーンが同居している場合は、実績の費用の比率で請求を按分する規則を、経理と営業で決めておきます。

AIへ渡す前に整形する

1. 列の正規化 … 媒体ごとのデータ構造で読み、日付・アカウントID・キャンペーンID・費用・通貨の共通の列にそろえます
2. 金額の正規化 … 桁区切りのカンマ、全角の数字、税込・税抜の混在をそろえます。税込か税抜かは媒体ごとの表で決めます
3. 対象月の決定 … 実績は日付で、請求は請求の対象月の欄で月を決めます。請求書の発行日で月を決めないようにします
4. 広告主への寄せ … 対応表でアカウントIDとキャンペーンIDから広告主コードを付けます。対応表に無いものは unmapped にします
5. 3つの突き合わせ … 広告主×媒体×月の単位で、実績・請求・下書きを1行に並べます。どれか1つでもある組み合わせは、すべて行を作ります
6. 見込みの計算 … 契約の条件の表の率と方式で、媒体の請求の額から広告主への請求額の見込みを出します
7. 差の判定と絞り込み … 差が許容の範囲（媒体ごとに額と率で決める）を超えたもの、下書きに行が無いものだけを次に回します

5番目の「どれか1つでもあれば行を作る」が、請求漏れを拾う仕組みです。 下書きを起点に並べると、下書きに無いものは並びません。実績か請求のどちらかがあって下書きに無い行が、請求漏れの候補です。

7番目の許容の範囲は、差の種類ごとに分けて持ちます。

実績と請求の差に幅を持たせるのは、運用型の広告では調整で差が出るのが普通だからです。 一方で、見込みと下書きの差は計算どうしの差なので、1円でも違えば理由があります。

6番目の計算は、ワークフローの側で行います。 ネット建てなら媒体費×（1＋率）、グロス建てなら媒体費÷（1－率）のように、方式で式が変わります。この計算をAIにさせると、方式を取り違えたまま、もっともらしい額を書きます。

AIに処理させる

させるのは、計算で出た差の1件ずつについて、原因の区分を1つ選び、根拠になったデータの行と契約の条件の文を示すことです。

AIに渡すのは、その1件の行と、比べるための候補の額です。 「別の率で計算した額」「もう一方の方式の額」は、ワークフローがあらかじめ計算して渡します。 AIは、渡された額のどれが下書きと合うかを見て区分を選ぶだけです。

1行目がいちばん大事です。 「グロス建てで計算し直すと〇〇円になります」と書かせると、AIが計算した額が直した後の請求額として使われるおそれがあります。額はワークフローが出したものだけを使います。

指示内容を固定する

あなたは広告会社の経理部で、広告主へ請求する前の検算を担当しています。
渡された1件の差について、原因の区分を1つ選んでください。
渡されたデータと契約の条件だけを使ってください。推測で埋めないでください。

【区分】
adjustment / timing / rate_mismatch / base_mismatch / minimum_fee /
unbilled / no_contract / unknown

【判定の手がかり】
- adjustment：請求の明細に調整・クレジットの行があり、その額で差が説明できる
- timing：前月・翌月の記録に、同じ広告主・媒体で逆向きの差がある
- rate_mismatch：candidate_amounts の「他の率での額」のどれかが下書きの額と一致する
- base_mismatch：candidate_amounts の「もう一方の方式の額」が下書きの額と一致する
- minimum_fee：契約の特約に最低手数料があり、媒体費がその基準の前後にある
- unbilled：実績か媒体の請求があり、下書きの行が無い
- no_contract：契約の条件にその媒体の行が無い

【厳守事項】
- 金額を計算しないでください。比べるのは渡された額どうしだけです。
- 「一致する」は、渡された額が1円の単位まで同じ場合だけです。
  近い額を一致として扱わないでください。
- 区分は1つだけ選んでください。2つ以上当てはまりそうなら unknown にしてください。
- evidence には、根拠にしたデータの行の番号と、契約の条件の文をそのまま写してください。
- 契約の特約の文が、この差に当てはまるか読み切れないときは unknown にしてください。
- 請求額をいくらにすべきか、広告主や媒体にどう伝えるかは書かないでください。
- 運用の担当に確かめないと決められない場合は、needs_ops_check を true にし、
  ops_question に、運用の担当がその場で答えられる質問を1つ書いてください。

【差の行】{diff_row}
【比べるための候補の額】{candidate_amounts}
【媒体の請求の明細（この広告主・媒体・月）】{invoice_lines}
【契約の条件】{contract_terms}
【前月・翌月の記録】{adjacent_months}

「近い額を一致として扱わない」を明記しないと、端数の差を一致と読みます。 手数料の率の取り違えは、1円の単位で合うかどうかで見分けます。近い額で区分を決めると、別の原因の差が rate_mismatch に紛れます。

「2つ以上当てはまりそうなら unknown」は、確認の順番を守るためです。 調整と計上月のずれが同時に起きている月はあり、AIが片方を選ぶと、もう片方の確認が省かれます。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "diff_id": "2026-09_ADV-0231_MEDIA-07",
  "category": "base_mismatch",
  "matched_candidate": "gross_basis_amount",
  "evidence": [
    "請求明細 行3：対象月2026-09 媒体費 1,200,000",
    "契約の条件：手数料はグロス建て20％"
  ],
  "needs_ops_check": false,
  "ops_question": "",
  "confidence_note": ""
}

1つ目の理由は、区分を列挙の値に固定できることです。 スキーマで category を8つの値に限れば、集計と並べ替えがそのまま効きます。 経理の担当は、区分ごとにまとめて確かめられます。

2つ目は、matched_candidate で、どの額と合ったかを機械で確かめられることです。 ワークフローは、AIが選んだ候補の額と下書きの額が本当に一致するかを受け取った後に計算で確かめます。 合っていなければ、区分を unknown に戻して人へ回します。

3つ目は、evidence で確認が速くなることです。 元のCSVを開く前に、どの行と契約のどの文で判定したかを読めます。

システムへ連携する

販売管理の仕組みへは書き込みません。 請求の下書きを直すのは経理の担当です。この構成から請求の額を書き換える経路を作ると、AIの判定の誤りが、そのまま広告主への請求書になります。

人が確認する

人が見るのは、許容の範囲を超えた差だけです。 許容の範囲に収まった行は、件数と合計の額だけを一覧で流し見ます。

1. すぐ確かめる区分を先に見る … rate_mismatch、base_mismatch、minimum_fee、unbilled。契約の条件の表と、契約書の原本を照らして確かめます
2. 人が調べる区分を見る … unknown と no_contract。営業の担当に、契約の中身を確かめます
3. まとめて確かめる区分を流し見る … adjustment は請求の明細の調整の行を、timing は前後の月の記録を確かめます
4. 下書きを直し、記録する … 直した額と、その理由の区分を記録に付けます

1番目で契約書の原本まで見るのは、契約の条件の表が誤っていることがあるからです。 表の率と下書きの率が違うとき、誤っているのが表の側ということも珍しくありません。 表を直したら、同じ広告主の過去の月も見直します。

例外に対処する

上から2行目と3行目が、最初の月に集中します。 対応表の整備が追いついていないと、判定の前の段階で止まる行が多く出ます。 判定の精度より先に、対応表を埋めてください。

記録を残す

• 受け取ったファイルと、読み込んだ日時、使ったデータ構造の版
• 広告主×媒体×月で並べた行と、計算した見込みの額、候補の額
• AIの判定の結果（JSONの全文）と、計算で一致を確かめた結果
• そのとき参照した契約の条件の表の内容
• 人が直した額と、その理由の区分
• 毎月続く差の一覧（同じ広告主・媒体で同じ区分が続いているもの）

4つ目で契約の条件の内容を残すのは、表が後から直るためです。 率を直した後に過去の月を見直すとき、当時どの率で検算したかが残っていないと、見直しの範囲が決まりません。