kintone×マネーフォワード×n8nで、手作業だった請求作業を自動化する方法を紹介！

標準連携でつなげば、請求まわりは自動化できると思っていないか

見積・受注・検収はkintoneで管理し、請求書の発行と入金の管理はマネーフォワード クラウドで行う。この2つを連携させて運用する中堅製造業の管理部門は、少なくありません。

問題は、この2つのあいだで毎月末に転記が集中することです。月末になると、kintoneの受注・検収レコードを見ながら、マネーフォワード クラウドで請求書を1件ずつ起こしていく。発行したあとは入金を消し込み、その結果を今度は手作業でkintoneの案件ステータスへ戻す。締めのたびに、この二重の入力と突合が経理に押し寄せます。

「標準連携でつなげば、こうした請求まわりは自動化できるはずだ」。そう考えて、標準連携の導入だけで済ませようとする方もいます。実際、kintoneとマネーフォワード クラウドをつなぐ公式の連携や、項目を同期するコネクタは存在します。なかには終了・縮小した公式連携もあり、代替手段を探している方もいるでしょう。

ところが、いざ導入してみると月末の手作業はなくなりません。帳票のフォーマットは連携できても、「検収が終わったら請求を起こす」「入金を確認したら案件を完了に進める」という肝心の部分が、思ったように自動で動かないのです。

標準連携は帳票発行と項目同期どまり、業務の節目で動かす部分はn8nが担う

先に結論をお伝えします。kintoneとマネーフォワード クラウドの標準的な連携は、帳票の発行と項目の同期が中心です。「検収の完了」や「入金の確認」といった業務の節目を合図に、次の工程を自動で動かす仕組みは持っていません。

私たちは、この足りない部分をn8nというワークフロー自動化ツールで補う設計を採っています。kintoneで検収を確定すると、その情報をもとにマネーフォワード クラウドの請求書が発行される。入金の消し込みが済めば、その結果がkintoneの案件へ戻り、ステータスが「完了」へ進む。この一連の流れは、SIerに大規模な開発を発注しなくても、自社の手で組める範囲にあります。

kintoneとマネーフォワード クラウドの連携で、標準連携とn8nの守備範囲を切り分けて示した図

なお、この設計はn8n上で組み上げ済みで、実運用での精度検証は現在進めている段階です。

ただし、思いつきで着手すると認証やプランの前提でつまずきがちです。どこでつまずくのかを先に知っておけば、回り道をせずに済みます。この記事では、標準連携では埋まらないギャップを3つに整理し、それぞれをn8nでどう埋めるかを順に見ていきましょう。あわせて、その設計を実際にn8nで組むと画面がどうなるのかも、手順として示します。

検収と入金の節目で、請求発行と案件完了をつなぎ直す

なぜ、わざわざ業務の節目で工程をつなぐ必要があるのか。理由は、売上の計上と入金の確認にタイムラグが生じ、そのしわ寄せが月末に集中するからです。

請求（売上の計上）と入金の確認がkintoneの外に分かれていると、業務の節目が次の工程を動かしません。検収が終わっても請求は自動では起きず、入金があっても案件は自動では完了しない。だれかが気づいて手で転記するまで、情報は分断されたまま止まります。この「気づいて転記する」作業が、締めのタイミングでまとめて発生するわけです。

標準連携の項目同期だけでは、この分断は解けません。項目をそろえることはできても、「検収が完了した」という状態の変化を検知して、次の請求発行を起こすことまではできないからです。だからこそ、検収と入金という節目を起点にして、請求発行と案件完了の流れをつなぎ直す必要があります。

ここで一点、誤解を避けておきたい点があります。請求連携をSIerに相談すると、数か月・数百万円規模の見積もりが返ってくることも少なくありません。一方でこの連携は、OAuth2やAPI連携の実装経験があれば手が届く範囲にあり、経験がない場合も着手のハードルはあるものの、大規模な開発を発注せずに済む余地があります。

とはいえ、それを社内で回す時間を確保できるかどうかは、技術とは別の体制の問題です。まず何が必要になるのかを、次章から具体的に見ていきましょう。

標準連携に任せて気づく、埋まらない3つのギャップ

自前で連携を組もうとすると、コードを書き始める前の段階でつまずきやすい箇所があります。設定・認証・検知の順に、代表的な3つを挙げます。

kintoneとマネーフォワード クラウドを自前連携する際につまずく3つのギャップを整理した図

APIの利用可否が、契約プランに左右される

まず引っかかりやすいのが、マネーフォワード クラウド側のAPIを呼ぶ前提です。「APIがあるならつながるだろう」と考えて着手すると、契約しているプランによっては想定した使い方ができないことがあります。

マネーフォワード クラウドは開発者向けにAPIを公開していますが、利用できる範囲や帳票作成のリクエスト上限は契約プランやオプションによって異なります。たとえば、ひとり法人プランやスモールビジネスプランでは、帳票作成のリクエスト上限が設けられています（2026年8月時点。プラン名・上限は変更されうるため、最新の条件はマネーフォワード クラウド開発者サイトで確認してください）。

