入金消込に追われる経理が、生成AIで例外確認だけに変わるまで

月初の朝、青葉商事の経理部では、プリンターの音が静かな部屋に続いていた。窓の外を走る車の音も、少し遠くに聞こえる。美咲の机には、銀行の入出金明細、請求書一覧、売掛金台帳が広がっていた。

美咲は、きちんと並べることが好きな人だった。書類の端をそろえ、確認した行には小さな印をつける。けれど月初だけは、その丁寧さが机の上で止まってしまうことがあった。

明細は銀行のサイトからCSVで取り込み、Excelの表に並べている。美咲は入金日と金額を見ながら、請求書一覧の取引先名を探した。画面の一行目には、振込名義が「アオバ産業」と表示されていた。

そのすぐ下には「アオバサンギョウ」とある。さらに別の行には「アオバ（カ」と続いていた。美咲は指を止め、売掛金台帳の検索欄に同じ名前を入れた。

「これは、同じ会社かしら」

過去の明細を開くと、似た名義がいくつも見つかった。株式会社の文字が省かれているものもあれば、本社名だけになっているものもある。担当者の個人名らしい振込名義が残っている月もあった。

美咲は取引先の住所と担当営業を確認し、ようやく同じ会社らしいと判断した。名義がそろっていれば、作業はすぐ終わる。けれど、請求額と入金額が合わないと、そこで手が止まった。

「金額が違うものは、別の画面に移しておきます」

美咲は、確認待ちの表を開いた。取引先名は合っている。入金日も近い。それでも、請求書の金額と銀行から入った金額が一致しない。振込手数料が引かれたのか、請求額の一部だけが支払われたのか、明細だけでは分からなかった。

部長が、隣の机から資料の束をのぞき込んだ。部長は忙しいときでも、声を荒らげない人だった。美咲の画面に並ぶ保留中の行を見て、静かに息をついた。

「この作業は、毎月同じところで止まるね」

「はい。名義が少しずつ違うと、同じ取引先かを手で調べる必要があります。取引先名が合っていても、金額が合わないものは、すぐには決められません」

美咲は、画面を指でたどった。ひとつの入金で、複数の請求書をまとめて支払っている取引先もある。どの請求書に充てるかは、営業担当のメモを見なければ分からなかった。

「一括で入っているものもあります。先月分と今月分をまとめたのかもしれません。でも、請求書の組み合わせが一つに決まらないと、勝手には消せません」

「部分的な入金もあるのかい」

「あります。今月は一部だけ、という約束が口頭で残っていることもあります。残りを翌月に回すのか、別の請求に充てるのか、確認が必要です」

美咲は、入金の横に小さくメモを残した。入金と請求書を結びつけ、台帳の残高を更新する。この作業を、経理では入金消込と呼んでいる。消込が終わらなければ、会計ソフトのfreeeへ仕訳を入力することもできない。

だから美咲は、名義を調べ、金額を比べ、営業部へ問い合わせる。返事を待つ間に、別の入金を確認する。戻ってきた画面には、さきほど保留にした行がそのまま残っていた。

「この入金は、まだ入っていないという意味ではないんですよね」

部長の問いに、美咲はうなずいた。未消込のまま残っているだけで、入金がない場合もあれば、名義や金額が違うだけの場合もある。台帳に残った数字だけでは、その違いまでは見えなかった。

時計の針が進むにつれ、机の右側には確認待ちの紙が増えていった。美咲は一枚ずつ付箋を貼り、どこまで調べたかを書き込んだ。丁寧に進めても、次の明細が届けば、また同じ確認が始まる。

部長は、未処理の表と美咲の手元を見比べた。美咲は画面を閉じず、最後の名義を検索欄へ入力した。朝の銀行明細は、まだ終わりを見せていなかった。

月初の朝、青葉商事の経理室に銀行明細が届いた。美咲は振込名義の欄に「アオバブツリュウ」と表示された入金を見つけ、取引先の請求書一覧を開いた。そこには、同じ会社の請求がいくつも並んでいた。

