元帳までつながるCRM

証憑ごとにたどる一連の流れ

リード・トゥ・キャッシュは比喩ではありません。それぞれが総勘定元帳に対して定められた影響を持つ証憑の連なりであり、その大半は元帳にまったく影響しません。どれがどれなのかを取り違えるところから、お金が漏れていきます。

リードは関心の記録です。商談(オポチュニティ)は、担当者が付けた見込金額と確度を持つ予測上のオブジェクトです。どちらも元帳には触れず、触れるべきでもありません。見積書は申込みであり、価格・範囲・有効期限を約束しますが、何も確保しない場合もあります。受注は、その申込みを顧客が承諾したものです。双方にとっての約束であり、調達・スケジュール・生産のきっかけになることも多いものの、それでもまだ会計仕訳ではありません。収益も売掛金も生じません。

最も重要になることが多いのは納品やサービス完了という事象です。そこで商品やサービスに対する支配が移転するからです。請求書は認識の時点であり、売掛金を借方に、売上を貸方に計上し、売上に係る税の負債を計上します。入金は売掛金を現金または預金と消し込むもので、収益は認識せず、すでに存在する債権を決済するだけです。貸方票(クレジットノート)は請求書の一部または全部を取り消し、税が課されていればそれも取り消します。

これが「受注は請求ではない」という考え方の実務上の形です。支払われ、督促され、年齢表に載るのは、元帳に転記された証憑だけです。システムが受注に対して入金を充当できたり、受注金額を認識済み収益と同じ列に並べて報告したりするなら、月次決算が始まる前に流れはすでに断ち切られています。

• リードと商談:パイプラインの記録であり、元帳への影響はありません。
• 見積書:有効期限付きの価格提示であり、元帳への影響はありません。
• 受注:双方の約束であり元帳への影響はありませんが、在庫・購買・スケジュールを動かします。
• 納品書またはサービス完了承認:支配の移転を示す証拠であり、在庫と売上原価を動かすことがあります。
• 請求書:売掛金を借方、売上を貸方に計上し、売上に係る税を計上します。認識はここで行われます。
• 入金:現金または預金を借方、売掛金を貸方に計上します。決済であり、収益ではありません。
• 貸方票:請求金額と税を取り消し、基礎となる債務を元に戻すか、償却します。

分断が実際にもたらすコスト

CRMと元帳が別々のシステムでも、初日に劇的なことは何も起きません。損害は、人が黙って手作業で行い、やがて行わなくなる小さな照合作業の中に生じます。

顧客マスタが再入力され、同じ買い手が二通りの表記と二通りの支払条件で二重に存在するようになります。CRMでは値引き交渉がまとまったのに請求書は古い価格表から作成され、顧客が異議を唱えるか、誰かが修正のために貸方票を発行することになります。営業マネージャーが承認した値引きは、請求画面が決して読み取らないCRMの項目にしか存在しません。コミッションは請求・回収済みの金額ではなく受注金額に基づいて計算されるため、会社はまだ認識しておらず、ときには回収もできない収益に対してコミッションを支払うことになります。営業は四半期の数字をひとつ報告し、経理は別の数字を報告し、会議はその差を行動に移すのではなく説明することに費やされます。

いずれも原因は同じです。あるシステムで一度入力された値が、手作業またはインポートによって別のシステムに再入力されることです。取り除くべき仕組みは、不一致ではなく再入力そのものです。

顧客レコードはひとつ。まず困るのは売掛金管理

顧客の重複は、たいてい営業データの衛生問題として語られます。しかし何よりもまず売掛金の問題です。与信残高はレコードごとに計算されるため、レコードが二つあれば、誰も承認していないのに与信限度額が実質的に二倍になります。年齢表も二つに分かれ、どちらも督促するほど悪くは見えません。入金は両方の口座に計上された請求書をまとめてひとつの送金で届き、消込は手作業になります。

顧客レコードは、両方の部門が依存する項目を、一度だけ保持して双方から読み取れるようにしなければなりません。正式名称と屋号、税務登録番号、与信限度額、支払条件、適用価格表、通貨、請求先と納品先の住所、そして購買担当者と必ずしも同じではない回収担当者の連絡先です。サウジアラビアと湾岸諸国では、税務登録番号はあれば便利という程度のものではなく、適格な税務請求書の必須項目です。誤った番号や空欄のまま発行された請求書は、書式の問題ではなくコンプライアンスの問題です。

