複数店舗の粗利管理はどこまでまとめる？店舗入力とPOSデータ連携の選び方

まず、粗利を何の判断に使うか決める

同じ「利益を見る」でも、必要な数字は判断によって変わります。

たとえば、店舗別の売れ方や仕入れ条件を見直すための日次管理なら、対象期間の売上と、それに対応する原価の見積もりを同じ基準でそろえることが中心です。取消や値引きがあるなら、売上だけでなくその反映方法も必要です。

日次では、商品ごとの販売数量に、その販売日に適用する1点当たりの標準原価を掛けて推定原価を出します。同じ商品・同じ期間の純売上から、その推定原価を差し引いたものが、早く判断するための粗利の見積もりです。売上と原価では、税、返品、取消、値引きの扱いをそろえます。その日の仕入額が、そのまま売れた商品の原価になるわけではありません。実際の期間消費額は、期首在庫、期間中の仕入れ、期末在庫などを同じ範囲で照合して確定します。廃棄や在庫差異を別に反映する場合は、期間消費額に含まれた分を重ねて足さず、二重計上を防ぎます。店舗間の移動も、店舗別の負担や在庫場所は変えますが、移動だけで会社全体の粗利が減るわけではありません。日次は同じ基準で変化を捉え、月末に棚卸や会計の数字と照合して差を確定します。

一方、人件費、家賃、決済手数料などを含む店舗全体の利益を確定したい場合、POSと原価表だけでは足りません。日々の粗利管理と月次会計を一つの表へ無理に詰め込まず、日次では何を早く見るのか、月次で何を確定するのかを分けます。

最初に一文で決めておくと、集める項目が増え続けるのを防げます。

「毎日の営業終了後に、店舗別・区分別の売上と原価のずれを確認し、仕入れや価格の見直し候補を見つける」

このように、見る人、見る時点、次に行う判断まで定めます。改善額や利益率の目標は、実績を確認できるまでは置かなくても構いません。

選び方は、POSの外に残る事実で分ける

判断の分かれ目は、POSを使っているかどうかではありません。POSから取り出せる事実だけで、予定している判断ができるかです。

売上、取消、値引きまでPOSで確定でき、商品と原価表を安定して結べるなら、同じ数字を店舗が打ち直す必要はありません。POSを売上の正本にし、原価表との対応を本部側で管理する方が単純です。

しかし、期間原価や店舗別の内訳を確かめるための仕入れ、廃棄、店舗間移動、後日の訂正などがPOSの外に残るなら、POSだけを集計しても判断材料が欠けます。その場合は、売上を再入力するのではなく、POSにない事実だけを店舗の締めで追加する併用を検討します。

既存Excelを残す案も、消極策とは限りません。店舗が扱う項目が少なく、本部が同じ日または翌営業日に確認でき、数式や集計範囲を勝手に変えられないなら、まず入力欄と責任をそろえる方が早く判断できます。権限、履歴、再集計、複数人での同時利用を表だけで保てなくなった時点で、追加の仕組みを比較します。

商品名だけで原価表と結ばない

店舗別・商品別の集計では、売上側の一行と原価表の一行を対応づける必要があります。ここを商品名だけに頼ると、表記の変更、同名の商品、セット商品の扱いによって、対応できない行が生まれます。

利用できる商品コードがあるなら、店舗と商品の組み合わせで管理します。安定したコードが使えない場合は、名称の対応表を持つだけでなく、次の責任も決めます。

• 新しい商品を誰が対応表へ追加するか
• 対応できない商品や原価未設定の商品にひもづく売上額をどこへ分けるか
• 原価が変わった日をどこに残すか
• 過去の対応を直したとき、どの期間を再集計するか

自動で結べなかった行を似た名前へ推測で寄せると、見た目だけは集計できます。経営判断に使うなら、判明している売上は売上合計に残したうえで、商品未対応・原価未設定の商品に対応する売上額を別に示します。これは原価の金額ではなく、原価がゼロという意味でもありません。全体の粗利は暫定と明示するか、原価が確定するまで合計の提示を見送る方が安全です。

架空例：売上はPOS、例外だけ店舗で締める

複数店舗を運営する架空の飲食会社で、売上と取消はPOSから取得でき、原価表は本部が更新しているとします。一方、廃棄と店舗間の食材移動はPOSに入りません。

この場合、店舗が売上をExcelへ再入力する方式ではなく、POSを売上の正本にし、店舗は廃棄と移動だけを営業終了後に確定する案が候補です。本部は、商品と原価の対応、未対応データ、原価の適用日を管理します。

ここで必要なのは、すべての業務を一つの画面へ集めることではありません。日々の粗利判断に必要な事実が重複せず、欠けず、後から直した理由を追える分担です。

投資判断の前に埋める確認欄

次の項目を一枚にすると、既存表の改善で終える範囲と、追加で仕組みにする範囲を分けられます。

• この数字を、誰が、いつ、何の判断に使うか
• 売上の正本はPOS、店舗入力、会計データのどれか
• 日次の推定原価は、販売数量に、販売日に適用する1点当たりの標準原価や移動平均単価のどれを掛けるか。月次の実際の期間消費額と混ぜていないか
• 取消・値引き・廃棄・移動・訂正のうち、必要なものは何か
• 店舗が締める項目と、本部が管理する項目は何か
• 判明している売上を合計に残し、商品未対応・原価未設定の商品に対応する売上額を別に示せるか
• 締め後の訂正を誰が承認し、どの期間を再集計するか
• 日次の管理値と月次会計を、どこで照合するか

まず代表的な一日分で、必要な売上と原価が結びつくか、POS外の事実がどれだけ残るかを確認します。その結果、既存Excelで責任と保護範囲をそろえれば足りるなら、開発は不要です。POS出力と原価表を安定して結べるなら、定期集計から試せます。

独自開発を見積もる前に、現在のPOSや一般的な店舗管理SaaSの標準機能で、必要な集計、締め・訂正の管理、月次照合をどこまで満たせるかを比較します。それでも必要な例外処理、権限、履歴、再集計を保てない範囲だけを、自動化や限定的な開発の対象にします。

追加の自動化や開発が必要になったら、システム開発の発注前に書く7項目で、依頼範囲と完了条件を整理できます。