「入金済/未入金」の先までも楽に請求管理できる！freee×kintone×n8nの入金消込自動化と滞留追跡

入金管理はプラグインで完結するはずが、分かるのは入金済か未入金かだけだった

月末になると、複数の案件分の入金がまとめて振り込まれます。取引先が1回の振込に何件もの請求をまとめてくるため、経理の担当者は入金明細と請求一覧を横に並べます。どの入金がどの案件のものかは、手作業で突き合わせるほかありません。

件数が多い月ほど照合に時間がかかり、消込が終わるまで売掛金の残高は確定しません。月末に人手の突合が積み上がるほど、入金消込の自動化を考え始める担当者も増えていきます。

こうした請求・入金まわりの手間について、世間には一つの見方があります。「freee for kintoneや請求書系のプラグインを入れれば、入金管理はkintoneのなかで完結する」という考え方です。

会計・請求はfreeeで、案件管理はkintoneで動かしているなら、両者をつなぐプラグインで入金の管理もkintone側に片づくはずだ、という理屈になります。ところが、プラグインを入れて実際にkintoneのレコードに現れるのは、多くの場合「入金済か、未入金か」という状態だけなのです。

請求書を送ってから何日で入金されたのか。どの取引先の入金が遅れがちなのか。まとめて振り込まれた金額のうち、どれがどの案件なのか。こうした「入金済/未入金の一歩先」は、プラグインを入れただけでは見えてきません。

足りないのは滞留の時系列と金額照合｜freee請求書API×n8nで両方を自動化できる

先に結論をお伝えします。プラグインの「入金済/未入金」で止まっていた請求管理は、freee請求書APIとn8nを組み合わせれば、二つの方向に広げられます。

一つは、請求書の「送付→閲覧→入金」という流れを追い、入金がどれだけ滞っているかを可視化する滞留の追跡です。もう一つは、振り込まれた入金の金額と案件ごとの請求金額を突き合わせ、消込までを進める金額の照合になります。

鍵になるのは、プラグインが同期する「入金済/未入金」という結果ではなく、freee請求書APIが返す元のデータを扱うことです。freee請求書APIでは、請求書の送付や入金の状態に加え、URL共有で送った請求書を相手がいつダウンロードしたか（開封に相当する時刻・状態）も取得できます。

これらの元データをn8nで日次に取り込み、そこに「一括振込を分解する」「振込手数料の差を吸収する」といった業務のルールを組み込んでいきます。この業務ルールの部分こそ、既存のプラグインが持たず、n8nで補う必要のある領域なのです。

n8nそのものの基礎的な使い方は、n8nとは？kintoneと生成AI連携のはじめかたで解説しています。本記事では入金消込と滞留追跡の中身に絞って進めます。

freee×kintone×n8nの入金消込自動化の全体像。入金済/未入金の二択から滞留追跡と案件別消込へ広げる連携図

この全体像を、実際にn8nの画面へ落とし込んだものが次のワークフローです。「滞留の追跡」と「入金の消込」という二つの流れに分かれており、本記事の後半ではこの二つを順に見ていきます。

入金済/未入金の二択でしか見えない状態を時系列にすると、未回収の放置と月末残業がなくなる

なぜ、わざわざAPIまで持ち出して「入金済/未入金の一歩先」を作る価値があるのでしょうか。理由は、入金が二択でしか見えないことが、そのまま二つの業務上の負担につながっているからです。

一つ目は、月末の照合残業です。口座同期で入金そのものは自動で取り込まれても、それがどの案件への入金かはkintone側では分かりません。担当者が請求一覧と入金明細を突き合わせ、金額を手で分解して割り当てます。この突合が終わらないと売掛金の残高が確定せず、月次決算までずれ込むのです。

二つ目は、未回収の放置です。「入金済か未入金か」だけでは、未入金がどれだけ滞っているのかが分かりません。送付から30日たった未入金も、昨日送ったばかりの未入金も、同じ「未入金」に見えてしまいます。

滞留の日数が見えなければ、督促の優先順位もつけられません。回収が遅れた債権が、気づかないうちに積み上がってしまいます。

入金を「入金済/未入金」の二択から、滞留の時系列と案件の紐付けに変えると、この二つが仕組みの側で解消に向かいます。督促すべき相手が滞留日数の順に並び、入金と案件が結びついて消込が進むのです。

もう一点、触れておきたいことがあります。この仕組みを「誰が組むのか」という論点です。kintoneのアプリ作成ができ、APIの設定に手が届く担当者であれば、外部のシステム会社に大がかりな開発を発注しなくても、自社で組める範囲に入ります。

新たに専用の入金消込システムを契約する必要もありません。n8nはクラウド版なら月額数千円規模、自社サーバーで動かすセルフホストなら無料の選択肢もあり、freee請求書APIもfreeeの契約プランの範囲で使えます。

