店舗の売上集計をデジタル化する設計

「店舗から日報が上がってくるが、集計は本部でExcelに手打ち」「月次がまとまるのは翌月の半ば」——多店舗で商売をしていると、この形が固定化しがちです。

結論から言うと、店舗の売上集計をデジタル化する作業の中心は機器の入れ替えではなく、1日の締めの定義と、店舗をまたいで並べられる表の形を決めることです。ここが決まっていないと、どこからデータを取り出しても最後は手作業に戻ります。

株式会社Fyveは中小企業の業務をAI前提に組み替える立場から、この記事では製品比較ではなく、集める設計と手集計の残し方の判断基準を扱います。

売上集計が紙とExcelに残り続ける理由

店舗の売上データは、実はほとんどの場合すでにデジタルで存在しています。レジや販売機器の中に、日次の売上も取引の明細も入っている。それなのに本部での集計が手作業になるのは、次の3つが噛み合っていないからです。

• 取り出す方法が店舗ごとに違う：導入時期の違いで機器の世代が違い、データの出し方も違う
• 締めの定義が揃っていない：何時で1日を切るのか、深夜の売上をどちらの日に付けるのかが店舗任せになっている
• 集計表の形が店舗を増やせない形になっている：横に店舗の列を並べた表は、店舗が増えるたびに作り直しになる

このうち2番目と3番目は機器と関係ありません。ルールと表の形の問題です。ここを直さずにデータの取り出しだけ自動化すると、「取り出したものを人が突き合わせる」という新しい手作業が生まれます。

この記事では、決めるべき順番として「締めの定義 → 表の形 → 取り出しの自動化」を採ります。逆順で進めると、たいてい作ったものを作り直します。

まず「1日の締め」を定義する

集計の土台は、1日をどこで切るかです。ここが曖昧なままだと、店舗間で数字を比べられません。

決めるべき4項目

• 締めの時刻：営業終了後の何時で切るか。日付をまたいで営業する店舗がある場合、何時までを前日の売上として扱うかを明文化します
• 締めを実行する人：店長か、その日の責任者か。役職ではなく「その日の最後のシフトに入っている責任者」のように、必ず1人に決まる形にします
• 確定の合図：締めが終わった状態をどう示すか。精算票を出す、所定の場所に数字を入れる、など
• 訂正の扱い：締めた後に間違いが見つかったとき、上書きするのか訂正行を足すのか。上書きは履歴が消えるので避けます

この4つのうち、いちばん軽視されるのが訂正の扱いです。売上の数字は後から直ることがあります。上書きしてしまうと「昨日見た数字と違う」が起きて、どちらが正しいのか分からなくなります。訂正は行を足す形にして、いつ誰が直したかを残します。

営業日の定義を揃える意味

締めの時刻がずれていると、店舗間の比較が成立しません。片方の店舗は深夜0時で切り、もう片方は営業終了時に切っている場合、同じ「8月6日」でも含まれる時間帯が違います。曜日別や時間帯別に分析しようとした段階で、この差が効いてきます。

比較する予定があるなら、定義を揃えるのは最初にやるべき作業です。後から揃えると、過去データの再集計が必要になります。

販売機器からデータを取り出す方法の類型

取り出し方は機種によって違いますが、方式としては次の5つに分類できます。自社の店舗がどの型なのかを先に把握すると、打ち手が決まります。

型A：管理画面からファイルをダウンロードする

POSレジや自動精算機などの販売機器がクラウドの管理画面を持っている場合、日次や期間指定で売上データをファイルとして書き出せます。いちばん扱いやすい型で、この機能があるならまずここから始めます。

詰まりどころは次の点です。店舗ごとにログイン情報が分かれている場合、店舗数だけ作業が発生します。ダウンロードしたファイル名が毎回同じだと、フォルダに置いた瞬間に上書きされます。期間指定を手で選ぶ運用だと、選び間違いで欠損や重複が起きます。ファイル名に店舗コードと日付を必ず入れるルールを決めておくと、これらの多くを防げます。

