入金消込で残った差異をClaude Codeで自動分類する実装パターン

入金消込で毎月残る振込手数料差異・二重入金・過不足入金・該当請求なし入金を、理由コードの決定的ルールで自動分類し、調査下書きと残管理台帳までClaude Codeで仕組み化する実装パターンを解説。

結論：入金消込で毎月残る「消し込めない差異」は、振込手数料差異・二重入金・過入金・不足入金・該当請求なしの5つの理由コードに分類する決定的ルールを先に設計し、Claude Codeには分類の実行・原因調査の下書き・残管理台帳の更新だけを任せる構成にすれば、月初に残るのは「本当に人が判断すべき差異」だけになります。

要点1：残の分類は「金額差の符号と幅」「同一名義・同額・日付窓」「該当請求の有無」で機械的に判定できる決定的ルールに固定し、AIの推測で仕訳を確定させない
要点2：振込手数料差異は「差額が0より大きく、社内で定めた手数料上限以下、かつ取引先マスタの手数料負担区分が先方負担」の3条件をすべて満たすものだけを候補にする
要点3：分類できない残は消したことにせず、理由コード付きの残管理台帳に繰り越して翌月も追跡する。「残を消す」のではなく「残に名前を付ける」のが設計の中心

対象読者：経理部門とAI活用を進める開発者・PM・経営企画

今日やること：先月の消込作業で最後まで残った未消込入金のリストを取り出し、1件ずつ「なぜ消せなかったのか」を書き出して、理由が何種類に集約されるかを数えてみる

「突合スクリプトを作ったのに、月初になるとやっぱり数十件残るんです」。売掛金の消込を自動化した経理チームを支援していたとき、そう相談されたことがあります。

入金明細と請求台帳の突合そのものは、請求書番号・金額・名寄せの多段マッチングでかなりの割合が自動で消えます。ところが、最後に残る未消込入金——数百円だけ足りない入金、同じ取引先から同じ金額が2回来ている入金、どの請求書にも対応しない入金——は、突合ロジックをいくら賢くしても消えません。消えない理由が「データの照合」ではなく「業務上の事実確認」にあるからです。この記事では、この「消し込めない残」を理由コードで自動分類し、調査と月次の繰り越し管理まで仕組み化する実装パターンを解説します。

事例区分：実装パターン解説
本記事は複数の現場でよく見られる入金消込の残処理の課題を一般化した実装パターン解説です。登場する数値は特定の実在案件を示すものではなく、実装を検討する際の試算・想定値として記載しています。

なお、入金明細と請求台帳の突合（消込の本体）の設計は、経理の月次決算・残高照合をClaude Codeで仕組み化する実装パターンで詳しく扱っています。本記事はその続きにあたる「突合しても残ったもの」の処理に絞ります。

なぜ「消し込めない残」は毎月たまるのか——残の5分類

未消込入金を1件ずつ調べていくと、残る理由はおおむね次の5パターンに集約されます。まずこの分類を社内の共通語彙にすることが、仕組み化の出発点です。

理由コード	内容	典型的な兆候
FEE（手数料差異）	振込手数料が差し引かれて入金され、請求額に数百円届かない	差額がマイナス側で小さく、取引先の手数料負担区分が「先方負担」
DUP（二重入金の疑い）	同じ請求に対して2回入金されている	同一名義・同額の入金が短い期間に2件あり、対応する未消込請求が1件しかない
OVER（過入金）	請求額より多く入金されている	差額がプラス側。将来請求分の前払いや、先方の支払ミスなど原因は複数
SHORT（不足入金）	請求額より少なく入金されている（手数料幅を超える不足）	差額がマイナス側で手数料上限を超える。一部支払・相殺・先方の計上漏れなど
NOREF（該当請求なし）	どの未消込請求とも対応づかない入金	請求前の前受金、名寄せできない名義、他部門の入金の混入など

