海外の仕入先から毎月届く英文の取引残高明細（Statement of Account）を読み取り、自社の買掛金の明細と1行ずつ照らして、未計上の請求・支払の行き違い・二重計上の候補を理由付きで出す

処理の起点を決める

受付フォルダ（Amazon S3）に取引残高明細が保存されたことを起点にします。 明細は月初に集中して届きますが、仕入先ごとに届く日が違うため、月初にまとめて回す定時実行にはしません。 届いた日に照らせば、月次の締めの前に未計上の請求を取り寄せられます。

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

届いていない明細も数えます。 毎月10日に、取引のあった仕入先のうち明細が届いていないものを一覧にし、購買の担当が依頼します。明細の来ない仕入先ほど、照合されないまま差がたまります。

入力データを集める

質を決めるのは、下の3つです。 自社の明細に仕入先の請求書番号が無ければ行を対応付けられず、支払の記録に消し込んだ請求書番号が無ければ入金の行を確かめられません。仕入先ごとの癖の一覧は、最初は空でかまいません。 担当者が理由の候補を直すたびに1行ずつ増え、(d)の属人化をほどいていきます。

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

結果は GetDocumentAnalysis で取ります。1回の呼び出しで返る件数は既定・最大1,000で、NextToken が返る限り続けて取ります。 JobStatus が PARTIAL_SUCCESS のときは Warnings に出たページを記録し、その明細を needs_review にします。

質問は QueriesConfig に3つ並べます。「What is the statement date?」「What is the closing balance?」「What is the currency?」です。答えが見つからないときは空のまま返るので、期末残高の無い明細（Open Items だけの様式）をここで見分けます。

表はページごとに返ります。 数ページにわたる明細は、2ページ目以降の表を列見出しの並びで1ページ目の表につなぎます。列見出しが2ページ目に印字されない様式では、列の数と位置でつなぎ、つないだことを記録に残します。

空のセルには文字が付きません。 借方と貸方の列が分かれた様式では、片方のセルが空で返ります。空のセルを0とみなさず、「その列に値が無い」として扱うと、借方と貸方の取り違えが防げます。

AIへ渡す前に整形する

1. 形式の確認 … 文書の分析は JPEG、PNG、TIFF、PDF を扱います。表計算のファイルで届いたものは、この処理を通さず直接読み込みます
2. パスワードの確認 … PDFはパスワードで保護されていてはいけません。保護されたものは仕入先に解除したものを頼みます
3. ページ数とサイズの確認 … 非同期の処理でPDFは500MB・3,000ページが上限です
4. 文字の大きさの確認 … 文字の高さが15ピクセルを下回ると検出されません。150 DPIで8ポイント相当です
5. 基準日の確認 … 基準日が前月末でないもの（期中の日付、2か月前の日付）は、照合する期間をその日付に合わせます
6. 照合の相手の準備 … その仕入先の買掛金の明細と支払の記録を、基準日の前後10日の分まで含めて読み込みます

6番目で基準日の後ろまで読み込むのは、行き違いを見分けるためです。 基準日の2日前に自社が送金した支払は、仕入先の明細では翌月の入金になります。基準日の後ろの記録が無いと、送金済みの支払を「仕入先の記録漏れ」と見誤ります。

1番目で表計算のファイルを分けるのは、読み取る必要が無いからです。 OCRを通すと、正しい数字を読み取りの信頼度付きの数字に変えるだけです。

AIに処理させる

させるのは、表の各行を4つの種類に分け、請求書番号と金額を原文から写し、根拠の文字列を添えることだけです。

行の種類は、摘要と番号の頭の文字と、借方か貸方かの列で決めます。 「INV」で始まり借方の列にあれば invoice、「Payment received」で貸方の列にあれば payment。仕入先ごとの癖の一覧に書き方があれば、それを優先します。

3行目がいちばん起きやすい失敗です。 「Payment received」とだけ書かれた入金の行を渡すと、AIは同じ金額の請求書を探して「INV-0815 の支払」と埋めがちです。埋めた瞬間、自社の支払の記録と照らす前に結論が出てしまいます。 摘要に番号が無ければ not_found と返させ、金額と日付からの候補探しはプログラムが支払の記録を相手に行います。

指示内容を固定する

あなたはメーカーの購買部で、海外の仕入先から届いた英文の取引残高明細を点検する担当です。
OCRが返した表の行だけを見て、各行を項目に分けてください。推測で埋めないでください。

【やること】
1. 各行の種類を下の区分から選ぶ
2. 日付・請求書番号・摘要・金額を原文のまま写す
3. 金額が借方と貸方のどちらの列に書かれていたかを、列見出しのとおりに書く
4. 各項目の根拠にした原文の文字列を evidence に入れる

