入金消込を自動化する｜振込名義の対応表を持ち、合わない入金を3種類に分ける

月初に銀行口座の入金明細を開き、請求書の一覧と突き合わせる。金額が一致すれば消し込み、合わなければ保留にして原因を探す。この作業が、請求の件数が月100件を超えるあたりから半日、200件を超えると1日仕事になります。

消込の自動化は、金額が一致する入金を機械に処理させるところまでは簡単です。難しいのはその先で、合わない入金をどう扱うかを決めていないと、保留の一覧が月々積み上がっていくことになります。この記事では、突合を自動化する仕組みと、合わない入金を3種類に分けて処理する設計を説明します。

ムダの現状：合っている入金を確認する時間

入金消込の作業を分解すると、請求書照合と同じ構造が見えます。

入金明細を1行ずつ見て、請求の一覧から相手と金額を探し、一致すれば消し込む。1件あたり1分から2分。月200件なら3時間から7時間です。そして、実際に一致しないのは全体の1割から2割で、残りの時間は「合っていることの確認」に使われています。

合わない入金は、3種類に分かれる

自動化を設計するうえで重要なのは、合わない入金の性質を先に整理しておくことです。3つに分かれ、それぞれ対処する人が違います。

3つ目を営業に渡すのが、この仕組みの分かれ目です。経理が督促まで抱えると、他の2つの処理が止まります。そして、取引の経緯を知らない経理が督促しても、先方の事情が分かりません。

機械に渡せる部分と、人に残す部分

4番目の「名義の対応づけ」は人がやりますが、1つの名義につき1回だけです。一度登録すれば、翌月から機械が処理します。この積み上げが、消込の自動化の精度を決めます。

スキームの全体図：突合、分類、追いかけ

必要なツールと費用（2026年9月22日時点）

最初に確認すべきは、1つ目の入金明細の取得方法です。これが手作業でのダウンロードしかない場合、毎日の取り込みが続きません。自動で取得できる手段があるかを、仕組みを作る前に確かめてください。

導入手順：入金の識別方法を決めるところから

Step 1：過去3か月の入金を、名義で分類する

消込が自動化できるかどうかは、入金を請求先に結びつけられるかで決まります。まず、その実態を確認します。

過去3か月の入金明細を集め、振込名義と請求先が一致するかを見てください。たいてい、次のような分布になります。

2つ目までなら、ルールで吸収できます。3つ目は対応表が必要です。4つ目のまとめ入金が多い場合は、実装の難易度が一段上がるので、その件数を先に数えておいてください。

Step 2：名義の正規化ルールを決める

表記の違いを吸収するルールを決めます。銀行の入金明細は、たいていカタカナで届きます。

やることは4つです。全角と半角を揃える。カタカナに統一する。法人格の表記を外す。空白と記号を除く。この4つで、表記の違いの大半は吸収できます。

ただし、正規化を強くしすぎると、別の会社が同じ文字列になります。似た社名が複数ある業界では、正規化の後に重複がないかを必ず確認してください。重複があれば、その会社だけは対応表で個別に扱います。

正規化ルールの作り方と、確認のしかた

正規化のルールは、いきなり全件に当てないでください。過去3か月の名義をリストにして、正規化した結果を横に並べた表を作ります。

この表を目で見ると、2つのことが分かります。1つは、正規化しても請求先に結びつかない名義がどれだけあるか。もう1つは、正規化した結果、別の会社が同じ文字列になっていないかです。

2つ目は必ず確認してください。似た社名が複数ある業界では実際に起きます。重複が見つかったら、その会社だけは正規化の対象から外し、対応表で個別に扱います。ルールを弱めると、他の名義が結びつかなくなるためです。

そして、正規化のルールは1度決めたら頻繁に変えないでください。ルールを変えると、過去の突合結果と整合しなくなります。個別の例外は、ルールではなく対応表で吸収するのが原則です。

Step 3：突合と分類を書く

次のApps Scriptは、入金明細を1行ずつ見て、請求を探し、合わないものを3種類に分類します。

