海外子会社から毎月届く英文の債権債務の残高確認書を読み取り、相手先ごとの残高を自社の帳簿と照らして、連結の消去の前に差異と理由の候補を拾う

処理の起点を決める

子会社と月ごとの受け取りの場所（S3 のフォルダ）にPDFが保存されたことを起点にします。 フォルダは ic/<対象月>/<子会社の記号>/<相手先の記号>/ の形にし、どの子会社のどの相手先との残高確認書かを、保存した場所で決めます。 残高確認書の中の会社名を読み取って決めると、似た名前のグループ会社と取り違えます。

読み取りを始めるとき、ClientRequestToken に「対象月＋子会社の記号＋相手先の記号＋版」を入れます。 公式のページでは、同じトークンで StartDocumentAnalysis を呼ぶと同じ JobId が返り、同じジョブを誤って二度始めるのを防げるとされています。子会社が訂正版を送ってきたら版を上げます。

完了は Amazon SNS の通知で受け、JobTag に入れた子会社と相手先の記号で、どの残高確認書かを知ります。 JobId は7日間だけ有効なので、結果は受け取ったその場で S3 に保存します。

照合は、親会社の帳簿の月次の締めの印が付いてから始めます。 親会社の側の計上が終わっていないうちに照らすと、自社の計上待ちが差異として出て、子会社への照会が空振りになります。

入力データを集める

質を決めるのは、請求書番号がそろっているかです。 親会社の請求書番号を子会社がそのまま帳簿に入れていれば、請求書の単位で突き合わせられます。子会社が自分の伝票番号しか持っていないと、金額と日付で照らすしかなくなり、同じ金額の請求書が並ぶと決められません。 最初の準備は、子会社に請求書番号を残高確認書に載せてもらうことです。

前月の照会の記録も入力にします。 前月に照会して回答が無い差異が今月も残っていれば、それ自体を照会の催促として拾います。

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

表は、CELL のブロックの RowIndex と ColumnIndex で組み立てます。 公式のページでは、表は TABLE のブロックとして返り、各セルは CELL のブロックで表の中の位置の情報を持つとされています。結合されたセルは MERGED_CELL で示されます。

結果は1回に最大1,000ブロックずつ返ります。 NextToken が返る限り呼び続け、全ページ分をそろえてから表を組み立てます。 途中で組み立てると、ページの境目で請求書の行が落ちます。

基準日と相手先は、問い合わせで取ります。 問い合わせは英語の文書でだけ使え、非同期では1ページあたり30件までです。答えが見つからなければ空のまま返るので、基準日の書かれていない残高確認書を見分けられます。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、PDF、TIFF のどれかであることを確かめます。XFA の形式のPDFは扱えないとされています
2. パスワードの確認 … パスワードで保護されたPDFは扱えません。 子会社に解除して送り直してもらいます
3. 基準日の確かめ … 問い合わせで取った基準日が、保存した場所の対象月の末日と合うかを確かめます
4. ページをまたぐ表の連結 … 見出しが同じなら1つの表として続け、繰り返しの見出しの行は落とします
5. 数の整え … 子会社ごとの設定で桁区切りと小数点を読み替え、括弧付きの金額を負の数に直します
6. 請求書番号の整え … 前後の空白、記号、先頭のゼロをそろえ、親会社の請求書番号の形に合うかを確かめます
7. 合計の照合 … 請求書の行を通貨ごとに足し、科目の残高と比べます

6番目を軽く見ないでください。 子会社の帳簿では「INV-0012345」が「12345」や「INV12345」になっていることがあり、そろえないと同じ請求書が片側ずつにしか無いように見えます。

AIに処理させる

させるのは、言葉を扱う3つの仕事だけです。 数の読み取りは Textract、照合と理由の候補付けはプログラムが行います。

2行目は、プログラムの理由の候補を補う手がかりです。 子会社が「Goods in transit, received on 3 Oct」と書いていれば、出荷の記録と照らす前に見当が付きます。ただし、備考の区分だけで理由を確定させず、記録で裏付けが取れたものだけを理由の候補にします。

3行目を外すのは、差異の多くが自社の側の計上の遅れから出るからです。 AIに「どちらが誤りか」と聞くと、もっともらしく子会社の誤りと答えることがあります。照会は、確認をお願いする形に限ります。

指示内容を固定する

備考の区分の指示です。

あなたは商社の経理部で、海外子会社から届いたグループ会社間の残高確認書の
備考を、差異の理由の区分に分ける担当者を手伝います。渡された備考の一覧だけを見てください。

【区分】
in_transit_goods（未着の商品）／payment_in_transit（送金の行き違い）／
timing（計上の時期のずれ）／dispute（請求の内容の争い）／fx（換算の違い）／other

【厳守事項】
- 備考の言葉だけで判断してください。金額の大きさから推し量らないでください。
- 備考の原文を raw にそのまま残してください。
- 日付や請求書番号が書かれていれば、そのまま dates と invoice_refs に写してください。
- 2つの区分に当たりうる備考は other とし、note に理由を書いてください。
- どちらの会社の誤りかを書かないでください。

