取引銀行から紙で届く当座勘定照合表を読み取り、でんさい・振込・口座振替などの入出金を当座預金の帳簿と照らして、未記帳と食い違いを拾う

処理の起点を決める

起点は、担当が照合表をスキャンして受領フォルダに保存したことです。 照合表は銀行ごとに届く日が違うので、届いた日にスキャンすれば、その口座の突き合わせはその日のうちに終わります。 月末にまとめるのをやめることが、第3章の（c）への手当てです。

ファイル名は「銀行コード_口座番号の下4桁_対象期間」とします。照合の処理は、ファイル名から銀行の書式と口座を決めます。 ファイル名の形が合わないものは処理せず、担当に通知します。

処理が成功したファイルは処理済みフォルダへ移します。移すのは成功したときだけにします。 受領フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、銀行ごとの書式の表です。 「お支払金額」「支払」「お引出し」はどれも出金の列で、「デンサイ」「電債」「でんさい決済」はどれもでんさいの決済です。この表があれば、列の意味と区分は値で決まり、AIに推し量らせる必要がありません。

手形・小切手の台帳は、電子化の途中のあいだだけ使います。 振出が終わり、期日がすべて過ぎた口座は、台帳との照合を外します。外したあとに手形・小切手の行が照合表に出たら、例外として扱います。

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

読み取りは、ワークフローからレイアウト モデル（prebuilt-layout）を呼びます。 出力の形式に outputContentFormat=markdown を指定すると、内容が Markdown で返り、公式では v4.0（2024-11-30）からテーブルが HTML のテーブルとして表され、結合されたセルや複数行の見出しを表せるとされています。照合の処理は、Markdown の表ではなく tables のセルのインデックスで列をそろえます。 見出しの語で列を決めるためです。

ページをまたぐ表は、照合の処理でつなぎます。 公式でも、テーブルが複数のページにまたがる場合は、分析の後にページを1つのテーブルにまとめる後処理を行うことが挙げられています。2ページ目以降の先頭の行が「前頁繰越」なら、その残高を前のページの最後の残高と照らしてからつなぎます。

元帳は、会計システムから当座預金の科目・口座・期間を指定してCSVで出力し、照合の処理が読みます。でんさいの決済予定と手形・小切手の台帳は、表計算から同じように読みます。

AIへ渡す前に整形する

1. ファイルの確認 … PDFまたは画像であること、ファイル名の形を確かめます
2. ページ数とサイズの確認 … 公式では PDF は最大2,000ページ、有料（S0）レベルで500MBが上限で、Free レベルは最初の2ページだけが処理されます。試すとき以外は有料のレベルを前提にします
3. 解像度の確認 … 抽出するテキストの最小の高さは、1024×768の画像で12ピクセル（150dpiで約8ポイント）です。照合表の明細は小さい字で印字されるので、300dpiでスキャンします
4. 列をそろえる … 列見出しのセルの語を書式の表で引き、日付・摘要・番号・出金・入金・残高の6つにそろえます。引けない語があれば処理を止めます
5. 数字を整える … 「¥」「,」「*」を除き、金額を整数にします。数字以外の文字が残るセルは、そのまま読み違いの疑いにします
6. 日付をそろえる … 和暦の月日、西暦の月日を、照合表の対象期間から年を補って日付にします
7. 残高を検算する … 行ごとに、前の行の残高＋入金−出金＝この行の残高かを確かめます

7番目の検算は、ずれた行だけでなく、その前後の行にも印を付けます。 残高の計算がずれるとき、読み違えたのはその行の金額か、その行の残高か、前の行の残高かのどれかです。3行を画像で見れば、どれを読み違えたかはすぐ分かります。

5番目で数字を補わないでください。 「1,2*4,000」のように読めない文字を、前後の行や残高から計算して埋めると、見つけたかった読み違いが消えます。

AIに処理させる

読み取りはレイアウト モデル、照合は照合の処理が規則で行います。 生成AIに任せるのは、照らせなかった入金の行について、摘要の振込名義から取引先の候補を挙げることだけです。

日付に前後2営業日の幅を持たせるのは、帳簿の日付と銀行の処理日がずれるからです。 振込の支払は、社内で支払日として記帳した日と、照合表に出る日が一致しないことがあります。幅を広げすぎると別の取引と対応してしまうので、2営業日で決まらないものは mismatch にして人が見ます。 振込の手数料が本体と別の行で引かれる銀行では、書式の表に「手数料は直前の振込の行と組にする」と書いておき、照合の処理が2行を1組として元帳の1行と照らします。

生成AIに渡すのは、照らせなかった行の摘要と金額と日付、取引先の振込名義の一覧（候補の絞り込みのため、上位の数十社）だけです。 照合表の全体も、口座番号も、残高も渡しません。

取引先の候補を生成AIに任せるのは、振込名義の書き方がばらばらだからです。 「カ）ヤマダコウギョウ」「ヤマダコウギヨウ（カ」「ヤマダ工業」、名義が略されたもの、代表者の個人名のもの。名義の一覧の完全一致では引けない入金が、毎月数十行残ります。 ここは規則より、表記の揺れを読めるモデルのほうが向いています。

指示内容を固定する

Azure OpenAI の構造化出力（response_format に JSON スキーマ、strict: true）で呼び、次の指示を渡します。

あなたは財務部で、銀行の当座勘定照合表のうち、帳簿と照らせなかった
入金の行について、振込名義から取引先の候補を挙げる担当です。

