請求漏れを解消！kintoneのステータス変更でfreeeの請求書を自動発行するワークフロー

kintoneの請求書発行を、案件のステータス変更に連動して自動化したいと考えていませんか。案件管理をkintoneで運用していると、「納品完了」にした案件の請求書を出し忘れる場面が起こります。この記事では、ダブルチェックでも請求漏れが消えない理由をひも解きます。そのうえで、kintoneのステータス変更を引き金にfreeeの請求書を自動発行する仕組みを解説します。読み終えるころには、出し忘れを「気をつける」対象から外す道筋が見えているはずです。

ダブルチェックしているのに、なぜまた請求書を出し忘れるのか

kintone 請求書の出し忘れ：月末にチェックリストで目視確認する経理担当者の様子

月末の請求業務を思い浮かべてください。kintoneの案件管理を開き、「納品完了」になった案件を上から目視で拾っていきます。1件ずつ内容を確認し、freeeで請求書を作成して発行する流れです。作業前にはチェックリストも用意しています。それでも先月、1件だけ請求書を出し忘れました。

出し忘れに気づいたのは、翌月に入金の消し込みをしていたときでした。あわてて取引先へ連絡し、事情を説明して請求書を送り直します。幸い大きな問題にはなりませんでした。経理を担当していれば、「次は大丈夫だろうか」という不安を覚える場面ではないでしょうか。

チェックリストの項目を増やしても、この不安は消えません。むしろ確認作業が増えて、月末の負担だけが重くなります。なぜ、これだけ気をつけているのに請求漏れが起きるのでしょうか。答えは、担当者の注意力とは別のところにあります。

出し忘れの原因は注意不足ではなく、「人が発行操作をする」構造にある

kintone 請求漏れの原因構造：人が発行操作をする手順からうっかりが発生する仕組みの図解

請求書の出し忘れは、担当者の注意不足が原因ではありません。「人が発行操作をする」という業務の構造そのものが原因です。ここを取り違えると、対策の方向を誤ります。

「人が発行操作をする」とは、次のような状態を指します。月末に担当者がkintoneの納品完了案件を目視で拾い、1件ずつfreeeの発行ボタンを押していく状態です。この一連の作業は、すべて人の手と判断に委ねられています。人が介在する手順が残る限り、うっかりは一定の確率で発生します。

請求漏れの主な原因も、この見方を裏づけます。よく挙がるのは、「作成したつもりで発行操作が抜けた」というヒューマンエラーです。加えて、受注や納品のデータと請求システムが別々に管理され、連携していないことによる反映漏れもあります。どちらも、人が手で情報を突き合わせる前提だからこそ起こります。

つまり、出し忘れをなくす鍵は「もっと気をつける」ことではありません。人の発行操作という手順そのものを業務から外すことです。次章では、なぜ確認を増やす方向では解けないのかを掘り下げます。

チェックを増やしても、出し忘れは「起きた後に気づく」だけで発生自体は止められない

kintone 請求漏れ対策の比較：事後のチェック強化と発生源の自動化を対比した図解

チェック体制の強化は、請求漏れの発生自体を止められません。増やせるのは「起きた後に気づく」確率だけです。発生源に手を付けない限り、漏れの芽は残り続けます。

理由は、確認作業の性質にあります。ダブルチェックや確認リストは、すでに起きた漏れに気づくための事後対策です。検知の網を細かくすれば、見つかる漏れは増えるでしょう。しかし、漏れが生まれる手順そのものは変わりません。人が発行操作をする限り、検知すべき対象は毎月新しく生まれます。

たとえば、確認担当を2人に増やしたとします。たしかに見落としは減るでしょう。ただ、月末の確認工数は2人分に膨らみます。しかも繁忙期に2人とも別業務に追われれば、確認そのものが後回しになりかねません。事後対策は、担当者の余力に依存する点で不安定です。

本命は、検知を増やすことではありません。発行を人手から切り離して自動化し、そもそも操作を発生させないことです。次章では、多くの現場が頼るfreee for kintoneが、この「自動化」をどこまで担えるのかを確認します。

freee for kintoneを入れても、請求書発行のボタンは結局あなたが押している

理由は、freee for kintoneが担う役割の範囲にあります。この連携は、kintoneのレコード情報をもとにfreeeで請求書を作成できます。ただし、作成を始めるきっかけは人の操作です。読者が対象レコードを選び、実行を指示して初めて請求書ができあがります。

