メルペイ 会計システム概要と歴史

Merpay Tech Talk 〜メルカリグループ全体を支える決済基盤全容 [会計編]〜
https://mercari.connpass.com/event/404444/

Transcript

1. 会計システムの概要と歴史 Merpay Tech Talk 〜メルカリグループ全体を支える決済基盤の全容 [会計編]〜 @mewuto 1
2. mewuto みゅーと メルペイ所属 Payment & Customer Platform Accounting team Product Engineer 学生時代、同チームに2度のインターンを経て、 2025年4月に新卒入社し、グループ全体の会計基 盤の開発・運用をしています Twitter: @mewuto 2
3. 目次 1 なぜ会計システムが要るか 2 会計システムとして必要な要件 3 メルペイの現在地 4 課題、これから 3
4. なぜ会計システムが要るか 上場企業の会計要件と会計システムに必要な要件 4
5. 上場企業の会計要件 投資家に届く財務情報を守る 3 つの制度 期限厳守 有価証券報告書： 3 か月以内 決算短信：45 日以内 内部統制 (J-SOX) 経営者が自己評価 内部監査が継続チェック → システムの全変更に証跡 = 社内で正しく作る 外部監査 会計監査法人が独立チェック • • 財務諸表監査 内部統制監査 = 第三者の保証 ※ 上場企業だけ気をつければ良いというものではない → 付録 出典: 金商法 / EDINET / 東証 TDnet 5
6. 会計システムとは？ Subledger と GL の役割分担 会計システムの目的：「財務三表 (損益計算書,貸借対照表,キャッシュフロー計算書 ) = 会計データ」の作成 ⭐Subledger General Ledger 社内のお金の移動・価値の移動を記録 ・1 取引ごとの明細を記録 ・任意時点の残高を再計算できる ・監査の追跡証跡 (audit trail) 集約 弊社の台帳サービス + 帳簿サービス2つ 合わせてSubledgerの役割をカバー ・勘定単位で集約 ・期末決算 ・監査対応 ・GAAP / IFRS 例: NetSuite, Freee会計 (会計 ERP) 経費 6
7. 単式簿記と複式簿記 単式簿記 — 家計簿風 複式簿記 — 仕訳帳風 日付 内容(メモ) 変動 残高 借方科目 金額 貸方科目 金額 7/1 期首 — 10,000 食費 500 現金 500 7/2 xxx -500 9,500 内容は自由記述 • • 借方 (Dr, Debit) = 価値の行き先 (to) 貸方 (Cr, Credit) = 価値の出所 (from) → 両方書かれ , Σ(Dr)=Σ(Cr) をシステムが保証 メルペイを含む金融・Fintech はすべて複式簿記 なぜ単式ではだめなのか？ 7
8. 単式簿記がシステム上詰む 3 つの理由 観点 単式簿記 複式簿記 + 業界標準 ① 検知 ミスに気付けない Σ(借)=Σ(貸) を自動 check → 成立しなけれ ば reject ② 原子性 2 record を別々に書く → 中断でズレ る 1 record にまとめて書き込み ③ 因果関係 対の紐付けは外付け ID 頼み スキーマレベルで対を定義 8
9. 会計システムとして必要な要件 Stripe / Uber / Airbnb等が独立に到達したプラクティス 1 書き込み時に Dr, Cr両方の指定を強制 2 append-only 3 業務と会計の分離 4 リコンサイル 参考 Ledger: Stripe’s system for tracking and validating money movement Uber’s Finance Computation Platform Tracking the money — Scaling financial reporting at Airbnb 9
10. メルペイの現在地 第 1 世代 → 第 2 世代 → 第 3 世代 10
11. メルペイの 3 世代マップ 2017 第 1 世代 • • 2024〜 2019 第 3 世代 第 2 世代 本番 DB を直接クエリ 独立会計DBへ仕訳 任意時点の残高が 再計算できない Subledger 要件を満たす 残高移動とセットで 会計イベントを発火 プロダクト側は決済だけ 送れば済む 各世代は「前世代の何を治したか」で並ぶ 共通テーマ：業務データと会計仕訳を切り離す + append-only に近づける 11
12. 第 1 世代 (廃止進行中 ) • • 業務データ（メルカリの取引データ）を直接クエリするMS 「Append only」、「業務と会計の分離」に違反 Transaction 金額 ステータス 日付 1000円 progress 9/19 Update 1500円 Update “Done” Update 8/31 12
13. 第2世代 会計データフロー 上流プロダクト MS 決済命令 決済MS Pub/Subで 会計仕訳を投げる 残高移動命令 残高・台帳MS 会計仕訳が登録されている か、リコンサイル APIを叩く 帳簿MS 第2世代 13
14. 第 2 世代 (2019 年～) Subledger 要件を満たす Good • • • 会計専用DB Bad • Pub/Subベースの連携(非同期) かつ、決済と会計イベントの送信 が互いに独立 • 仕訳情報の管理の手間 Append Only リコンサイル → 次スライド 14
15. 第 2 世代 (2019 年～) Bad point 1 件の取引完了 (総額 1,000 円、支払いは 3 手段に分散) → 会計イベントとして独立 3 events が必要 # 支払手段 金額 借方(Dr) 貸方(Cr) Event 1 ポイント 300 円 販売者売上 300 買い手ポイント 300 Event 2 残高 500 円 販売者売上 500 買い手残高 500 Event 3 送料 (残高払) 200 円 送料売上 200 買い手残高 200 = 3 独立 event × 1 pair、atomic 保証なし pain: • 上流 MS が 3 events を別々に発火 (会計知識が上流に漏れる ) • Event 2 だけ失敗すると お金の移動と記帳がズレる → 人間が気付いて手動修正オペが発生 • 1 usecase を 1 event で書けない 15
16. 第3世代 会計データフロー 第2世代との比較 上流プロダクト MS 決済命令 決済MS 残高移動命令 残高・台帳MS リコンサイル 第 3 世代 残高移動と セットで投げる 帳簿MS 第2世代 帳簿MS 第3世代 16
17. 第 3 世代 (2024 年～) Good • • 残高移動と会計の連携 DBスキーマの改善 ◦ Bad • • 全接続点Reconcile 経理にシステム理解の負荷 お金の移動(from → to)を構 造的に記録 17
18. 第 3 世代 の階層モデル : 1 event で複数対を束ねる 1 会計イベント： 1 件の取引完了 (総額 1,000 円、支払いは 3 手段に分散) │ ├─ Item A：ポイント支払 300 円 │ └─ 借方 ポイント消費 300 / 貸方 販売者売上 300 │ ├─ Item B：残高支払 500 円 │ └─ 借方 顧客残高 500 / 貸方 販売者売上 500 │ └─ Item C：送料 200 円 (残高支払) └─ 借方 顧客残高 200 / 貸方 送料売上 200 仕訳化 3 Items × Dr/Cr = 6 仕訳レコードを全部まとめて 1 Spanner transaction で atomic に書き込 み → 途中失敗 (Item A は書けたが Item B で落ちた…) は構造的に発生しない 18
19. 課題、これから 19
20. 課題、これから ⭐単式管理の残存 全接続点 reconcile 経理業務の改善 第 1 世代の単式取引テーブル 台帳サービス (旧版) 単式記帳 現状：会計サービス直前上流の み 無数 ex. 新規ビジネス要件に関する 会計論点の整理 → 新版 (複式) への統合を継続 目標：処理追跡系でプロダクト層 → 決済 → 台帳 → 会計サービスを 横断照合 FDE, PdEな動き方が求められ る 20
21. 付録 21
22. Synapse社のインシデント • Synapse 経営破綻 (2024-04) ◦ fintech に銀行機能 + 台帳管理を SaaS で貸す会社 顧客資金は提携銀行の合算口座 (複数顧客をまとめて預入れ) • Synapse 側で内訳の台帳管理 • ずさんな台帳管理により、口座内の顧客の残高内訳を計算できなくなった • 口座凍結 → 10 万人超が預金アクセス不能 • 出典: CNBC 2024-06-07 「Synapse bankruptcy trustee says $85 million of customer savings is missing」 22