海外のSaaSベンダーから毎月届く英文の請求書と利用量明細を読み取り、契約・部門ごとの利用量で費用を配賦して、前月から急に増えた請求を拾う

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 請求書は月初に集中しますが、ベンダーごとに締め日が違い、月の途中にも届きます。月末にまとめて処理すると、増えた請求に気づくのが支払の直前になります。

共有のメールボックスから受付フォルダへの保存は、メールのルールで添付ファイルを取り出す形にします。件名や送信元でベンダーを決め打ちしません。 送信元のアドレスはベンダーの都合で変わり、決め打ちすると、その月だけ処理されない請求が出ます。

保存を AWS Lambda が受け、StartExpenseAnalysis を呼びます。ClientRequestToken にファイルのハッシュから作った値を入れ、同じPDFが二度保存されても同じ JobId が返るようにします。 JobTag には受け取った月を入れます。

完了は NotificationChannel の Amazon SNS に届きます。状態が SUCCEEDED であることを確かめてから、GetExpenseAnalysis で結果を取ります。 JobId は7日間だけ有効なので、結果は取り次第 S3 に保存します。

入力データを集める

質を決めるのは、2つの対応表です。 品目の対応表が無ければ、明細行は毎月 unmapped になります。ワークスペースの対応表が無ければ、金額は読めても、どの事業部に配るかが決まりません。

対応表は、最初から全部を埋めなくて構いません。 unmapped の行が出るたびに人が対応を決め、表に1行足します。3か月ほどで、ほとんどの行が対応表で引けるようになります。

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

GetExpenseAnalysis の結果から、次のものを取り出します。

請求期間は標準の項目にありません。 「Billing period」「Service period」のような見出しは OTHER に入るので、LabelDetection の文字列で拾います。請求期間が取れないと、前月との比較の相手が決まりません。

ワークスペース名は EXPENSE_ROW から取ります。 明細の列にワークスペースやプロジェクトの名前があっても、標準の名前には入らないことがあるからです。行全体の文字列を生成AIに渡し、対応表と照らします。

GetExpenseAnalysis は1回の呼び出しで返す結果の数に上限があり、続きは NextToken で取ります。NextToken が返らなくなるまで取り切ってから保存します。 途中で止めると、明細の後半が無いまま配賦されます。

AIへ渡す前に整形する

1. 形式の確認 … StartExpenseAnalysis は JPEG、PNG、PDF を扱います。TIFFで届いたものはPDFにします
2. パスワードの確認 … PDFはパスワードで保護できません。保護されたものは担当者へ戻します
3. サイズの確認 … 非同期の処理でPDFは500MBが上限です
4. 言語の確認 … 英語以外の請求書が混ざっていないかを見ます。日本法人経由の日本語の請求書は、この構成の外で扱います
5. 請求書と明細の組み合わせ … 明細が別のPDFで届くベンダーは、請求番号で請求書と組にします
6. 重複の検知 … 同じベンダー・同じ請求番号のものが既にあれば止めます
7. 利用者の列を落とす … 席ごとに利用者の氏名やメールアドレスが並ぶ明細は、生成AIに渡す前にその列を消します。配賦に要るのはワークスペースと数量だけです

5番目が、この題材で手間のかかるところです。 明細に請求番号が書かれていないベンダーもあり、そのときは請求期間と口座番号で組にし、組にできなければ人へ回します。

AIに処理させる

させるのは2つです。 明細行を対応表にそろえることと、増えた明細行の差に理由の候補を付けることです。

対応づけには、対応表を必ず渡します。 対応表なしに「この明細はどの事業部の利用か」と聞くと、ワークスペースの名前から事業部を推し量ります。推し量った配賦は、一度入ると誰も直しません。

3行目がいちばん起きやすい失敗です。 「design-team」というワークスペースを見れば、AIはデザインの部署に結びつけます。実際には複数の事業部のデザイナーが使っていることもあり、対応表に書かれた結びつけ以外はさせません。

指示内容を固定する

あなたは情報システム部で、海外のSaaSの請求書の明細行を
社内の品目と事業部にそろえる担当です。
OCRが返した明細行と、渡した対応表だけを使ってください。推測で埋めないでください。

【やること】
1. 明細行ごとに、品目の対応表から品目コードを選ぶ
2. 明細行ごとに、行全体の文字列からワークスペース名を見つけ、
   ワークスペースの対応表から事業部を選ぶ
3. 明細行の種類を seat / usage / overage / one_time / discount / tax / unknown から選ぶ
4. 前月の明細行が渡されたときは、増えた行について差を並べる