入金額は、そのうち一つの請求額に近かった。美咲は画面を左右に見比べ、いちばん差の少ない請求書を選んだ。

「これで、ひとまず一件は消せます」

消込のボタンを押すと、請求書の行にあった赤い表示が消えた。けれど、同じ取引先の売掛金には、まだ別の請求が残っていた。銀行明細の入金額と、残った請求額を足すと、最初の入金は一件分ではなく、複数の請求をまとめた金額に見えた。

美咲の指が止まった。振込名義には請求書の番号も、どの月の支払いかも書かれていない。取引先から届いていたメールにも、「まとめて振り込みました」とあるだけだった。

「このままでは、どの請求に充てたのか説明できませんね」

隣の部長が画面をのぞき込んだ。美咲は一度消し込んだ行を開き直したが、すぐに戻すことはできなかった。別の請求書を未入金のまま残せば、台帳には支払いが遅れているように表示される。

そのとき、別の取引先の明細が目に入った。請求額の一部だけが振り込まれている。銀行の備考欄は空白で、請求書には残りの金額がそのまま残っていた。

「こちらは、金額が合いません。振込手数料でしょうか」

美咲が過去のメールを探すと、取引先から「今月は半分だけ支払います」と書かれた短い連絡が見つかった。けれど、そのメールは担当者の個人フォルダにあり、売掛金台帳には記録されていなかった。画面の残高だけを見ると、まだ支払いがない会社と同じに見える。

午前の半ば、督促を担当する健太が経理室へ入ってきた。手には未入金リストがあり、画面には送信前の督促メールが開かれていた。

「この会社には、今日中に確認メールを送ります。未入金の一覧に出ています」

「待ってください」

美咲は椅子を回し、健太の画面を見た。そこには、さきほど一部だけ振り込まれた取引先の名前もあった。

「まだ、未入金とは決められません。入金の一部だけが反映されているかもしれません」

健太の指が、送信ボタンの上で止まった。メールの宛先には取引先の担当者名が入り、本文には「ご入金を確認できておりません」と表示されている。その一文が、今は正しいのか分からなかった。

美咲は、最初に消し込んだ請求書へ戻った。もし一括入金の全額を一件に充てれば、別の請求は未入金のまま残る。反対に、複数の請求へ分ければ、どの順番で充てたのかを決めなければならない。間違った請求に入金済みの印を付ければ、月末の決算で残高がずれ、資金繰りの表にも違う入金予定が映る。

「今日見つかったのは、三つですね」

美咲は机の端に付箋を並べた。

「振込名義が少しずつ違うこと。一度の振込に複数の請求が入ること。それから、部分入金や分割払いが残ることです」

部長は、消し込んだ行と未処理の行を見比べた。

「名前だけでは同じ会社か分からず、金額だけでは一つの請求か分からない。だから、機械的に消すほど危ないのですね」

美咲は小さくうなずいた。画面の未消込表示は減っていない。それどころか、最初に押した消込を戻すための確認が増えていた。

健太は送信前のメールを下書きへ戻した。部長は、付箋の三つの言葉を見ながら、ゆっくり息をついた。

「全部を人が探し続けるのではなく、迷うものだけを残せないでしょうか」

美咲は、銀行明細と請求書の組み合わせを見つめた。名義の揺れ、一括入金、部分入金。三つの付箋は、消し込めない理由を隠す印ではなく、先に確認すべき場所を示す印になっていた。

美咲は業務改善担当の直人と、経理部の画面を囲んでいた。画面には、銀行明細と売掛金台帳が並び、前月から残った未消込の行が静かに光っている。直人は白いホワイトボードを壁から外し、机の横に立てかけた。

「今日は、消込を全部自動にする話ではありません。迷った入金だけを、美咲さんの机へ戻す流れを作ります」