【渡すもの】
- 照らせなかった入金の行（日付、金額、摘要の文字列）
- 取引先の一覧（取引先コード、正式な名称、登録済みの振込名義）

【やること】
1. 摘要の文字列から、振込の名義と思われる部分を書き出してください。
2. 取引先の一覧から、名義が近い取引先を最大3つ挙げてください。
3. それぞれ、摘要のどの部分と一覧のどの名義が近いかを書いてください。

【厳守事項】
- 取引先の一覧に無い会社を挙げないでください。
- 近い取引先が無いときは、候補を空にしてください。無理に挙げないでください。
- 金額や日付から取引先を推測しないでください。名義の文字だけで判断してください。
- 摘要の文字列を直したり補ったりしないでください。読めない文字は
  そのまま書き写してください。
- 入金の理由（売上の回収、前受け、返金など）を推測しないでください。
- 候補ごとの近さは high ／ medium ／ low のどれかで書いてください。
  名義が略されている、個人名である、などの理由があれば書いてください。

「金額や日付から推測しない」を入れるのは、モデルが売掛金の残高を推し量ろうとするからです。 「この金額はA社の請求額に近い」は、記帳担当が売掛金の明細で確かめることで、名義の近さと混ぜると、候補の根拠が分からなくなります。

「無理に挙げない」がもう一つの要です。 候補を3つ埋めるよう求めると、関係の無い取引先を low で並べます。空の候補は、名義の一覧に足すべき取引先がある、という知らせになります。

出力形式を固定する

照合の処理は、1口座1期間ごとに次の形の結果を作ります。

{
  "bank_code": "",
  "account_last4": "",
  "period": "",
  "opening_balance": 0,
  "closing_balance": 0,
  "rows": [
    { "row_no": 0, "page": 0, "date": "", "kind": "densai | transfer | debit | fee | bill | check | other",
      "description": "", "instrument_no": "", "debit": 0, "credit": 0, "balance": 0,
      "balance_check": "ok | ng", "min_confidence": 0,
      "status": "matched | unrecorded | mismatch | misread_suspect",
      "ledger_ref": "", "candidates": [ { "partner_code": "", "closeness": "high | medium | low", "reason": "" } ] }
  ],
  "summary": { "matched": 0, "unrecorded": 0, "mismatch": 0, "misread_suspect": 0 }
}

1つ目の理由は、balance_check と status を分けられることです。 検算が ng の行は、帳簿と照らす前に misread_suspect にします。担当は、読み違いの疑いの行から先に画像で確かめ、直した値で照合をやり直せます。

2つ目は、kind で照らす先を切り替えられることです。 でんさいはでんさいの決済予定、手形・小切手は台帳、それ以外は元帳。電子化が進んで手形・小切手の行が無くなっても、kind の区分の表を直すだけで済みます。

3つ目は、summary を口座ごとに並べられることです。 毎月、口座ごとの unrecorded の数を見れば、どの銀行の、どの種類の入出金が記帳から漏れやすいかが分かります。

candidates は、Azure OpenAI の構造化出力をそのまま受けます。公式では、構造化出力は JSON スキーマの定義にモデルを従わせるもので、スキーマには required と additionalProperties: false を書きます。

システムへ連携する

会計システムには書き込みません。 一覧の unrecorded の行を見て記帳するのは記帳担当です。照合結果から仕訳を自動で起こすと、読み違いの行が誤った仕訳として残ります。

通知には、口座ごとの matched 以外の件数だけを書きます。 金額や取引先をメールの本文に書くと、資金の動きがメールの履歴に広がります。担当は通知を見て、一覧を開いて中身を確かめます。

人が確認する

人が見るのは matched 以外の行だけです。 matched の行は件数を流し見るだけにします。

1. misread_suspect を先に見る … 前後の行を含めて照合表の画像を開き、読み違えた数字を直します。直した値で照合をやり直します
2. mismatch を見る … 金額か日付が合わない行です。記帳の誤りか、銀行の側の処理日のずれかを確かめます
3. unrecorded を記帳担当へ回す … 候補の取引先を添えて回します。記帳担当が取引先を決めて記帳します
4. 期末の残高を合わせる … 照合表の最終の残高と元帳の残高の差を、未記帳と未達の行で説明できるかを確かめ、調整表を作ります

1番目を省かないでください。 読み違いの行を unrecorded のまま記帳担当に回すと、存在しない入金を探す問い合わせが営業へ飛びます。

目標は、60枚をならして1枚12分です。 matched 以外の行が1枚に数行という想定で、それより多い月は、スキャンの解像度が足りないか、書式の表が古くなっています。

例外に対処する

6行目は、電子化の途中に特有の例外です。 振出を終えたはずの口座に手形・小切手の決済が出れば、台帳に載っていない振出があったか、銀行の取扱いの変更かのどちらかです。どちらも財務の責任者が知っておくべきことです。

記録を残す

• 照合表の画像と、受け取った日・スキャンした日
• レイアウト モデルが返したJSONの全文
• 照合の結果（rows と summary）と、そのとき使った書式の表の版
• 担当が misread_suspect の値を直した記録（直す前と後の値）
• unrecorded の行を記帳した日と伝票番号
• 口座ごとの unrecorded と misread_suspect の件数の月ごとの推移

4つ目の直した記録は、スキャンの設定を見直す材料になります。 特定の銀行の照合表だけ直しが多いなら、印字の小ささか用紙の色が理由で、解像度を上げるか、その口座をインターネットバンキングの明細に切り替える検討の材料になります。