freee for kintoneを導入しても、請求書発行の引き金は担当者の手に残ります。kintoneのステータス変更に連動して自動で発行する動きは、本記事執筆時点の公開仕様では実現しません。まずは、この線引きを正確に押さえましょう。

kintone 請求書の手作業負担：経理の手作業1位は帳票発行57.2%を示す横棒グラフ

手作業の請求業務が負担になっている実感は、調査データにも表れています。ラクスが2020年1月に実施した調査を見てみましょう。経理部門の手作業が多い業務の1位は「請求書などの帳票発行作業」で、57.2%を占めました（出典：経理プラス）。手で発行する手順が残れば、出し忘れは入金遅延や取引先の信頼低下につながりうる課題として残り続けます。

freee for kintoneは、請求業務を大きく助ける連携です。ただし、発行の引き金を人から外すところまでは守備範囲の外にあります。ここからは、freee for kintoneでできる範囲を具体的に確認していきましょう。

freee for kintoneでできるのはレコードを選んで請求書を作るところまで

freee for kintoneでできるのは、kintoneのレコードを選んでfreeeの請求書を作るところまでです。複数レコードをまとめて処理する一括作成も用意されています。ただし、その一括作成も対象レコードを選んで実行を指示する手動の操作です。

操作の流れは次のようになります。

  • kintoneで請求書にしたい案件のレコードを選ぶ
  • freeeへの請求書登録を実行する
  • 確認画面で内容を確かめ、作成を確定する

freee for kintone 請求書作成の操作フロー：レコード選択から確定までの3ステップ図解

つまり連携の守備範囲は、「案件データを受け渡して請求書を作れる」ところまでです。詳しい操作手順はfreee for kintoneの基本操作（freee公式ヘルプ）で確認できます。作成のきっかけを人が握る点は変わりません。

ステータス変更を引き金にした自動発行は既存連携にはない

kintoneのステータス変更を引き金にした自動発行は、本記事執筆時点の公開仕様では、既存の連携に用意されていません。freee for kintoneのステータス連携は、あくまで発行状況や入金状況をkintoneのレコードへ反映する仕組みです。請求書を自動で作り出す引き金とは、向きが逆になります。

整理すると、役割は次の2つに分かれます。

  • freee for kintone：案件データを受け渡し、請求書を作れる状態にする
  • ステータス変更を引き金にする自動発行：既存連携の外にあり、別の仕組みが必要になる

freee for kintone とステータス自動発行の比較表：発行のきっかけと出し忘れの有無の違い

freee for kintoneの連携内容は、サイボウズ公式の連携ページでも確認できます。発行の引き金を自動化するには、この線を越える別の道具が要ります。その役割を担うのが、次章で解説するn8nです。

kintoneのステータス変更でfreee請求書を自動発行する仕組みをn8nでつくる

kintoneのステータス変更を引き金にfreeeの請求書を自動発行する仕組みは、n8nでつくれます。n8nは、kintoneと外部サービスをつなぐ自動化ツールです。人の発行操作を挟まないため、「手動から自動」への差分がそのまま出し忘れの余地を消します。

n8nを使う理由は、既存連携が越えられなかった線を越えられるからです。freee for kintoneは請求書を作れますが、作るきっかけは人が握ったままでした。n8nは、kintoneのステータス変更という出来事そのものを引き金にできます。担当者が発行ボタンを押す代わりに、ステータスの更新が仕組みを起動します。

導入の規模は、大がかりなシステム刷新を前提にしません。ただし会計データを扱うため、進め方は情報システム部門や全社の方針を確認したうえで決めましょう。必要な承認の範囲は、会社によって異なります。方針を確認できたら、まず1つの案件アプリと1本のワークフローに絞って試し、動きを確かめてから対象を広げると安全です。n8nとkintoneの連携の基礎は、エンジニアに頼らず、販売管理システムとkintoneをn8nで連携してみたでも紹介しています。既存ツールが持たない動きをn8nで補う例もあります。たとえばkintoneの在庫管理データをLooker Studioで可視化し、安全在庫割れをSlackへ自動通知するワークフローです。ここからは、仕組みの中身を3つのステップで見ていきましょう。

全体像はkintoneの更新をn8nが受け取りfreeeに渡す3ステップ

