海外子会社の英文の銀行取引明細を毎月読み取り、会計の残高・明細と照合して、差異の理由の候補と要確認の一覧を作る

処理の起点を決める

受付フォルダに明細のPDFが保存されたことを起点にします。 口座ごとにフォルダを分け、PDFと元帳のCSVがそろった時点で処理を始めます。片方しか無いうちは動かしません。 明細だけで読み取りを進めると、照合の段で元帳が無く、要確認の一覧が「元帳なし」で埋まります。

Textract の非同期の処理は、StartDocumentAnalysis で始め、完了を Amazon SNS のトピックへ通知します。その通知を AWS Lambda で受けて、GetDocumentAnalysis で結果を取ります。 ドキュメントは、Get の操作を繰り返し呼んで完了を待つやり方を勧めていません。呼びすぎると絞られるためです。

同じ明細を二重に処理しないように、ClientRequestToken を付けます。 同じトークンで同じ入力の Start を呼ぶと、同じジョブ番号が返り、処理はやり直されません。トークンには「口座の番号＋明細の期間＋ファイルのハッシュ」を使います。

入力データを集める

質を決めるのは、口座の台帳と前月の結果です。 台帳に書き方が無ければ、「03/04」をどちらの日付と読むかが決まりません。前月の結果が無ければ、先月の未落ちの支払が今月落ちたのかどうかが分かりません。

入出金の列の形は、銀行ごとに3つほどに分かれます。 「入金」と「出金」の列が分かれている形、1つの金額の列に符号（- や末尾の DR）が付く形、金額の列とは別に「DR／CR」の列がある形です。台帳にどの形かを書いておき、Python の変換の規則を選びます。

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

問いは、1ページに5つほどにとどめます。 非同期の処理では1ページあたり30問まで使えますが、残高は1ページ目か最後のページにしかないことが多いので、問いに Pages を指定して、聞くページを絞ります。

結果は自社のS3に書き出させます。 非同期の処理の結果は、既定では Textract が持つ場所に7日間だけ保管され、7日を過ぎると取り出せません。OutputConfig で自社のバケットを指定し、照合の記録と同じ場所に残します。

AIへ渡す前に整形する

1. 形式の確認 … 受け付けるのはPDF、TIFF、JPEG、PNG。XFA形式のPDFには対応しないため、印刷用のPDFに出し直してもらう
2. パスワードの確認 … パスワード付きのPDFは扱えない。子会社にパスワードを外したPDFを置いてもらう
3. ページ数とサイズの確認 … 非同期の処理で500MB・3,000ページまで
4. 口座の特定 … ファイル名と問いで取った口座番号の末尾4桁を、口座の台帳と突き合わせる
5. 数値への変換 … 台帳の書き方で「1.234,56」「(1,234.56)」「1,234.56-」「1,234.56 DR」を符号付きの数値に直す
6. 日付への変換 … 台帳の書き方で日・月の順を決める。13以上の数が無い日付は、明細の期間の中に収まるほうを取り、両方収まるなら印を付ける
7. 行の整理 … 「Balance brought forward」「Balance carried forward」のような繰越の行と、集計のセルを、取引の行から外す
8. ページをまたぐ表の連結 … 各ページの表の列見出しをそろえ、1つの取引の一覧にする

7番目を落とすと、照合が根こそぎ崩れます。 繰越の行は金額を持っているので、取引として数えると入金・出金の合計がずれ、明細の中の計算が全ページで合わなくなります。

AIに処理させる

残高の計算と照合は、すべて Python が行います。 AIにさせるのは、照合できなかった行に、決まった区分の中から理由の候補を付けることと、問い合わせの下書きを書くことだけです。

AIに選ばせる区分は、この7つに限ります。 区分が自由文だと、毎月の件数が数えられず、子会社ごとの傾向も見えません。

2行目がいちばん起きやすい失敗です。 「1,234.56 と 1,234.65 の差は読み違いだろう」とAIに直させると、本当に金額が違う取引を消してしまいます。 読み違いを疑うのは、明細の中の計算が合わないときだけで、それは第5章の5番目で読み直しに回っています。

指示内容を固定する

あなたは本社の財務部で、海外子会社の預金残高を確かめる担当者です。
銀行の明細と会計の元帳を照合した結果、照合できなかった行を渡します。
各行について、差異の理由の候補を1つ選んでください。

【選べる区分】
outstanding_payment / deposit_in_transit / bank_charge_unbooked /
interest_unbooked / fx_conversion / duplicate_booking / unknown