型B：機器から記録媒体に書き出す

機器本体からUSBメモリやSDカードにデータを書き出す方式です。オフラインの機器ではこれしか手段がないことがあります。動きますが、物理的な持ち回りが発生するのが弱点です。誰がいつ抜いて、どこに入れるかを決めないと、そこで止まります。

型C：日次の精算票を読み取る、または入力する

営業終了時に印字される精算票の数字を使う方式です。機器を変えられない場合の現実解になります。ただし精算票には集計値しか載っていないため、商品別や時間帯別の粒度は最初から取れません。粒度の限界を先に認識しておかないと、後から「商品別を出したい」となったときに方式ごと変えることになります。

型D：連携機能で他システムへ直接渡す

機器やクラウドサービスが会計・在庫システムとの連携機能を持っている場合、ファイルを経由せずに渡せます。対応している組み合わせは限られるため、まず自社の機器の公式仕様を確認するのが先です。この型の作業の本体はデータの移動ではなく、売上区分や勘定科目の対応付けを決めることです。

型E：手書き日報に転記する

デジタル化されていない状態です。この型が残っている店舗があるなら、そこを型AかCに移すのが最初の一歩になります。

実務では、店舗によって型が混在するのがふつうです。全店舗を同じ型に揃えるのを条件にしないのが重要で、型が違っても最終的に同じ形の表に落ちるようにすれば集計は成立します。

どの粒度で集めるか

粒度は細かいほど良いわけではありません。細かい粒度は、集めるコストと維持するコストが両方乗ります。

• 日次の合計：売上高、現金とキャッシュレスの内訳、客数、税率区分別の金額。まずここだけで、月次の締めと店舗間の比較はできます
• 時間帯別：シフトの設計や営業時間の見直しに使います。使う予定がなければ後回し
• 商品・メニュー別：仕入や品揃えの見直しに使います。商品マスタの整備が前提になります
• 取引明細：1取引ごとのデータ。件数が多く、分析の目的が明確でないと持て余します

判断の基準はひとつです。使う目的が決まっていない粒度は集めない。集めておけば後で使えるという考えで細かいデータを溜めると、毎日の取り込み作業と保管の手間が増える一方で、誰も見ないまま残ります。

商品別を扱う場合は、店舗ごとにメニュー名の表記が揺れる問題が必ず出ます。同じ商品が店舗によって別名で登録されている状態では、合算できません。ここはマスタで吸収する領域です。

CopilotAIの読み取り精度を上げるマスタ設計

複数店舗を1つに集める設計

ここが多店舗特有の設計です。1店舗なら成り立っていた形が、店舗が増えた時点で崩れます。

店舗コードを決める

店舗を識別するのは名前ではなくコードにします。名前は変わりますし、表記も揺れます。短く、意味を埋め込まないコードを振ります。地域や業態をコードに含めると、店舗の移転や業態変更で破綻します。

コードはファイル名にも、表の列にも、フォルダ名にも同じものを使います。ここが統一されているだけで、突き合わせの手間が大きく減ります。

縦に積む形にする

いちばん重要な設計判断です。集計表は1行＝1店舗・1日・1区分という縦持ちの形にします。

• 良い形：日付／店舗コード／区分／金額 という列構成で、行が増えていく
• 悪い形：列に店舗を横に並べる。店舗が増えるたびに列を足し、数式を全部直すことになる

横に並べた表は人間には読みやすいのですが、機械で扱う前提だと壊れやすい。元データは縦持ち、人に見せるのはそこから作った集計表という二段構えにします。この分離をしておけば、店舗が増えても元データの構造は変わりません。

欠損を検知できるようにする

多店舗の集計でいちばん怖いのは、1店舗分の1日が抜けていることに気づかないまま月次を締めてしまう事故です。合計は出るので、見た目には何の問題もありません。

対策は単純で、店舗数×日数の行が揃っているかを確認することです。10店舗で30日なら300行あるべき、という数え方をします。行数が足りなければどこかが抜けている。この確認を締めの手順に1行入れておくだけで、後から遡る作業がなくなります。

