はじめに：社名変更と本日のテーマ
この番組は、中小小売企業の取り締まり役経験のある2人が、 そのリアルについてゆるくお話しします。
人事に軸足を置いたジェネラリスト、私戸部有利が、 インドのM&A経験がある連続企業家、樋口幸太郎さんに話を聞いていきます。
既に小売企業を経営している方、これから小売ビジネスで 企業を考えられている方に役立つ情報を楽しく語っていきます。
リテールトーク103回目です。よろしくお願いします。
お願いします。
今日は、EC売上形状における落とし穴、 お客様の支払総額 == 売上ではない、というお話です。
樋口さん、社名変更されたんですね。
社名変更しました。
ストアレコードと侵入するぞっていう覚悟を、 社名に込めようというような形で、
やっぱり社名とサービス名が一致してた方が、 いろいろコストが低いというか、認知もしてもらえてサービスも広まるんで、
そうしようというので社名変更しました。
結構手つぶきが、僕じゃなくて一緒にやってる エビサーさんが面倒くさそうでしたっていう感じですね。
そうですよね。
私の観測している範囲で言うと、多分ホットキャストの概要欄だったりとか、 ノートの記載とかも全部変えなきゃですね。
確かに。そこを変えないとですね。今回、文から変えていきます。
私のプロフィールは、もしかしたら全職が入っている可能性が高いです。
ください。一緒に変えます。
この後、ジャスラックしておきます。
この人の方針、前にいただければ変えておきます。
本題行きたいと思います。
EC売上計上の落とし穴：税込み管理
テーマは、ECUの売上形状における落とし穴。 お客様の支払い総額イコール売上ではないという話ですね。
これあったなっていうのを、このテーマを見て思い出していて、
入金金額が思っていたのとちょっと違って、よなよな答え合わせをしたりしながら、 勉強していったのを思い出しました。
僕もそうですね。最初、全職で初めてやったとき、どれを売上にすればいいのか分からなくて、
注文CSVとかと格闘しながら計算式やって、これ売上だなみたいなのを特定したので、実は結構得意です。
ストアレコードの導入を進めていると、僕らがこれまで売上形状してたのと全然違う。
これまで管理してた数字と全然違うの、なんでなのかっていうのを説明を求められることが多くて、
結構この1、2月は導入が多かったので、その説明を何度もしていたので、ちょっと改めて整理して話したいなと思いました。
基本的なストアレコードの形状は、財務会計上の形状基準に合わせて発送売上で、しかも税抜きで形状して、
正しく基本的なマネ法とかフリーみたいな会計ソフトで見ていただくような売上に近くなるような形で設計して形状しているので、丁寧に説明したいと思います。
もちろん弊社のストアレコードの方の取り込み方が間違っているケースもなくはない。
かなり見たので少ないかなと思うんですけど、間違えてたらすぐ修正する体制になっているので、
ちょっとあればクライアントさんは言ってくださいっていうのを言っています。
ストアレコードを導入するとずれるっていうのは、そもそもの管理会計が財務会計上の基準とは違う形で認知されてたみたいな感じなんですかね。
具体的にはどういうのがあるんですか。
基本的にはそんなに売上財務会計管理会計でこうこうっていうふうにやってるっていうよりは、
今まで見てた管理画面の数字であったり、取ってきた数字と全然違うっていうケースが多いかなと思っていて、
これまでやっぱり40社超える企業の導入ストアレコードを進めていて、
外れてたケースどういうものがあったかっていうのをパターンでご紹介したいと思います。
1個目がそもそも税込みで売上管理してましたっていうケースが結構あって、
どういうケースかっていうと、ショッピファイとか楽天のRMSの管理画面をあの数字をベースに管理していると気づかないまま税込み管理になっていて、
楽天のRMSの売上の横のハテナマークとかマウスオーバーすると定義が出てくるんですけど、
そこに税とのしラッピング代が込みですみたいなのが入っていたり、
ショッピファイの販売合計の推移みたいなところをマウスオーバーすると、
ここにも税が入ってます。送料返品ディスカウント手数料込みですみたいな形になっていて、
税込みで表示されているケースが多いので、ここを管理で使っていたっていう形だと、
税込み管理になっちゃってるっていうケースが結構多いなと。
税込みで管理したいというか、税込みで売上見てるケースも結構あって、
キャッシュフローが重要なので、税抜きで分けて管理するんじゃなくて、
税込みで入金額見たいから、税込みで管理してますっていうケースも、
結構小規模な企業だと少なくないかなと思います。
実際、着勤するベースで管理して、キャッシュフローで管理していて、
ざっくり管理してるっていうケースですかね。
毎月いくらぐらいお金が入るかが分かればいいので、そこで管理しているというような形で、
ただ一方で免税事業者じゃない限り、消費税ってあくまでお客さんから預かっているお金なので、
売上と区別しないといけないですと、
財務会計上でも基本的には税抜きで管理していて、
預かり経営はBSで管理するみたいな形なので、
総益計算書、税リストなんか出す時ともあってくるので、
そちらで管理すべきだよなというのは思っています。
消費税は一時的に預かっているだけみたいな感覚って、なかなか身につかなかったんですけど、
私たちは店舗ビジネスだったんで、店頭で値札を税込み価格にしてたんですけど、
消費税変更あったじゃないですか、2019年とか。
あそこの時にガラッとシステムも値札も商品管理も全部税抜きに切り替えるっていうのを経験して、
あの時痛い思いをして、かなりその感覚を理解しました。
基本的にお客様から預かっているだけのお金をちゃんと区別しておかないと、
お金足りなくなっちゃいますよね。
消費税の納付時期に焦ってるみたいなことをよく聞くんですけど、
うちだって別管理しているので、そこが食い込むっていうことはないんですよね。
結構大変なのは、軽減税率対象の食品などの商品も一緒に扱っていると、
余計に管理が複雑になるので、利益率の計算なんかも税込み管理でやっていると、
軽減税率対象商品が入ってくると、あれなんか違うぞと、微妙にズレるぞみたいなことがあるので、
結構変わっちゃうなと。
売上1万円消費税1000円っていうのを、売上1万1000円で管理しちゃうと、
10%分多くなるので、結構肝大きくなっちゃったり、
誤った経営判断につながりかねないなというのは思っています。
10%の間隔ズレは結構大きいですね。
あと軽減税率も混在していると余計に無理ですね。
軽減税率の商品を扱っているけれども、簡易的に一律10%で管理しているケースなんかも、
EC売上計上の落とし穴：ポイント・クーポン利用
売上がズレるケースの2つ目としてあります。
あるのは一部食品を扱っているみたいなケースで、
ECの事業者さんだと、食品に関しては軽減税率が適用されるので8%。
でも多くの商品は税率10%ですと。
エクセルで分けて商品ごとに税率設定をして計算式に反映するとなると、
SKUが多い企業さんだと結構煩雑なエクセルになっちゃうので、
管理上はもう全部10%で計算して税抜きで管理しているみたいなケースに、
スターレコードと一部売上がズレてきていて、
何でなのか突き止めようとしたら軽減税率がちゃんと正しく適用されているので、
その分売上が増減していたみたいな形でズレているというのが2つ目のケースですね。
消費税関連でのズレがあるよということですね。
3つ目がタイトルにもしている通り、お客様の支払い総額を売上としているケース。
これが3つ目ズレるケースですと。
結構多いのが売上から引かなくてもいいポイントの割引であったり、
モール負担のクーポンを売上から引いているケースがありますと。
例えば楽天とかだとポイント利用額と楽天発行のクーポン利用額の2つの項目は、
売上から引く必要がないんですよね。
楽天負担分は楽天がその分補填して上で入金してくれるからということですかね。
そうですね。楽天の発行のクーポン利用金額については楽天が費用負担してくれているので、
その分上乗せてくれます。
しかし事業者側の売上に影響しないと。
あくまでお客さんの支払い総額から引かれるだけですと。
楽天側がお客さんがポイント利用で使った分も補填して売上として払ってくれますと。
これってあくまでお客さんが貯めていたポイントをお金の代わりに支払いに利用しているだけなんで、
お客様の支払い総額から引かれるけれども、店舗の売上から差し引かれるわけではないと。
一方でポイントの発行費用というのは売上とは別に半換費として計上してあるべきで、
楽天であれば楽天の会員の購入代金かける付与率1%みたいな形なんで、
ほぼほぼ会員で買っている人が多いので、売上かける1%のポイント費用というのに加えて、
ポイント倍率の変更ができるので、それを適用している場合にはその分の費用負担を半換費として計上する必要があるという感じです。
あと結構、給店に出店する事業者さんがストアレコードを導入いただく例も増えてきていて、
給店も結構複雑で、給店負担の商品割引っていうのに加えて、メガプロモーション保証金という項目があるんですけれども、
これ売上から引く必要がなくて、メガプロモーションの保証金の扱いが全然わからなくて、
売上から引いてましたみたいなケースが結構多いかなという風に思います。
めちゃくちゃややこしそう。一見値引きとか割引だけど、自社の値引きなのかモール側での値引きなのかで管理が違うのはややこしいですね。
普通に間違えそう。
本当に間違えて形状しているケースが多いので、結構売上思ってたのよりも低く出ちゃってる。
本当はもっと高いはずなのに低く出ちゃってる事業者さんが結構多いですと。
EC売上計上の落とし穴：受注ベースと発送ベース
4つ目が受注と発送売上を分けずに管理していたケース、みたいなのが売上ずれるケースですと。
僕自身前職の子ども部のECだとショピファイを利用していて、会計の締めもやってました。
ショピファイは結構販売面は強いんだけれども、会計基準に合わせて締めようとすると結構厄介だなというのがあります。
ショピファイに関しては受注ベースで売上全部形状していて、スターレコードの発送基準の売上にすると大きくずれるみたいなことが結構あって、
なんでこれ受注にしているかというと、そもそも発送基準でショピファイの売上を取るのが結構めんどくさいっていうのが理由としてあります。
基本的に財務会計の回転でいくと月が閉まったら発送基準で、その月に発送した売上だけを形状するっていうのが基本なんですけれども、
ショピファイだとCSVの項目の中に発送日っていうフルフィールドアットかなっていうカラムがあるんですけれども、
発送日基準で売上を絞り込む機能が多分まだないんじゃないかなと思います。
日付を絞って見えているデータは全部受注日ベースでの売上なんで、これをベースに計算しているとなかなか難しいと。
結構難しいのが予約商品とかあって、注文日と発送日が結構ずれちゃうみたいなケースだと、
例えば2月の売上を占めるのに1月ならず12月中にも予約商品を取っていて、
12月予約、2月発送みたいな売上を特定するためには、
12月分の注文データ全部と1月、2月の注文データ全部ダウンロードして、
フルフィールドアットで絞り込みをするみたいなそういうのが必要になっていて、
結構これは大変なので、やってないケースも多いかなと思います。
ショッパイ結構この会計基準上闇深いのは、決済手数料の計算もすごい全職でやったときめんどくさくて、
ショッパイペイメントの手数料とキャリア決済の手数料と、
コモジュとかペイリーみたいな決済手段ごとの決済手数料が違うので、
それぞれ明細が各会社から届くっていうような形で、
それを手数料と形状しなきゃいけないので、僕自身全職でも苦労してました。
えー、私今業界外にいるので、
ショッピファイってすごく使いやすい魔法のツールみたいな感じに聞こえ方しかしてこないんですけど、
初めて使いにくいところを聞きました。
そうですね、そこは結構僕自身もやってて思うし、
ショッピファイの中で実際に使って真面目に会計締めようとしている方は大変だよねっていうのを共感してもらいます。
EC売上計上の落とし穴：部分発送と月跨ぎ
えー、他にもあります?
これは結構レアなケースなんですけれども、
発送タイミングの突きずれで売上がずれていたケースがあります。
どういう事例かというと、1つの受注で複数の商品を受注しましたと、
発送が結構複数に分かれちゃう。
商品Aについては今日発送するけれども、
商品Bは3日後に発送しますみたいな形で、
2つに分かれちゃう。
しかもそれが、商品Aに関しては前月、
商品Bに関しては当月みたいな形で突きずれしてしまった時に、
どっちの発送付きの売上にするかみたいなところを、
ストアレコードだとちゃんと商品Aに関しては前月の売上だよね、
商品Bについては当月の売上だよねみたいな形で、
突きずれを考慮していますと。
一方で注文単位で管理していると、
後に発送された方に合わせちゃおうみたいな形で、
商品AとBで分かれていた場合に、
商品Bが発送された当月の売上に、
商品Aもしちゃおうみたいな形で管理している会社さんがあって、
そこでずれてしまいましたと。
ストアレコードに関して受取の手数料とか送料、
あとはクーポンの割引に関しても、
商品金額の合計に応じて半分しているので、
当月と前月にそれぞれ受取送料、クーポンの割引も分かれちゃうので、
そこで売上がかなりずれちゃうということがありました。
クーポンの割引金額とか受取送料、手数料を半分計算するのは、
Excelだと結構しんどいので、
やらずにどっちかに合わせて、
後ろ直しか前倒しにして計上しちゃうというケースが多いので、
そこでのずれがあったのは結構面白いなと思いました。
部分発送めちゃくちゃめんどくさそう。
だから諦めてたら、
ストアレコードだとちゃんと管理してくれてるからずれるってことですね。
半分までするんだ、すごい。
単位がほんと細かいですね、ストアレコードの。
結局そう、ちゃんと正しくやろうとすると、
全部SKU単位で半分して計上するっていうのが、
正しい売上把握の重要性
救ってて行き着いたっていう感じで、
細かく作りすぎて、
自分でもわけわかんなくなっちゃう時があるので、
最近はAIにものすごい、
この計算どうなってるんだっけっていうのを確認しながら、
お客さんに回答するっていうのはやっているのと、
マニュアルをAIに書いてもらって、
残すっていうのをやるようにしてます。
事業がまだそんなに大きくないと、
多少大雑把でもいいかみたいな気持ちも、
結構私はわかるんですけど、
やっぱり精緻に正しく売り上げ、
把握するっていうのが効いてきます?
おっしゃる通りで、
ちっちゃい時はいいと思うんですけど、
やっぱり1億超えてとか、
5億超えてとか、
10億超えてっていう時にはやっぱり、
どのタイミングかは、
それは経営者のごまかせによるんですけれども、
少なくとも市場5億超えたら、
ちゃんとやらないと、
10%のズレが大きいような形になるので、
そこはやったほうがいいなと思ってます。
やっぱり売上げを正しく計算して、
売上総利益率、限界利益率、
営業利益率が今何%で、
何%目指したいのか、
みたいなところを把握したり、
あとは限界利益率がこのぐらいだから、
広告費の比率はこのぐらいまで踏み込めるよね、
みたいなところを、
やっぱり一定、ちゃんと持っておくことによって、
大胆な投資というか、
正確な意思決定を
瞬時に下せるっていうところがあるので、
事業が厳しい時には、
しっかり適切に、
早めにブレーキをかけるっていう判断もできるし、
今成長し時だな、
攻め時だなっていう時には、
この金額であれば全然事業構造上も、
利益率を既存大きくすることなく、
投資をするっていう意思決定ができるので、
意思決定の基準となる利益率を正しく把握するためにも、
売上げを正しく把握するっていうのは、
すごい大事だなと思っています。
基本的には皆さん、
最初は間違った方法で形状していて、
僕が偉そうに言っているものの、
もうめちゃくちゃな状態から、
一個一個なんかずれてるなみたいなのを、
繰り返していって、
良くなっていくみたいな、
結構時間がかかるものだなと思うので、
ちょっと聞いてみて、
正しくやってみたいなと思ったら、
その瞬間からスタートして、
どこが今一番大きくずれてるか、
みたいなところを、
ちょっと日々正しくしていくようにすると、
毎月毎月制度が上がってくると思うので、
これを機会に正しく、
売上げを把握するっていうところに、
チャレンジする人が出てくると、
嬉しいなと思っています。
まとめと次回予告
ありがとうございます。
今日は、
EC売上げ形状における落とし穴、
お客様の支払い総額イコール、
売上げではないというお話でした。
ありがとうございます。
ありがとうございました。
ディテールトーク、
ここまでお聞きいただき、
番組の詳細欄に、
GoogleフォームのURLがあるので、
質問やメッセージは、
そちらからお送りいただけると嬉しいです。
番組内で、
ご紹介させていただくかもしれません。
次回もぜひよろしくお願いします。