重要なのは、この5分類のうち機械的に判定してよいのは「兆候」までであって、原因の確定はどれも取引先への確認や契約書の参照といった一次資料の確認が必要だという点です。だからこそ、仕組みの目標を「残をゼロにする」ではなく「残全件に理由コードと次のアクションが付いている状態」に置きます。

設計方針——分類は決定的ルール、調査の下書きだけAI

残処理の実装で最初に決めるべき境界線は、「どこまでをコードの決定的ロジックに固定し、どこからをClaude Codeの言語処理に任せるか」です。この記事では次の分担を推奨します。

理由コードの判定＝決定的ルール — 金額差の符号と幅、日付窓、名義の一致、請求の有無といった判定条件はすべてYAMLの設定ファイルに書き下ろし、Pythonなどのコードで機械的に判定する。同じ入力なら必ず同じ結果になることが監査上の生命線
設定ファイルとコードの生成・保守＝Claude Code — 判定ルールそのものの実装、経理担当者の口頭ルール（「◯◯社はいつも手数料を引いて振り込んでくる」）の設定ファイルへの翻訳、テストデータでの検証をClaude Codeに任せる
原因調査の下書き＝Claude Code（人が確定） — 取引先への確認メール文面、社内の調査メモ、残管理台帳の更新案はClaude Codeが下書きし、送信と仕訳の確定は必ず人が行う

「AIに消込をやらせる」のではなく、「消込ルールを書き下ろす作業と、残った差異の調査事務をAIに手伝わせる」という整理です。この境界を曖昧にすると、後述する失敗パターンのほぼすべてを踏むことになります。

実装ステップ1：データと理由コード定義を揃える

前提として、突合処理が終わった後の「未消込入金リスト」と「未消込請求リスト」が出力されている状態から始めます。ディレクトリ構成の例です。

data/unmatched/2026-07_payments.csv    # 未消込入金（突合処理の出力）
data/unmatched/2026-07_invoices.csv    # 未消込請求（突合処理の出力）
customer_master.csv                    # 得意先マスタ（手数料負担区分の列を含む）
rules/reason_codes.yaml                # 理由コードの判定ルール定義
data/residual_ledger.csv               # 残管理台帳（月をまたいで蓄積）
data/output/                           # 分類結果・調査下書きの出力先

判定ルールは、コードに直書きせず設定ファイルに分離します。経理担当者がレビューできる形にしておくためです。

# rules/reason_codes.yaml の例
fee:
  max_diff_jpy: 1100        # 振込手数料として許容する差額の上限（円）。自社の実績から決める
  require_bearer: "sender"  # 得意先マスタの手数料負担区分が「先方負担」の場合のみFEE候補
dup:
  window_days: 14           # 同一名義・同額の入金をこの日数以内で二重入金候補とみなす
short:
  min_diff_jpy: 1101        # この額を超える不足はFEEではなくSHORTに分類
noref:
  amount_tolerance_jpy: 0   # 該当請求なし判定は金額完全一致の候補が1件もない場合のみ

手数料上限（この例では1,100円）は仮の値です。振込手数料の実額は銀行・振込方法によって異なるため、必ず自社の過去の入金実績から「手数料差異として実際に発生した差額の最大値」を集計して決めてください。この集計自体もClaude Codeに任せられます。

claude -p "data/unmatched/ 配下の過去6ヶ月分の未消込入金CSVから、
最終的にFEE（手数料差異）として処理された行の差額列を集計し、
差額の分布（最小・最大・頻出値）を data/output/fee_diff_stats.md にまとめてください。
rules/reason_codes.yaml の max_diff_jpy の推奨値も、根拠付きで提案してください。
ファイルが見つからない場合は、最初に質問してから作業を開始してください。"
  --allowedTools "Read" "Write"

実装ステップ2：理由コードの判定ロジックを固定する