店舗ごとの差はマスタに吸収する

店舗によって機器が違う、税率区分の設定が違う、営業時間が違う。こうした差を集計の数式の中に条件分岐として書き込むと、店舗が増えるたびに数式が複雑になります。店舗マスタに属性として持たせて、処理は同じにするのが基本です。

現金の突合を集計に組み込む

売上を集めるだけでは、数字が正しいかどうかは分かりません。現金商売が残っている業態では、3つの数字を並べる必要があります。

• 機器上の売上（現金分）：レジや販売機器が記録している現金売上
• 実際に手元にある現金：数えた額から釣銭準備金を除いた額
• 銀行への入金額：実際に預け入れた額

この3点が一致していることを、日次で確認します。2点だけで見ていると、どこでずれたのか特定できません。

注意点として、釣銭準備金を売上と混ぜない設計にします。混ぜると毎日の差異計算が複雑になり、原因追跡ができなくなります。準備金は別の管理として固定額で持ち、売上とは分けて数えます。

差異が出たときの扱いも決めておきます。誰が数えたか、いつ気づいたか、原因は何だったか。この3つを記録に残すと、同じ原因が繰り返されているかどうかが見えます。差異の記録がないと、毎回その場で解決して終わり、傾向が蓄積しません。

日次の締め手順を1枚にする

締めの定義を決めたら、それを店舗が毎日見る1枚の手順に落とします。ここを口頭で伝えている限り、人が変わるたびに手順が変わります。

1枚に載せるのは次の内容です。

• いつ実施するか——営業終了後、退店前。時刻ではなく作業の順序で書いたほうが守られます
• 機器の操作——精算の実行、票の印字、必要ならデータの書き出し。ボタンの名称まで書きます
• 数える手順——現金を数える順序、釣銭準備金を分ける方法、記録する場所
• 入力または送信——どこに何を入れるか。項目名を手順書と入力欄で完全に一致させます
• 確認して終わる——3点が一致しているか、差異があれば記録したか
• 差異が出たときの連絡先——誰に、いつまでに伝えるか

この手順書で意識すべきなのは、判断させないことです。「必要に応じて」「適宜」という表現が入っていると、人によって解釈が変わります。分岐が必要なら「◯◯なら手順5へ、そうでなければ手順6へ」と明示します。

手順書は最初から完成させず、2週間ほど運用して、実際に迷った箇所を書き足していく形が現実的です。迷った箇所こそが手順書の価値がある場所で、最初に想像で書いた部分はたいてい問題になりません。

店舗と本部の役割分担を決める

集計の仕組みが止まる原因の多くは、技術ではなく役割の曖昧さです。とくに次の3つは、決めておかないと必ず宙に浮きます。

数字を確定させるのは誰か

店舗が入力した数字を、そのまま確定として扱うのか、本部が確認してから確定とするのか。両方に見えて実は違います。前者なら店舗の責任が重くなり、後者なら本部の作業が毎日発生します。店舗数が少ないうちは本部確認、増えたら店舗確定に移すという段階の設け方が扱いやすいです。

抜けを追いかけるのは誰か

未提出の店舗に連絡するのは本部です。ここを「気づいた人が」にすると誰もやりません。欠損の確認を毎朝の作業として本部側の手順に組み込み、連絡する人を決めます。

差異の原因を調べるのは誰か

現場で起きたことは現場でしか分かりません。原因の調査は店舗、記録の管理は本部、という分担が素直です。本部が原因を推測して記録すると、実態と違う記録が残ります。

役割を決めるときのコツは、作業ではなく「その結果に責任を持つ人」で決めることです。作業は誰がやってもよいが、抜けたときに気づく人は1人に決まっていなければなりません。

手集計が残る箇所の見極め

全部を自動化しようとすると、例外の処理で行き詰まります。残していい手作業と、潰すべき手作業を分けます。

残していい手作業