直人はペンを走らせた。ホワイトボードには、「銀行明細の取得 → 名義の正規化 → 照合 → 消込 → 仕訳 → 例外確認」と、六つの言葉が矢印でつながった。

「名義の正規化というのは、振込名義の表記をそろえることです。たとえば『アオバ産業』と『アオバサンギョウ』を、同じ取引先として見つけやすくします」

美咲は、昨日の画面を思い出した。会社名の一部だけが表示された入金を、請求額が近いという理由だけで充当しかけた場面だ。あのまま進めていたら、別の未入金まで消えていたかもしれない。

「AIに全部任せるのではなく、迷った入金を人の机に戻す。これが大事です」

直人は、ホワイトボードの最後の矢印を丸で囲んだ。例外とは、決めたルールでは安全に判断できない入金のことだと、ゆっくり説明した。

「たとえば、振込名義、取引先、請求額がそろっている入金は、自動で消込候補にします。過去にも同じ形で処理できていれば、AIはその候補を先に出せます」

「候補、ということは、最後には私が見るのですね」

「はい。AIは整理係です。確定するボタンは、人が押します」

直人は新しい表を画面に開いた。列には「過去の振込名義」と「正式な取引先名」が並んでいる。「カ）青葉商事」「青葉商事本社」「Aoba Shoji」といった名前が、「青葉商事」へ結びついていた。

「これは名義マッピング辞書です。いろいろな呼ばれ方を、正式な取引先名へ結びつける表です。美咲さんが確認した名義を足していけば、次の月から同じ迷いを減らせます」

美咲は、これまで自分の頭の中だけにあった記憶を思った。旧社名で振り込む会社も、担当者の個人名で入金する会社もある。その知識を表に残せば、休みの日にも処理が止まらない。

「では、辞書にない名前は、すぐに消込しないのですね」

「そうです。未知の名義は確認へ回します。初回入金も同じです。新しい取引先か、別の会社の入金か、まだ分からないからです」

直人は画面に赤い印をいくつか置いた。同じ金額の請求書が複数ある場合も、複数の請求書にまたがる一括入金も、赤い印の対象になった。銀行APIから明細を取得できなかった場合も、処理を止めて確認する設定にした。

「一括入金は、先に充当ルールを決めます。たとえば古い請求書から充てる、または契約で決めた順に充てる。組み合わせが一つに決まらないときは、人に戻します」

「金額が足りない入金はどうしますか。昨日のような部分入金です」

「一部だけ回収した記録を残し、残りは売掛金として残します。次回へ繰り越すルールも用意します。口頭の約束にせず、台帳に残る形にしましょう」

美咲は画面を見つめた。これまでなら、金額が合わない行を自分で調べ、メモを書き、あとで思い出そうとしていた。新しい流れでは、判断できるものと、判断を止めるものが最初から分かれる。

直人はテスト用の明細を読み込んだ。名義が少し違う入金には、消込候補と判定理由が表示された。参照した請求書も並び、金額不足の入金には「残額の確認が必要」と表示された。

「結果には、候補だけでなく理由も出します。どの請求書を見たか、なぜ確認が必要なのかも残します。あとから別の人が見ても、判断の道筋が分かるようにします」

「それなら、私が確認するときに、最初から探し直さずに済みますね」

「はい。AIが候補を出し、美咲さんが正しいものを選びます。人の確認をなくすのではなく、探す時間を短くする仕組みです」

直人は会計ソフトの連携画面を開いた。そこには、仕訳を書き込むボタンがあったが、まだ押せない状態になっている。銀行との接続も、明細を読むだけの読み取り専用にしていた。

「会計ソフトへの書き込みは、最初から自動にしません。まずは銀行APIで明細を読むだけにして、候補と例外の動きを確かめます。安心して使えると分かってから、次の連携を考えます」

美咲は小さく息を吐いた。便利そうだからと急いで任せるのではなく、止まる場所を決めてから始める。その順番なら、誤消込への不安を抱えたまま走らずに済む。

