業務システムを組む時に考慮すべき、売上計上のポイント
こんにちは。URIHOの開発をしている今川です。
今回は技術的な話と言うよりは簿記の話です。なぜ簿記の話を書こうと思ったのかというと、システムの設計で「どこまで要件を詰めるか（どこまでがmustでどこからがbetterなものなのか）」を判断する際に、知識として簿記を理解しておくと要件が整理しやすくなると思うからです。まずは簿記の基本的な仕組みをざっと説明しましょう！
簿記ってなに？
wikipediaによると下記のものになります。
簿記とは企業などの経済主体が経済取引によりもたらされる資産・負債・純資産の増減を管理し、併せて一定期間内の収益及び費用を記録することである。より平易な言い方をすると「お金やものの出入りを記録するための方法」である。
そのお金や物の出入りを記録するための方法として単式簿記と複式簿記があります。単式簿記とは家計簿をつけるように電気代で5000円支払った場合に-5000円と記録することです。それに対して複式簿記とはお金の出入りには原因と結果があるので電気代の例では5000円支払った原因が「電気代：5000円」、結果として現金がなくなったので「現金：5000円」と記録します。
単式簿記だとお金の出入りだけ記録しているので、何にお金を使ったのか、いくら増えたのかしかわかりません。それに対して複式簿記だと原因と結果がわかるので経営の分析に活かすことができます。そのため企業の会計で採用されているものは複式簿記になります。
仕訳とは？
wikipediaによると下記のものになります。
資産・費用は借方、負債・純資産・収益は貸方に分類し、取引の貸借が分類されたとおりであればその勘定科目を増加し、逆であればその勘定科目を減少させるというルールがある
複式簿記で説明した原因と結果を記録する具体的な方法のことです。これは本当によくできていて、このルール通りに記録すると最終的に決算資料ができあがるというものです。「ルール通りに記録すること」というところがソフトウェアと相性がいいことから様々な企業で会計ソフトが作られています。借方は左、貸方は右で記載します。
仕訳の具体例（1000円の商品を売ったときの仕訳）
| 借方（金額） | 貸方（金額） |
|---|---|
| 現金（1000円） | 売上（1000円） |
お金の流れを把握する
販売管理システムの本に書いてあるような一般的な企業のお金の流れを確認しながら仕訳をしていきます。仕入れを行い、それを販売し、入金されるビジネスモデルの企業を例にします。
現金取引のところもあると思いますが企業間取引では締日を設けて支払いを行うことが多いので販売したときは売掛金で処理します。同様に物を仕入れたときなどの支払債務を負ったときは買掛金で処理します。
1000円の商品を仕入れたときの仕訳
| 借方（金額） | 貸方（金額） |
|---|---|
| 仕入（1000円） | 買掛金（1000円） |
仕入れた商品を1500円で販売したときの仕訳
| 借方（金額） | 貸方（金額） |
|---|---|
| 売掛金（1500円） | 売上（1500円） |
翌月末に販売した商品の代金が入金されたときの仕訳
| 借方（金額） | 貸方（金額） |
|---|---|
| 現金（1500円） | 売掛金（1500円） |
仕訳についての簡単な説明はこのくらいにして、ではこの仕訳はいつ経理システムに連携すればいいでしょうか？ERPを使っている企業であれば即時に販売管理システムから経理システムへ連携できると思いますが別々のシステムになっている場合はどうすればいいでしょうか？
またこのくらいなら普通に設計していれば経理システムを意識しなくても問題ないと思われる方もいらっしゃると思うので注意が必要なビジネスモデルの仕訳をみていきましょう！
注意すべきビジネスモデルの仕訳
前提として売上データを保存するテーブルにはデータ作成日があるものとします。
サブスクリプションモデルの場合
Webサービスを提供している企業なら毎月利用料をお客様からいただくビジネスモデルが多いと思います。このビジネスモデルの場合の仕訳と売上日はどうなるでしょうか？毎月10000円請求するとします。
月初に当月利用料を請求する場合（6/1に請求）
| 借方（金額） | 貸方（金額） |
|---|---|
| 売掛金（10000円） | 売上（10000円） |
売上日は6/1で売上データの作成日と売上日が一緒なのでこちらは簡単ですね。
月初に前月利用料を請求する場合
| 借方（金額） | 貸方（金額） |
|---|---|
| 売掛金（10000円） | 売上（10000円） |
こちらは6/1に前月分（5/1〜5/31）を請求するので、売上データの作成日（6/1）、売上日（5/31）で日付がずれてますね。売上データの作成日を売上日としてしまうと5月分の売上なのに6月分の売上として認識され正しく経理システムに連携することができなくなります。このあたりから設計を失敗する可能性が出てきますね。
ここまでは普通に設計していればなんとなく簿記の知識がなくても設計できそうな感じがします。
では年間利用料を一括で支払う場合（120000円）はいかがでしょうか？直ぐに思いつくのはこんな感じでしょうか？
| 借方（金額） | 貸方（金額） |
|---|---|
| 売掛金（120000円） | 売上（120000円） |
これをやってしまうと一括請求した年だけ売上が計上されることになり仕訳の目的である年度ごと決算の実態を正しく表さなくなってしまいます。例えば2021年6月1日に一括で支払ってもらった場合、実際の利用は2022年5月まで続くのに2022年度の売上が計上されなくなってしまいます。なのでこういった仕訳を表すような売上データを作ってしまうと経理からクレームが来ると思います。
なので下記のような仕訳が適切かと思います。
6/1の一括払い請求の場合の仕訳
| 借方（金額） | 貸方（金額） |
|---|---|
| 売掛金（120000円） | 前受金（120000円） |
6月分の売上（利用料）を計上
| 借方（金額） | 貸方（金額） |
|---|---|
| 前受金（10000円） | 売掛金（10000円） |
| 売掛金（10000円） | 売上（10000円） |
これは一括請求をした場合は一括請求分を売上に計上するわけにはいかないので一旦前受金として計上します。当月分の売上は当月に計上されるように調整し、前受金を切り崩していきます。売上データには一括請求時に12ヶ月分の売上データを作成するか当月ごとに売上データを作るかの2パターンかなと思います。
試用販売の場合
試用販売とはお客様に商品を試しに使ってもらい、購入したいという意思決定があれば購入代金をいただき、気に入らなければ返品してもOKという販売形態です。
今回はマッサージチェア（仕入原価が150000円）を試用してもらって1ヶ月後に購入（200000円）の意思表示を受けた場合の売上日はいつになるでしょうか？マッサージチェアをお客様に配送した日でしょうか？それとも購入の意思決定を受けたときでしょうか？仕訳をみていきましょう。
マッサージチェアをお客様に配送時の仕訳
| 借方（金額） | 貸方（金額） |
|---|---|
| 試用品（150000円） | 仕入（150000円） |
購入の意思表示を受けたときの仕訳
| 借方（金額） | 貸方（金額） |
|---|---|
| 売掛金（200000円） | 売上（200000円） |
| 仕入（150000円） | 試用品（150000円） |
売上日はやはり購入の意思表示を受けたときですね。売上日が実際に物が移動したときではなく購入の意思決定時点という例でした。
試用販売ではお客様の購入意思時点が売上日としましたが、自社倉庫をもっていて、そこからお客様の店舗まで商品を届ける場合はどの時点が売上の基準点になるのでしょうか？つぎはこの売上の基準点についてみていきましょう。
売上の基準点
自社倉庫からお客様の店舗に届ける場合下記のような時点が売上日の候補に挙がると思います。
- 出荷日
自社倉庫から出荷処理を行った時点です。
- 商品納品日
商品がお客様の店舗に届いた時点です。
- 商品検収時
商品がお客様に届けられて商品の中身を確認した時点です。
ではどの時点が売上の基準点になるでしょうか？
正解は…
全部でした！。
これは各企業に売上の基準点を決めることが委ねられているため全ての基準点が採用できます。ただし一貫性をもった基準を採用する必要があるので今年度は出荷日を基準として売上を計上するけど次年度は商品納品日を基準として売上を計上することはできません。実務的には商品納品日、商品検収日はお客様と密なコミュニケーションかシステム連携でもしてない限りコストが非常に高いので採用しにくいと思います。出荷基準なら自社で完結するので出荷基準が採用されるところが多いです。
そのため自社がどういった基準点を売上として認識しているかは経理チームに聞きましょう！プロジェクトを始めるときは経理チームを最初から巻き込んでおくのをオススメします。
終わりに
いかがだったでしょうか？今回は技術的な話ではなく簿記という苦手な人には難しかったと思いますが、勉強しておかないと要件定義で失敗する可能性があるものだったのではないでしょうか？特に一括払いの話はミスが発生しやすい箇所ですし、売上日は各社によってことなるので経理チームとの連携が不可欠な箇所になります。
簿記は決まった手順で処理していけば決算資料ができあがるので、エンジニアにはとっつきやすいものだと思います。ネットワークのプロトコルを覚えるよりは楽だと思います（笑）。
是非この記事をきっかけに簿記の勉強をしてみてください。きっと要件定義、システム設計に活かせると思います。
さて、ラクーングループは一緒に働く仲間を絶賛大募集中です！企業間取引という普段生活していてもかかわりのないビジネスを一緒に作りたい方こちらからエントリーお待ちしています！
