海外の広告媒体から毎月届く英文の請求書を読み取り、出稿の申込（IO）と配信実績に照らして、広告主へ請求する前に金額・期間・キャンペーン名の食い違いを洗い出す

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 請求書は月の初めの数日に集中して届くため、届いた順に処理します。月の初めの10日間に照合を終えたいので、まとめて夜に流すより、届いたものから食い違いを出したほうが照会の時間を確保できます。

請求書の受け取り用のメールアドレスを媒体ごとに案内しておき、添付を自動で受付フォルダへ保存する形にすると、担当者の保存の手間もなくなります。

配信実績のファイルは、媒体ごとに月の締めの後で出力して別のフォルダに置きます。 請求書と実績のどちらかが先に届いても、照合は両方がそろった時点で動かします。処理が終わった請求書は処理済みの場所へ移し、移すのは照合の一覧への書き出しまで成功したときだけにします。

入力データを集める

質を決めるのは、名前の辞書と過去の請求です。 辞書が育つほどAIの対応付けに頼る行が減り、過去の請求が無いとクレジットを元の請求につなげません。

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

読み取りは、Lambda から StartExpenseAnalysis を呼んで始めます。 文書はS3の場所で指定し、完了の通知先にSNSのトピックを渡します。ClientRequestToken に受付のファイルごとの値を入れ、同じ請求書の処理が二重に始まらないようにします。 JobId は7日間しか有効でないので、完了を受けたらすぐに GetExpenseAnalysis で結果を取り、自社のバケットへ書き出します。

IOの番号は、媒体ごとに置き場所が違います。 PO_NUMBER に入る媒体もあれば、明細の行の説明に「IO#12345」と書く媒体もあります。媒体の一覧に「IOの番号を書く欄」を持たせ、LabelDetection（書かれていた項目名）で拾い分けます。

配信実績は、管理画面から出力したCSVを Python で読みます。 媒体ごとに列の名前が違うので、媒体の一覧に列の対応（どの列が費用か、どの列がキャンペーンIDか）を持たせます。 出力するときは、期間を請求書の締めと同じ月の初日から末日にそろえ、時間帯の設定も媒体の請求の基準に合わせます。 ずれていると、月末の1日分の費用が差として出続けます。

AIへ渡す前に整形する

1. 形式の確認 … StartExpenseAnalysis が扱うのはJPEG、PNG、PDFです。XFA形式のPDFには対応していません
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 媒体に保護のないものを送り直してもらいます
3. ページ数とサイズの確認 … 非同期の処理はPDFで500MB・3,000ページまで。明細の多い請求書も収まります
4. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上（150dpiで8ポイント）。明細の行の小さな文字が、この下限に近いことがあります
5. 数値の正規化 … 媒体の一覧の書き方で、金額と日付を自社の形に直します。元の文字列は残します
6. 期間の取り出し … 明細の行に「Oct 1 - Oct 31」のような配信の期間があれば、開始と終了に分けます
7. 重複の検知 … 同じ媒体・同じ請求番号のものが既にあれば、再送か重複かの印を付けます

5番目はAIに任せません。 「1.250,00」の読み方を生成AIに決めさせると、千倍ずれた値を返すことがあります。書き方は媒体の一覧で決め打ちします。

AIに処理させる

させるのは、明細の行の種類を分け、IOのキャンペーンの候補に対応付け、根拠にした文字列を写すことだけです。

候補を最大3つまで出させるのは、似た名前のキャンペーンが同じ広告主に並ぶからです。 「BrandX_Q4_Video_A」と「BrandX_Q4_Video_B」のように、IOでは別の上限を持つ2つが、名前の末尾だけで分かれます。1つに決めさせると、もっともらしい方を選んで終わります。

1行目がいちばん起きやすい失敗です。 請求書とIOを並べて渡すと、AIは頼まなくても差を計算し、「おおむね一致」とまとめます。 そのまとめが、上限を少し超えた請求を見落とす原因になります。

指示内容を固定する

あなたは広告会社の経理部で、海外の媒体からの請求書の明細を、
出稿の申込（IO）のキャンペーンに対応付ける立場です。
渡すのは、OCRが返した明細の行と、その媒体・その月に有効なIOの一覧です。
そこに書かれたことだけを使ってください。

【書き出すこと】
1. line_type: media_cost / fee / credit_adjustment / tax / other / unknown
2. media_cost の行: IOのキャンペーンの候補を最大3つ。
   それぞれに、対応の根拠にした文字列（請求書側とIO側）を写す
3. credit_adjustment の行: 元の請求番号、元の月、元のキャンペーンの記載
4. 行に書かれた配信の期間