月末にまとめて大量の請求書を起こす運用では、この上限が効いてくる場面があります。着手前に、自社の契約で必要な範囲のAPIが使えるかを確認しておくと、後戻りを防げます。

OAuth2認証の維持でつまずく

次につまずくのが認証です。マネーフォワード クラウドのAPIは、OAuth2による認可で利用します。認可の画面を通してアクセストークンとリフレッシュトークンを受け取り、以降はそのトークンを使ってAPIを呼び出す流れです。

やっかいなのは、アクセストークンに有効期限があることです。期限が切れたトークンをそのまま使い続けると、連携がある日突然止まります。そのため、リフレッシュトークンで新しいトークンへ更新していく処理を、あらかじめ組み込んでおかなければなりません。ここを軽く見ると、動いていた連携が思わぬタイミングで止まり、原因の特定に時間を取られます。

業務の節目を、標準連携は起点にできない

3つ目は、この記事の核心にあたるギャップです。標準連携や公式コネクタは、項目の同期や帳票の発行を担いますが、「検収が完了した」「入金が消し込まれた」という業務の節目を合図にして、次の工程を起こす仕組みを持っていません。

kintone側で検収完了のステータスに変わったことをきっかけに請求を起こす、あるいはマネーフォワード クラウド側で入金が消し込まれたことをきっかけに案件を完了へ進める。この「きっかけで動かす」部分こそ、自前で用意しなければならない要になります（kintoneのWebhookやREST APIの仕様はkintone REST APIの公式ドキュメントで確認できます）。

逆に言えば、ここさえ押さえれば、あとの流れは組み立てやすくなります。

ギャップをn8nで埋める、双方向連携の勘所

標準連携が持たない「節目を合図に次工程を動かす」部分を、n8nで明示的に作ります。ここでは、3つのギャップと対策が1つずつ対応するように並べていきましょう。

kintoneとマネーフォワード クラウドをn8nで双方向連携し、請求発行と入金結果の書き戻しをつなぐ流れ図

検収完了を検知して、自動で請求データを組み立てる

起点は、kintoneの検収完了です。kintoneでレコードのステータスが「検収完了」に変わったことを合図に、n8nが動き出す設計にします。kintoneのレコード更新を検知し、受注・検収のデータからマネーフォワード クラウドの請求書に必要な項目を組み立てて、APIへ送る。この流れをn8nのワークフローとして1本に描きます。

ポイントは、標準連携が持たない「状態の変化を合図にする」部分を、n8n側で明示的に作ることです。項目をそろえるのではなく、「検収が終わった」という節目を検知して次を起こす。ここが、業務の節目で動かす仕組みの入口になります。

入金消込の結果を、kintoneへ書き戻す

請求を起こしたら、次は入金の確認です。マネーフォワード クラウド側で入金が消し込まれた結果を取得し、kintoneの案件ステータスを「完了」へ進めます。

注意したいのは、入金の消し込みはリアルタイムに通知が届くとは限らないことです。そこで、一定の間隔でマネーフォワード クラウド側の消込結果を取りにいき、該当する案件があればkintoneへ書き戻す形にします。kintoneからマネーフォワード クラウドへ請求を送り、マネーフォワード クラウドからkintoneへ入金結果を戻す。この双方向の流れがそろって初めて、案件の完了までが自動でつながります。

トークンとエラー時の扱いを、1か所にまとめる

先ほど触れたトークンの更新は、請求のワークフローの中にばらばらに書くと、修正のたびにあちこち直すはめになりがちです。認証とトークンの更新は、共通のワークフローとして1か所に切り出しておくと、修正が一度で済み、トークン切れの事故も防ぎやすくなります。

あわせて、トークンの更新に失敗したときの扱いも決めておきましょう。更新に失敗したまま処理を進めると、空の値で上書きして復旧できなくなることがあります。更新に失敗したら、その先の処理は止める。この一手を入れておくだけで、事故の芽をひとつ減らせます。n8nの料金体系や社内で安全に動かす構成については、n8nのセルフホスティングの記事もあわせて参考にしてください。

【実装担当向け】品目マスタと冪等設計で事故を防ぐ

ここは実装を担当する方向けの補足です。読み飛ばしても、記事の理解には差し支えありません。

請求書を組み立てるとき、品目や単価はマネーフォワード クラウド側で自動では補完されません。kintone側に品目のマスタを持たせ、そこを参照して請求データを作ると、単価のずれを防げます。

もうひとつ、同じ検収から請求書が二重に発行されないよう、冪等な作りにしておくことが大切です。検収レコードごとに一意のキーを持たせ、すでに請求済みのものは再発行しない。この設計が、月末のやり直しをなくします。kintone側のデータの持たせ方や外部連携の考え方は、kintone×n8nでデータを連携する記事でも詳しく取り上げました。

n8nで組む手順を、画面で確認する

