見積書と同じ感覚で請求書を作ると、なぜ後から少し苦しくなるのか
請求業務のご相談を受けていると、案件も顧客もExcelで管理している会社にたくさん出会います。
Excelは、誰でもすぐに触れて、導入コストもかからないとてもすぐれた道具です。事業の初期段階を支える相棒として、これ以上のものはなかなかありません。創業初期の限られたリソースの中では、Excelだけで十分に回せるケースがほとんどです。
ただ、事業が続いて人が増え、情報が増えていくと、Excelが支えている業務のほうが想像を超えて育っていきます。誰かが更新したファイルをメールで送り、別の人がまた手を入れ、デスクトップには似たような名前のファイルが並んでいく。これはExcelが悪いのではなく、業務がそれだけたくましく成長した証拠だと言えます。
こうしたタイミングこそが、kintoneのような仕組みに情報をまとめていく絶好の機会です。案件管理や顧客管理を一箇所に集約し、全員が「同じ事実」をリアルタイムで見られるようにする。ここが、業務改善の確かな土台になります。
データがまとまると、次に「帳票も作りたい」となる
データが集約され、検索や共有がスムーズになると、現場から自然に次の声が上がります。
「このデータを使って、見積書も作れないかな」
これは非常に理想的な流れです。せっかく情報がkintoneにあるのですから、それを活かして見積書まで出力できれば、転記の手間や事務作業はぐっとラクになります。多くの会社が、ここでシステム化の確かな手応えを感じます。そして、その成功体験のまま、次にこう考えます。「見積書がこんなに簡単に作れるなら、請求書も同じように作ろう」ごく自然な発想であり、多くの企業が同じルートを検討します。しかし、この先に「運用の段差」があることに、後から気づかされるケースは少なくありません。
見積書と請求書は、似ているようで「別の業務」
見た目も似ているし、扱うデータも重なっている。だから「請求書は見積書の延長線上にある」と捉えるのは当然のことです。ただ、実際に運用が始まると、この二つは根本的に性格が違うことに気づきます。それは、業務の流れを「どんなアプリで管理するか」をブレイクダウンしていくと見えてきます。
1.見積管理（プロセスの往復）
見積書は、一度で金額が決まるとは限りません。金額を調整して出し直したり、条件を変えて再提示したり。何度もキャッチボールが行われます。そのため、見積アプリは「複数回発行すること（履歴の管理）」を前提とした設計になります。
2. 受注・契約管理（確定の節目）
度重なるやり取りの末に、どの見積内容で確定したのかが決まります。ここで「商談中のデータ」と「確定したデータ」が明確に分かれます。この節目をきっちり挟むからこそ、次の請求データがきれいになります。
3. 請求管理（一回きりの確定データ）
受注によって確定した情報だけが、このフェーズに入ってきます。見積のように何度も出し直すものではなく、確定後にきっちり一度だけ発行する。請求書を出すのは、この段階です。
ここまでで、ひとつの事実に気づきます。見積から請求まで「ひとつのアプリ」で足りると思っていたのに、業務の節目ごとにアプリが分かれていく。この「アプリが分かれていく」こと自体が、業務の性質が変わっているサインなのです。そして、いちばん大きく性質が変わるのは、この先にあります。
請求書を出した瞬間、「入金管理」という別の仕事が始まる
請求書を出すというのは、「入金を待つ（債権を管理する）」ということです。見積書を作るところまでは、社内の情報を整理して形にする「帳票作成」の話でした。しかし、請求書を出した瞬間に、業務の中心は「お金を確実に回収する」ほうへ移ります。ここからは、書類を作る話ではなく、入金をどう管理するかという話になります。具体的に、現場では何が起きるでしょうか。請求管理アプリには、発行した請求データが並んでいます。そこに、銀行の入金明細データを持ってくる。そして、請求データと入金データを、金額ベースで突き合わせる。「この振り込みは、あの時の請求のものだな」と、一件ずつ確かめていく。これがいわゆる「入金消込（けしこみ）」です。文字にすると一行ですが、現場で実際にやると、なかなか骨の折れる仕事です。
タイミングのズレ
いつ入金されるかは、相手の都合に左右されます。「月末払い」と書かれていても、それは期限であって、必ずしもその日に振り込まれるとは限りません。早めに払ってくださる方もいれば、少し遅れる場合もある。常に「いつ入るか分からないもの」を追い続けることになります。
名義や金額の不一致
入金があっても、それが何のお金かすぐには判別できないことがあります。同じ取引先に複数回請求していると、合算されて振り込まれ、「この金額は、どの請求の合計だろう？」と迷うことになります。また、振込手数料が差し引かれていて、請求額とぴったり合わないケースも日常茶飯事です。
件数の多さと督促の心理的負担
少額の請求がたくさんあると、突き合わせる対象が一気に増え、一件ずつ取引を追う手間が膨れ上がります。さらに、入金が遅れている相手への確認連絡は、非常に気を遣う仕事です。相手との関係性を損なわないよう配慮しながら、「あの件ですが……」と切り出すのは、担当者にとって心理的な重荷になります。その際、「どの見積の話だったか」がパッと手元で分からないと、連絡をすることすら難しくなります。
つまり、入金の管理は単なる事務作業ではなく、「債権の管理」であり、帳票を作る仕事とは全く別物なのです。
「うちはイレギュラーなんて滅多にない」という会社こそ
「うちの取引先は丁寧な会社ばかりだから、そんなトラブルは滅多に起きないよ」と話される企業もあります。それは本当に素晴らしい関係性を築かれている証拠です。ただ、「滅多に起きないからこそ」考えどころでもあります。年に数回しか出番のない消込のために、kintoneの中にしっかりした仕組みを作り、それを維持していく。これが合っている会社もあります。一方で、出番の少ない仕組みを抱え続けることが、別の負担になる会社もあります。どちらがいいかは、その会社の規模や体制によって変わります。
作り込む前に「選択肢」を並べてみる
この入金まわりをどう管理するか、いくつかの選択肢が生まれます。
選択肢A：自社でアプリを作り込む
請求管理アプリや入金消込アプリを、自社の運用ルールに合わせてkintone上に構築する道です。独自の回収ルールや細かいこだわりがはっきりしている会社にとっては、手元で柔軟に調整できる確実な選択肢です。
選択肢B：外部の決済・回収サービスに任せる
請求書の発行や入金回収、消込にまつわる作業そのものを、外部の専門サービス（決済代行や請求代行）に委託する道です。手を動かす実務を外に出すことで、自社は本業のコア業務に集中できます。ここで重要なのは、「作業を外に出しても、経営に必要な情報まで手放すわけではない」という点です。月ごとの売上推移、取引先ごとの状況、現在の未回収残高など、「経営判断に使いたい情報」はkintone側にしっかりと残せます。手放すのはあくまで「消込の作業」であり、「見たい数字」は手元に残る。ここは切り離して考えることができます。
どちらが正解、ということではありません。取引の規模や、社内に割けるリソースに合わせて、どちらも対等な選択肢として選ぶことができます。
システムを決める前に、「取引の流れ」をデザインする
目の前の困りごとから順番にアプリを作っていくやり方は、その都度ラクになるため、非常に実用的です。そのうえで、もし開発をスタートする前に少しだけ立ち止まって、「見積 → 受注 → 請求 → 入金」という一連の流れ全体を見渡しておくことができると、後からの大幅な手戻りを減らせます。「請求書を出すところまでは、使い慣れたkintoneでスムーズにやって、その先の入金確認は外部のサービスと連携させて任せる」といった、自社にとってちょうどいい距離感の組み合わせも見えてくるはずです。
システムをどう作るかを考える前に、まず「自分たちの仕事の流れをどうデザインするか」。この順番を意識するだけで、導入後の運用の落ち着き方が大きく変わります。うまく進んでいるプロジェクトほど、最初からシステム（機能）の話はしません。
- 誰が何をしていて
- 情報はどこで生まれ
- どこで滞っているのか
その全体像が見えてきて初めて、道具（システム）をどう活かすかの具体的な相談が始まります。見積から請求、そしてその先の入金にいたるまで、自社の流れを一度じっくり書き出してみませんか。システムの話はいったん脇に置いて、いまの仕事の流れを一緒に整理するところから。遠回りに見えて、実はそれが一番たしかで、一番の近道と考えています。
