入金消込のAI活用請求台帳と銀行明細の照合・差額・未入金を確認する

入金消込では、請求と銀行明細から候補を作り、確認済みの入金を請求へ割り当てます。

残額は計算で確認します。名義や金額が同じだけでは確定せず、担当者が根拠を確かめます。

月末にまとめ入金や、請求額と少し違う振込が届き、経理が顧客名を探している会社を想定します。

全件をAIへ渡す必要はありません。一致する取引を通常の条件で照合し、差額や不明名義を確認へ回す流れを作ります。

台帳・明細・割当結果は架空の設計例です。金額は計算で検算しています。

AIや銀行連携は未実行です。差額の会計処理、返金、回収方針は責任者が判断します。

通常の照合とAIの役割

確かなIDでの照合、合算、残額計算には通常の処理を使います。

AIは表記違いや顧客の説明を読み、担当者が調べる候補と理由を整理する補助に使います。

承認した名義の対応を台帳へ残すと、次回から固定条件で照合できる場合があります。

名義の追加には確認資料と担当者を残します。AIが自動で学習すると仮定しないでください。

これは顧客から受け取った入金を、売上の請求へ対応させる業務です。

仕入先へ支払う前に行う、請求書と納品等の照合とは目的が異なります。

請求書照合の記事は、末尾の関連記事から読めます。

請求台帳と銀行明細を用意する

入力するのは、消込済み額を引いた未消込残額です。

請求全額と比べると、前回の入金との重複が起こるおそれがあります。

請求側には請求ID、取引先ID、請求額、消込済み額、未消込残額、期日を用意します。

銀行側には入金ID、入金日、金額、振込名義、口座の識別を付けます。

実データを試す際は、閲覧権限と外部サービスへ渡せる情報の範囲を先に確認してください。

架空の請求六件は、すべて未消込で期日は10月31日です。

税等を含む請求総額が台帳にあるものとし、税の再計算はしません。

請求残額の合計は198,000円です。同じ受取口座への入金五件を用意します。

振込名義は架空です。A・B・C・E社との対応は、担当者が資料を確認できるものとします。

入金合計は173,060円です。日付と金額だけでは、同日に同額の別入金を区別できません。

銀行からの取引識別や、管理上の入金IDを残します。

まとめ入金を請求に割り当てる

P1の66,000円は、A社の44,000円と22,000円の合計に一致します。ただし、合計が同じだけでは対象請求を断定できません。

ほかの請求や別口座の入金も調べ、担当者がI1・I2への入金であると確認してから割り当てます。

P1からI1へ44,000円、I2へ22,000円を対応させ、元の入金IDを残します。

P1の銀行明細そのものを複製すると、入金総額が二重になるためです。

入金P1：66,000円
割り当て1：P1 → I1　44,000円
割り当て2：P1 → I2　22,000円
割り当て合計：44,000＋22,000＝66,000円
P1の未割当額：0円
I1・I2の請求残額：ともに0円

同じ顧客の請求でも、期日順に勝手に消し込みません。

支払通知や担当営業の確認をもとに、対象の請求IDを根拠として残します。

月末の請求が後から修正された場合にも、どの請求へ割り当てたかを追えるようにします。

CSVの重複や訂正を取り込む際の確認は、Excel月次集計のAI活用で、元の行を残しながら最新の状態を選ぶ例を紹介しています。

一つの請求へ複数回の入金がある場合は、各入金IDから同じ請求IDへ金額を対応させます。

都度残額を更新し、最後の入金だけでなく、それまでの履歴も残します。

440円の不足は理由を確認する

P2は、I3の33,000円に対して32,560円です。差額は440円です。

差額理由や負担者は推定せず、担当者が取り決めを確認します。支払通知や顧客との確認も調べます。

32,560円がI3への入金であることは確認できています。

受領額を対応させ、440円は理由確認中の請求残額として残します。

請求全額を入金済みにする処理でも、440円を自動で費用へ移す処理でもありません。

担当者向けの確認メモの完成例

対象：I3／B社／入金P2
請求残額：33,000円
確認済み入金：32,560円
割り当て後の請求残額：440円

事実：請求額より入金額が440円少ない。
未確認：差額の理由、手数料等の負担に関する取り決め。
次の確認：支払通知と取り決めを確認し、必要に応じて顧客へ照会する。
処理状態：32,560円を割り当て、440円は理由確認中として残す。

AIへの指示では、「事実」「未確認」「次の確認」を分けます。