つまり、かかる費用よりも、社内で手を動かす時間を確保できるかどうかが実際の論点になります。技術的に組めることと、社内にそれを進める時間があることは、分けて考える必要があるでしょう。

期待と現実のギャップを生む、消込を止める三つの壁

「APIがあるなら、あとはつなぐだけだろう」と考えて着手すると、消込を自動で回そうとした段階で三つの壁に当たります。いずれも、プラグインの「入金済/未入金」だけでは越えられない壁です。踏む順に見ていきましょう。

入金消込の自動化を止める三つの壁の図解。入金の状態のみ・一括振込の混在・振込手数料のずれ

同期される入金は入金済/未入金の状態だけで、滞留の時系列を持てない

一つ目の壁は、同期されるデータがどこまで細かいか、です。freee for kintoneなどのプラグインや口座同期で得られるのは、多くの場合「入金済か、未入金か」という状態にとどまります。この状態だけでは、「請求書を送付したのがいつか」「入金されたのがいつか」という日付の履歴を、時系列として持てません。

滞留日数を出すには、送付日と入金日の差を計算する必要があります。その計算のもとになる日付そのものが同期されていないため、二択の状態を眺めているだけでは滞留は見えてこないのです。滞留を追いたいなら、freee請求書APIから送付や入金の日付を取り込み、kintone側に履歴として貯めるところから始めます。

一括振込は1入金に複数案件が混ざり、請求との対応がつかない

二つ目の壁は、一括振込です。取引先が複数の案件をまとめて1回で振り込むと、口座に現れるのは合計金額の1明細だけになります。この1件の入金を、kintone上にある複数の請求レコードへ、そのまま結びつけることはできません。

たとえば、3件の請求（10万円・15万円・20万円）に対して45万円が1回で振り込まれたとします。入金は45万円の1件、請求は3件です。この45万円を、どの請求とどの請求の組み合わせなのかに分解しなければ、案件ごとの消込は進みません。

1対1で素直に対応がつく入金ばかりではない。この点が、消込を手作業に押し戻す大きな要因になっています。

振込手数料の差引きで金額が一致せず、突合が止まる

三つ目の壁は、振込手数料です。取引先が振込手数料を差し引いて振り込むと、入金額は請求額とぴったり一致しません。10万円の請求に対して、手数料を引いた9万9,780円が入金される、といったずれが日常的に起こります。

金額が完全に一致することを条件に突合しようとすると、この手数料分ずれた入金がすべて「一致しないもの」としてはじかれてしまいます。すると、はじかれた入金を担当者が一件ずつ確認するはめになり、自動化したはずの消込がまた手作業に戻るのです。

なかでも、この手数料のずれが月末の手戻りにもっとも直結します。

ギャップを埋める、日次取得と誤差を許した突合の設計

三つの壁は、いずれもプラグインの外側に業務のルールを組むことで越えられます。ここからは、壁の一つずつに対応する設計を、実際に組む順に見ていきましょう。全体を貫く考え方は、機械が確実に判断できるところは自動で進め、迷うところは人に残す、という割り切りです。

APIで送付・閲覧・入金日を日次取得し、kintoneに時系列で蓄積する

最初に、滞留を追うための土台を作ります。n8nのスケジュール実行でfreee請求書APIを1日1回呼び出し、請求書の送付日、相手のダウンロード（開封）状況、入金の状態、金額を取り込みましょう。取り込んだデータは、その時点の状態としてkintoneに履歴で貯めていきます。

日々の状態を貯めておくと、「送付から今日で何日たったか」「入金までに何日かかったか」を、あとから計算できます。一つ目の壁だった「日付の履歴がない」状態が、これで解消するのです。

実際にkintoneへ貯めた画面が次の一覧です。「入金済／未入金」という状態だけでなく、送付日・入金日・送付からの経過日数（滞留日数）まで列として持てているのが分かります。用意するアプリのフィールドは、請求書番号・取引先名・送付日・入金状態・入金日・滞留日数などです。

滞留日数を持てれば、未入金を滞留の長い順に並べ、督促すべき相手から手をつけられます。kintoneに貯めたデータをどう活用の幅につなげるかは、kintone×n8nで貯まったデータをスムーズに連携する方法もあわせて参考にしてください。

一括振込は金額の組み合わせで案件に割り当て、確定は人が承認する

次に、一括振込への対応です。1件の入金額に対して、合計が一致する請求の組み合わせをn8nで探し、候補として提示します。先ほどの45万円の例であれば、「10万円・15万円・20万円の3件」という組み合わせを候補に挙げます。

ただし、組み合わせの候補が複数見つかることも少なくありません。そこで、最終的にどの組み合わせで確定するかは、人が画面上で承認します。分解の計算という手間のかかる部分はn8nに任せ、判断の一手だけを人が担う。こうすれば、二つ目の壁だった一括振込を、手作業に戻さずに処理できます。