この設計をn8nで組むと、検収完了の受け取りから請求発行・書き戻しまでが1本のワークフローになります。ここでは設計をn8n上でどう組むかを画面構成のイメージとして示し、どの画面のどこを設定することになるのかだけを押さえます。全体の流れをつかめれば十分で、細かな設定は実装担当に任せて差し支えありません。運用してみたときの精度や使用感は、検証が進んだ段階で改めて追記します。

全体像は、左から右へノードが一列に並んだ形です。前章の「検収を合図に受け取り、二重発行を防ぎ、単価をそろえ、請求書を発行し、結果を書き戻す」という流れが、そのままノードの並びになっています。

検収完了を受け取るWebhookノードを置く

入口は、kintoneの検収完了をn8nが受け取るノードです。どのアプリの、どのイベント（ステータスが検収完了になったとき）で通知するかは、kintone側のアプリ設定で決めておきます。n8n側のこのノードで見ておくのは、その通知を待ち受けるURLが発行される箇所です。

二重発行を防ぐ冪等チェックと、品目マスタの参照

受け取ったら、まず確認するのは「すでに請求済みでないか」の分岐です。請求済みフラグが立っている検収は、ここで止めて二重発行を防ぎます。そのうえで、品目マスタから標準単価を引き、請求データの単価をそろえます。この2つが、前章の冪等設計と品目マスタ参照を、画面上で担うことになる箇所です。

マネーフォワード クラウドで請求書を発行する

そろえたデータを、マネーフォワード クラウドの請求書APIへ送るノードです。設定画面で見るのは、請求先や品目・数量・単価を組み立てているボディの箇所と、OAuth2のトークンを渡している箇所になります。ここが、標準連携では起こせなかった「検収を合図にした請求発行」を担うことになる部分です。

発行結果をkintoneの案件へ書き戻す

最後に、発行した請求書番号と「請求済み」の印を、kintoneの案件レコードへ書き戻します。これで次回以降、同じ検収からの二重発行は、前段の冪等チェックで止まる仕組みです。

入金消込は、別のワークフローで定期的に取りにいく

請求の発行とは別に、入金の消し込み結果を一定間隔で取りにいくワークフローを、もう1本用意します。役割は、マネーフォワード クラウド側で消し込まれた結果を取得し、該当する案件があればkintoneのステータスを「完了」へ進めること。

前章で触れたトークンの更新も、この請求発行と入金消込の2本から共通で呼べるように、1か所へ切り出しておきます。細かなつまずきどころは、運用検証を進めるなかで別途まとめる予定です。

検収と入金が、次の請求発行と案件完了へ自動でつながる

ここまでの設計と、それをn8nでどう組むかの見取り図がそろうと、業務の流れは大きく変わります。これまで標準連携で止まっていた「検収から請求」「入金から案件完了」の区間が、業務の節目で自動的に動く1本の流れになります。

kintoneに入力したデータが、kintone内で止まっているうちは、現場の記録のままです。検収と入金という節目が次の工程を動かすようになって初めて、見積から請求・入金までが分断されずにつながります。月末にまとめて発生していた転記と突合は、締めのイベントの中に溶けていきます。

埋めるべきギャップは、プランの確認・認証の維持・業務の節目の検知の3か所です。数が限られているとわかっていれば、着手の見通しは立てやすくなります。まずは動かせる範囲から始めればよく、全社的なシステムの入れ替えを一気に決める必要はありません。

費用の面でも、n8n自体はクラウド版・セルフホストいずれも小規模から運用でき（構成はn8nのセルフホスティングの記事を参照）、大規模なライセンス投資を前提とする仕組みではありません。

一方で、技術的に実現できることと、それを社内で回す時間を確保できることは別の問題です。手を動かす人と時間をどう用意するかは、体制の話として切り分けて考える必要があります。ここが見えないまま「自社でできる」とだけ判断すると、着手したあとで止まりかねません。

まとめ

kintoneとマネーフォワード クラウドの標準連携は、帳票の発行と項目の同期を担いますが、「検収で請求を起こす」「入金で案件を閉じる」という業務の節目で動かす仕組みは守備範囲の外にあります。

この足りない部分をn8nで補うとき、つまずきやすいのは次の3つです。

  • APIの利用可否がプランに左右されること
  • OAuth2のトークンを維持し続ける必要があること
  • 業務の節目を検知する仕組みを自前で用意しなければならないこと

逆に言えば、この3か所を先に押さえれば、検収から請求、入金から案件完了までを自社の手でつなげます。

最後に

ここで挙げた詰まりどころや対策は、自社の契約プランや運用の仕方によって変わります。「うちの契約でこのAPIは使えるのか」「どこから手をつければよいか」といった判断がつかない場合は、無理に一人で抱え込まず、専門家に相談するのが近道です。

私たちは、kintoneと外部クラウドをn8nでつなぐ業務自動化を支援しています。自社の環境で何ができて、どこを外部に任せるべきかの見極めも含めて、ものづくりAI自動化ファクトリーの無料相談で承ります。見積から請求・入金までを分断させない仕組みづくりの第一歩として、気軽にご活用ください。

関連記事