海外の現地代理人から毎月届く英文のデビットノートを読み取り、料金の取り決めと案件台帳に照らして支払う前に点検する

処理の起点を決める

受付フォルダ（Amazon S3）にPDFが保存されたことを起点にします。 デビットノートは月末と月初に集中しますが、1日1回の定時処理にはしません。照会が必要なものを早く見つけ、代理人の月次の締めに間に合わせたいからです。照会が翌月にずれると、代理人の側でも当時の記録を探し直す手間がかかります。

メールの添付も、代理人のポータルから取得したものも、同じフォルダに入れ、そこから先は区別しません。

処理が終わったファイルは処理済みの場所へ移します。移すのは、判定の一覧への書き出しまで成功したときだけです。 受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の4つです。 指示記録が無ければ「指示した作業か」を確かめられません。料金の取り決めに適用開始日が無ければ、値上げの前に指示した作業に新しい料金が当たっているのか、正しく旧料金なのかを決められません。

登録済みの振込先は、なりすましを見つけるために持ちます（第13章）。

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

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

自社の整理番号は、標準の項目に決まった場所がありません。 「Your Ref.」として書かれることが多く、PO_NUMBER に入ることもあれば OTHER になることもあります。LabelDetection（書類に書かれていた項目名）を見て、「Your Ref」「Client Ref」に当たる値を拾います。

AIへ渡す前に整形する

1. 形式の確認 … StartExpenseAnalysis が扱うのはJPEG、PNG、PDFです。XFA形式のPDFには対応していません。 対応外のものはPDFに変換します
2. パスワードの確認 … パスワードで保護されたPDFは読めません。 代理人に保護のないものを送り直してもらいます
3. ページ数とサイズの確認 … 非同期の処理はPDFで500MB・3,000ページまで。1枚の請求ならまず収まります
4. 解像度の確認 … 読み取れる文字の高さは15ピクセル以上で、150dpiで8ポイントの文字に当たります。明細の脚注の小さな文字が、この下限に近いことがあります
5. 数値・日付の正規化 … 代理人の一覧の書き方で、金額と日付を自社の形に直します。元の文字列は残します
6. 複数の請求の分割 … 1つのPDFに複数のデビットノートがあれば、ExpenseIndex（文書内の請求書の番号）で分けます
7. 重複の検知 … 同じ代理人・同じ請求番号のものが既にあれば、再送か重複かの印を付けます

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

AIに処理させる

させるのは、明細の1行ずつを「どの案件の、どの作業の、どの種類の費用か」に対応付け、根拠にした文字列を写すことだけです。

3行目の combined が、この構成で大事な区別です。 手数料と庁費用が1行に合算されているものを、どちらか一方として扱うと、取り決めの照合が通ってしまうか、根拠の無い差額が出ます。 合算は合算として記録し、内訳を求めるかは規則で決めます。

3行目がいちばん起きやすい失敗です。 合算行を渡すと、取り決めの手数料を差し引いて「残りが庁費用」と割り振りたがります。その瞬間、手数料が取り決めどおりかという、確かめたかったことが確かめようのない値で埋まります。

指示内容を固定する

あなたは特許事務所の外国部で、海外の現地代理人から届いたデビットノートを点検する立場です。
OCRが返した項目と明細の行だけを見て、各行を対応付けてください。推測で埋めないでください。

【やること】
1. 請求全体と各行から、自社の整理番号（Your Ref. / Client Ref. など）と
   代理人側の整理番号（Our Ref. など）を書き出す
2. 各行の作業名を、下に示す作業区分の一覧のどれに当たるかで対応付ける
3. 各行の費用の種類を service（手数料）/ official（庁費用）/ disbursement（実費）から選ぶ
4. 行に書かれた作業日、引用されている庁の通知の日付を書き出す
5. 時間制の記載（時間数・時間単価）があれば書き出す

【status の選び方】
- ok .......... 対応付けができ、根拠の文字列がある
- unmapped .... 作業区分の一覧に当たるものが無い
- combined .... 1行に複数の費用の種類（例：Official fee and our charges）が合算されている
- ambiguous ... 整理番号や作業区分の候補が複数あり、1つに決められない
- unreadable .. 文字は検出されているが信頼度が低く、値として確定できない
迷ったときに ok を選ばないでください。

【厳守事項】
- 金額と通貨は、OCRの値をそのまま amount_text と currency に入れてください。
  桁区切りや小数点を直さないでください。通貨を換算しないでください。