「手数料控除で完了」と返した場合は、未確認を事実に変えているため採用しません。

理由確認後の処理も承認を経て行います。値引き、相殺、手数料等では必要な根拠が違います。

後から440円が入金されたら、新しい入金IDをI3へ対応させ、残額を0円にします。

一部入金・不明名義・過入金

P3の30,000円はI4への一部入金です。55,000円から引くと25,000円が残ります。

受領した分を記録しながら、未入金が残る状態を示します。

P4の27,500円はI5と同額ですが、名義とD社の対応は不明です。

P4は未割当のまま保留し、I5の請求残額も27,500円のまま残します。

P5は、I6の16,500円分を確認して対応させます。

入金17,000円との差500円は、請求残額ではなく「入金の未割当額」です。

返金するのか別請求分なのかを担当者が確認します。AIから自動で返金を指示しない構成にします。

表は確認が得られた後の設計です。AIが表を作っても、銀行明細が更新されたわけではありません。

候補一覧と確定一覧は別に管理してください。

不足額について相手へ問い合わせる文面は、経理の生成AI活用の確認メール用プロンプトを使い、確認できていない点と回答方法を指定して下書きにできます。

請求と入金をそれぞれ検算する

請求残額と未割当入金は別に管理し、同じ割当額で両方の合計を確かめます。

割当145,060円、請求残額52,940円、未割当入金28,000円です。

請求側：198,000＝145,060＋52,940
入金側：173,060＝145,060＋28,000

請求残額：440＋25,000＋27,500＝52,940円
未割当入金：P4の27,500＋P5の500＝28,000円

請求総額と入金総額の差は24,940円ですが、未入金の一覧と同じ数字ではありません。

不明名義と過入金が残るためです。顧客へ案内する際は、請求ごとの確認状態を見てください。

合計が合っても、違う顧客へ同額を対応させれば誤消込は起こります。

金額の検算と、取引先・請求ID・入金IDを両方確認します。AIの信頼度だけで確定しないでください。

不明名義を確認できた後の更新例

P4について、D社の支払通知でI5への入金と確認できた場合を考えます。担当者が承認したと仮定します。

27,500円をI5へ対応させると、請求残額と未割当入金は同じ金額だけ減ります。

対象入金：P4／27,500円
確認根拠：D社の支払通知と請求I5の対応
処理：P4の27,500円をI5へ割り当てる
I5の請求残額：27,500円 → 0円
P4の未割当額：27,500円 → 0円

全体の割当額：145,060＋27,500＝172,560円
全体の請求残額：52,940−27,500＝25,440円
全体の未割当入金：28,000−27,500＝500円

更新後の検算：
請求側　198,000＝172,560＋25,440
入金側　173,060＝172,560＋500

確認根拠が増えた入金だけを確定します。

P4の確認が済んでも、P2の不足440円とP5の余剰500円は別に調べます。

逆に「たぶんD社です」という回答だけなら、確定の条件を満たすかを責任者が判断します。曖昧な回答を承認済みへ変えません。

名義と取引先の対応を次回の照合へ登録する場合も、その支払通知と担当者を残します。同名の別法人がないかも確認してください。

新しい請求が届いて金額だけ一致しても、以前の確認を別の取引へ広げません。過去の対応資料を使える範囲を管理します。

既製品と連携方法を比べる

現在の台帳と明細を取り込めるか、例外を担当者へ返せるかを確認します。

AIの有無より先に、現在の会計・販売管理ソフトの入金管理機能を調べてください。

STREAM公式ページは、名義表記やまとめ入金の課題を説明しています。

CSV形式の入金データや、会計システム等との連携も紹介されています。

個別ルールは対応条件を確認します。宣伝される照合率を自社の結果とみなさず、サンプルで試してください。

顧客ごとに入金先を識別できれば、名義推定を減らせます。

GMOあおぞらネット銀行の公式説明には、銀行APIやバーチャル口座の構成が示されています。

取引先ごとの入金先管理が業務に合うか、既存の請求方法と併せて検討します。

入金先を識別する方法と、AIで候補を探す方法を同じ条件で比べます。

不明名義が多いなら、支払通知や請求番号の伝達を見直す方法もあります。

個別連携が必要なのは、複数の管理ソフトに台帳が分かれ、確認済みの結果を転記する手間が残る場合などです。

データの項目、更新頻度、承認、会計への反映方法を整理します。

