海外の取引先から届く英文の送金明細（Remittance Advice）を読み取り、請求書ごとの支払額・銀行手数料・相殺を拾って、入金の消込の候補と差額の理由を出す

処理の起点を決める

受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 財務部の共有のメールアドレスに届いた添付を remit/<受信日>/ へ保存します。手で保存する運用から始めても、そこから先は同じです。

読み取りを始めるとき、ClientRequestToken に「受信日＋メールの識別子＋添付の番号」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。完了は Amazon SNS の通知で受け、JobTag でどのファイルかを知ります。JobId は7日間だけ有効なので、結果はその場で S3 に保存します。

銀行の到着の記録は、毎朝インターネットバンキングから前日分を書き出して置きます。 入金は送金明細より遅れることが多いので、先に届いた送金明細は「入金待ち」として保留し、到着の記録が来た日に照合をやり直します。

入力データを集める

質を決めるのは、いちばん下の取引先の条件の一覧です。 手数料の取り決めが無いと、差額を「取り決めどおり」と「請求し直す候補」に分けられません。差額を費用に落としてよい上限も、先に決めて書いておきます。 書いていない取引先は、差額のある入金をすべて人に回します。

依頼人の名前は、親会社や支払を代行する会社の名前で届くことがあります。 一覧に無い名前の入金は、金額が合っていても自動では対応を付けません。

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

表は、TABLE のブロックから CELL を行の番号・列の番号の順に並べて組み立てます。 公式のページでは、セルには行と列の位置が付き、列の見出しのセルには COLUMN_HEADER の印が付くとされています。見出しのセルの文字から、どの列が請求書番号・請求額・支払額・差し引き額かを決めます。見出しの言い方は取引先ごとに違う（Invoice No.／Document No.／Your Reference、Amount Paid／Payment Amount／Net など）ので、言い換えの一覧を持ちます。

合計の行にも気を付けます。 公式のページでは、合計の行のセルに TABLE_SUMMARY の印が付くことがあるとされています。請求書の行として数えると支払額が二重になるので、送金明細の合計として別に持ち、行の合計との一致を確かめます。

問い合わせは、表の外にある項目だけに使います。

**問い合わせには Pages: ["*"] を付けます。 公式のページでは、ページを指定しないと既定で1ページ目だけに当てる**とされ、最後のページにある合計が空で返ります。

結果は NextToken が返る限り GetDocumentAnalysis を呼び続け、全ページ分をそろえてから組み立てます。 公式のページでは、1回で返るブロックは最大1,000件とされています。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFとパスワードで保護されたPDFは扱えないとされています。取引先の仕組みがパスワード付きで送ってくる場合は、取引先に外してもらうか、財務担当が外してから保存します
2. ページをまたぐ表のつなぎ … 次のページの表の列の見出しが同じなら、1つの表としてつなぎます
3. 金額の読み方の統一 … 「1.234,56」（欧州の書き方）と「1,234.56」を、取引先ごとの設定で読み分けます。設定の無い取引先で区切りが1つだけの金額は人に回します
4. 負の数の読み方 … 「(120.00)」「-120.00」「120.00 CR」を差し引きの値として読みます
5. 請求書番号の正規化 … 先頭の0、ハイフン、取引先側で付けた接頭辞を外した形を別に作ります。元の文字列も残し、照合の根拠として使います

3番目を軽く見ないでください。 「1.250」が1,250ユーロか1.25ユーロかを取り違えると、消込が1,000倍ずれます。 取引先ごとに設定し、送金明細の合計と行の合計の一致で確かめます。

AIに処理させる

させるのは、差し引きの行の文を区分に当てはめることと、参照している番号を写すことだけです。 読み取りは Textract、照合と計算はプログラムが行います。

差し引きの区分は、その差し引きを認めるかの判断ではありません。 値引きに分けても、それを認めているかは取り決めで決まります。

4行目がいちばん起きやすい失敗です。 合計と入金額の差を見せると、AIは「中継銀行の手数料と思われる」と金額まで書きがちです。AIには入金額を渡しません。 差の分解はプログラムが行います。

指示内容を固定する

あなたは商社の財務部で、海外の取引先から届いた送金明細（Remittance Advice）の
差し引きの行を整理する担当者を手伝います。
渡された「行の一覧（行番号・請求書番号・請求額・支払額・差し引き額・理由の文）」と
「表の外の注記」と「区分の表」だけを見てください。

