「数字が合わない」：経理 vs 分析、社長会議で発覚

経営会議の30分前。「経理の月次報告では1.2億、BIダッシュボードでは1.1億って出てるけど、どっちが正しいの？」── データチームの胃が痛くなる瞬間。数字が合わない原因は10種類以上。順序立てた調査が必須。

ズレが起きる典型10原因

1. 1期間定義の違い：会計は「計上日」、分析は「決済完了日」
2. 2通貨換算の違い：日次レート vs 月末レート、税抜 vs 税込
3. 3返品・キャンセルの扱い：会計は遡って消す、分析は別レコードで残す
4. 4消費税端数処理：四捨五入 vs 切り捨て vs 銀行家丸め
5. 5重複データ：JOIN で1対多が発生し、片方は二重計上
6. 6フィルタの差：会計は「全社」、BI（Business Intelligence） は「Active customer のみ」がデフォルトに
7. 7集計タイミング：日付の境目で「23:59 の取引」が翌日扱いされる
8. 8タイムゾーン：UTC vs JST（次回 EP.10 で詳述）
9. 9通帳ベース vs 計上ベース：入金日 vs 売上発生日
10. 10サンプリング：BI が高速化のためサンプリングをしている

調査手順（探偵手順）

1. 1まず期間と粒度を一致させる：「2026年4月の集計」は同じ条件か。タイムゾーンも
2. 2フィルタを揃える：BI が `WHERE active = true` でフィルタしてないか確認
3. 31件レベルで突合：両者の生データから「金額の高い TOP10」を出して、突合表を作る
4. 4差額の特徴を見る：差は固定額（1万円）か、比率（1%）か。後者は丸め・税端数の可能性大
5. 5横断 SQL（Structured Query Language） で確認：両ソースを `FULL OUTER JOIN` で繋いで `IS NULL` を抽出
6. 6履歴を追う：dbt（data build tool） のバージョン履歴・ETL（Extract, Transform, Load） のリビルドタイミングを確認

WITH accounting AS (  SELECT order_id, total_amount FROM accounting.monthly_sales  WHERE year_month = '2026-04'),analytics AS (  SELECT order_id, SUM(amount) AS total_amount  FROM analytics.fact_orders  WHERE DATE_TRUNC(order_date, MONTH) = '2026-04-01'  GROUP BY order_id)SELECT  COALESCE(a.order_id, b.order_id) AS order_id,  a.total_amount AS accounting_amount,  b.total_amount AS analytics_amount,  a.total_amount - b.total_amount AS diffFROM accounting aFULL OUTER JOIN analytics b USING(order_id)WHERE a.total_amount IS DISTINCT FROM b.total_amountORDER BY ABS(diff) DESC LIMIT 30;

再発防止：3層構造

• 第1層：定義の一元化 ─ 「売上」「アクティブ顧客」「契約数」など重要KPIを dbt メトリクスレイヤー や Looker LookML / Cube.js で1箇所に
• 第2層：日次突合バッチ ─ 経理の closing 数字と BI の集計を毎日自動比較、差が閾値超えで Slack 通知
• 第3層：監査ログ ─ KPI が変わった時に「いつ・誰が・何のクエリで」変更したかを SQL の version/hash で記録

ふくふくの進め方

「数字合わない」は1〜2ヶ月の中規模プロジェクトになります。KPI 辞典の作成 → メトリクスレイヤー化 → 突合バッチ稼働の3ステップ。社長会議で堂々と数字を出せる体制まで持って行きます。