契約金の請求書を出し忘れていたことに、2か月後に気づく。請求書は作ったのに送っていなかった。振込先の口座番号が抜けたまま送ってしまった。請求のミスは金額が大きいほど言い出しにくく、発覚が遅れるほど客との関係に響く。住宅会社の請求業務は、事務担当1〜2人の記憶と注意力に支えられていることが多い。本記事では、請求書の作成漏れ・送付漏れ・記載漏れを、仕組みで見張る考え方を解説する。
請求漏れと一口に言っても、中身は3種類に分かれる。対策を考えるときは、まずこの3つを分けて考えたい。
1つ目は作り忘れである。そもそも請求書が存在しない状態だ。住宅会社の請求は種類が多い。注文住宅なら契約金・着工金・中間金・最終金と、工事の進み具合に合わせて分割で請求する。リフォームは工事のたびに請求する。OB客向けの有料点検や保証延長のように、毎月や毎年決まって請求するものもある。種類が多いほど、どこかで1件抜ける。
作り忘れの多くは、営業から事務への連絡漏れから起きる。上棟が終わったのに、営業が事務に伝え忘れる。事務は連絡がなければ請求書を作らない。誰も悪気はないまま、請求が抜け落ちる。
2つ目は送り忘れだ。請求書は作ったが、メールでも郵送でも客に届いていない状態である。クラウドの請求ソフトでは、作成と送付が別の操作になっていることが多い。下書きを作って安心してしまい、送付ボタンを押していない。月末の慌ただしさの中で、よく起きるミスである。
3つ目は書き忘れ。請求書は作って送ったが、必要な情報が抜けている状態だ。代表的なのが振込先の口座番号である。客は振り込みたくても振り込めない。問い合わせが来て初めて気づき、送り直す手間と気まずさが残る。
この3つは、どれも人の注意力だけでは防ぎきれない。月末に請求が集中すれば、どんなに丁寧な担当者でも見落とす。しかも、担当者が休んだり辞めたりすれば、記憶に頼った管理はそこで止まる。だからこそ、機械に見張らせる。
請求業務を自動化しようとすると、いきなり請求書の作成から手を付けたくなる。しかし、先に整えるべきは入口である。どこから請求の情報が入ってくるのかを、1つに決める。
今回紹介する仕組みでは、入口を申込フォームに一本化している。新しい契約が決まると、会社名、利用開始日、申込書の保存先がフォーム経由でスプレッドシートに記録される。仕組みはこのシートを定期的に確認し、まだ請求書を発行していない行を見つけると、請求ソフト（MFクラウド請求書）に請求書を自動で作らせる。（Zapierで反響管理を自動化する方法についてはこちら）
発行した行には、処理済みの印を付ける。次に確認するときは、印の付いた行を飛ばす。この印があるから、同じ契約に請求書を二重に発行することがない。
住宅会社に置き換えれば、入口は請負契約を結んだ時点の登録になる。契約を結んだら、営業が決まったフォームに支払いの予定を入力する。口頭やメッセージアプリでの連絡に頼らない。入口が1つに決まっていれば、作り忘れの多くは連絡漏れの段階で防げる。
導入時に忘れてはいけないのが、既存の契約の扱いである。仕組みを入れた時点で、すでに請求している取引先がある。そうした取引先にも、最初に一度だけ「処理済み」の印を付けておく。これを怠ると、仕組みが既存の取引先をすべて新規と判断し、請求書を一斉に作ってしまう。自動化で最も避けたい事故の1つだ。
請求書の宛先は、顧客一覧にある担当者の情報から自動で入れる。担当者の情報がなければ、宛先は「本社」とする。支払期限と振込先も、請求書を作るときに毎回明示的に指定している。ソフト側の初期設定に任せると、知らないうちに設定が変わっていたときに気づけないからだ。
請求ソフトを使っている会社では、請求の仕組みが2つ並んでいることが多い。
1つは、請求ソフトに標準で付いている「毎月自動作成」の機能だ。金額と宛先をひな形として登録しておけば、毎月決まった日に請求書が自動で作られる。もう1つは、今回のように外部から請求書を作る仕組みである。新しい契約は外部の仕組みで発行し、古くからの取引先はソフトの自動作成に任せる、という形になりやすい。
2つ並ぶと、隙間が生まれる。ある取引先がどちらの仕組みで請求されているのかが、だんだん分からなくなるのだ。ソフトの自動作成に登録したつもりで登録していない。外部の仕組みで発行しているつもりで、対象から外れている。どちらの仕組みも自分の担当分は正しく動いているのに、その間に落ちた取引先には誰も気づかない。
そこで、請求書を作る機能とは別に、2つの仕組みをまたいで見張る機能を持たせている。顧客一覧で有料の契約中になっている取引先それぞれについて、ソフトの自動作成でカバーされているか、実際に請求書の下書きがあるかを確認する。どちらもない取引先だけを「作成漏れ」として知らせる。
ここに、1つ厄介な制約がある。ソフトの「毎月自動作成」のひな形は、外部の仕組みから中身を見ることができない。そのため、ひな形で請求している取引先は、仕組みの側に一覧として持たせている。新しい取引先をソフトのひな形に登録したら、この一覧にも追記しなければならない。追記を忘れると、本当は請求されている取引先を「作成漏れ」と誤って知らせてしまう。
誤報が続くと、担当者は通知を信用しなくなる。2つの仕組みを並べる以上、どちらか一方に取引先を足したら、もう一方の一覧も更新する。この運用ルールだけは、人が守るしかない。
見張る内容は、冒頭の3種類の漏れにそのまま対応している。
振込先のチェックは、月末にまとめて行うだけでなく、請求書を作った直後にも即座に行っている。作った瞬間に抜けが分かれば、送る前に直せる。送ってから気づくのとでは、手間も気まずさもまったく違う。
送付の進み具合は、スプレッドシートの1つのタブで一覧にしている。取引先ごとに、会社名、請求金額、送付済みかどうかの3列だけを並べる。項目を絞っているのは、月末の忙しい時期に一目で状況をつかむためだ。送付済みの取引先には印が付き、印のない行がそのまま「まだ送っていない取引先」の一覧になる。
月末には、翌月分の請求を確認するためのレポートも作る。取引先を「初回の請求」「ソフトの自動作成」「手作業が必要」「対象外」などに分け、それぞれの件数と金額を並べる。初回の請求は、初回だけ費用が上乗せされるなど、継続の請求と金額の形が違うことが多い。分けて並べることで、金額の妥当性を確認しやすくなる。
チェックの中身と同じくらい大事なのが、タイミングである。同じチェックでも、遅すぎれば手遅れになり、早すぎれば対象がそろっていない。今回の仕組みでは、月末から月初にかけて、次の4つのタイミングで通知を送る。
まず月末の前日に、送付漏れと振込先漏れのチェックをまとめて行う。前日なら、見つかった漏れをその日のうちに直し、月末までに送れる。
次に月末の最終日に、「明日、ソフトの毎月自動作成が走る」ことを予告する。あわせて、外部の仕組みで発行済みの新規分を一覧にする。翌日に何が起きるかを前日に知っておけば、自動作成された請求書を確認する準備ができる。
そして毎月1日に、ソフトの自動作成が終わったあとの確定金額を通知する。初回の請求と継続の請求に分け、番号を付けて並べる。前日の予告と照らし合わせれば、作られるはずの請求書が作られたかを確認できる。
最後に第一営業日に、もう一度送付漏れのチェックを行う。1日が土日や祝日に当たると、送付の作業は休み明けにずれる。そのため、祝日のカレンダーを見て、実際に業務が始まる日に確認するようにしている。
これらの通知は、事務担当が普段使っているチャットに届くようにしておく。メールで届く通知は、ほかのメールに埋もれやすい。
すべての請求を自動化しようとすると、かえって事故が増える。今回の仕組みでは、自動化しない範囲を最初に決めている。
1つは、特殊な請求の取引先である。たとえば、コンサルティングの費用と定額の料金をまとめて1枚で請求している取引先は、自動化の対象から外している。住宅会社でいえば、工事の追加変更の精算を最終金に合算する場合や、値引きの条件が個別に付いている場合がこれに当たる。こうした請求を仕組みに乗せると、例外処理だらけになり、かえって誤りが増える。
取引先ごとに決まった請求ルールがある場合もある。翌月分を前月に請求する、件名に「〇月分」と入れる、取引先が指定するシステム経由で送るといったルールだ。これらは「請求時の注意事項」として1枚のシートにまとめ、人が請求するときに参照する。仕組みはこのシートを使わない。参照専用と割り切ることで、ルールが変わっても仕組みを直す必要がなくなる。
もう1つ、意図的に決めた方針がある。金額の推定値を使わないことだ。ソフトの毎月自動作成で作られる請求書の金額は、実際に請求書ができるまで外部から知ることができない。前月と同じ金額だろうと推定して表示することもできるが、それはしない。推定値の通知は、確定値と見分けがつかないまま一人歩きする。金額が変わっていたとき、推定値を信じた人が確認を省いてしまう。だから金額は、確定してから通知する。
自動化の価値は、人の確認を減らすことではない。人が確認すべき場所を絞り込むことにある。
最後に、仕組みを作る過程で実際に手間取ったポイントを挙げておく。自社で導入する場合も、同じところでつまずく可能性が高い。
一番手間がかかるのは、会社名の表記ゆれである。同じ取引先が、顧客一覧では「株式会社〇〇」、請求ソフトでは「(株)〇〇」、フォームでは全角の英字で入力されている。人が見れば同じ会社だと分かるが、機械には別の会社に見える。そこで、会社名を比べる前に、全角と半角の違いや「株式会社」の表記の違いをそろえる処理を挟んでいる。それでもそろわない名前は、別名として対応表に登録する。この対応表の整備に、最初は一番時間がかかる。
次に、日付の自動変換である。スプレッドシートは、入力された日付の文字列を勝手に日付の形式に変えることがある。利用開始日が、あるときは文字列、あるときは日付として入っていると、「いつから請求するか」の計算がずれる。どちらの形式で入っていても同じように読み取れるようにしておく必要がある。
解約の反映も見落としやすい。顧客一覧で解約になった取引先が、売掛金の管理表では契約中のまま残っていると、作成漏れのチェックが誤って鳴る。顧客一覧の解約の情報を、売掛金の管理表に自動で反映させる処理を用意した。解約の情報を入力する場所は1か所に決め、ほかはそこから写す。
そして、何かおかしいと思ったときに調べる手段も用意しておきたい。今回の仕組みには、請求書の番号や取引先名を指定すると、請求ソフトに登録されている中身をすべて確認できる調査用の機能がある。普段は使わないが、通知の内容に疑問があったときに原因を追える。請求ソフトからの応答が空だった場合でも、処理全体が止まらない作りにしてある。（来場アンケート集計を自動化する方法についてはこちら）
請求漏れは、作り忘れ・送り忘れ・書き忘れの3種類で起きる。どれも、担当者が気をつけていれば防げるように見えるが、月末に請求が集中すれば、どこかで必ず抜ける。入口を1つに決め、2つの請求の仕組みをまたいで見張り、3種類の漏れをそれぞれ機械にチェックさせる。チェックは月末前日・月末・1日・第一営業日と、手を打てるタイミングで鳴らす。特殊な請求は自動化から外し、金額は確定してから知らせる。
事務担当が休んでも、交代しても、同じように漏れに気づける状態をつくる。それが、少人数で回る住宅会社の請求業務を守る現実的な方法である。客との信頼を、請求書の1枚で損なわないための備え。