【厳守事項】
- 書かれていない項目は「不明」としてください。推測で埋めないでください。
- 金額を比べたり、差を計算したりしないでください。
  「一致」「おおむね一致」などの評価を書かないでください。
- 候補が見つからない行は unmatched とし、候補を作らないでください。
  広告主が同じというだけで候補にしないでください。
- 候補を1つに絞れないときは、無理に絞らず複数を挙げてください。
- 金額と日付は、読み取り結果の文字列のまま写してください。
- クレジットの元の請求番号や元の月が書かれていなければ「不明」とし、
  当月の請求に当てはめないでください。
- 媒体へ照会すべきかを書かないでください。
- evidence には、根拠にした文字列をそのまま写してください。
- 請求書でない書類（実績レポート、見積など）と判断した場合は、
  対応付けをせず document_type に種類を書いてください。

【明細の行】{line_items}
【この媒体・この月に有効なIOの一覧】{io_list}
【名前の辞書で既に対応が決まっている行】{known_mappings}

「広告主が同じというだけで候補にしない」を書かないと、unmatched がほとんど出ません。 同じ広告主のIOが1つしか無ければ、それを候補にして返します。IOの無い出稿（運用の担当者が管理画面だけで足したもの）が見えなくなります。

名前の辞書で決まっている行も渡すのは、残りの行の手がかりになるからです。 同じ請求書の中で「_A」が決まっていれば、「_B」の候補は絞れます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format にJSONスキーマを渡す）を使うと、スキーマどおりの形で返り、必須の項目が欠けません。

{
  "invoice_id": "",
  "media": "",
  "document_type": "invoice",
  "lines": [
    { "item_text": "", "amount_text": "", "period_text": "",
      "line_type": "media_cost",
      "io_candidates": [ { "io_id": "", "campaign": "", "evidence": "" } ],
      "credit_ref": { "original_invoice": "", "original_month": "" } }
  ]
}

この後に、Python が照合を足します。

1つ目の理由は、上限を「累計」で見られることです。 IOの上限は、キャンペーンの期間全体での金額です。月ごとの請求だけを見ると、3か月目で上限を超えたことに気づきません。 過去の請求を足し上げて照らすのは、規則の側でしかできません。

2つ目は、クレジットを元の月につなげることです。 不正な操作に対するクレジットの詳細には、元の請求番号、元のサービスの月、PO番号、キャンペーン名などが含まれるとする媒体もあります。元の行が分かれば、広告主への請求をどの月で直すかが決まります。 なお、同じ媒体の説明では、請求のやり直しがあった場合に元の番号が変わっていることもあるとされています。

システムへ連携する

会計システムへは書き込みません。 照合の結果は一覧までで、支払の登録と広告主への請求は、確認を終えた人が既存の手順で行います。名前の辞書への追記も、メディア部の担当者が確定したものだけです。

人が確認する

人が開くのは match 以外の行です。 種類ごとに見る人と順を決めます。

1. over_io を最優先で見る … 超過額を確かめ、媒体に照会するか、広告主と相談するかをメディア部と決めます
2. unmatched を見る … IOの無い出稿か、辞書の抜けか。IOの無い出稿なら、広告主への請求の根拠が無いので、まずメディア部に事情を聞きます
3. amount_diff と period_diff を見る … 差額が許容を少し超えた程度なら、調整の反映待ちかを媒体の次の請求で確かめます
4. credit のつなぎ先を確かめる … 元の行と、広告主への請求をどの月で直すかを決めます
5. 対応を確定したら辞書に残す … 翌月から同じ名前の行は機械で引けます

5番目が、この構成を月ごとに速くします。 最初の月は needs_human と unmatched が多く出ますが、辞書が育つと、毎月同じ名前で請求される継続のキャンペーンは確認の対象から外れます。

目標は、150件をならして1件12分です。 明細の多い請求書で over_io が出ると30分以上かかり、継続のキャンペーンだけの請求書は数分で終わる想定です。

例外に対処する

下から3行目を軽く見ないでください。 「振込先が変わりました」という連絡と一緒に届く請求書は、なりすましの典型です。メールの返信で確かめず、登録済みの連絡先に別の経路で確かめます。

記録を残す

• 元の請求書のPDFと、受け取った日時・送り元
• OCRが返したJSONの全文
• AIが返したJSONと、そのとき参照したIOの一覧と名前の辞書の版
• 配信実績のファイルと、照合に使った列の対応
• 行ごとの判定と差額、IOごとの累計の請求額
• 人が対応を確定・変更した記録と、辞書への追記
• 媒体への照会と回答、広告主への請求に反映した月

「IOごとの累計の請求額」を残すのは、上限の照合が累計で行われるためです。 途中の月の請求を後から直したとき、どの月の照合をやり直すかが、この記録で決まります。