【やること】
- 差し引き額のある行ごとに、deduction_type を次のどれかで付けてください。
  discount ........ 早期の支払・数量などの値引きと書かれている
  credit_note ..... クレジットノート（CN、Credit Memo）の充当と書かれている
  claim ........... 品質・数量・遅れのクレームと書かれている
  rebate .......... リベート・販売奨励と書かれている
  bank_charge ..... 取引先が銀行の手数料を差し引いたと書かれている
  prepayment ...... 前払い・過払いの充当と書かれている
  other ........... 上のどれでもないが、理由は書かれている
  unclear ......... 理由が書かれていない、または文から決められない
- 文の中にある番号を、ref_numbers にそのまま写してください（例：CN 2611-08）。
- 表の外の注記ごとに、note_type を charge_terms（手数料の負担の書き方）か
  other か unclear で付けてください。
- evidence には、判断に使った文をそのまま写してください。

【厳守事項】
- 金額を計算しないでください。渡された値をそのまま返してください。
- 差し引きを認めるか、請求し直すかを書かないでください。
- 誰が手数料を負担すべきかを書かないでください。
- 理由の文が「Deduction」「Adj.」だけの行は unclear です。
- 番号が書かれていない行に、番号を補わないでください。
- 迷ったときに discount や bank_charge を選ばないでください。unclear にしてください。

「Deduction だけの行は unclear」を例として書くのは、AIが前後の行から理由を補いがちだからです。 補った区分で消込を済ませると、自社が発行していないクレジットノートの分を認めることになります。 bank_charge を独立の区分にしているのは、取引先が自分で差し引いた手数料を、途中の銀行の手数料と分けるためです。

出力形式を固定する

区分は、Claude API の構造化出力で形を決めて受けます。 公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。ただし、数値の minimum／maximum などの制約はスキーマに書けないとされているので、値の範囲はプログラムで確かめます。

{
  "advice_id": "remit/2026-10-14/msg-0412-1",
  "rows": [
    { "row_no": 3, "invoice_ref": "INV-26-07731",
      "deduction_type": "credit_note", "ref_numbers": ["CN 2611-08"],
      "evidence": "Less CN 2611-08 price adjustment" },
    { "row_no": 6, "invoice_ref": "INV-26-07802",
      "deduction_type": "unclear", "ref_numbers": [],
      "evidence": "Adj." }
  ],
  "notes": [
    { "note_type": "charge_terms",
      "evidence": "All bank charges outside our country are for beneficiary's account" }
  ]
}

プログラムは、これに照合と差額の分解の結果を足して消込の候補にします。

{
  "currency": "USD",
  "advice_total": 48210.00,
  "received_amount": 48175.00,
  "matches": [
    { "invoice_no": "INV-26-07731", "open_amount": 12400.00,
      "paid": 11900.00, "credit_note": "CN-2611-08", "cn_amount": 500.00,
      "status": "matched" }
  ],
  "gap": { "advice_vs_received": 35.00,
           "explained_by": "intermediary_charge_estimate",
           "charge_terms": "SHA", "within_writeoff_limit": true },
  "checks": [ "row_6_unclear_deduction" ]
}

形を分けるのは、区分と照合を別の層に置くためです。 rows はAIが埋め、matches と gap はプログラムが決めます。区分を1行直せば照合はやり直すだけで済み、差額の根拠も入金ごとに残ります。

システムへ連携する

会計の仕組みへの消込の入力は人が行います。 候補の数字がそのまま消込になると、誤りがそのまま売掛金の残高に進みます。取引先の条件の一覧にも書き込みません。 消込の都合で条件を書き換えると、契約と扱いが食い違います。

人が確認する

財務担当が全件の消込の候補を見ます。 見る順を決めておきます。

1. checks のあるものを先に見る … 照合できない請求書番号、合計の不一致を原本で確かめます
2. unclear の行と cn_not_issued を読む … 原本の文を読み、必要なら取引先の経理に問い合わせます
3. gap_over_limit と double_charge を確かめる … 差額を取引先に請求し直すかを、取引先の条件と営業の意見で決めます
4. 会計の仕組みに消込を入力する … 候補を確かめたものだけを入力します
5. 請求し直す差額を営業に知らせる … 取引先への連絡は営業と財務担当が行います

例外に対処する

5行目が、この構成で最も守りたいことです。 通貨が違う入金を換算して自動で照合すると、相場の差を手数料の差と取り違えます。

記録を残す

• 送金明細の原本と、受け取ったメールの識別子・受信日
• Textract が返した結果の全文と、組み立てた行の一覧
• AIの区分の結果（rows、notes）と根拠の文
• 照合と差額の分解の結果（matches、gap、checks）と、そのとき使った取引先の条件
• 財務担当が直した消込 … どの行を、どの請求書に、なぜ充て直したか
• 請求し直した差額と、営業に知らせた日

4つ目で「そのときの取引先の条件」を残すのは、取り決めが後から変わるためです。 当時の条件が残っていないと、どの入金をやり直すかが決まりません。