Embedded Accounting: Build vs Buy for Marketplaces
A scope list, a cost model with stated assumptions, and the conditions under which each answer is correct.
どのマーケットプレイスも、やがて独自の台帳システム（ledger）に行き着きます。問題は、それがコントロール機能を備えた設計されたシステムとして意図的に構築されるか、それとも3つのサービスが書き込みを行い、誰も完全に信頼していない balance カラムとして偶発的に作られるかという点だけです。
この記事は、その選択を意識的に行うためのものです。開発作業に実際に含まれる内容、自分自身を欺かずにコストを見積もる方法、そして自社開発が本当に正しい選択肢となる特定の条件について解説します。時にはそれが正解である場合もあるからです。
ここで言う「組み込み会計 (embedded accounting)」とは
組み込み会計とは、誰かが別個に開くアプリケーションの中ではなく、会計帳簿が自社プロダクトの内部に存在することを意味します。イベントが発生するとソフトウェアが仕訳を記録し、ユーザーはインターフェースに表示される内容を確認できます。月末に誰かがスプレッドシートをエクスポートして経理担当者に渡す必要もありません。
マーケットプレイスにとって、これは最低限、受け取った買い手からの支払い、売り手に支払うべき金額、得られた手数料、決済手数料、手数料および基となる供給にかかるVAT（付加価値税）、返金、チャージバック、留保金（reserves）、ペイアウト、そしてこれらすべてと銀行や決済事業者との突合（reconciliation）を網羅するものです。
自社開発する場合に実際に構築しているもの
台帳そのものはほんの一部に過ぎません。開発チームは最初の項目だけを見積もり、残りの項目を後から発見することになります。
| コンポーネント | 含まれる作業 |
|---|---|
| 仕訳帳と勘定科目 | 貸借一致の仕訳、勘定科目体系、勘定科目タイプ、期首残高 |
| イミュータビリティ（不変性） | 追記型ストレージ、取消および修正のワークフロー、インプレース編集の禁止 |
| 期間管理 | 締めの処理、ロック、遅れて到着する仕訳の拒否、監査証跡付きの制御された再オープン |
| 冪等性 (idempotency) | キー、過去のレスポンスの保存、変更されたペイロードの衝突検知 |
| 金銭処理 | 正確な小数点以下の計算または最小通貨単位での計算、通貨コード、為替レートとその取得元、端数処理勘定 |
| VATエンジン | 有効期間付きの国別税率、供給地（place of supply）、リバースチャージ、みなし供給者ルール、免税措置 |
| VAT事業者番号の検証 | 公式レジストリに対する検証、キャッシング、タイムスタンプ、リクエスト識別子、失敗時の手動レビューキュー |
| 帳票類 | 請求書、クレジットノート、シリーズおよび年ごとの連続した番号付与、PDFレンダリング、配信 |
| 電子インボイス | EN 16931 UBLなどの構造化フォーマット、および義務付けられている国における国内フォーマット |
| 銀行データの取り込み | 取引明細のインポートまたは同意に基づく銀行接続、すでにインポートされた取引の重複排除 |
| 突合 (reconciliation) | マッチング規則、スコアリング、部分一致、人間が解決できる例外処理 |
| ペイアウト | 支払いファイル生成、ペイアウトのバッチ処理、ペイアウトと元となる明細との紐付け |
| レポート | 試算表、貸借対照表、損益計算書、キャッシュフロー、VATサマリー、滞留債権 |
| 税務台帳と申告書 | 管轄官庁が受け付けるフォーマットでの、各国の要件に応じた書類 |
| 監査 | アクター、アクション、エンティティ、および変更内容そのもの（すべての変更についてクエリ可能） |
| 保管とエクスポート | OSS記録の10年間の保存、完全なデータエクスポート、証拠能力のあるアーカイブ |
チームが「台帳を自社で作ろう」と言うときに頭に思い浮かべるのは、この17行のうちおよそ2行分に過ぎません。
正直なコスト試算
この金額はチームによって異なるため、以下の内容は見積もり額というよりは手法として捉えてください。上記のコンポーネントを取り上げ、自社チームのベロシティに基づいてそれぞれにエンジニア・週（engineer-weeks）単位の規模を割り当て、その上で通常の見積もりが見落としがちな3つの補正を適用します。
補正1: コンプライアンス関連のコンポーネントは一度きりの作業ではない。 税率、閾値、フォーマットは変更されます。また、EUの「デジタル時代のVAT (ViDA: VAT in the Digital Age)」パッケージにより、期日付きの義務が生じます。2027年1月1日からのOSSおよびIOSSの変更、2028年7月1日からのプラットフォームルールの拡大、2030年7月1日からの国境を越えたデジタル報告などがその例です。自社開発するということは、これらの移行作業のすべてを自ら引き受けることを意味します。
補正2: 正確性を維持するための作業は、機能開発よりも長く続く。 初版はハッピーパス（正常系）を処理します。ロングテールとなるのは、ペイアウト後の返金、部分返金、数週間遅れて到着するチャージバック、通貨の端数処理、重複するウェブフック、そして自社の記録と一致しない決済ファイルです。ここで開発スケジュールが見えなくなっていきます。
補正3: 会計士はレビュアーではなくステークホルダーである。 経理のプロが承認しない帳簿は未完成であり、そのフィードバックは開発の終盤になってから届きます。
有用な妥当性確認の方法として、最小限の信頼できる自社開発（台帳、修正機能、期間のロック、冪等性、金銭処理、1カ国のVAT、請求書、銀行からの取り込み、マッチング、基本レポートセット）のコストを算出し、従量課金制サービスの年間費用と比較してみましょう。Nordletの公開されているプランは、3,000リクエストが含まれて月額10ユーロから始まり、200,000リクエストで月額300ユーロとなっています。もし自社開発のコストが1人分のエンジニア年俸の端数程度であれば、それは自社開発を正当化する確かな根拠になります。しかし、複数年分のエンジニアの人件費に加え、永続的なメンテナンスコストがかかるのであれば、比較になりません。そして、ルールが変わるたびにその差はさらに広がっていきます。
自社開発が本当に正しい場合
3つのケースがありますが、どれも現実のものです。
台帳が自社のプロダクトそのものである場合。 決済プラットフォーム、バンキングプロダクト、あるいは並行処理における残高挙動が差別化要因となるウォレットを構築している場合、台帳はコアであり自社で所有すべきです。ゼロからのスクラッチ開発ではなく台帳インフラ製品の導入を検討しつつ、法定会計は別系統として分離しておきましょう。
自社のビジネスモデルが既存のどの会計システムにも適合しない場合。 マルチパーティの条件付き分配、段階的なマイルストーン付きエスクロー、複雑な留保金ポリシーなど、一部のマーケットプレイスには本当に特殊な決済構造が存在します。どの製品もそれをモデル化しておらず、ワークアラウンド（回避策）が自社開発よりも厄介である場合は、自社開発してください。
取引量が膨大であるため従量課金制が適さない場合。 極端なレベルの取引量に達すると、リクエストごとの課金は魅力がなくなります。「極端」の基準はほとんどのプラットフォームが到達する水準よりも高いため、思い込む前に実際の数値でシミュレーションを行ってください。
購入が正しい場合
会計業務が必要であるものの差別化要因ではない場合（多くの場合はこれに該当します）、購入が勝利します。仕訳がエレガントであるという理由でマーケットプレイスを選ぶ人はいません。帳簿が間違っているときにだけ、人々はそれに気づきます。
また、義務の対象国が複数ある場合も、購入が正しい選択肢です。国ごとのVATルール、エビデンスの保持、電子インボイスの義務化は永続的なメンテナンス作業となりますが、ベンダーはすべての顧客にわたってその労力を分散させることができます。Nordletは、VIES検証、OSSおよびIOSSの申告計算、iSAFレジストリ、Peppol向けEN 16931 UBLを備えた国別EU VAT機能を、スケジュールを組むプロジェクトとしてではなく、製品の一部として提供しています。
多くのチームが行き着く中間的なアプローチ
現実的な答えは、通常、二者択一ではありません。「台帳は購入し、ワークフローは自社で構築する」というものです。
会計バックエンド側が仕訳、税務処理、帳簿書類、期末締め、監査証跡を管理します。一方、プロダクト側はユーザーが目にするすべての要素と、マーケットプレイス特有のビジネスルール（いつ資金が解放されるか、留保金ポリシーとは何か、紛争がどのように処理されるか、セラーダッシュボードに何が表示されるか）を管理します。お金がコミットされる瞬間に会計APIを呼び出し、自社固有の部分を手元に残します。
この境界線は、代替案よりも優れた変更耐性を持ちます。新しい国を追加する場合でも、プロジェクトではなく設定の追加で対応できます。新しいペイアウトポリシーはベンダーへの依頼ではなく、自社のコードとして実装できます。
コミットする前に決定すべきこと
- 台帳は差別化要因か、それとも単なる義務か？ 正直に判断してください。ほとんどの場合は義務です。
- 対象国は何カ国で、それぞれどのような要件があるか？ 税率のみか、申告や台帳が必要か、あるいは提出まで求められるか。
- 修正処理の仕組みはどうなっているか？ ペイアウト後の返金や遅れて到着するチャージバックは、設計の脆弱性を露呈させるケースです。
- 誰が帳簿に署名するか？ 設計が固まった後ではなく、固まる前にその人物を関与させてください。
- 10年間の保管計画はどうなっているか？ OSSの記録は取引年の年末から10年間保管する必要があり、アーカイブとは単なるバックアップではなくシステムそのものです。
- 3年後の移行はどうなっているか？ どちらの方向であっても同様です。初日にテスト用のエクスポート機能を構築し、常に機能し続けるように維持してください。
FAQ
マーケットプレイスの台帳構築にはどれくらい時間がかかりますか？
貸借一致の仕訳を計上する初期バージョンであれば、数週間で稼働させることができます。しかし、ペイアウト後の返金、遅れて到着するチャージバック、複数通貨の端数処理、重複するプロバイダのウェブフック、期末締め、そして会計士が受け入れる監査に対応するバージョンとなると、はるかに長い時間がかかり、メンテナンスは終わりません。本番運用とはまさにそのことを意味するため、2つ目のバージョンを前提として見積もってください。
最初は balance カラムから始めて、後から移行することはできますか？
可能ですし、実際にそうするチームも多くありますが、移行作業は元の構築よりも困難になると計画しておいてください。変更可能な残高から過去の履歴を再構築することは、それを変更したすべてのイベントを記録していた場合にのみ可能です。つまり、それは最初から台帳を持っていた場合にしかできないということです。
組み込み会計APIは経理チームの代わりになりますか？
いいえ。手動での記録や突合の作業をなくすものですが、依然として誰かが月次締めを行い、例外処理を確認し、判断を下し、申告を行う必要があります。
台帳がイミュータブル（不変）である場合、GDPRとの関係はどうなりますか？
金銭的ファクトおよび仮名化された参照情報はイミュータブルな記録に保持し、個人情報は独自の保持および削除プロセスを持つ別個のシステムに保持します。イミュータブル性が適用されるのは財務イベントに対してであり、それに付随するすべての属性に対してではありません。
オープンソースの会計ソフトウェアは中間的な選択肢になりますか？
現実的な選択肢ではありますが、コストをなくすのではなく形を変えるだけです。ホスティング、アップグレード、国別のローカライズ、コンプライアンスのアップデートをご自身で引き受けることになります。ライセンス費用の節約を全体のコスト削減と捉える前に、それらのコストを試算してください。