照会の英文の下書きの指示です。

あなたは商社の経理部で、海外子会社の経理担当へのグループ会社間の残高の照会を
英文で下書きする担当者を手伝います。渡された差異の一覧と根拠だけを見てください。

【書き方】
- 差異ごとに、請求書番号、通貨、自社の帳簿の金額、残高確認書の金額、根拠
  （出荷の日、送金の参照番号、残高確認書のページ）を並べてください。
- 数は渡された値をそのまま書いてください。足したり引いたりしないでください。
- どちらの誤りかを書かないでください。確認をお願いする形にしてください。
- 前月から回答待ちのものは、前月の照会の日付を添えて、分けて書いてください。
- 回答の希望日は、渡された日付だけを書いてください。

日付と請求書番号を写させるのは、プログラムで記録と照らすためです。 「received on 3 Oct」の日付が出荷の記録の着荷の予定と合えば、未着の商品の候補として裏付けが取れます。写させずに区分だけを返させると、裏付けの照合ができません。

出力形式を固定する

照合の結果は、プログラムがJSONで出します。 生成AIの出力も、Claude API の構造化出力で形を決めて受けます。公式のページでは、output_config.format に JSON スキーマを渡すと、スキーマに合う JSON が返るとされ、正式提供の機能です。

{
  "period": "2026-09",
  "entity": "SG01",
  "counterparty": "JP00",
  "as_of_date": "2026-09-30",
  "summary_check": "matched | mismatch",
  "balances": [
    { "account": "trade_receivable", "currency": "USD",
      "ledger": 1200000.00, "confirmation": 950000.00, "difference": 250000.00 }
  ],
  "items": [
    { "invoice_no": "INV-0012345", "currency": "USD", "amount": 250000.00,
      "side": "ledger_only | confirmation_only | both_amount_differs",
      "reason": "in_transit_goods | payment_in_transit | timing | unknown",
      "evidence": "Shipped 2026-09-28, ETA 2026-10-06",
      "remark_class": "in_transit_goods", "min_cell_confidence": 98.1 }
  ],
  "follow_ups": [ { "invoice_no": "", "first_asked": "2026-08-05", "status": "awaiting_reply" } ],
  "needs_human": [ { "item": "", "reason": "low_confidence | no_mapping | summary_mismatch | as_of_mismatch" } ]
}

1つ目の理由は、side と reason を分けて持てることです。 side は事実（どちらの帳簿にだけあるか）、reason はプログラムが記録で付けた候補です。理由の候補が誤っていても、事実の列は残ります。

2つ目は、follow_ups で照会の漏れを防げることです。 前月から回答待ちの差異を毎月の結果に載せ続け、回答が来るまで一覧から消えません。

システムへ連携する

会計の仕組みにも連結の仕組みにも書き込みません。 差異の一覧から自動で調整の仕訳を起こすと、理由の候補が誤っていたときに、誤った仕訳が連結の数字に入ります。

Claude を Amazon Bedrock から使う場合は、構造化出力の対応を先に確かめます。 公式のページでは、Bedrock では構造化出力が旧来の連携でだけ使え、Claude in Amazon Bedrock では使えないとされています。

人が確認する

経理の担当者が全件の照合の結果を確かめます。 見る順を決めておきます。

1. needs_human を先に見る … 合計が合わないもの、基準日が違うもの、対応なしの見出しは照合に進んでいません
2. unknown の差異の根拠を確かめる … 自社の計上の漏れでないかを、会計の仕組みで先に見ます
3. 理由の候補の根拠を流し見る … evidence の出荷の日・送金の参照番号が妥当かを確かめます
4. 照会を直して送る … 下書きの番号と根拠を確かめ、送信は担当者が行います
5. follow_ups を確かめる … 回答が来たものを閉じ、来ていないものを催促します

2番目を省かないでください。 自社の計上の漏れなのに照会を送ると、子会社は自分の帳簿を調べ直すことになり、回答が締めに間に合わなくなります。

例外に対処する

上から4行目と6行目は、最初の数か月に多く起きます。 どちらも子会社の書式の問題で、グループで残高確認書の様式をそろえると減ります。

記録を残す

• 残高確認書の原本と、保存した場所（月・子会社・相手先・版）
• Textract が返したブロックの全文と、組み立てた表
• 子会社ごとの設定の、その月に使った版
• 照合の結果（balances、items、follow_ups、needs_human）と、理由の候補付けに使った出荷と送金の記録
• 担当者が直した箇所 … どの理由の候補を、どう変えたか
• 子会社への照会と回答、差異の解消の記録
• 子会社ごとの差異の件数と理由の推移

最後の行は、グループの経理の会議の材料になります。 同じ子会社で timing の差異が毎月出るなら、締めの日程か計上の基準をそろえる話し合いが要ります。