【厳守事項】
- 計算をしないでください。差異の額は渡した値をそのまま使ってください。
- 金額や日付を直さないでください。読み違いと考えられる場合も、
  直した値を書かずに unknown とし、note に「読み取りの確認が必要」と書いてください。
- 手がかりが摘要と金額に無い場合は unknown を選んでください。
  もっともらしい区分で埋めないでください。
- evidence には、判断の根拠にした摘要の文字列をそのまま写してください。
- 前月から持ち越した行の一覧に同じ金額のものがあれば、
  carried_from に前月の行の番号を入れてください。
- 仕訳の案や、処理の方法を書かないでください。
- 子会社への問い合わせの下書きは英語で、unknown と duplicate_booking の行だけについて、
  日付・金額・摘要を示して理由を尋ねる文にしてください。

【口座】{account_profile}（数字・日付の書き方を含む）
【照合できなかった行（明細側）】{unmatched_statement_lines}
【照合できなかった行（元帳側）】{unmatched_ledger_lines}
【前月から持ち越した行】{carried_items}

「直した値を書かない」を明記しないと、直してきます。 1桁違いの金額が2つ並んでいれば、人の目にも読み違いに見え、AIは親切に揃えます。揃えた瞬間に、照合の記録から事実が消えます。

「もっともらしい区分で埋めない」も同じ理由です。 7つのうちどれかを選べと言われれば、手がかりが薄くても fx_conversion あたりを選びます。unknown が残ることを、指示の側で許します。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力で、output_config.format にJSONスキーマを指定し、reason を enum で7つに限ります。オブジェクトには additionalProperties: false を付けます。

{
  "account_key": "SG01-USD-4821",
  "period": "2026-09",
  "items": [
    { "side": "statement | ledger", "line_no": 0,
      "reason": "outstanding_payment | deposit_in_transit | bank_charge_unbooked | interest_unbooked | fx_conversion | duplicate_booking | unknown",
      "evidence": "", "carried_from": "", "note": "" }
  ],
  "inquiry_draft": ""
}

照合の結果の全体は、Python が次の形でまとめます。

{
  "account_key": "SG01-USD-4821",
  "statement_opening": 0, "statement_closing": 0, "ledger_closing": 0,
  "internal_check": "ok | mismatch",
  "continuity_check": "ok | mismatch",
  "difference": 0, "explained": 0, "unexplained": 0,
  "verdict": "reconciled | reconciled_with_items | needs_inquiry | needs_reread"
}

1つ目の理由は、AIの出力と計算の出力を分けておけることです。 items はAIが埋め、difference と unexplained は Python が計算します。AIの区分が誤っていても、金額は誤りません。

2つ目は、verdict を規則で決められることです。

3つ目は、翌月に持ち越せることです。 outstanding_payment の行は翌月の入力の「前月から持ち越した行」になり、翌月に落ちなければ、2か月続けて残った行として目立たせます。

システムへ連携する

会計システムへは書き込みません。 手数料や利息の未計上が見つかっても、計上するのは子会社の経理です。この構成が出すのは照合の結果までで、書き込みを足すと、読み違いが仕訳まで一息に進みます。

人が確認する

人が開くのは、needs_reread と needs_inquiry の口座だけです。 reconciled と reconciled_with_items は、一覧で口座と差異の額を流し見ます。

1. needs_reread を先に見る … PDFの該当のページを開き、計算が合わない行の数字を目で確かめて直す
2. needs_inquiry の候補を確かめる … evidence の摘要と金額を見て、理由の候補が妥当かを判断する
3. 問い合わせを送るかを決める … 下書きを直して送る。送信は人が行う
4. 候補を覆したら記録する … どの行を、どの区分に変えたかを残す

1番目で直した数字は、元の読み取り結果を上書きしません。 直した値と直した人を別に記録し、どの口座のどの列で読み違いが多いかを数えます。

例外に対処する

上から3行目は、運用で決めておく話です。 タイ語だけの明細や、中国語の明細はこの構成では読めません。対象外の口座をはっきりさせ、そこだけ従来の手順を残します。

記録を残す

• 元の明細のPDFと元帳のCSV、受け取った日時と置いた人
• Textract の読み取り結果の全文（自社のS3に書き出したもの）
• 数値と日付への変換に使った口座の台帳の内容（そのときの書き方の設定）
• 照合の結果（internal_check、difference、unexplained、verdict）
• AIの出力（items、inquiry_draft）と、人が覆した記録
• 子会社への問い合わせと返答、持ち越した行の翌月の結果

台帳の設定を残すのは、書き方の設定を後から直すことがあるためです。 日付の順を誤って設定していた口座は、過去の照合をどこまでやり直すかを、そのときの設定から決めます。