var FEE_TOLERANCE = 880;
function matchPayments() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var alias = loadAlias(ss);
  var bills = loadBills(ss);
  var rows = ss.getSheetByName('入金明細').getDataRange().getValues().slice(1);
  var out = [];
  for (var i = 0; i < rows.length; i++) {
    var date = rows[i][0], name = rows[i][1], amount = Number(rows[i][2] || 0);
    if (!amount) continue;
    var key = normalize(name);
    var customer = alias[key] || key;
    var cand = bills[customer];
    if (!cand) {
      out.push([date, name, amount, '識別できない', '経理', '']);
      continue;
    }
    var hit = pickBill(cand, amount);
    if (hit) {
      hit.paid = true;
      var diff = hit.amount - amount;
      var note = diff === 0 ? '' : '差額' + diff + '円を手数料として処理';
      out.push([date, name, amount, '消込済み', '', hit.id + ' ' + note]);
    } else {
      out.push([date, name, amount, '金額が違う', '経理', '請求は見つかったが金額が一致しない']);
    }
  }
  addUnpaid(bills, out);
  write(ss, out);
}
function normalize(s) {
  return String(s || '').replace(/[Ａ-Ｚａ-ｚ０-９]/g, function (c) {
    return String.fromCharCode(c.charCodeAt(0) - 0xFEE0);
  }).replace(/[ 　\-\.\(\)（）]/g, '')
    .replace(/(カ|カブ|ユ|ユウ|カブシキガイシャ|ユウゲンガイシャ)$/, '')
    .toUpperCase();
}
function loadAlias(ss) {
  var m = {};
  var v = ss.getSheetByName('名義対応表').getDataRange().getValues().slice(1);
  for (var i = 0; i < v.length; i++) {
    if (v[i][0]) m[normalize(v[i][0])] = normalize(v[i][1]);
  }
  return m;
}
function loadBills(ss) {
  var m = {};
  var v = ss.getSheetByName('請求一覧').getDataRange().getValues().slice(1);
  for (var i = 0; i < v.length; i++) {
    if (v[i][4] === '消込済み') continue;
    var c = normalize(v[i][1]);
    if (!m[c]) m[c] = [];
    m[c].push({ id: v[i][0], customer: v[i][1], amount: Number(v[i][2] || 0),
                due: v[i][3], paid: false });
  }
  return m;
}
function pickBill(list, amount) {
  for (var i = 0; i < list.length; i++) {
    if (list[i].paid) continue;
    var diff = list[i].amount - amount;
    if (diff < 0) continue;
    if (diff <= FEE_TOLERANCE) return list[i];
  }
  return null;
}
function addUnpaid(bills, out) {
  var today = new Date();
  for (var c in bills) {
    for (var i = 0; i < bills[c].length; i++) {
      var b = bills[c][i];
      if (b.paid) continue;
      if (!b.due) continue;
      if (new Date(b.due) >= today) continue;
      out.push(['', b.customer, b.amount, '入金がない', '営業', b.id + ' 期日超過']);
    }
  }
}
function write(ss, out) {
  var sh = ss.getSheetByName('消込結果');
  sh.getRange(2, 1, Math.max(sh.getLastRow() - 1, 1), 6).clearContent();
  if (out.length > 0) sh.getRange(2, 1, out.length, 6).setValues(out);
}

実装で押さえている点を4つ挙げます。

1つ目、差額の判定を片側だけにしていること。請求額より入金が少ない場合だけを手数料の候補とし、入金が多い場合は一致とみなしません。過入金は別の原因があるためです。

2つ目、手数料の許容額を定数にしていること。振込手数料は銀行や金額で変わるので、自社に入ってくる実績を見て設定してください。大きくしすぎると、一部入金を手数料として処理してしまいます。

3つ目、担当の列を自動で入れていること。「識別できない」と「金額が違う」は経理、「入金がない」は営業。分類と同時に担当が決まる形にしないと、結局は経理が全部見ることになります。

4つ目、期日を過ぎた未消込の請求を、明細の側からではなく請求の側から拾っていること。入金がないものは入金明細に現れないため、この処理がないと永久に検出されません。

Step 4：対応表を、運用しながら育てる

「識別できない」に出た入金は、経理が請求先を特定して対応表に追加します。この作業は1つの名義につき1回だけです。

3か月も運用すれば、継続的な取引先の名義はほぼ登録済みになります。その後に「識別できない」が出るのは、新しい取引先か、先方の支払方法が変わったときです。件数が月に数件まで落ちてきたら、この仕組みは定着しています。

対応表には、登録した日と登録した人も残してください。後から「なぜこの名義がこの会社になっているのか」を確認する場面が出ます。

Step 5：毎日走らせる

月初にまとめて処理するのをやめてください。毎日、前日の入金を取り込んで突合します。

