「金額は合っていそう。でも、この振込名義はどの会社だろう？」
請求一覧と入金明細を開いて、社名の空白を消す。株式会社を略称に直す。日付をそろえる。ようやく金額を比べられると思ったら、同じ取引先の請求が何件もある――。
経理の照合作業は、数字を比べる前の準備に時間がかかりがちです。これは担当者の確認が遅いからではありません。別々に作られたデータを、つながりにくい状態のまま照合していることが一因です。
今回のテーマは、請求書と入金データの突合自動化。目指すのは、表記と照合ルールを整え、候補と差分を機械で整理して、人が差額や例外の確認に時間を使える状態です。
※がんばる商事・つながる商事と登場人物は架空です。漫画・本文の帳票や例は説明用であり、特定企業の導入事例や実測成果ではありません。
金額の前に「同じ相手のデータか」を確かめる
がんばる商事の経理担当・しめ田さんは、毎月、請求一覧と入金明細を見比べています。同じ会社でも、請求書には「株式会社あおば」、台帳には「（株）あおば」、銀行明細には「カ）アオバ」と書かれているかもしれません。
人なら推測できても、文字の完全一致だけでは同じ相手と判定できません。一方、名前を似せる処理だけで結び付けると、似た社名の別会社を取り違えるおそれがあります。
そこで、「比較しやすい形に整えること」と「同じ取引先だと確認すること」を分けます。
前者を「正規化」と呼びます。空白や日付などの表し方を、決めたルールにそろえる作業です。後者には、取引先コードや、確認済みの振込名義と取引先を結び付けた対応表を使います。
① 入力を統一する。元データは残す
まず、請求データ・入金データそれぞれの項目を整理します。取り込んだデータを直接書き換えず、元の値と照合用に整えた値を分けて持つと、判定の理由を後から追えます。
| 項目 | そろえること | 間違えやすい点 |
|---|---|---|
| 取引先名・振込名義 | 前後の空白、全角・半角など、対象とする表記のルール | 略称やカナ名義は、確認済みの対応表で取引先コードに結び付ける |
| 請求対象月 | 年を含む「2026-10」など、同じ意味・同じ形式 | 「10月」だけでは年を区別できない。売上月・請求月・入金月も別の項目 |
| 請求日・入金予定日・入金日 | 日付として扱える値と、表示形式 | 表示をそろえても、それぞれ別の出来事を示す日付 |
| 金額 | 通貨、税込・税抜、数値としての扱い | カンマや円記号を外すだけでなく、比較する金額の意味をそろえる |
たとえば「2026/10/31」と「2026-10-31」は、同じ日付を別の形で表示した例です。しかし「10月請求」と「11月入金」は、同じ月に直してよい値ではありません。請求と入金の関係をたどる必要があります。
また、GoogleスプレッドシートのTRIM関数は、先頭・末尾や繰り返しのスペースを整理する機能です。社名の略称・カナ表記まで統一する機能ではなく、単語間の空白や特殊な空白も含めて何を処理するかは別に決めます。[1]
「株式会社を全部消す」「空白を全部消す」で終わらせず、変換後に複数の取引先が同じ表記になっていないかも確認しましょう。
② 照合キーを決める。社名と金額だけに頼らない
照合キーとは、どの請求とどの入金を比べるかを絞るための手がかりです。
請求番号が入金側にも届くなら、有力な手がかりになります。銀行明細に請求番号がない場合は、確認済みの名義対応表から取引先コードを特定し、未処理の請求、支払期日、金額などを組み合わせて候補を探します。
| データの状況 | 照合の考え方 |
|---|---|
| 双方に同じ請求番号がある | 請求番号を軸にし、取引先・金額・重複の有無も確認する |
| 振込名義と金額しかない | 取引先を対応表で特定し、未処理請求の中から候補を絞る |
| 同じ取引先に同額の請求が複数ある | 最初に見つかった行を選ばず、「候補複数」として人に戻す |
| 複数請求をまとめて払う／分割して払う | 請求と入金の割当を別に管理し、残額を追う |
大切なのは、一つの入金を複数の請求へ重複して割り当てないこと。単純な行同士の比較で済む範囲と、合算・分割を扱う範囲は分けて考えます。
似た名前を探す機能は、候補づくりには使えます。ただし、「たぶん同じ」を、そのまま「入金確認済み」にしないのが基本です。
③ 差分を出す。「一致しない理由」が分かる一覧に
自動化の出力が、単に「一致／不一致」だけだと、担当者は結局すべてを開き直すことになります。次のように、確認する理由を分けておくと、その後の仕事につながります。
| 一覧に出す状態 | 人が確認すること |
|---|---|
| 一致候補 | 決めた条件で一意に対応しているか。最初は手作業の結果と比較する |
| 差額あり | 手数料、値引き、金額誤りなどの理由。理由を自動で決め付けない |
| 期日到来前・入金未確認 | まだ支払期日前か。未入金の催促対象と混同しない |
| 期日超過・入金未確認 | 明細の取込漏れや名義不明がないかを確認してから、担当者へつなぐ |
| 対応する請求が見つからない | 前受け、対象期間の違い、取引先未登録などを調べる |
| 候補複数・合算・分割 | どの請求にいくら割り当てるかを判断する |
未確認の入金をすぐに「未入金」と断定しないことも大事です。銀行明細の更新が遅れているだけかもしれません。一覧には、データの対象期間、最終取込日時、元の請求・入金を確認できる情報を添えます。
④ 人の確認と、確認後の記録までつなげる
つながる商事で九ちゃんが整えたいのは、「不一致の一覧を作るところ」だけではありません。
差分を誰が確認し、営業担当などに何を問い合わせ、いつ締めの責任者に引き継ぐのか。確認が済んだら、誰が・いつ・何を根拠に確定したかを残します。
翌日同じデータを取り込んだときに、確認済みの内容を消したり、入金を二重に計上したりしない設計も必要です。元データ、名義対応表、照合結果、確認記録を役割ごとに分けると、手直しと再実行の影響を整理しやすくなります。
スプレッドシートとGASで、どこまで任せられる？
Googleスプレッドシートは、データや確認一覧を共有する場として使えます。Google Apps Script（GAS）は、Googleのツールをプログラムで操作する仕組みです。シートの読み書きや独自メニューなどに対応しており、決めたルールに沿う整形・候補抽出・差分一覧の更新を組み立てられます。[2]
ただし、GASを付ければ銀行データや請求書の内容が自動でそろうわけではありません。CSVなどの取得方法、対象列、明細の識別方法、取込担当を先に決めます。PDFの請求書から項目を読み取る作業が必要なら、読み取り精度と確認方法を含めた別の設計になります。
また、実行時間などの制限があり、上限に達すると処理が停止する場合があります。[3] 定期実行を設定する場合は、実行するアカウントと権限、失敗時の通知・再開手順、担当者変更時の引き継ぎも用意します。[4]
最初の一歩は、対象を絞ったサンプルで、今の手作業と結果を並べること。表記違い、同額請求、差額、合算・分割、重複取込などを含め、誤って一致扱いにするケースがないかを確かめます。本記事は設計の考え方を示すもので、完成システムや検証済みコードの提供ではありません。
実データの共有先は必要な担当者に限り、検証には匿名化したサンプルを使いましょう。外部の生成AIを併用する場合は、請求先や口座情報などを入力してよい契約・設定かを別に確認します。
まず「毎月直している項目」を書き出してみる
いきなり全件の自動処理を目指さず、次の3点を整理するところから始められます。
- 毎月手で直している社名・空白・日付などの項目
- 同じ取引先・同じ請求だと判断している手がかり
- 手数料や合算入金など、人の判断が必要な例外
この3点が見えると、入力元を直すべきか、名義対応表が必要か、GASで整理できる範囲はどこかが具体的になります。
「何をそろえればよいか分からない」「今ある表を使って、確認対象を絞りたい」という方は、株式会社いざなうへご相談ください。最初のお問い合わせでは、実際の請求書や口座情報を添付せず、作業の概要と困っている点をお知らせください。
関連記事：スプレッドシートのGASとは？請求書づくりでわかるGoogle Apps Scriptの基本
参考情報・監修
Google公式情報の確認日：2026年11月5日。製品仕様や制限は変更される場合があります。
- Google ドキュメント エディタ ヘルプ：TRIM
- Google for Developers：Extend Google Sheets
- Google for Developers：Quotas for Google Services
- Google for Developers：Installable Triggers
監修：株式会社いざなう／代表取締役 蓼沼康之
Googleのツールを使った業務改善・情報管理・自動化を支援。入力元、データ構造、マスタ、運用ルールを整理し、スプレッドシート・GASや生成AIの実務活用につなげる観点から監修しています。
おまけの対話：「応募が多い開発」と「任せて回る仕組み」の違い
※以下は説明のための架空の対話です。募集・応募の傾向は蓼沼の案件閲覧経験に基づく所感であり、市場全体の統計ではありません。
いざな丑スキルマッチングサイトを見ると、こうしたスプレッドシートの開発相談は、1件の募集に多くの応募が集まる印象があるね。
九ちゃん使う場所がGoogleスプレッドシートと決まっていて、整形や比較だけなら、実装そのものに高度な技術を必要としないケースもあります。取り組みやすく見えるのだと思います。
いざな丑でも、「社名と金額が合えば完了」で作ると、同額の請求や、まとめて振り込まれたときに困るね。
九ちゃんはい。難しいのは、何を同じ取引とみなすか、どこから人に戻すかを決めることです。経験があると、正常なデータだけでなく、未登録の名義、取消し、取込漏れ、再実行なども最初に確認できます。
いざな丑コードを書けることに加えて、経理の仕事を聞き取り、誤った一致を防ぐ設計ができるかが大切なんだね。
九ちゃんそうです。経験の強みは、複雑なコードを増やすことより、確認しやすい一覧、元データをたどれる記録、失敗に気づく仕組み、引き継げる手順まで考えられること。依頼するときは「何をもって一致とするか」「例外は誰が見るか」「担当者が変わっても回るか」を一緒に相談してみてください。