一括振込45万円を10万円・15万円・20万円の請求に分解して案件別に消込する仕組みの図解

この分解を実際にn8nで動かすと、次のような結果になります。45万円の入金が「10万円・15万円・20万円」の3件に分解され、案件ごとの消込の候補として並びます。

金額の近さで突き合わせ、手数料分の誤差を許容する

組み合わせを探すときも、単純な1対1の入金を突き合わせるときも、金額の一致には幅を持たせます。請求額とぴったり同じであることを条件にせず、数百円程度の範囲であれば同じものとみなすのです。

こうすると、振込手数料の分だけずれた入金も、対応する請求と自動で結びつきます。三つ目の壁だった手数料のずれを、この誤差の許容で吸収するわけです。どこまでの差を許すかは、取引先が使う金融機関の手数料の水準にあわせて決めます。

ここまでの「合計が一致する組み合わせの探索」と「金額の誤差の許容」は、n8nのCodeノードにまとめて記述します。下の画面がその中身です。先頭にある許容誤差（TOLERANCE）の値を変えれば、どこまでの手数料のずれを同じ入金とみなすかを調整できます。

照合できない入金は「要確認」に回し、全自動化に固執しない

どれだけルールを組んでも、機械が判断しきれない入金は残ります。金額がどの請求とも合わない、組み合わせの候補が見つからない、といった入金です。こうした入金は、無理に自動で当てにいかず、「要確認」の状態にしてkintoneに残します。

こうして自動で消し込めた入金と、人の確認に回す入金は、kintone上で次のように振り分けられます。「消込候補」は人が中身を見て承認し、「要確認」は個別に調べるという出口を用意しておくわけです。

大切なのは、機械が判断できる範囲は自動で進め、判断に迷う入金は人の目に委ねる姿勢です。機械が迷うものを人に回す出口を用意しておけば、例外的な入金で一連の処理全体が止まることを防げます。自動で片づくものが大半を占め、人は残りの少数に集中できる。これが、現実的に回る仕組みなのです。

【実装担当向け】freee請求書APIのステータス値は、数件のレスポンスを実際に取得して確かめる

ここは実装を担当する方への補足のため、読み飛ばしても記事の理解には支障ありません。freee請求書APIが返すステータスの値は、公式のfreee APIリファレンスの説明を読むだけでは、実際にどんな値がどこまで細かく入るのかが分かりにくいことがあります。

そのため、設計を固める前に、テスト用の請求書を数件発行して、実際のレスポンスをたしかめることをおすすめします。どのフィールドに送付日や入金の状態が入るのかを実際のデータで押さえておくと、後段の突合ロジックを組むときの手戻りが減るはずです。

kintone側のREST APIの仕様については、cybozu developer networkを参照してください。

入金が案件ごとに結びつき、督促も決算も前倒しできる

入金がkintoneのなかで「入金済/未入金」の二択にとどまっているうちは、経理の担当者が月末に突合を繰り返す状態から抜け出せません。滞留の時系列と案件の紐付けが加わると、この状態が変わります。

未入金は滞留日数の順に並び、督促の判断がその場でつきます。入金と案件が結びつくため、消込が進み、売掛金の残高が早く確定します。結果として、督促も月次決算も前倒しできるようになるのです。

詰まる場所は、これまで見てきた三つに絞られます。

  • 同期される入金の状態
  • 一括振込の分解
  • 振込手数料のずれ

この三つを先に押さえておけば、あとは自社の手で組める範囲に収まります。残るのは、その手を動かす時間を社内で確保できるかという体制の問題だけです。

まとめ

freee単体や既存のプラグインでは、入金は「入金済/未入金」の二択でしか見えません。

そこにfreee請求書APIとn8nを組み合わせ、送付から入金までの日付を日次で貯め、金額の誤差を許した突合と一括振込の分解を業務ルールとして組む。そうすれば、滞留の追跡と案件ごとの消込までを自社で仕組み化できます。

越えるべき壁は、入金の状態・一括振込・振込手数料の三つです。この三つに対して、日次のデータ取得・組み合わせによる割り当て・金額の誤差を許した突合・要確認への振り分けという設計で応じれば、月末の照合残業と未回収の放置を、手作業に頼らず抑えられます。

最後に

入金消込の自動化と、freeeでの入金管理を一歩先へ進めたい方に向けて補足します。ここで示した設計は、あくまで考え方の骨格です。

実際にどこで詰まるか、どの差までを許すべきか、構築や運用にどれくらいの手間がかかるかは、取引先の振込の慣習や請求の件数によって変わってきます。

自社の請求・入金の運用に当てはめたときに判断がつかない場合は、ものづくりAI自動化ファクトリーの無料相談をご利用ください。kintoneとfreeeをどうつなぎ、どこまでを自動化してどこを人に残すか、自社の環境にあわせて一緒に整理します。

関連記事