• 現金を数える：物理的な作業なので置き換えられません
• 差異の原因を調べる：判断が入ります。人が持つ領域です
• 日報の定性コメント：天候、近隣のイベント、機器の不調。数字に表れない情報は、書いてもらう価値があります
• 締めの確定：最終的に「この数字で確定」と決めるのは人です

潰すべき手作業

• 転記：ある場所に書かれた数字を別の場所に打ち直す作業。ここは例外なく潰します。転記は間違いを生むだけで、何も付加していません
• 電卓での合算：合計は集計表に計算させます
• 店舗別ファイルの手作業での結合：コピー貼り付けでの統合は、貼り付け位置のずれで静かに壊れます
• 月次でのフォーマット組み直し：毎月同じ作業をしているなら、元データの形が間違っています

判断の軸は「判断が入るか」「原本が物理か」の2つです。どちらでもない作業は、原則として潰す対象になります。転記が残っている限り、デジタル化は途中です。

Excelで集約するときの表の形

Microsoft 365環境なら、集約先はExcelとSharePointの組み合わせになります。ここで表の形を間違えると、後段の集計とAIの活用がどちらも苦しくなります。

• 1行1レコード・1列1項目を守る。1つのセルに複数の情報を入れない
• 結合セルを使わない。見た目のために結合すると、並べ替えも集計も止まります
• 見出しは1行だけ。2段の見出しは機械が扱えません
• 集計行を表の中に混ぜない。小計行が途中に入ると、行の追加で崩れます
• 日付は日付として入れる。文字列の日付は並べ替えも期間指定もできません
• 店舗コードは文字列で扱う。先頭が0のコードは数値として扱うと0が消えます

この6点は、AIを使うかどうかに関係なく効きます。表の形が整っていれば、集計も抽出も指示が短く済みます。逆に形が崩れていると、何をするにも「この表はこういう構造で」という説明から始めることになります。

人に見せるレポートは、元データから別のシートに作ります。元データを直接きれいに整えたくなりますが、それをやると機械が読める形が失われます。機械が読む表と人が読む表を分けるのが原則です。

AIに任せられる範囲と任せられない範囲

売上集計の文脈でAIに任せられるのは、数字を確定させる前後の作業です。

任せられること

• 集計や抽出の数式・手順の下書きを作らせる
• 取り出したファイルの列名と自社の項目の対応付けの案を出させる
• 前月と比べて動きの大きい店舗や日付を挙げさせる
• 月次の報告コメントの文案を作らせる
• 表の形が崩れている箇所を指摘させる

任せられないこと

• 数字の確定：会計に載る数字は人が確認した跡を残します
• 締めの確定：責任の所在が必要な判断です
• 差異の原因の断定：現場に確認しないと分かりません
• 欠損の判断：抜けているのか、その日が休業だったのかは、AIには判別できません

また、AIが出した集計値をそのまま使わないことも重要です。合計は必ず別の方法で検算する。店舗別の合計を足したものと全体の合計が一致するか、といった単純な突き合わせで十分です。検算の手順を仕組みに入れておけば、間違いが混ざったまま報告されることを防げます。

Copilotで具体的にどこまでできるかは基礎編で扱っています。ExcelのCopilot使い方、業務別の型はMicrosoft 365 Copilot活用事例、導入判断はMicrosoft 365 Copilotは必要かを参照してください。

導入の順番と、測るべき指標

順番を守ると、作り直しが起きません。

• 第1段階：定義を決める。締めの時刻、締める人、確定の合図、訂正の扱い、店舗コード。表もツールもまだ作りません。文書1枚で足ります
• 第2段階：日次合計だけを縦持ちで集める。当面は店舗が所定の場所に数字を入れる形でも構いません。2〜4週間回すと、店舗ごとの差と例外が具体的に見えます
• 第3段階：取り出しを自動化する。型Aのダウンロードやファイルの取り込みを仕組みにします。粒度を上げるのはこの段階以降です

取り込みの受け皿としてフォルダを使う場合、命名規則とトリガーの設計が別に必要になります。

Copilotスキャン→フォルダ→自動処理をつなぐ設計

