月末の役員会で「数字が合わない」が始まる瞬間

飲食の経営をやっていると、月末に“あの瞬間”が来ます。

• 店舗から上がってくる「POS日計」
• 経理が確定させた「会計の売上」
• そして、BIの「日次売上」

この3つが、微妙に合わない。

最初は「締め作業のミスかな？」で済むんですが、店舗数が増えるとそうはいきません。
ズレの理由が、店舗ごとに違う。POSごとに違う。運用の癖でも違う。

あるチェーンの例では、レジのキー追加が入るたびに集計側で手作業が発生し、変換ミスが散見される。レジ締めミスや開局ミスがあると、また手作業が増える。そして最終的に「POS日計と一致しない」が常態化する、という典型パターンに落ちていきます。

こうなると、会議で何が起きるか。
議論は「施策」ではなく「数字の整合」に吸い込まれます。

• 値上げの効果は？
• 人件費率の改善は？
• 店長交代の成果は？

…その前に「そもそも売上が合ってない」で止まる。
この状態は、経営としてはかなり危険です。なぜなら、経営判断が“曖昧な数字”の上に立つから。

このコラムで言いたいのは、ここです。

「日計（集計後データ）」中心でやる限り、
このズレは“頑張っても消えない”。
仕組みを変えないと、ずっと同じ地獄を周回する。

そして、その“仕組みの変え方”が トランザクション基盤です。

---

そもそも日計は「結果」であって「原因」が消えている

日計データって、言ってしまえば「集計済みの最終結果」です。
便利なんですが、落とし穴がある。

日計が持つ構造的な弱点

1. 計算式がPOSごとに違う
   日計はPOS側の計算結果なので、POSの思想（VOID/キャンセル、返品/取消/打消、赤伝/黒伝、総売上/純売上など）の差が、そのまま数字に混入します。
2. 運用の揺れに弱い（締め忘れ・開局ミス・修正運用）
   まさに現場で起きる「あるある」が、日計には直撃します。
3. 外部連携で“二重の数字”が生まれやすい
   日計ベースで本社・経理側が修正する運用を続けると、

• POSトランザクションから集計した分析用の数字
• 会計（OBIC等）で修正後の財務用の数字
  が二重管理になり、乖離が生じる、という問題がはっきり出ます。

日計を中心にすると、どんどん「最終結果だけをパッチで直す」世界に入っていく。
そして最終的に“何が起きたか”が追えなくなる。

---

トランザクション基盤って何か：レシート単位まで降りて「こちらで再集計する」

トランザクション基盤というのは、簡単に言うとこうです。

• 日計（集計後）ではなく
• レシート／伝票／明細（トランザクション）を直接受け取る
• そのうえで こちら側の定義で再集計する

テンアライド案件の議事録でも、理想像として「日計ベースではなく、トランザクション（レシート）単位で修正する運用への移行」が明確に語られています。

さらに「理想はレシート／伝票単位で修正し、その結果を集計する運用」であれば、分析（TEAL BI）と財務（OBIC/ガジェットフード）が同じトランザクションから再集計でき、整合性が取れる、という整理までされている。

これができると、何が変わるか。
ここからが本題です。

---

トランザクション基盤にすると「経営数字」が壊れにくくなる理由

1) “POSごとの計算式”を吸収できる（＝統一集計が成立する）

各POSは集計ルールも項目定義も違う。これは資料にも整理してあります。

だから、日計を集めて並べても、数字は揃わない。

一方、トランザクション（伝票明細・商品明細・支払種別・値割引）を取れば、
こちら側の共通定義で売上も客数も客単価も作り直せる。

実際、TEALがやっていることとして「各POSレジの計算式を独自で解読」し、トランデータから統一フォーマット集計する、と明示しています。

ここで初めて、M&AでPOSが混ざっても「同じ尺度」で比較できるようになる。

---

2) “ズレ”が起きた時に、原因に降りられる（＝健康診断になる）

日計は、ズレても理由が分からないことが多い。
でもトランザクションなら、「どの伝票・どの明細・どの支払」でズレたかに降りられる。

だから僕は、トランザクション基盤を 経営者目線の健康診断って呼びます。

• 売上が変だ → どの時間帯？どの支払？どの値引き？どの取消？
• 客単価が落ちた → 値引き？セット構成？カテゴリ構成？数量？
• 原価率が悪化 → そもそも売上の基準が揺れてないか？

“体温”だけ見て「熱っぽいね」で終わるのが日計。
“血液検査”までして原因に降りられるのがトランザクション。

---

3) レジ締め・開局ミスなどの“運用事故”を、検算で早期発見できる

ここは地味だけど、めちゃくちゃ重要です。

日計中心の運用だと、事故が起きた時に「誰かが気づくまで」放置されやすい。
そして後追い修正が増えて、さらに二重管理が増える。

TEALはここを仕組みにしています。
「各POSレジの日計集計と毎日検算。誤差±0を表示」と、明確に“検算”を前提に置いている。

つまり、トランザクションから再集計した日計（こちらの計算結果）と、POSの公式日計を毎日突合して、ズレを即座に見える化する。
この運用は、経営の安心感が段違いになります。

---

4) 「加工済みデータ（30分集計など）」ではなく、最小単位のRAWが必要になる

ここ、よく勘違いされます。

「30分集計が取れます」「日次でCSVが出せます」
もちろん助かるんですが、トランザクション基盤を作るにはそれでは足りない。

議事録でも、必要なのは加工データではなく「伝票明細（TITEM）レベルのRAW」である、と明言しています。

最小単位の明細がないと、

• 計算式の吸収
• 定義統一
• 不正検知
• 原因追跡
• 検算（±0）

この全部が成立しない。
だから、最初から“RAW前提”で設計する必要がある。

---

「日計集計の罠」が生まれる典型パターン（現場で起きる順番）

僕が現場で何度も見てきた順番を、そのまま書きます。

1. キー追加・運用変更・店舗事故が起きる
2. まず日計で始める（早く見える化したいから）
3. そのたびに変換やExcel補正が増える
4. 外部システム（会計・基幹）側でも修正が走る
5. 結果、分析と財務で数字が二重化して乖離する
6. 役員会で「数字が合わない」が定例化
7. “施策の議論”ができなくなる

これ、経営の速度を落とすだけじゃなくて、
意思決定の質を落とします。最悪、現場の信頼も落ちる。

---

TEAL Gateway × トランザクション基盤の現実解

ここまで理想を語りましたが、現場に落とす時に重要なのは「流れ」です。
テンアライド×NSWの整理は、まさに“現実解の見本”になっています。

• POS → TEAL Gatewayでトランザクション受信
• Gateway上で標準化（アイテム／伝票／支払種別／割引）
• 基幹（ガジェットフード）側で日次処理
• 売上変更は本部側で“伝票単位”修正し、変更後トランを再集計
• 変更分をGatewayへ戻し、TEAL BIは常に修正済みトランを前提に可視化

この一連が、僕が「日計の罠から脱出するために必要な設計」だと思っているものです。

---

まとめ：日計中心は“見える化が早い”が、経営の足腰が弱くなる

最後に、今日の結論を経営者向けに一本で言います。

• 日計中心は早い。でも、事故・修正・連携が増えるほど壊れる
• トランザクション基盤は遅い。でも、統一集計と検算で壊れにくい
• そして最大の価値は「数字の原因に降りられる」こと＝健康診断

だから僕は、
「BIを入れる」より先に、
「トランザクション基盤を作る」ことを推します。

BIは最後の“見せ方”です。
足腰（基盤）が揺れていたら、どれだけ綺麗なダッシュボードでも経営は良くならない。