EC売上と入金はなぜ一致しないのか：BigQueryで突合システムを構築した実体験

EC売上と入金はなぜ一致しないのか

BigQueryで突合システムを構築した実体験

EC事業を運営していると、必ず直面する問題があります。

それは 「売上と入金が一致しない問題」 です。

一見すると、
「売上が発生したら入金されるだけでは？」
と思うかもしれません。

しかし実際のEC事業では、売上と入金は複数のシステム・複数の決済手段をまたいで管理されるため、必ずしも簡単には一致しません。

私が以前勤務していた会社でも、この問題を解決するために 売上・入金突合システムの開発プロジェクト を行いました。

結果としてシステムは完成しましたが、その過程では

• ロジックの複雑化
• 組織間の調整
• 開発の長期化
• システムの正確性を証明できない問題

など、多くの課題に直面しました。

この記事では、実際に BigQueryを使って売上・入金突合システムを構築した経験 をもとに、ECデータ管理の難しさとシステム開発の現実について解説します。

---

なぜECでは売上と入金が一致しないのか

ECビジネスでは、売上データと入金データが複数のシステムに分散しています。

例えば次のような構造です。

売上データ

• カートシステム
• ECモール
• 注文管理システム

入金データ

• クレジットカード決済
• 代引き
• 銀行振込
• 決済代行会社
• 返金データ

つまり

売上データ + 入金データ + 返金データ + 顧客対応データ

を 横断的に突合する必要 があります。

さらにECでは次のような例外処理が頻繁に発生します。

• 注文キャンセル
• 決済方法の変更
• 返金処理
• 入金遅延
• 誤配送による返金
• システムエラー

このため

売上 = 入金

という単純な関係にはなりません。

---

カートシステムだけでは入金管理できない理由

多くのECカートでは、カード決済などのオンライン決済については 入金ステータスが自動反映 されます。

つまり

注文 ↓ カード決済 ↓ 入金済み

という管理が可能です。

しかし現実の運用では、次のようなケースが必ず発生します。

① 会社口座への直接振込

顧客が

• 指定口座に直接振込
• 別の名義で振込

などを行う場合。

② 顧客対応による返金

テレオペ対応で

• 誤配送
• クレーム対応
• 個別返金

が発生する場合。

③ 注文金額と入金額の不一致

例えば

• 二重入金
• 入金不足
• 誤送金

などです。

こうしたケースは カートシステムだけでは正確に把握できません。

そのため

売上データ vs 入金データ

を 外部システムで突合する必要 がありました。

---

売上・入金突合システムの概要

そこで構築したのが、BigQueryを使った売上・入金突合システムです。

システムの概念は次の通りです。

売上データ (カート)

入金データ (決済会社・銀行)

返金データ

↓

BigQuery

↓

売上・入金突合

↓

未入金 / 不一致抽出

↓

テレオペ確認

このシステムによって

• 未入金顧客
• 過入金
• 金額不一致

を検出できるようにしました。

---

最大の問題：ロジックが爆発的に複雑になる

このシステム開発で最も大変だったのは ロジックの複雑化 でした。

ECのデータ構造は想像以上に複雑です。

例えば次のようなケースがあります。

ケース① 注文キャンセル

注文 ↓ キャンセル

ケース② 再注文

注文 ↓ キャンセル ↓ 再注文

ケース③ 決済方法変更

注文：カード ↓ 入金：銀行振込

ケース④ 返金

入金 ↓ 返金

これらをすべて考慮してロジックを作る必要があります。

---

最終的にテーブルとビューが100近くになった

開発が進むにつれて、データ構造は次のように膨らんでいきました。

rawデータ

↓ 整形テーブル

↓ 決済別ビュー

↓ 売上突合ビュー

↓ 不一致ビュー

↓ 最終集計

例えば

• 売上テーブル
• 入金テーブル
• 返金テーブル
• テレオペ修正データ

などを取り込みます。

その上で

• 決済方法別ビュー
• 売上一致ビュー
• 売上不一致ビュー
• 未入金ビュー

などを作成します。

最終的には テーブルとビューが100近く になりました。

---

BigQueryでも計算に10分以上かかった

このような構造になると、集計処理も重くなります。

開発中は

• 小さな処理：5分
• 全体集計：10分以上

という計算時間がかかりました。

そのため

SQL修正 ↓ 実行 ↓ 10分待つ ↓ 結果確認

という作業を何度も繰り返す必要がありました。

さらに私は 経理担当として日常業務を行いながらプロジェクトリーダーを兼務 していたため、開発期間は長期化しました。

---

そもそも本当にシステムは必要だったのか

このシステムについて、私は開発中ずっと疑問を感じていました。

それは

費用対効果です。

例えば

開発費：1000万円
保守費：月50万円

一方、システムがない場合の誤差は

約0.5%

程度でした。

つまり

0.5%の精度 vs 大きなIT投資

という問題になります。

これは 経営者のガバナンス意識によって判断が分かれる領域 です。

---

小規模企業ではExcelの方が合理的な場合もある

売上規模が小さい企業では

Excel + RDB

で集計する方が現実的な場合もあります。

実際、過去に情報システム部が一般的なデータベースで集計を試みた際は

1年分の集計 ↓ 1か月以上

かかったこともありました。

その意味では、大量データ処理にはBigQueryのような仕組みが必要でした。

---

それでもシステム化には意義がある

一方で、システム化には別の意味で大きな意義もあります。

それは 人の仕事を減らすこと です。

毎月

売上データ ↓ 入金データ ↓ Excel突合

という作業を事務員が行う場合、それは

単純作業に近い業務

になります。

しかも

• ミスのリスク
• 担当者依存

もあります。

その意味では

データ量 + 経営者の意向

によっては、システム化は合理的な選択になります。

---

システムの正確性を証明できない問題

このプロジェクトで最後まで悩んだのが システムの正確性の証明 です。

完成したシステムのロジックは非常に複雑でした。

しかし

ロジックを理解できる人 ↓ プロジェクトリーダーのみ

という状態でした。

つまり

ロジックが正しい ↓ だから結果も正しい

という判断を 客観的に検証できる人がいない のです。

結局

• 単純ロジックの集計
• システムの集計

が 近い数字であること を確認する程度しかできませんでした。

---

本来あるべき開発体制

この経験から感じたのは、システムの信頼性を担保するには

開発 ↓ 検証

を 分離することが重要 だということです。

理想的には

外部開発会社 ↓ 社内レビュー

という体制が望ましいでしょう。

そうすることで

• ロジックの妥当性
• 出力結果の正確性

を 客観的に検証 できます。

---

EC事業者の多くが同じ問題を抱えている

当時、社長と話していて印象的だったのは

他のEC事業者も同じ問題で困っている

という話でした。

実際

• 売上
• 入金
• 返金

を完全に突合できている企業は それほど多くありません。

ECの売上管理は、見た目以上に難しい領域なのです。

---

まとめ

ECの売上・入金管理は想像以上に複雑です。

この記事で紹介したように

• 複数システムのデータ統合
• 複雑な例外処理
• ロジックのブラックボックス化
• システムの費用対効果

など、多くの課題があります。

そのため企業の状況によって

Excel運用 or システム化

の判断は大きく変わります。

重要なのは

技術ではなく、経営判断としてIT投資を考えること

だと感じています。