判定の中核は、未消込入金1件ごとに「最も近い未消込請求」との差額を計算し、ルール定義に沿って理由コードを割り当てる処理です。実装イメージをPythonで示します（実際のコード生成はClaude Codeに任せ、人はルールの正しさをレビューします）。

# classify_residuals.py（抜粋・実装イメージ）
def classify(payment, candidate_invoice, rules, customer):
    if candidate_invoice is None:
        return "NOREF"
    diff = payment.amount - candidate_invoice.amount  # マイナス=不足
    if diff == 0:
        return "MATCH_PENDING"  # 金額一致なのに未消込＝突合側の名寄せ問題として差し戻す
    if diff < 0:
        if abs(diff) <= rules["fee"]["max_diff_jpy"] and customer.fee_bearer == "sender":
            return "FEE"
        return "SHORT"
    return "OVER"

二重入金の検知は、入金明細だけを対象にした別パスで行います。「同一の振込人名義」「同一金額」「一定日数以内」の3条件で候補を抽出し、対応する未消込請求が1件しかない場合にDUP候補として立てます。

claude -p "data/unmatched/2026-07_payments.csv を読み、rules/reason_codes.yaml の
dup.window_days 以内に同一の振込人名義・同一金額の入金が2件以上ある組を抽出してください。
各組について、data/unmatched/2026-07_invoices.csv に同額の未消込請求が何件あるかを数え、
入金件数が請求件数を上回る組だけを data/output/dup_candidates.csv に書き出してください。
判定基準を変更・拡大解釈しないでください。"
  --allowedTools "Read" "Write"

なお、claude -p の実行オプションや --allowedTools によるツール制限の詳細はClaude Code公式ドキュメントを参照してください。ここで大切な設計判断が2つあります。

「金額一致なのに未消込」は残処理に混ぜない — 差額ゼロで残っている入金は、手数料でも二重入金でもなく、突合側の名寄せ辞書の不備であることがほとんどです。MATCH_PENDINGとして突合工程に差し戻し、残処理の台帳には載せません
DUPはあくまで「疑い」として出力する — 毎月同じ金額の定額契約では、正当な入金2件が二重入金に見えます。DUP候補には必ず「対応する請求の件数」を添えて、確定は人が行います

実装ステップ3：残全件に「次のアクション」を付ける

分類が終わったら、理由コードごとに定型の次アクションを割り当て、調査が必要なものはClaude Codeに下書きを作らせます。たとえば取引先への確認が必要なSHORT・OVER・DUPについては、確認メールの下書きを一括生成します。

claude -p "data/output/classified_2026-07.csv のうち理由コードが SHORT・OVER・DUP の行について、
取引先ごとに1通、経理担当者から送る確認メールの下書きを作成してください。
文面には、対象の入金日・入金額・こちらで把握している請求番号と請求額を明記し、
「原因の断定はせず、事実確認を依頼する」トーンで書いてください。
宛名は customer_master.csv の正式名称を使い、
出力は data/output/inquiry_drafts/ に取引先ごとの .md ファイルで保存してください。"
  --allowedTools "Read" "Write"

FEEに分類された差異は、多くの現場で「支払手数料（または売上値引・雑損失など、自社の会計方針で定めた勘定科目）で処理する」という定型運用になっています。ここでも、仕訳ドラフトの生成までをClaude Codeに任せ、会計システムへの登録は人が行う分担にします。どの勘定科目で処理するかは会計方針・税務の論点を含むため、事前に顧問税理士と取り決めた科目を設定ファイルに固定しておくのが安全です。

claude -p "data/output/classified_2026-07.csv のうち理由コードが FEE の行について、
rules/journal_template.yaml に定義された勘定科目・摘要フォーマットに従って
仕訳ドラフトCSVを data/output/journal_draft_fee_2026-07.csv に生成してください。
テンプレートにない勘定科目を推測で使わないでください。
差額が max_diff_jpy を超える行が混ざっていたらエラーとして報告してください。"
  --allowedTools "Read" "Write"