【行の種類】
- invoice ......... 請求（Invoice、INV）
- credit_note ..... 減額（Credit Note、CN、Credit Memo）
- payment ......... 入金（Payment、Receipt、Remittance）
- adjustment ...... 調整（Adjustment、Exchange difference、Bank charges、Write-off）
- carried_forward . 繰越・前月残高（Balance brought forward、Opening balance）
- まず「この仕入先の書き方の一覧」を見る。一覧にある書き方ならその種類を使う
- 決められなければ "ambiguous" にする

【厳守事項】
- 入金の行で、摘要に請求書番号が書かれていなければ "not_found" にしてください。
  金額や日付から、どの請求書の支払かを推測しないでください。
- 空のセルを 0 として書かないでください。"empty" にしてください。
- 借方と貸方を入れ替えないでください。列見出しのとおりに写してください。
- 残高を計算しないでください。合計を検算しないでください。
- 日付が日・月の順か月・日の順か決められないときは "ambiguous" にしてください。
- 差の理由や、どちらの誤りかを書かないでください。
- confidence は OCR が返した値をそのまま入れてください。

【表の行】{table_rows}
【列見出し】{column_headers}
【この仕入先の書き方の一覧】{supplier_patterns}

「空のセルを0としない」を書いているのは、借方・貸方の列が分かれた様式で、0が入ると取り違えの跡が消えるからです。 片方が空、もう片方に金額、という形が残っていれば、列の読み違いを後から見つけられます。

出力形式を固定する

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

{
  "supplier_code": "",
  "statement_date": "",
  "currency": "",
  "closing_balance_as_written": "",
  "rows": [
    { "row_no": 1, "page": 1, "type": "invoice | credit_note | payment | adjustment | carried_forward | ambiguous",
      "date": "", "doc_no": "", "doc_no_status": "ok | not_found",
      "column": "debit | credit", "amount": "", "description": "",
      "confidence": 0, "evidence": "" }
  ]
}

照合のプログラムは、この rows と自社の明細を照らし、差のある行に次の理由の候補を付けます。

理由は、AIの出力とプログラムの判定を別の層に置けることです。 rows はAIが原文から埋め、理由の候補はプログラムが自社の明細を相手に付けます。「直前」が何日かは仕入先ごとの一覧で決め、変えるのは規則だけです。

仕入先ごとには、すべての行が対応し残高が合えば matched、差がすべて理由の候補で説明できれば explained、unexplained・ambiguous・unreadable があれば needs_review とします。

システムへ連携する

基幹システムへは書き込みません。 duplicate_booking が出ても、取り消しの起票は担当者が行います。照合の誤りで正しい計上を取り消すと、次の支払で仕入先に払い漏れます。

人が確認する

担当者が開くのは explained と needs_review の仕入先で、差のある行だけです。 matched の仕入先は一覧で残高を流し見ます。全行を読む設計にすると、第10章の12分には収まりません。

1. needs_review を先に見る … unexplained の行の原本を読み、癖の一覧に足せる書き方かを確かめます
2. not_booked の請求書を取り寄せる … 受信箱に届いていないか、入荷前の請求かを購買と確かめます
3. duplicate_booking を確かめる … 再発行の請求書を二度計上したのか、本当に2回の取引かを、発注番号と入荷の記録で見分けます
4. payment_not_recognized を仕入先に照会する … 送金の控えを添えます。送るのは担当者です
5. 理由の候補を変えたら記録する … どの行を、どの理由に、なぜ変えたかを残します

3番目を急がないでください。 同じ金額の部品を同じ月に2回発注することは珍しくなく、番号の書き方が違うだけの2回の取引を、二重計上として取り消す誤りがいちばん高くつきます。

例外に対処する

上から6行目が、立ち上げの時期にいちばん多く出ます。 番号の書き方の違いは、照合の前に変換すれば済むものです。仕入先ごとの変換の規則を、最初の2か月で上位の仕入先から作ります。

記録を残す

• 取引残高明細の原本と、受け取った日時・仕入先・基準日
• OCRが返したJSONの全文（GetDocumentAnalysis の全ページ分）
• AIのそろえ直しの結果（rows）と、ページをつないだ記録
• 照合の結果と理由の候補、そのとき参照した自社の明細と支払の記録の内容
• 担当者が理由の候補を変えた記録
• 仕入先への照会と回答、残高確認の回答を送った日時

4つ目で自社の明細の内容を残すのは、計上が後から訂正されるためです。 当時どの明細と照らしたかが分からないと、翌月の照合で同じ差がまた出たときに、前月の判断を追えません。