与信管理は約束をする前に

元帳は、顧客がいくら未払いで、どれだけ遅れているかをすでに知っています。年齢表は請求書が転記された瞬間に存在します。問題は、営業担当者の行動が変わるタイミング、つまり経理が条件を拒否した後ではなく、条件を提示する前に、それが見えるかどうかです。

避けるべきパターンはおなじみのものです。期日を過ぎた請求書を複数抱える顧客に支払条件の延長が提示され、それを前提に契約がまとまり、経理は条件を撤回して関係を損なうか、誰も承認していないリスクを受け入れるかの選択を迫られます。その時点では、どちらの結果も経理の判断ではありません。営業担当者に残高が示されていなかったことの帰結です。

システムがひとつであれば、仕組みは単純です。現在の残高、期間区分ごとの延滞残高、与信限度額と残りの余力が、取引先画面と見積画面に表示されます。限度額を超える受注には承認が必要で、その承認は廊下での口約束ではなく受注に対して記録されます。Skyline Nexusがこのように動くのは、CRMと売掛金元帳が同じ顧客口座を読み取るからです。営業に示されるリスクは、経理が見ている残高そのものであり、そのコピーではありません。

認識のタイミングはCRMのデータの中にある

IFRS第15号のもとでは、収益は履行義務が充足されたとき、すなわち約束した財またはサービスに対する支配が顧客に移転したときに認識されます。それは納品のような一時点の場合もあれば、保守契約や段階的な建設プロジェクトのように一定の期間にわたる場合もあります。この基準は、取引価格を契約内の別個の履行義務に配分することも求めています。

これらすべてを決める情報は、商取引の証憑の中にあります。何を約束したのか、契約が別個の成果物を束ねているのか、それぞれがいつ納品・検収されたのか、何をどの基準で値引きしたのか。CRMがその契約と納品のデータを持ち、会計システムがそれを一切見ないのであれば、期末に誰かがスプレッドシートで組み立て直し、監査証跡はそのスプレッドシートで途切れます。受注明細が履行義務を持ち、納品記録が日付を持っていれば、繰延と取崩しのスケジュールは記憶からの再構成ではなく、証憑から導き出されます。

パイプラインは予測、収益は事実

加重パイプラインは、成約するかもしれないものを確度で調整した見積りです。認識済み収益は、ある期間に稼得されたと元帳が示すものであり、監査することができます。両者は異なる問いに答えるものであり、決してひとつの数字として示すべきではありません。

つながったシステムは両者を統合するのではなく、両者の間をたどれるようにします。パイプラインの数字からその背後の商談へ、商談が変わった受注へ、受注から生まれた請求書へ、そして受け取った現金へとたどれます。この経路こそが予測を改善可能にします。受注金額が過去にどれだけ請求済み収益に転換し、どれだけの期間を要したかを測定し、予測方法について議論するのではなく調整できるのです。

共有すべきもの、そして月次決算の手ごたえ

共有とは、すべてをコピーすることではありません。一度だけ存在して両部門から読み取られる、定められたレコードの集合と、再入力なしに証憑を次の段階へ進める、定められたイベントの集合を持つことです。

月次決算での見返りは、限定的かつ具体的です。すべての請求書が同じシステム内の受注から生まれるため、年齢表に漏れがありません。営業が口にする売上高と試算表の売上高は、ひとつしかないため同じ数字です。繰延収益は誰かが管理するスケジュールではなく、納品記録によって裏づけられます。コミッションは元帳データから計算され、請求済みまたは回収済みの金額に基づいて計上されます。貸方票は取り消す対象の請求書と紐づくため、紛争は「回収が遅い気がする」という感覚ではなく数字として見えます。Skyline NexusがCRM・販売・在庫・会計をひとつのデータベースに置いているのはこのためです。請求書はそれが属する受注から作成され、入金はそれが決済する請求書に充当されます。

• 顧客マスタ:識別情報、税務登録番号、与信限度額、支払条件、価格表、通貨、住所。
• 請求書で実際に使われる価格表と税区分を持つ、商品・サービスマスタ。
• 承認済みの値引きとその承認者を、メモではなく証憑上に保存。
• 再入力なしで請求明細へ引き継がれる受注明細。
• 認識のタイミングを決める、納品日と検収日。
• CRMの画面から確認できる、リアルタイムの売掛金残高と年齢表。
• 起点となった商談にさかのぼって紐づく、請求書・入金・貸方票の参照番号。