テスト画面には、緑の候補と赤い例外が並んだ。緑の行では、名義と取引先と請求額が一致している。赤い行には、未知の名義、初回入金、同名候補、一括入金、部分入金、そして銀行APIの取得エラーが集まっていた。

「この赤い行だけなら、私は一件ずつ理由を見て判断できます」

「その状態を目指します。例外を確認したら、必要なものだけ辞書やルールへ戻します。仕組みは、使うたびに少しずつ賢くなります」

美咲は、ホワイトボードの最後に書かれた「例外確認」を指でなぞった。すべてを機械に渡すのではない。定型の入金は流れに乗せ、迷いのある入金だけを自分の目で確かめるのだ。

「直人さん。この方法で、まずは読み取り専用から試してみましょう。今日の入金を、候補と例外に分けるところから始めたいです」

直人がうなずくと、画面の読み込みが始まった。美咲は赤い行を一つ開き、判定理由と参照請求書を確認した。積み上がった紙の山はまだ消えていなかったが、机の上には、次に見るべき場所がはっきり見えていた。

青葉商事では、読み取り専用の銀行APIをつないだ初めての試運転が始まった。美咲の画面には、今日の入出金明細と売掛金台帳、請求書一覧が同じ表に並んでいた。生成AIはまだ消込を確定せず、候補を作るだけの設定だった。

「まずは、銀行から明細を読むところだけです。会計データを書き換える道は、まだ閉じておきます」

直人は検証用のExcelを開き、銀行APIから明細を取り込んだ。空白を取り、全角と半角をそろえ、記号を外す処理を、Claudeに順番どおり実行させる。株式会社、（株）、カ）といった法人格の表記も同じ形にし、カナ表記の揺れも整えた。

「たとえば、アオバ　サンギョウと、アオバサンギョウを同じ検索キーにするんですね」

「そうです。ただし、整えたから同じ会社だと決めるわけではありません。正規化した名義を、名義マッピング辞書と照合し、取引先、請求書、金額、入金日を順に確かめます」

辞書には、正式名称だけでなく、過去に使われた振込名義も登録されていた。請求書番号が振込メモにあれば強い手がかりになる。金額と入金日が請求データと合えば候補を上げるが、金額差異が許容範囲を超えたときは、理由を添えて止める仕組みにした。

一括入金には、古い請求から充当するという社内ルールを入れた。合計額に合う請求書の組み合わせを探し、組み合わせが一つに決まると充当順を表示する。複数の組み合わせが残れば、候補だけを出して人の承認へ送る。部分入金は回収済みの額だけを消し、残額は未消込として売掛金台帳に残した。

「全部を消してしまわないのが大事なんですね」

「ええ。残額を消すと、まだ受け取っていないお金まで受け取ったことになります」

試運転の途中で、赤い帯のついた行が現れた。振込名義は、正規化すると「アオバ」だった。辞書には、青葉設備株式会社と青葉製作所株式会社の二つがあり、どちらにも同じ金額の請求書が見つかった。

画面には、こう表示された。

「候補を一意に特定できません。両社の請求書金額が一致し、支店情報と請求書番号がありません。誤消込の可能性があるため、要確認」

美咲は、画面を見つめた。

「答えを出さないのも、正しい動きなんだね」

直人はうなずいた。候補を一覧で示し、最後の確定を担当者が押す方式は、マネーフォワード クラウドの解説にもある考え方だという。美咲は営業担当へ支払通知書を確認してもらい、青葉設備の入金には請求書番号が必ず記載されると分かった。

二人は辞書に「アオバ」という略称を一社だけへ結びつけなかった。請求書番号が青葉設備の形式に合う場合だけ候補を強め、番号がない場合は今後も確認待ちにするルールを追加した。過去の入金を見て、都合よく決めるのではなく、根拠のある条件だけを残した。