銀行データを取得できても、消込や仕訳まで自動で反映できるとは限りません。

銀行認証とデータ取得は、AIの説明処理と分けます。認証情報をAIへ渡さない構成にします。

試験は読み取りと確認表の作成に限り、送金・返金の権限を含めません。

自社のデータで確かめる項目

最初は過去データのコピーで候補を作り、担当者の確認結果と比べます。

本番台帳は更新しません。候補になった請求と入金の組み合わせを確かめます。

P1にI1・I2が示されるか、P2の440円が未確認のまま残るかを確かめます。

P4を金額だけでI5へ確定しないことも確認します。

AIに候補表を作らせる指示例

以下は、この架空例で自社の確認方法を試すための指示文です。AIでの動作試験済みテンプレートではありません。

入金を消し込む前の候補表を作ってください。確定や台帳の更新はしないでください。

【架空の入力】
請求I5：D社／未消込残額27,500円／期日10月31日
入金P4：10月23日／27,500円／振込名義サンプルジム
名義とD社の対応資料：未確認

【出力する項目】
入金ID、候補の請求ID、候補の理由、確認済みの根拠、未確認事項、次の確認を表にする。

【守る条件】
金額が一致しても、サンプルジムをD社だと推定しない。
I5は金額一致の候補として残し、名義の対応は担当者へ確認する。
支払通知や振込人の説明を創作しない。別の同額請求があれば候補を全て残す。
入金日と期日だけで延滞と判断しない。送金・返金・消込確定は行わない。

この入力で分かるのは金額の一致だけです。D社からの入金かは、別の確認が必要です。

P5の500円は請求残額ではありません。数字の計算が正しくても、未確認という状態を消す出力なら採用できません。

候補一覧には、入金ID、候補の請求ID、候補とした理由、確認済みの根拠、未確認事項を並べます。

例えばP4は「金額が27,500円でI5と一致するが、名義の対応は未確認」と書きます。

「D社からの支払」と断定する文ではありません。

候補が複数ある場合も、一番目だけを表示しないでください。

同じ残額の請求が二件あるなら両方を残し、判断できない理由を示します。

過去の名義対応がある場合は確認資料を参照できるようにします。名称が似ている別法人との混同も確認してください。

測るのは自動で一致した割合だけではありません。違う請求を候補にした件数と、誤って確定扱いした件数を記録します。

確認に戻した理由や、候補を見ても調査の手間が減らなかった記録も残します。

人が全件を見る時間を含め、現在と同じ作業範囲で比較します。

名義や請求IDの整備に掛かる作業も、導入の負担に含めます。

台帳が不完全なままAIを追加すると、確認する人の手間が増える場合があります。

まず名義対応や請求IDをそろえ、条件で一致できる範囲を確かめてください。

差額の自動処理は、責任者が条件と必要資料を決め、例外を人へ戻せると確認してから検討します。

不足理由の推測や、返金の自動指示を試験の成功条件にしません。

資料がなく確かめられない入金は保留にします。候補を出せなかったことも試験結果です。

担当者が探した資料を記録すれば、次に整備する入力が分かります。

再取り込み時の二重消込を防ぐ

入金IDと割当履歴を管理し、再実行時の重複を確認します。

CSVの再取り込みや、接続が途中で切れた場合も想定してください。

候補、承認済み、反映待ち、反映済み、取り消しを区別します。

会計への反映が失敗したら、登録できた範囲を確認して再処理します。消込から繰り返さないでください。

明細や請求が訂正された場合も、元データと変更内容を残します。

消込を取り消す場合は、確認資料、取り消した担当者と理由を記録します。

候補作成、消込承認、会計反映の完了を区別します。

担当者が確認した取引先・請求IDと、実際に更新した台帳の対応を確かめます。

まずは過去の入金データで試す

入金消込では、AIの候補と担当者が確定した結果を分けます。

差額や不明名義は確認へ戻し、請求残額と未割当入金を別に残して検算します。

直近のデータで、まとめ入金・不足・一部入金・不明名義・過入金を確かめてください。

誤消込、保留理由、確認の手間、台帳への反映も含め、現在の結果と比べます。

既製品で足りる条件を先に使い、台帳間の受け渡しや例外の説明に手間が残る場合に連携を検討します。

相談には、顧客情報を除いた項目一覧と、消込を確定する担当者・確認内容を整理します。

まるっとAIでは、現在の確認手順から必要な連携範囲を検討します。