測る指標は、次の5つに絞ります。

• 締めから集計完了までの日数：本来の目的がここです
• 欠損行の件数：店舗数×日数と実際の行数の差
• 現金差異が発生した日数：突合が機能しているかどうか
• 手で転記している箇所の数：減っていくべき数字。ゼロを目指します
• 締め後に訂正した件数：多いなら、締めの手順か機器の設定に原因があります

売上の金額そのものは経営指標であって、デジタル化の指標ではありません。集計が何日で終わるか、手作業がいくつ残っているかを見ます。

店舗の経費側、つまりレシートや小口現金の扱いは、売上とは別の設計になります。

Copilotレシート・小口現金のデータ化｜運用設計の手順

よくある質問

レジを買い替えないとデジタル化できませんか

できます。管理画面からのファイル書き出しがない機器でも、日次の精算票の数字を所定の形式で集める運用にすれば、店舗間の比較と月次の集計は成立します。ただし商品別や時間帯別の粒度は取れないため、その分析が必要になった時点で機器の見直しを検討する形になります。

店舗によって機器が違いますが、揃えるべきですか

揃えるのが理想ですが、揃うまで待つ必要はありません。取り出す方法は店舗ごとに違っていてよく、最終的に落とす表の形が同じであれば集計はできます。先に表の形と店舗コードを決めておけば、機器の入れ替えは順次進められます。

締めの時刻は何時にすべきですか

業態によります。重要なのは時刻そのものより、全店舗で同じ定義を使い、日付をまたぐ売上の扱いを明文化することです。深夜まで営業する店舗がある場合は、何時までを前日扱いにするかを決めて、機器の設定と合わせます。

Excelで管理し続けても問題ありませんか

店舗数と粒度によります。日次合計を10店舗前後で持つ規模なら、縦持ちの表を守っている限りExcelで十分回ります。行数が万単位になり、複数人が同時に触るようになると、データベース側に置くことを検討する段階です。ただし表の形が崩れているまま基盤を変えても解決しません。順番としては形の整備が先です。

店舗から数字が上がってこない日はどうすればよいですか

欠損として検知できる状態にしておき、翌営業日に確認する運用にします。空欄をゼロとして集計してしまうと、休業日と入力漏れが区別できません。「未提出」という状態を持たせるのが正しい設計です。

キャッシュレス決済の入金と売上が一致しません

決済事業者からの入金は手数料が差し引かれ、入金のタイミングも売上日とずれます。売上の集計と入金の照合は別の作業として設計します。売上側は決済区分ごとの金額を持ち、入金側は入金日で管理して、月次で突き合わせる形が扱いやすいです。会計上の処理方法は顧問税理士に確認してください。

本部で集計する人が1人しかいません

その場合こそ、締めの定義と表の形を先に固める価値があります。手順が明文化されていれば、その人が不在の日でも別の人が代われます。属人化を解くのは自動化ではなく、定義の明文化が先です。

まとめ

店舗の売上集計をデジタル化する順番は、機器から始まりません。

• 締めの時刻・締める人・確定の合図・訂正の扱いを最初に決める
• 店舗を識別するのは名前ではなくコード。意味を埋め込まない
• データの取り出し方は5つの型に分類できる。店舗ごとに型が違っても構わない
• 使う目的が決まっていない粒度は集めない
• 元データは縦持ち。横に店舗を並べた表は店舗が増えると壊れる
• 店舗数×日数で行が揃っているかを確認する。欠損は合計を見ても分からない
• 現金は機器上の売上・実際の現金・銀行入金の3点で突合する
• 判断が入る作業と物理作業は人が持つ。転記は例外なく潰す
• AIには数字を確定させない。集計値は必ず別の方法で検算する
• 指標は売上額ではなく、集計完了までの日数と残っている手作業の数

集計が翌月半ばにしか出ない状態では、数字を見て手を打つ余地がありません。締めの定義と表の形を整えるだけで、そこは変わります。私はこの順番で組むことを勧めています。