次に、直人は正常な入金だけでなく、振込名義や入金日が空欄の明細、請求額と入金額が矛盾する明細、辞書にない名義を用意した。一括入金の組み合わせが決まらない場合や、部分入金の扱いが台帳にない場合も、人の承認へ送られるかを確かめた。処理中に銀行APIが止まったときは自動停止し、担当者へエスカレーションするようにした。

さらに、権限のない利用者が明細を取得しようとする操作、freeeへの仕訳転記を試みる操作、処理範囲や出力件数、実行時間の上限を超える操作も試した。どれも確定処理へ進まず、エラーとして止まった。判定不能なケースを、無理に成功扱いにしないためだった。

「止まった理由が分からないと、次に直せませんね」

そこで監査ログも確認した。ログには操作時刻、実行ユーザー、使ったAIモデル、参照した明細と請求書、銀行APIの操作、権限チェックの結果、エラー内容が残っていた。美咲が候補を承認した時刻も、辞書を変更した履歴も追えるようになっていた。

再実行すると、定型の入金は候補として静かに並び、名義不足や金額矛盾は赤い帯で残った。「アオバ」の二社も、確認待ちのままだった。美咲は確定ボタンを押す前に、候補の根拠と参照請求書を一つずつ見た。

机の端には、新しい辞書の欄が増えていた。そこには名義だけでなく、どの条件なら安心して候補にできるかが書かれている。小さな試運転は、答えを急がない仕組みを育てる時間になっていた。

本番運用の朝、美咲の画面には、定型入金ではなく、確認が必要な名義と充当候補だけが並んでいた。始業のチャイムが鳴るころ、読み取り専用の銀行APIから明細が取り込まれ、短い通知音が静かな経理部に響いた。

画面の上部には、「明細を取り込みました」「名義を整えました」「消込候補を作成しました」と、処理の進み具合が順に表示された。「アオバ産業」「アオバサンギョウ」「アオバ（カ」と並んでいた振込名義は、顧客マスタと過去の入金履歴をもとに、同じ取引先の候補としてまとめられている。

「名義正規化というのは、ばらばらの表記を、同じ会社だと分かる形にそろえることです」

美咲は、前章で部長から聞いた言葉を、今度は画面の動きとして確かめた。生成AIは、銀行明細と売掛金台帳を照らし合わせ、請求書との組み合わせを候補として示している。定型の入金は処理済みの欄へ移り、判断が必要なものだけが未確認の一覧に残った。

以前なら、銀行明細の取得だけで15〜30分、売掛金台帳との照合に1〜4時間、消込記録に30分〜2時間、仕訳入力にも30分〜2時間ほどかかる目安が示されていた。入金消込の工程別時間の目安 その朝の画面では、作業の入口から出口までを一枚の流れとして眺められた。

一覧の一行目は、初めて見る振込名義だった。二行目には、一度の入金で複数の請求書を支払った可能性が表示され、三行目には請求額の一部だけが入っていることと、残りを次回入金へ繰り越す候補が示されていた。金額が一致しない入金には、差額の理由を確認する赤い印が付いている。

「候補は、いちばん近いものから並んでいます。最後に確定するのは、私ですね」

美咲が請求書を開くと、取引先名、請求日、金額、過去の入金履歴が横に並んだ。内容が合っている行では、承認ボタンを押すだけで消込記録が残り、会計システムへ渡す仕訳の準備も進んだ。候補を承認できない行は、取引先への確認、または次回入金への繰越として別の箱へ移した。

机の脇に置かれた導入事例の資料には、従業員22名の企業で、月60〜80件の入金照合を経理担当者が月初3〜4日かけて行っていた例が載っていた。Claude Codeの導入後は、銀行データの取り込みから照合作業の完了まで30分以内になったと記されている。Claude Code導入事例 美咲はその数字を、自分たちの成果としてではなく、変化の大きさを測る物差しとして静かに読んだ。

