海外の仕入先から届く英文のクレジットノートを読み取り、対象の請求書と返品・値引きの内訳を買掛金の明細と返品の記録に照らして、計上漏れと金額の食い違いを拾う

処理の起点を決める

受付フォルダ（Amazon S3）にクレジットノートが保存されたことを起点にします。 仕入先ごとに発行の時期がばらばらで、返品の数日後に来るものも、月末にまとめて来るものもあるため、1日1回の定時実行にはしません。 届いた日に照らせば、支払の締めの前に減額を反映できます。

S3 への保存を AWS Lambda が受け、StartExpenseAnalysis を呼びます。ClientRequestToken に仕入先のコードとファイルのハッシュから作った値を入れると、同じトークンで呼び直しても同じ JobId が返り、同じクレジットノートを二度読みません。 JobTag には仕入先のコードを入れ、完了の通知（Amazon SNS）から仕入先を引けるようにします。通知の状態が SUCCEEDED であることを確かめてから結果を取り、すぐ S3 に保存します。 JobId は7日間しか有効ではありません。

届いていない減額の一覧は、別のトリガーで動かします。 毎週月曜に返品の記録を読み、出荷から仕入先ごとに決めた日数を過ぎてもクレジットノートの記録が無い返品を数えます。支払の締めの前の週に必ず1回回るように曜日を決めます。

入力データを集める

質を決めるのは、下の3つです。 返品の記録が無ければ「減額されるはずの分」を数えられず、値引きの合意が無ければ値引きの額を確かめられず、前月までの計上が無ければ二重計上を見つけられません。値引きの合意は、購買がメールで済ませていることが多いため、一覧に登録する手順を最初に決めます。

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

結果は GetExpenseAnalysis で取ります。1回の呼び出しで返る件数は既定・最大20で、NextToken が返る限り続けて取ります。 JobStatus が PARTIAL_SUCCESS のときは Warnings に出たページを記録し、そのクレジットノートを needs_human にします。

ここに、この題材に固有の落とし穴があります。 クレジットノートにはそれ自身の番号と、対象の請求書の番号の両方が書かれています。標準の項目 INVOICE_RECEIPT_ID にどちらが入るかは様式次第です。LabelDetection に残る見出しの文字（「Credit Note No.」「Ref. Invoice」など）を必ず見て、2つの番号を取り違えないようにします。

金額の符号も様式次第です。 「-1,250.00」と書く仕入先、「1,250.00 CR」と書く仕入先、符号なしで見出しだけ「Credit」とする仕入先があります。プログラムでは符号を当てにせず、「クレジットノートの金額はすべて減額」として扱います。

AIへ渡す前に整形する

1. 形式の確認 … 請求書の分析で非同期に扱えるのは JPEG、PNG、PDF です。TIFFで届いたものはPDFに変換します
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは仕入先に解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFは500MB・3,000ページが上限です。返品の明細書や検査の報告書が添付されているものは、クレジットノートの部分と分けます
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です
5. 書類の種類の確認 … 請求書・デビットノート・取引残高の明細が同じ受信箱に届きます。見出しに「Credit Note」「Credit Memo」が無いものは、この処理から外します
6. 照合の相手の準備 … その仕入先の買掛金の明細（直近12か月）、返品の記録、値引きの合意、前月までの計上を読み込みます

5番目を省かないでください。 請求書を減額の書類として読むと、買掛金を増やすべきものを減らす起票の候補が出ます。 見出しで分けられないものは needs_human にします。

AIに処理させる

させるのは、対象の請求書番号・減額の理由・明細の行を切り出し、元の請求書の行に対応付ける手がかりを添えることだけです。

理由の区分は、照らす相手を決めるために使います。 return なら返品の記録、shortage なら入荷の検品の記録、discount なら値引きの合意、price_correction なら元の請求書の単価です。区分を誤ると、照らす相手そのものが間違います。

2行目がいちばん起きやすい失敗です。 対象の請求書番号が書かれていないクレジットノートを渡すと、AIは品番と日付から「おそらくこの請求書」と埋めがちです。埋めた瞬間、どの請求書の減額かという肝心の点が、AIの推測にすり替わります。 無ければ not_found と返させ、品番と時期からの候補探しはプログラムに任せます。

指示内容を固定する

あなたは専門商社の経理部で、海外の仕入先から届いた英文のクレジットノートを点検する担当です。
OCRが返した読み取り結果だけを見て、項目を切り出してください。推測で埋めないでください。

【やること】
1. クレジットノート自身の番号と、減額の対象になっている請求書の番号を分けて写す
2. 減額の理由を下の区分から選ぶ
3. 明細の各行から、品番・数量・単価・金額を原文のまま写す
4. 各項目の根拠にした原文の文字列を evidence に入れる