理由は2つあります。1つは、月初に1日仕事になるのを避けるため。もう1つは、入金がない請求に早く気づけるためです。期日の翌日に分かれば、営業が動く時間があります。月初にまとめて見ると、気づいた時点で2週間経っていることもあります。

最初の1か月で見る数字

運用を始めたら、1か月目は精度の確認に使ってください。見るのは2つです。

1つ目、自動で消し込めた件数のうち、実は誤っていたものがあるか。経理が全件を目で確認して数えます。誤りが出るとすれば、たいてい同名の会社か、金額が偶然一致した別の請求です。ここが0件で1か月通れば、目視をやめる判断ができます。

2つ目、「識別できない」に出た件数の推移です。1週目に多く、4週目には減っているはずです。減っていないなら、対応表への登録が回っていません。登録を誰がいつやるかを決め直してください。

この2つを見ずに運用に乗せると、精度が分からないまま使い続けることになります。1か月の確認は、その後の数年分の安心につながります。

現場の合意の取り方：営業に督促を渡す

この仕組みで合意が要るのは、入金がない請求を営業に渡す点です。経理の中だけで完結しません。

「督促」ではなく「確認」として渡す

言葉を変えるだけで、営業の受け取り方が大きく変わります。

期日を過ぎた入金の多くは、悪意ではありません。請求書が届いていない、担当者が変わった、支払のサイクルが違う。まず手違いを疑う姿勢で連絡すれば、営業も動きやすくなります。

そのために、確認の文面を1つ用意して配ってください。「ご入金の確認が取れておりませんが、請求書は届いておりますでしょうか」という程度で十分です。文面を考えさせないことが、着手の速さを決めます。

2回目以降は、経理に戻す

営業に渡すのは、最初の確認までにしてください。それで解決しない場合は経理、あるいは管理部門に戻します。

この線を引いておかないと、営業は何度も催促する役回りを背負うことになり、次第に確認そのものをやらなくなります。1回で終わる仕事だと分かっていれば、着手されます。

戻す先も決めておいてください。経理が引き継ぐのか、管理部門が担当するのか。ここが曖昧だと、営業が1回確認したあと誰も動かない状態が生まれ、結局は期日超過の一覧に残り続けます。

あわせて、何日で戻すかも決めます。営業に渡してから5営業日、といった形です。期限を切っておかないと、確認したかどうかが分からないまま時間が過ぎます。

失敗パターンと限界：帳簿と証憑の保存

消込の記録は、帳簿の裏付けになる

どの入金をどの請求に当てたか、差額を何として処理したか。この記録は、売掛金の残高を説明する根拠になります。

自動化すると、処理が速いぶん記録が軽くなりがちです。消込結果のシートを毎月上書きする設計にしないでください。月ごとに履歴として残し、後から特定の請求の経緯を辿れる状態にしておきます。

特に、差額を手数料として処理した記録は重要です。金額が小さいため軽く扱われがちですが、積み上がると無視できない額になります。誰がいつ、いくらを何として処理したかが残っていれば、後から検証できます。

電子で受け取った証憑には、保存の義務がかかる

入金の消込に関連して、取引先から送金明細や支払通知をメールで受け取ることがあります。これらは電子取引の対象になりえます。

電子帳簿保存法第2条第5号は、電子取引を取引情報（取引に関して受領し、又は交付する注文書、契約書、送り状、領収書、見積書その他これらに準ずる書類に通常記載される事項をいう）の授受を電磁的方式により行う取引と定義しています。そして同法第7条は、電子取引を行った場合には、財務省令で定めるところにより、当該電子取引の取引情報に係る電磁的記録を保存しなければならないと定めています。

何が対象になるかは書類の内容によるため、自社が受け取っているものが該当するかは、国税庁の資料や顧問税理士に確認してください。消込の仕組みを作るときに、受け取った電子データの保管先も同時に決めておくと、後から探し直す手間が省けます。

この仕組みが向かない場合

入金の大半がまとめ入金で、複数の請求が1件の振込になる業態では、突合の難易度が上がります。組み合わせを探す処理が必要になり、候補が複数出たときの判断も人に戻ります。

この場合は、まず取引先に支払通知の送付を依頼できないかを検討してください。どの請求に対する入金かが先方から届けば、突合は一気に簡単になります。仕組みで解くより、運用で解くほうが速い場面です。

