SaaSの経理の設計の諸々を疾く書き連ねる

Housmartの鈴木です。

弊社の不動産仲介会社向けSaaSであるPropoCloudは2019年3月にローンチし、2年と3ヶ月、すくすくと成長を続けています。

今回は、PropoCloudの経理の設計について赤裸々にお話をしていきたいと思います。

私は現在、Housmart管理全般を管掌しており、当然経理も見ています。キャリア的には本職で、経理歴10年ぐらい。

そこそこ長いキャリアなのですが、新しいビジネスの経理フローを設計したのは初めてで、とても刺激的な経験だったので、記録に残していきたいと思います。

経理の設計いつしたのん

最初のローンチ時点はSpreadsheetで管理をしていました。
請求書の発行だけであれば、Spreadsheetだけでも100店舗ぐらいまでは1人で回せる自信はあったのですが、SaaSのビジネスが想定以上に複雑で、システムの導入なしに適切な経営管理の実現は不可能と感じ、早め早めに設計をはじめました。

具体的には5店舗にご導入いただき、ある程度運用が明確になったタイミング。

ビジネスには色々と紆余曲折あるもので、あまりにも構築が早すぎると、運用の変化に耐えきれず、いきなり陳腐化するので要注意。

偉そうに書いてる現行の仕組みも、ローンチ2年で順調に設計的負債がいい感じに溜まってます。

経理の設計なにしたのん

HousmartはVertical SaaS事業を中心とした成長を目指しており、今後数年で従業員数百人の規模になることは想定していないので、少人数で事業を回す必要があり、特に管理部門に関しては5、6人で完結させたい。

それを実現するにあたっては、とにかく自動化が命。

- データ生成の自動化
- データ集計の自動化
- データチェックの自動化
- データ送付の自動化

この4点に絞って自動化を進めました。

データ生成の自動化

データ生成の自動化。これは、営業やカスタマーサクセスがデータを入力すると、請求データや管理会計データが自動で生成される仕組みです。

経理側では一切データの加工はせずに、営業・カスタマーサクセス側で入力したデータから全てのデータが生成されるようにしました。

ところで、サブスクモデルの請求って結構大変じゃないですか？設計始めて頭抱えました。

他の立ち上げ早々のSaaSの方ってどう管理してるんでしょう。

色々なシステムを検討したんですが、高かった。Salesforceを導入していたので、サブスクパッケージの提案も貰ったんですが、やはり高い。

ただ、Salesforceさんからサブスクパッケージの提案を受ける中で、構築のインスピレーションを得て、Salesforceの自動化機能であるプロセスビルダーを活用して、自前で構築することにチャレンジしました。

サブスクビジネスの特徴は、やはり1つの契約に対して、複数の請求がたつこと。

それを受けて作ったのが、契約オブジェクトに入力した開始月、終了月、月額利用料を入れると、それらの情報を元に請求オブジェクトが自動で生成される仕組み。

すごくシンプルだと思いません？ここまで作るのは簡単でした。しかしその後が地獄でした。

日割りへの対応
そもそも初月と最終月だけ請求額が違うという事象。日割り発生時の初月・最終の請求額の入力スペースを用意。お客様から回収する利用申込書にも同様のフォームを用意することで、入力ミス等を減らす。

そして契約期間と請求期間が変わる、契約期間は6ヶ月なのに7ヶ月分の請求が必要。この辺りはロジックで判定を作り込んで強引に解消しました。

前金で一括払
資金繰的には嬉しいんですが、前金一括で頂戴した時の処理も結構対応大変でした。請求オブジェクトに、請求金額と売上金額の項目を設けることで解決。請求金額を元に請求書は発行し、売上金額を元に会計データを生成する形にしました。

契約期間中の金額変更
これが一番しんどかったです。例えば3月50,000円、4月70,000円、5月80,000円のようにアップセルが約束された形で契約が締結される場合。
自動生成で対応するにはお手上げすぎたので、請求オブジェクトを手動で修正することで、対応。

契約が更新されると手動で修正した請求データも全て元に戻ってしまうので、自動生成を止めるチェックボックスを設けて対応。

ただ、請求データを手動更新できる仕組みを作ったのは失敗でした。入力側に十分に運用が周知できてなかったこともあり、よく誤ったデータが生成されました。

鬼のようにチェックをつけたので事故には至っていないのですが、現場サイドにSalesforce怖いと言わせた、私の中での一番の設計負債です。

これらの壁を乗り越え、無事に運用に載せることができました。

データ集計の自動化

データの生成がうまくいったので、次はデータ集計の自動化です。

集計の目的は大きく二つ。「請求書用のデータ」と「管理会計用のデータ」