【番号の見分け方】
- 「Credit Note No.」「Credit Memo No.」などの見出しの番号は credit_note_no に入れる
- 「Original Invoice」「Ref. Invoice」「Against Invoice」などの見出しの番号は ref_invoice_nos に入れる
- 見出しから見分けられなければ、両方を "ambiguous" にする

【減額の理由の区分】
- return ............ 返品（Return、RMA の記載がある）
- shortage .......... 数量不足（Short shipment、Shortage）
- discount .......... 値引き（Discount、Allowance、Price concession）
- price_correction .. 単価や数量の訂正（Price correction、Invoice error）
- other ............. 上のどれにも当たらない
- 理由が書かれていなければ "not_stated" にする。明細から理由を推測しないでください

【厳守事項】
- 対象の請求書番号が書かれていなければ "not_found" にしてください。品番や日付から推測しないでください。
- 金額を計算しないでください。単価×数量や合計を検算しないでください。
- 金額の符号（マイナス、CR）は原文のまま写してください。付け足したり外したりしないでください。
- 通貨を換算しないでください。
- 減額を受け入れてよいかどうかを書かないでください。
- confidence は OCR が返した値をそのまま入れてください。

【読み取り結果】{expense_result}
【この仕入先の番号の書き方の例】{supplier_hint}

「番号の見分け方」を手順の中に書いているのは、2つの番号の取り違えがこの題材でいちばん響くからです。 厳守事項の側に「取り違えないこと」と書くだけでは防げません。見出しの文字で見分ける手順と、見分けられないときの返し方を、具体的に示します。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に type: "json_schema" とスキーマを指定）を使い、形の崩れた応答を照合のプログラムに流さないようにします。

{
  "supplier_code": "",
  "credit_note_no": { "value": "", "status": "ok | not_found | ambiguous", "evidence": "" },
  "ref_invoice_nos": { "values": [], "status": "ok | not_found | ambiguous", "evidence": "" },
  "rma_no": "",
  "reason": "return | shortage | discount | price_correction | other | not_stated",
  "currency": "",
  "total_as_written": "",
  "lines": [
    { "line_no": 1, "product_code": "", "quantity": "", "unit_price": "", "amount": "",
      "confidence": 0, "evidence": "", "page": 1 }
  ]
}

照合のプログラムは、この lines に次の判定を付けます。

理由は、AIの出力とプログラムの判定を別の層に置けることです。 lines はAIが原文から埋め、判定はプログラムが買掛金と返品の記録を相手に付けます。取り決めが変わっても、直すのは照合の規則だけです。

システムへ連携する

基幹システムへは書き込みません。 この構成が出すのは照合の結果と起票の候補までで、買掛金を減らす起票は担当者が行います。 書き込みを足すと、番号の取り違えがそのまま別の請求書の減額になります。

人が確認する

経理の担当が開くのは query と needs_human のものと、届いていない減額の一覧です。 post のものは一覧で仕入先と合計を流し見て起票します。全件を開く設計にすると、第10章の6分には収まりません。

1. needs_human を先に見る … invoice_not_found は原本の番号を読み直し、自社の発注番号で書かれていないかを確かめます
2. amount_diff の根拠を確かめる … どの単価で計算した差かを見ます。元の請求書の単価と、仕入先が使った単価のどちらが取り決めに沿うかは購買が決めます
3. duplicate を確かめる … 再発行なのか、別の返品の減額なのかを、返品番号と数量で見分けます
4. 照会文と催促を直して送る … 送るのは購買の担当です
5. 判定を変えたら記録する … どの行を、どの判定に、なぜ変えたかを残します

3番目を急がないでください。 同じ品番を同じ数量だけ2回返品していることもあり、本当の二重計上と、2回の正当な返品は、返品番号でしか見分けられません。

例外に対処する

上から6行目が、立ち上げの時期にいちばん多く出ます。 購買がメールで値引きを取り決め、一覧に登録していないためです。値引きを合意したら一覧に1行足す、を購買の手順に入れると、この行は減ります。

記録を残す

• クレジットノートの原本と、受け取った日時・仕入先
• OCRが返したJSONの全文（GetExpenseAnalysis の全ページ分）
• AIの切り出しの結果（番号・理由・lines）
• 照合の結果と、そのとき参照した買掛金の明細・返品の記録・値引きの合意の内容
• 担当者が判定を変えた記録
• 照会・催促の内容と仕入先の回答、起票の日時
• 仕入先ごとの missing_credit の件数と、返品からクレジットノートまでの日数

最後の行は、仕入先との交渉の材料になります。 返品から減額までの日数が長い仕入先は、支払と相殺する取り決めに変えるほうが、毎月の催促より確実です。