実装ステップ4：残管理台帳で月をまたいで追跡する

残処理の仕組みが崩れる典型は、「先月の残がどうなったか誰も追っていない」状態です。そこで、月次の分類結果を単発のレポートで終わらせず、残管理台帳（residual_ledger.csv）に繰り越して蓄積します。台帳の列は最低限、次の構成で足ります。

residual_id, 初回計上月, 入金日, 振込人名義, 入金額, 差額,
理由コード, 状態(open/inquiring/resolved), 次アクション, 解消月, 解消方法

月初の締め作業では、新しい分類結果を台帳に追記すると同時に、前月からのopen残の棚卸しを行います。この突き合わせと更新案の作成もClaude Codeに任せられます。

claude -p "data/residual_ledger.csv の状態が open または inquiring の行と、
今月の消込結果 data/matched/2026-08_matched.csv を突き合わせ、
今月の入金・消込で解消されたとみられる残に resolved の更新案を作成してください。
更新は直接書き込まず、data/output/ledger_update_proposal_2026-08.csv に
「変更前・変更後・根拠となった消込行」の3点セットで出力してください。
3ヶ月以上 open のままの残は、別途 data/output/aged_residuals_2026-08.md に一覧化してください。"
  --allowedTools "Read" "Write"

「3ヶ月以上openの残」の一覧は、経理チームの月次ミーティングの定例議題にするのがおすすめです。二重入金の返金対応や、原因不明のNOREF入金を仮受金のまま放置しない仕組みは、ツールではなく運用の側に持たせます。なお、銀行明細CSVをはじめとする電子取引データの保存要件は電子帳簿保存法の電子取引データ保存をClaude Codeで仕組み化で扱っているとおり、残処理の作業ファイルとは別に原本保存の設計が必要です（一次情報は国税庁の電子帳簿保存法関連ページを参照）。

現場で踏みやすい失敗パターン

失敗1：手数料上限を広めに取り、不足入金まで自動で手数料処理する

❌ 「面倒だから」と max_diff_jpy を数千円に設定し、差額の小さい不足入金をまとめてFEEとして仕訳する
⭕ 手数料上限は自社の入金実績の分布から根拠を持って決め、上限を超える不足は必ずSHORTとして取引先確認に回す

なぜ重要か：不足入金には先方の相殺処理や請求金額の認識ズレが含まれます。手数料として消してしまうと、回収すべき債権を自社の費用で埋めたことになり、後から発見も回収も難しくなります。

失敗2：DUP候補を自動で返金処理まで進める

❌ 二重入金の疑いがある入金を、確認前に返金用の支払データまで自動生成して処理を進める
⭕ DUPはあくまで候補として提示し、取引先への事実確認と返金・相殺の合意を経てから、人が処理を確定する

なぜ重要か：定額契約の正当な入金を「二重」と誤判定して返金すると、実害が出るうえ取引先の信頼も損ないます。過入金・二重入金の処理方法（返金か、次回請求との相殺か）は取引先との合意事項であり、機械が決められる領域ではありません。

失敗3：AIに「差異の原因」を推測させてそのまま台帳に書く

❌ 「この差額はおそらく振込手数料です」というAIの推測を、確認せず台帳の解消方法欄に記録する
⭕ AIの出力は理由コードの「候補」と調査下書きまでに限定し、台帳の確定記録は一次資料（契約書・取引先の回答）を確認した担当者が書く

なぜ重要か：残管理台帳は監査で説明を求められる記録です。推測が事実として蓄積されると、台帳全体の信頼性が失われ、結局全件を人が見直すことになります。

失敗4：残処理を作り込む前に、突合側の名寄せを放置する

❌ 突合の名寄せ精度が低いまま、大量に残る未消込入金を残処理側の分類ルールでさばこうとする
⭕ 残の大半がMATCH_PENDING（金額一致なのに未消込）なら、先に突合側の名寄せ辞書を整備して、残処理には「本当に差異のあるもの」だけを流す