【厳守事項】
- 対応表に無い組み合わせを作らないでください。
  見つからなければ mapping_status を unmapped にし、候補を書かないでください。
- ワークスペースの名前から事業部を推し量らないでください。
- 金額の計算、合計、按分、外貨の換算をしないでください。
  金額は読み取り結果の文字列をそのまま amount_text に写してください。
- 明細行を足したり、まとめたり、省いたりしないでください。
  入力の行数と出力の行数を同じにしてください。
- 増えた理由は、数量の差、単価の差、新しく現れた行、消えた行のうち、
  明細から読み取れるものだけを書いてください。
  契約の変更や担当者の操作など、明細に書かれていない理由を書かないでください。
  説明できなければ「明細からは不明」としてください。
- 税の扱いについて意見を書かないでください。

【明細行】{line_items}
【品目の対応表】{product_map}
【ワークスペースの対応表】{workspace_map}
【前月の明細行】{previous_lines}

「入力の行数と出力の行数を同じに」を書かないと、行がまとめられます。 同じ品目が2行に分かれていると、AIは親切に1行にまとめます。まとめた行は、どちらのワークスペースの行だったかが消えます。 行数をそろえさせ、プログラムで行数を数えて確かめます。

「明細に書かれていない理由を書かない」も同じです。 席数が増えた行を見ると、AIは「新しいメンバーの参加」と書きます。それは推測で、契約の担当者に聞く前に答えが書かれていると、聞かずに済ませてしまいます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に json_schema）で形を守らせます。

{
  "invoice_id": "",
  "contract_id": "",
  "lines": [
    { "line_no": 1, "item_text": "", "amount_text": "", "quantity_text": "",
      "product_code": "", "workspace": "", "division": "",
      "line_type": "seat | usage | overage | one_time | discount | tax | unknown",
      "mapping_status": "mapped | unmapped" }
  ],
  "increase_notes": [
    { "line_no": 1, "diff": "quantity | unit_price | new_line | removed_line",
      "evidence": "", "reason_candidate": "" }
  ]
}

1つ目の理由は、按分をプログラムに渡せることです。 division と amount_text がそろえば、按分は機械的に決まります。プログラムは amount_text を数値に直し、明細の合計と SUBTOTAL が一致するかを検算してから按分します。

2つ目は、印を機械的に決められることです。

3つ目は、evidence で確認が速くなることです。 担当者はPDFを開く前に、どの行の数量がいくつからいくつに変わったかを読めます。

システムへ連携する

配賦表は明細行ごとに1行、列は「契約番号／請求番号／請求期間／品目コード／ワークスペース／事業部／通貨／金額／印」とし、事業部ごとの合計は別のシートに出します。明細行の単位で残しておくと、事業部から「なぜこの額か」と聞かれたときに元の行まで戻れます。

会計システムには書き込みません。 確定した配賦表を、経理が既存の取り込みの手順で入れます。契約台帳の対応表も、自動では書き足しません。 unmapped の行の対応を決めるのは人で、決めた結果を人が表に足します。

人が確認する

人が開くのは、印の付いた請求だけです。 ok の請求は、事業部ごとの配賦額を一覧で流し見ます。

1. needs_human を先に見る … 合計や通貨が読めなかったもの、検算が合わないものです。PDFを開いて値を確定します
2. unmapped の行の対応を決める … 決めたら対応表に1行足します。同じ行は来月から自動でそろいます
3. spike の理由を確かめる … increase_notes を読み、必要なら契約の担当者に聞きます。席の削減や契約の見直しにつなげるかは、契約の担当者が決めます
4. 経理が配賦表を確定する … 確定した表だけが会計と管理会計に回ります

2番目は手間ではなく投資です。 初月は unmapped が多く出ますが、対応表に足した分だけ翌月の確認が減ります。

目標は、120件をならして1件5分です。 印が付くのは3割前後という想定で、それより多い月は、対応表が追いついていないか、spike の基準が厳しすぎます。 印の件数を毎月数え、どちらが原因かを見分けます。

例外に対処する

5行目が見落としやすい失敗です。 明細が長い請求書で NextToken を取り切らずに止めると、後半の明細が無いまま、それらしい配賦表ができます。 検算で止まるようにしておきます。

記録を残す

• 元の請求書と明細のPDF、受け取った日時
• AWS Textract の結果のJSON全文と JobId
• Claude API の出力（lines、increase_notes）
• 配賦に使った対応表の版
• 按分の結果と、検算の結果
• 人が対応を決めた記録と、spike の確認の結果

4つ目で対応表の版を残すのは、表が毎月育つからです。 後から配賦を見直すとき、どの月にどの対応で配ったかが分からないと、事業部への説明ができません。