- 合算されている行を分けないでください。取り決めの手数料を差し引いて
  庁費用を逆算することをしないでください。status を combined にしてください。
- 整理番号は読み取った文字列をそのまま入れてください。
  似た番号に直す、桁を足すことをしないでください。
- 作業区分の一覧に無い作業を、近い区分に寄せないでください。unmapped にしてください。
- evidence には、判断の根拠にした明細の文字列をそのまま写してください。
- confidence には OCR が返した値をそのまま入れてください。
- 料金が取り決めどおりか、支払うべきかは書かないでください。
- デビットノート以外の書類（見積書、報告書、領収書の控えなど）と判断した場合は、
  対応付けをせず document_type に種類を書いてください。

【作業区分の一覧（コードと説明）】{work_codes}
【この代理人の情報（既定の通貨、整理番号の書き方）】{associate_profile}
【OCRの結果（標準の項目と明細の行）】{textract_result}

「近い区分に寄せない」を明記しないと、必ず寄せます。 代理人が気を利かせて行った「Prior art check」を「Reporting」として対応付けると、指示していない作業の請求が、指示した作業として照合を通ります。 第3章の（a）そのものです。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（あらかじめ決めたJSONの形に沿った応答だけを返させる機能）を使い、output_config.format にスキーマを渡します。status と cost_type の選択肢は enum で固定します。

{
  "document_type": "debit_note",
  "associate": "",
  "invoice_no": "",
  "invoice_date_text": "",
  "client_refs": [""],
  "lines": [
    { "line_no": 1, "client_ref": "", "associate_ref": "",
      "work_code": "", "cost_type": "service | official | disbursement",
      "work_date_text": "", "amount_text": "", "currency": "",
      "status": "ok | unmapped | combined | ambiguous | unreadable",
      "confidence": 0, "evidence": "" }
  ]
}

AIが埋めるのはここまでです。 この後ろに、Python が照合の結果を足します。

対応付けと判定を別の層に置くので、 差額をいくらまで許すかが変わっても、直すのは Python の規則だけです。

最後の行だけは、他の条件より優先します。 金額がすべて合っていても、振込先が違えば支払に回しません。

システムへ連携する

案件管理システムと会計システムへは書き込みません。 この構成が出すのは点検の結果と下書きまでです。支払と顧客への請求を起こすのは、経理の既存の手順です。 書き込みを足すと、対応付けの誤りがそのまま顧客への請求書に出ます。

照会文は英文、顧客への請求明細は日本語で下書きします。 照会文には合わない行を evidence の英文のまま引用させます。

人が確認する

人が開くのは query_associate と needs_human のものだけです。 approve のものは、代理人・件数・合計を一覧で流し見ます。全件を開く設計にすると、第10章の20.0時間には収まりません。

1. 振込先の不一致を最初に見る … 支払を止め、登録済みの連絡先で代理人に確かめます。メールの返信で確かめないでください
2. needs_human を見る … 多くは整理番号の読み違いか、作業区分の一覧の不足です。一覧に区分を足したら、それも記録します
3. query_associate の根拠を確かめる … 指示記録と取り決めの表を開き、本当に台帳に根拠が無いのかを確かめます
4. 照会文を直して送る … 送信は人が行います。照会の要否を決めるのも人です
5. 判定を覆したら記録する … どの行を、どちらに変えたかを残します

3番目を省かないでください。 指示記録の入力漏れで no になることがあり、そのまま照会すると自社の記録漏れを代理人に問い合わせることになります。

目標は、120件をならして1件10分です。 照会が3割を超える月は、作業区分の一覧か指示記録の入力に穴があります。

例外に対処する

下から2行目は、請求番号だけでは見つかりません。 請求を作り直すと番号が変わるので、案件・作業区分・金額の組で直近の請求と照らします。

記録を残す

• 元のデビットノートと、受け取った日時・経路
• Textract が返したJSONの全文（標準の項目、明細の行、項目名、信頼度）
• 正規化の前と後の金額・日付（元の文字列を残す）
• 対応付けの結果（lines）と、照合に使った取り決めの表の版と庁費用の表の版
• 判定（verdict）と、人が覆した記録
• 照会を送った日時、代理人の回答、訂正されたデビットノートとの対応
• 代理人ごとの unmapped と combined の件数

4つ目で表の版を残すのは、取り決めが後から変わるためです。 値上げの交渉の後に過去の請求を見直すとき、当時どの料金で照らしたかが残っていないと、照会の根拠を説明できません。