なぜ重要か：残処理は「少数の例外を丁寧に扱う」工程です。突合の取りこぼしが混ざると例外の件数が膨らみ、分類の精度も運用の集中力も両方崩れます。工程の役割分担を守ることが、全体の精度を決めます。

よくある質問

Q. 振込手数料の差異は自動で仕訳確定までしてよいですか？

3条件（差額が0より大きいマイナス側で社内で定めた手数料上限以下・取引先マスタの手数料負担区分が先方負担・処理する勘定科目が事前に取り決め済み）がすべて揃っている場合に限り、仕訳ドラフトの自動生成までは仕組み化できます。ただし会計システムへの登録・確定は担当者の確認を挟む運用を推奨します。手数料負担の契約条件が不明な取引先は、自動処理の対象から外して確認に回してください。

Q. 二重入金はどこまで自動で検知できますか？

「同一の振込人名義・同一金額・一定日数以内」という候補抽出までは機械的にできます。ただし毎月同額の定額契約は正当な入金でも同じパターンになるため、対応する未消込請求の件数を添えて候補として提示するところまでが自動化の適正範囲です。二重かどうかの確定と、返金・相殺の処理方法は取引先との確認・合意が必要です。

Q. どの請求にも対応しない入金（NOREF）はどう処理すべきですか？

原因が確認できるまでは仮受金などの科目でいったん計上し、残管理台帳でopenのまま追跡するのが基本です。請求発行前の前払いであれば前受金として整理し、名寄せの問題であれば突合側の辞書を直します。処理科目の選択は会計方針に関わるため、顧問税理士と取り決めたルールを設定ファイルに固定しておくと迷いがなくなります。

Q. 消込済みの扱いにする承認をClaude Codeに任せてもよいですか？

任せるべきではありません。この記事の構成でClaude Codeが担うのは、理由コード分類の実行、原因調査メールや仕訳ドラフトの下書き、残管理台帳の更新案の作成までです。残を解消済みにする判断と仕訳の確定は、必ず経理担当者（必要に応じて税理士）が確認して行う設計にしてください。

Q. 導入はどこから始めるのが現実的ですか？

いきなり全体を作らず、先月の未消込リストを使った「理由の棚卸し」から始めるのが現実的です。残る理由が5分類のどれに何件当てはまるかを数えると、自社で最初に自動化すべき理由コード（多くの場合はFEE）が分かります。ルール定義と分類スクリプトの整備で数週間、台帳運用が月次に定着するまで数ヶ月が一般的な目安です（試算であり実測値ではありません）。

まとめ：今日から始める3つのアクション

今日やること：先月の未消込入金リストを取り出し、1件ずつ「なぜ消せなかったか」を書き出して、FEE・DUP・OVER・SHORT・NOREFの5分類に振り分けてみる
今週中：件数が最も多い理由コードについて、判定条件（手数料上限・日付窓・手数料負担区分）を経理担当者と言語化し、reason_codes.yamlの形に書き下ろす
今月中：残管理台帳のフォーマットを決めて先月分の残を登録し、「3ヶ月以上openの残を月次で棚卸しする」定例をチームのカレンダーに入れる

月初の定常業務の仕組み化という意味では、給与計算の検算をClaude Codeで仕組み化する実装パターンも同じ設計思想——決定的ロジックで検算し、AIには説明の下書きを任せる——で書いています。あわせて参考にしてください。

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。

Uravationでは、経理・バックオフィス業務へのClaude Code導入を含むAI導入支援・個別指導を提供しています。自社の消込フローでどこまで仕組み化できるか検討したい方はご相談ください。

消込で確定した売掛金残高を、与信限度額のモニタリングに使う実装は与信管理・与信限度額の監視をClaude Codeで仕組み化する実装パターンで扱っています。