また、請求の件数が月50件に満たないなら、自動化の効果は限定的です。ただし、期日を過ぎた請求を自動で拾う部分だけは、件数が少なくても価値があります。

AIを足すなら、名義の推測に

この仕組みにも、生成AIは登場していません。突合も差額の判定も、条件がはっきりしているのでルールで書けるからです。

AIが役に立つとすれば、「識別できない」に出た名義から請求先を推測する場面です。カナの振込名義と、漢字の請求先の一覧を渡して、対応の候補を出させる。経理はその候補を確認して対応表に登録します。

ただし、AIの推測をそのまま対応表に書き込まないでください。一度間違った対応を登録すると、以降の消込がすべて誤ります。AIが出すのは候補まで、登録は人が判断する。この線を守れば、対応表を育てる作業が速くなります。

なお、請求先の一覧をAIに渡す場合、そこに個人事業主の氏名が含まれることがあります。利用目的の範囲内か、委託にあたるならその監督ができる形かを、先に確認してください。

効果の測り方

1つ目は、3か月かけて上げていく数字です。対応表が育つにつれて上がります。導入直後の数字で判断しないでください。最初の月は半分程度でも、3か月目には大きく変わります。

3つ目が、この仕組みの本当の価値です。月初にまとめて処理していたころは、期日超過に気づくのが2週間後だったはずです。毎日走らせる運用に変えると、ここが1日から2日になります。回収の早さは、そのまま資金繰りに効きます。

まとめ

入金消込も、時間の大半は「合っていることの確認」に使われています。ここを機械に渡し、人が見るのは合わないものだけにするのが基本の形です。

設計の要点は2つ。振込名義が請求先と一致しないことを前提に、正規化ルールと対応表を持つこと。そして、合わない入金を識別できない・金額が違う・入金がないの3種類に分け、分類と同時に担当が決まる形にすることです。特に3つ目を営業に渡さないと、経理が督促を抱えて他の処理が止まります。

運用では、月初にまとめず毎日走らせてください。期日超過に早く気づけるようになり、回収が早まります。営業には「督促」ではなく「確認」として渡し、文面を用意する。2回目以降は経理に戻すと決めておく。そして、消込の記録は帳簿の裏付けになるため、毎月上書きせず履歴として残してください。

よくある質問

振込名義がまったく違う取引先が多く、自動化できません

対応表を持てば解決します。1つの名義につき登録は1回だけで、3か月も運用すれば継続的な取引先はほぼ登録済みになります。最初の1か月は登録作業が発生しますが、その後は新規の取引先だけになります。この作業を惜しむと、毎月同じ調査を繰り返すことになります。

手数料の許容額は、いくらに設定すべきですか

自社に実際に入ってくる入金の差額を集計して決めてください。銀行や金額帯によって手数料は変わります。大きくしすぎると、一部入金を手数料として処理してしまうので注意が必要です。迷うなら小さめに設定し、経理が確認する件数を許容するほうが安全です。

過入金はどう扱えばよいですか

自動で一致とみなさず、必ず人が確認する扱いにしてください。二重振込、前払い、別の請求分が混ざっている、といった別の原因があります。この記事のコードでも、請求額より入金が多い場合は一致と判定しない設計にしています。

まとめ入金が多い場合は、どうすればよいですか

まず、取引先に支払通知の送付を依頼できないか検討してください。どの請求に対する入金かが先方から届けば、突合は簡単になります。依頼が難しい場合は、金額の組み合わせを探す処理を実装することになりますが、候補が複数出たときの判断は人に戻ります。

営業が確認をやってくれません

3点を確認してください。督促ではなく確認として渡しているか。文面を用意しているか。そして、2回目以降は経理に戻すと決めているか。特に3つ目が抜けていると、営業は何度も催促する役回りを背負うことになり、次第に着手しなくなります。

消込の記録は、どれくらい残すべきですか

毎月上書きせず、履歴として残してください。どの入金をどの請求に当てたか、差額を何として処理したかは、売掛金の残高を説明する根拠になります。保存の年数については、自社の帳簿書類の保存方針に合わせて判断し、迷う場合は顧問税理士に確認してください。

同じ部門の記事

経理請求書照合を自動化する｜発注・納品・請求の三点照合と、国税庁の公的APIによる登録番号の確認2026年9月28日
経理経理の仕訳を自動化する｜摘要辞書とAIと人の三層で、経理担当者と税理士が納得する仕組みにする2026年9月21日