別の事例では、最初からすべてを自動化せず、確認した例外を名義辞書や充当ルールに加えていった。その結果、3か月で自動消込率が70〜85％になったケースが紹介されている。導入初期の自動消込事例 青葉商事でも、曖昧な略称や新しい取引先を人が確認するたびに、辞書の中身が少しずつ育っていた。

自動消込率は80〜90％が現実的な目安とされ、設計上は90％超を目標にできる。ただし、取引先の数や名義の揺れ、台帳の整備状況によって結果は変わるため、残りを無理に自動化しない設計が大切だと説明されている。自動消込の目安と設計

「確認する仕事は、まだあります。でも、全部を探し直す仕事ではありません」

部長の声に、美咲はうなずいた。以前は未消込一覧を開くと、どの行から手を付けても同じように重く感じた。今は、初めて見る名義や判断の分かれる入金が、確認すべき理由と一緒に並んでいる。

窓から朝の光が差し込み、部長は積み上がっていた資料の一番上をそっと閉じた。未消込一覧の中身は、全件確認から例外確認へ変わった。美咲は候補を一つ承認し、次の行へ進んだ。経理部には、以前のような焦りではなく、必要なところに目を向けられる静かな空気が流れていた。

夕方の経理部で、美咲は最後の例外カードを確認していた。朝まで机を埋めていた銀行明細と請求書の束は、もうない。画面に残っているのは、確認理由の付いた数件だけだった。

美咲は、確認を終えた振込名義をマッピング辞書に追加した。これは、振込名義と取引先を結ぶ対応表だ。「アオバサンギョウ」と「アオバ産業」を同じ取引先として結び、次からは同じ揺れを自動で候補にできるようにした。

「今日の判断が、次の照合を助けてくれるんですね」

「そうだね。確認できたものだけを、次のルールに変えていこう」

直人は、美咲の画面をのぞいた。美咲は、一括入金の記録も開いた。一つの振込に複数の請求が含まれていたときは、古い請求から充てること、組み合わせが一つに決まらないときは人が確認することを、ルールとして残していた。

部分入金の欄には、まだ支払われていない残りを繰越残高として記録した。これまでは担当者の記憶や机の端のメモに残っていた判断が、今は次の画面にも引き継がれる形になっている。

「無理に消し込まない、という選択も記録できるんですね」

「うん。消えたように見せるより、残っている理由が分かるほうが安全だから」

画面の奥では、生成AIが自動処理した入金も並んでいた。銀行明細の該当行、照合した請求書、判定理由、確定した担当者が、ひとつの監査ログに保存されている。美咲が確認した例外も、同じように参照明細と理由を添えて残っていた。

直人は権限画面を開いた。銀行APIから明細を取得する権限と、会計ソフトfreeeへ仕訳を書き込む権限は、別々に設定されている。

「明細を見られる人が、そのまま会計データを書き換えられるわけではないんですね」

「役割を分けておけば、確認する場所も責任の範囲も見えやすいからね」

そのとき、見慣れない振込名義について確認依頼が届いた。美咲は候補を急いで選ばず、取引先への確認待ちとして画面に残した。別の部分入金も、未回収の残りを繰越残高として次の処理へ送った。

どちらも、消込済みにはならなかった。けれど、どこで止まり、何を待っているのかは、画面を開けば分かった。

美咲は椅子を引き、机の上を見渡した。以前なら、銀行明細と請求書を何度も並べ替え、名義を検索し、終わらない確認を続けていた。今は、確認理由の付いた例外だけが、静かな列になって残っている。

「明日の朝は、届いた明細を待つところからですね」

美咲はそう言って、次の入金を待つ画面を閉じた。閉じた机の上には、確認を終えたメモと、明日使う小さなノートだけが置かれていた。

経理部の照明が、通路の奥から一つずつ消えていく。最後の灯りの下で、銀行明細の通知を待つ画面も暗くなった。静かな部屋に、翌朝の処理を受け入れる準備だけが残った。