仕組みの全体像は、3つのステップで整理できます。

  • kintoneで案件のステータスが「納品完了」に変わる
  • n8nがその更新を受け取り、案件情報を整える
  • n8nがfreeeへ請求書の発行を指示する

kintone ステータス変更で請求書を自動発行する全体像：kintone・n8n・freeeをつなぐ3ステップのフロー図

この流れの中で、n8nは受け取った案件情報の整合性を確認する役割も担います。取引先名や金額がそろっているかを渡す前に点検すれば、誤った内容での発行を防げるはずです。データが十分に整っていない現場では、この点検の手順を挟む価値が特に大きくなります。3ステップの骨格を押さえたうえで、各ステップを具体的に見ていきましょう。

kintoneの「納品完了」への変更をn8nのWebhookで受け取る

最初のステップは、kintoneの「納品完了」への変更をn8nが受け取る設定です。kintone側で、ステータスが納品完了に変わったときに通知を送るように構成します。この通知をn8nのWebhookが受け取り、ワークフローが動き出します。

kintone Webhook のトリガー設定：納品完了への変更だけをn8nに通知する絞り込みの図解

ポイントは、引き金を「納品完了への変更」に絞ることです。すべての更新に反応させると、余計な発行が増えます。特定のステータスに変わった瞬間だけを引き金にすれば、狙った案件だけが処理されます。

受け取った案件情報からfreeeの請求書を発行する

次のステップで、n8nが受け取った案件情報からfreeeの請求書を発行します。案件のレコードには、取引先や金額といった請求に必要な情報が入っています。n8nはこの情報をfreeeのAPIへ渡し、請求書の発行を指示します。

この仕組みは、案件データが正しく入力されていることが前提です。入力データがそろっていない現場では、自動化の前に「請求に必要な情報を確実に残す運用」から整える必要があります。土台となるデータがそろって初めて、自動発行は安定して動きます。

同じ案件で二重発行しないよう発行済みフラグで止める

自動化で気をつけたい落とし穴が、同じ案件の二重発行です。ステータスが何度も更新されると、そのたびに発行が走るおそれがあります。これを防ぐ仕組みを、あらかじめ組み込んでおきましょう。

kintone 請求書の二重発行防止：発行済みフラグで処理を分岐させるフローチャート

有効なのは、発行済みフラグを使う方法です。請求書を発行した案件には「発行済み」の印を付けます。n8nは処理の前にこのフラグを確認し、すでに発行済みなら止まる設計にします。フラグとステータスの条件を組み合わせれば、1案件1発行を保てます。

請求漏れは「気をつける」対象から、そもそも起きない業務に変わる

kintone 請求業務のBefore After：人の発行操作を外して出し忘れが起きない業務に変わる図解

人の発行操作を業務から外せば、請求漏れは「気をつける」対象ではなくなります。ステータス変更が仕組みを動かすため、出し忘れの余地そのものが消えます。担当者は、確認に費やしていた時間を本来の業務へ戻せるでしょう。

ここで大切なのは、kintoneを「請求データの置き場」で終わらせない発想です。案件データは、蓄積するだけでは価値が限られます。データをfreeeまで人手を介さず動かしきってこそ、「納品したのに請求していない」をゼロにできます。kintoneに眠るデータをつないで動かす考え方は、kintoneユーザーのための生成AI実践大全でも軸に据えています。

前章でも触れたとおり、連携の導入は担当者ひとりの判断だけで進むとは限りません。会計データを扱うため、情報システム部門や全社での合意が出発点になります。まずは自社で「人が発行操作をしている作業」を棚卸しし、どこを自動化できるかを整理するところから始めましょう。既存連携でできることと、n8nで越えられる線を切り分けて考えると、進めやすくなります。

まとめ

請求書の出し忘れは、担当者の注意不足ではなく「人が発行操作をする」構造から生まれます。ダブルチェックを増やしても、それは起きた後に気づく確率を上げるだけでした。freee for kintoneは請求書を作れますが、発行の引き金は人の手に残ります。

この構造を変える鍵が、kintoneのステータス変更を引き金にしたn8nの自動発行です。「納品完了」への更新がそのままfreeeの請求書発行につながれば、出し忘れの余地は消えます。請求漏れは「気をつける」課題から、そもそも起きない業務へと変わります。

まずは、自社で人が発行操作をしている作業を洗い出してみてください。どこを自動化できるかを一緒に整理したい場合は、お問い合わせからお気軽にご相談ください。

関連記事