請求書用のデータ
データ送付の自動化項目でも書くのですが、請求書の発行はfreeeを利用しています。Salesforceとfreeeを直接繋ぎこむのもありだったのですが、運用がころころ変わったり新しい対応が発生した際の回収コストを鑑みて、当面はSpreadsheetを噛ませることとしました。

前項で生成した請求データをSpreadsheetに吐き出して、集計し、freeeにインポートできるCSV形式に加工。

freeeの請求書作成用のCSV形式は結構独特なので、吐き出したデータを自動的にその形式に流し込むためにはひと工夫が必要です。

さらにややこしいことに、1つのお客様に対して、複数の契約が締結されていたり、複数の店舗のご利用分を本社で一括請求する等、色々なパターンに対応する必要があり、とても大変でした。

CSVを自動で生成するため、関数を駆使して相当工夫しました。もはやパズルを解いてる感覚です。

管理会計用のデータ
毎月のMRRや、その増減内訳、他にもSaaSのメトリクスが自動でSpreadsheetに集計され、社内に周知されるようにしました。

SaaSのメトリクスなんかは非常に簡単に出すことができるのですが、MRRの増減内訳を出すのがかなりしんどい。

増加、減少の内訳でいうと、当月と前月を比較した、請求額の差分をそれぞれ以下に分類します。

増加：新規受注、別店舗拡大受注、アップセル、日割による増加
減少：解約、ダウンセル、日割による減少

これがどういうことかというと、例えば、月10万円で受注して、初月利用料は日割りで2万円分の請求をした時、社内的には10万円の新規受注で考えたいですよね。

ところがMRRは前月から2万円しか増えてないので、新規受注10万円としてしまうと、帳尻が合わなくなってしまう。そのために、この取引に対して、新規受注 10万円と日割△8万円として増減内訳を作ることで、綺麗になるのです。

しかしこの増減、かなり様々なパターンが発生するので、これもシステム側でフラグをつけてそれを集計するのではなく、Spreadsheetで強引に振り分けることにしました。

これもSpreadsheetを魔改造して実現してるので、もはや限界ぎりぎりまで負債が溜まってます。

例えば解約か、ダウンセルかを判定するために、発生しうるパターンごとに集計列を作成したのが下の画像。

解約とダウンセルの判定でもそれぞれ6~8パターンを定義してます。

この集計、相当しんどくはあるのですが、この増減内訳をきちんと出すことで、事業の状況を把握しやすくなるだけでなく、前月比のMRRの増減の矛盾等が洗い出されるため、データの正確性の担保に重要な役割を果たしています。

毎月の売上からLTV/CACまで完全自動で生成される仕組みを作ったのは結構自慢です。

データチェックの自動化

少人数で回す体制にするためには、データのチェックの自動化は欠かせません。現在、累計200店舗突破でリリースを出していますが、200店舗のデータを１件１件目視で隅から隅までチェックするのはあまり現実的ではないので、ここも自動化が必要です。

チェックは大きく3種類を入れています。

データ入力のバリデーション
Salesforce側でバリデーションをがっつり入れることで、そもそも明らかに矛盾したデータが作成されるのを防ぎます。

データの矛盾チェック
前項であげた、前月からのMRRの増減が、事前に定義した増減の種類に該当するかのチェックを入れています。事前に定義した増減に該当しない場合には、データが間違っている可能性があるので、営業、カスタマーサクセス側に修正依頼（今は各チームで自主的に気づいて修正してもらってます）をかける。

たまに新規で定義を追加したりもしています。

これによりデータの正確性が一定程度担保されています。

前月との比較チェック
請求データについては、さらに厳密にチェックするために、お客様ごとに前月のデータと比較して、増加、減少しているものについては、利用申込書等を確認して、正確性を確認しつつ、営業、カスタマーサクセスチームにもサマリを展開して、内容を確認してもらって完成。

データ送付の自動化

流石に１件１件を送付するのは大変なのでシステム導入ありきでした。
色々なシステムがあったのですが、要件としては、請求書の一括送付と、債券の消し込みができれば十分だったので、会計で利用してるfreeeをそのまま利用することにしました。

インポート用のCSVの自動生成も、実現できたので、すんなりと実装。

請求書画面が異様に重いことを除けば満足してますが、これ以上重くなったら別のシステムに乗り換えようかなとも思ってます。

最後に

疾く書き連ねるということで、一気に書き切ったので、誤字脱字矛盾等ご容赦くださいませ。

経理の設計から実装までもまだまだ小規模で全て一人で行ったので、トライアンドエラーを短期間で繰り返し、大体1ヶ月程度で運用開始。そこからちょこちょこ改修をして今の形に落ち着きました。

詳しく聞きたい方、私の仕組みの方が強いぞ等、ご意見をお待ちしております。

PropoCloudのビジネス職も絶賛募集中ですので、ご興味がある方は是非エントリーくださいませ。今なら入社特典として、私がオーダーメイドでデータを集計いたします。