Double-Entry Ledger APIs for Marketplace Accounting

A technical guide to how immutable double-entry ledger APIs work, why marketplaces need them, and what to look for when embedding accounting into your platform.

ほとんどのマーケットプレイスは、同じような経緯で会計上の課題に直面します。財務担当者が新たに入社し、ペイアウト（出金）のスプレッドシートを開いて、買い手が支払ってから資金がプラットフォームのアカウントから移動するまでの間、セラー（出品者）に対する債務を実際に誰が記録しているのかと尋ねるのです。エンジニアリングチームは transactions テーブルを指し示しますが、財務担当者はイベントのテーブルは帳簿ではないと指摘します。イベントデータと実際の会計の間に生じるこのギャップを埋めるために構築されたのが、複式簿記（double-entry）の帳簿 API です。

これは、規制面でも重要な意味を持つ技術的な問題です。マーケットプレイスは他者の資金を預かり、複数の管轄区域にまたがって VAT（付加価値税）を計算し、セラーに代わって請求書を発行します。自社開発のトランザクションテーブルでこれを運用することは可能ですが、監査法人、税務当局、あるいは慎重な買い手から証明を求められるまでの話です。

複式簿記の帳簿 API とは何か

複式簿記の帳簿 API とは、HTTP 経由で公開されるプログラマブルな会計エンジンです。プラットフォームが記録するすべての財務イベントは、貸借が一致した仕訳として書き込まれます。すなわち、勘定科目表（chart of accounts）内の指定された勘定科目に対して、合計額が等しい少なくとも 1 つの借方（debit）と貸方（credit）が記録されます。API は書き込み時にこの貸借一致を強制し、後から密かに編集できないようにエントリを保存します。

「複式」の部分は、すべての取引が少なくとも 2 つの勘定科目に影響を与えるという 400 年の歴史を持つ会計規則を指します。「API」の部分は、人間の簿記係ではなく、プロダクトが呼び出し元であることを意味します。「イミュータブル（変更不可）」の部分は、履歴を編集するのではなく、逆仕訳（reversing entry）を通じて修正を行うことを意味します。これら 3 つの特性が組み合わさることで、結果として作成される帳簿は単に整然としているだけでなく、監査に対応可能なものとなります。

実用的な定義は以下の通りです：

複式簿記の帳簿 API は、アプリケーションから財務イベントを受け取り、定義された勘定科目表に基づいてそれぞれをバランスの取れた仕訳に変換し、それらのエントリをイミュータブルに保存し、結果として得られる総勘定元帳（ledger）、試算表（trial balance）、および財務レポートを予測可能なエンドポイントを通じて公開します。

Nordlet はまさにこのアイデアを中心に構築されています。API としてのリアルな帳簿であり、元帳、VAT ロジック、請求書発行、および消込（reconciliation）のすべてに、プロダクトがすでに通信している同じ一連のエンドポイントからアクセスできます。

マーケットプレイスが特にこれを必要とする理由

単一のマーチャントを対象とした SaaS であれば、1 日に 1 回、一般的な会計ツールと同期させることで事足りる場合がよくあります。しかし、マーケットプレイスでは 3 つの理由からそれが通用しません。

第 1 に、マーケットプレイスは資金のやり取りの中心に位置しています。買い手がプラットフォームに支払い、プラットフォームが資金を保有し、その後手数料を差し引いた金額をセラーに支払います。これらの一連の移動はそれぞれ、現金、セラー未払金、プラットフォーム売上、未払 VAT、返金引当金など、異なる勘定科目に影響を与える明確な会計イベントです。status カラムを持つ payments テーブルでは、これを捉えきれません。

第 2 に、複数の税務管轄区域にまたがって事業を展開しています。リトアニア、ドイツ、ポーランドにセラーを抱え、ブロック全体に買い手を抱える EU のマーケットプレイスは、取引ごとに正しい VAT 処理を適用し、VIES（VAT 情報交換システム）に対してセラーの VAT 番号を検証し、各地域の当局の要件を満たす申告書を作成しなければなりません。これをアプリケーションコード内で正しく実装し、さらに別の会計システムと突合することは、ほとんどのマーケットプレイスが密かに破綻する原因となります。

第 3 に、手作業の簿記には取引量が多すぎます。月間 1 万件の注文を処理するプラットフォームでは、数万件の仕訳が発生します。これをエンドツーエンドで自動化しなければ、財務チームが成長のボトルネックになってしまいます。

API の仕組み：ステップバイステップ

そのメカニズムは、響きほど突飛なものではありません。マーケットプレイスの注文における一般的なフローは以下の通りです。

1. プラットフォームが財務イベントを発行する。 買い手がチェックアウトを完了します。バックエンドから元帳 API に対して、注文 ID、買い手、セラー、グロス金額、VAT 率、プラットフォーム手数料、通貨、およびべき等性キー（idempotency key）などを送信します。

2. 元帳が仕訳を構築する。 API はそのイベントを借方と貸方に変換します。単純なマーケットプレイスの販売の場合、入金中現金口座の借方計上、正味額に対するセラー未払口座の貸方計上、手数料に対するプラットフォーム売上口座の貸方計上、そして税額部分に対する未払 VAT 口座の貸方計上が行われます。すべて貸借が一致し、アトミックに計上されます。

3. エントリがイミュータブルに書き込まれる。 計上されたエントリには識別子とタイムスタンプが付与され、編集はできなくなります。何か問題がある場合は、逆仕訳と修正仕訳を投稿します。監査証跡（audit trail）こそが重要な点です。

4. 下流のレポートがリアルタイムで更新される。 試算表、セラー未払残高、VAT サマリー、損益計算書（P&L）に新しいエントリが即座に反映されます。夜間バッチ処理、エクスポート、数字が「確定する」までの消込期間は存在しません。

5. Webhook がシステムに通知する。 sale_invoice.paid や bank_transaction.matched などのイベントがエンドポイントに発火するため、プロダクト側でポーリングを行わずにリアクションできます。べき等性キーとの組み合わせにより、ネットワークの不具合時にリトライを行っても安全であり、重複が紛れ込むことはありません。

重要な設計上のポイント：元帳は財務的に何が起きたのかについての信頼できる情報源（シングル・オブ・トゥルース）となります。アプリケーションデータベースはプロダクトの状態についての信頼できる情報源です。元帳はアプリケーションのイベントから書き込まれるため、逆ではなく、これら 2 つのシステムは整合性を保ちます。

設計作業の大部分が行われる勘定科目表

マーケットプレイス向けの元帳を設定する際の知的な労力のほとんどは、勘定科目表の作成に費やされます。これは、借方と貸方が着地する名前付きのバケットのリストです。銀行ごとの現金口座、セラー未払口座（多くはセラーごとに 1 つ、またはサブ元帳を持つ 1 つの集約口座）、カテゴリ別のプラットフォーム売上、国別の未払 VAT、返金引当金、チャージバック引当金などが含まれます。

マーケットプレイス全体で共通して見られるいくつかのパターン：

セラーの資金は売上ではなく、負債である。 セラーに代わって保持する資金は未払金です。これを売上として扱い、後からペイアウトを「経費処理」することは、デューデリジェンスで必ず発覚する典型的な間違いです。
VAT は国ごとの個別の負債である。 EU の複数の管轄区域で事業を展開する場合、申告書が明確に対応付けられるよう、国ごとに個別の未払 VAT 口座を用意するのが望ましいです。
手数料は支払時ではなく、獲得した時点でモデル化する必要がある。 ここでは発生主義会計（accrual accounting）が必須となります。
返金、チャージバック、および紛争には、それぞれ独自の勘定科目が必要である。 これにより、損益計算書（P&L）がプラスとマイナスの売上の混乱ではなく、現実を反映したものになります。

優れた元帳 API を使用すれば、この構造を一度定義して信頼を持ってそれに投稿することができ、チェックアウトコード内で会計ロジックを再発明する必要がなくなります。

イミュータブル性、期間ロック、そして監査法人が気にする理由

イミュータブル（変更不可）という言葉はデータベースの細部のように聞こえますが、実際には、監査法人がサインする帳簿になるか、そうならないかの違いを意味します。

マーケットプレイスが前四半期の仕訳を密かに編集できる場合、会計学的に言えば前四半期の数値は「知り得ないもの」になります。イミュータブルな元帳は、歴史は歴史であるというルールを強制します。修正は修正として可視化されます。期間ロック（period locking）はこれを拡張したもので、一度月が締められると、明示的な再オープンアクション（それ自体がログに記録されます）なしには、その期間に新しいエントリや編集を行うことはできません。

将来的に資金調達を計画している、買収される、または税務監査に直面するプラットフォームにとって、これは「あれば便利」なものではありません。帳簿を防御可能なものにするための必須条件です。Nordlet の元帳はデフォルトでこの設計になっており、イミュータブルな複式簿記の構造と期間ロックが後付けではなく組み込まれています。

EU VAT：エンジニアリングの時間を奪う領域

ほとんどのマーケットプレイスの会計プロジェクトが難航するのが VAT です。「パーセンテージを適用する」という単純なものではありません。買い手がどこにいるか、セラーがどこにいるか、何を販売しているか、セラーが VAT 登録しているか、2021 年の電子商取引ルールに基づいてマーケットプレイスがみなし供給者（deemed supplier）に該当するか、そしてどの報告制度が現地で適用されるかによって異なります。

EU 向けの実用的な元帳 API は、少なくとも以下の処理を処理します：

セラーおよび買い手の VAT 番号の VIES 検証（理想的には結果がキャッシュされ、取引にスタンプされる）
軽減税率や免除を含む、国別の VAT 率ロジック
リトアニアの申告のための i.SAF 登録の生成、および他の加盟国で要求される場合は同等の構造化出力
義務化が進む電子請求書発行の管轄区域向けの Peppol BIS 3.0 電子インボイス
クロスボーダーの B2C 販売向けの OSS/IOSS の処理

これをアプリケーションコード内で国ごとに実装することは、ルールが変わり続けるため、終わりが見えないフルチーム分のエンジニアリング作業になります。これを元帳レイヤーに押し出すことが、現実的な選択となります。

時間の節約を実感できる消込（Reconciliation）

元帳が信頼できる情報源となれば、銀行の消込は毎月の苦行ではなくなります。銀行のステートメントが取り込まれれば、元帳側ですでに何が存在すべきかを把握しているため、マッチングは大部分が自動化されます。

現実的なレベルとしては「手作業がゼロになる」わけではありません。「例外が表面化する」ということです。きれいにマッチする 90% の取引に対するワンクリックの消込フローと、人間の判断を必要とする 10% のキューの組み合わせが、適切に設計された消込 API が提供するものです。スマートな決済マッチングは、人間がケースごとにルールを書くことなく、一部入金、過剰入金、および複数の請求書をカバーする決済を処理します。

サプライヤーやセラーへのペイアウトのための SEPA エクスポート（pain.001 フォーマット）により、出金側の処理が完結します。プロダクト内でペイアウトを承認すると、元帳が SEPA ファイルを生成し、銀行がそれを処理し、結果として生じる資金移動が自動的に消し込まれます。

自社開発 vs 外部サービス利用 vs 組み込み

マーケットプレイスのチームは通常、3 つの選択肢を検討します。重要な軸で比較すると以下のようになります。

アプローチ	本番稼働までの時間	監査対応力	EU VAT の処理	プロダクトへの統合
元帳の自社開発	12〜24ヶ月以上	チームに完全に依存	国ごとに自社で構築	はい
Xero / QuickBooks との同期	数週間	会計面では良好、マーケットプレイス特有のフローには弱い	部分的、アドオンが必要	いいえ、別のツールに存在
元帳 API の組み込み（例：Nordlet）	数週間	イミュータブルな元帳と期間ロックにより標準装備	VIES や i.SAF を含め EU 向けに標準装備	はい、API と SDK 経由

会計が自社のプロダクトそのものである場合は、自社開発を正当化できます。それ以外の企業にとっては、コストパフォーマンスが合うことはめったにありません。従来の会計ツールとの同期は単一企業規模のビジネスには機能しますが、マーケットプレイスのフロー、すなわち分割払い、セラーのサブ元帳、国ごとの VAT、みなし供給者シナリオなどでは破綻します。1 つの企業の帳簿向けに設計されたツールには、これらはうまくマッピングされません。

API ファーストの元帳を組み込むことが、現代の多くのプラットフォームが収れんしつつあるアプローチです。帳簿はプロダクトの体験内部に存在し、セラーは独自の財務データを UI上で確認でき、コンプライアンスの重労働はインフラストラクチャレイヤーで処理されます。

元帳 API を評価する際に確認すべきポイント

ベンダーとの打ち合わせ時に手元に置いておくと便利な短いチェックリスト：

編集可能な行ではなく、逆仕訳による修正を伴うイミュータブルな複式簿記ストレージ
ログに記録される再オープンアクションを伴う期間ロック
すべての書き込みエンドポイントにおけるべき等性キー
ポーリング API だけでなく、プロダクトがリアクションする必要があるイベントのための Webhook
チームが実際に使用している言語での型付き SDK
VIES、i.SAF または同等のもの、および OSS/IOSS を含む国別の VAT ロジック
複数の法人を運営している、または予定している場合のマルチカンパニー（複数企業）サポート
開発者、会計士、閲覧者を区別するのに十分な粒度のロールベースアクセス制御
大規模なレポートの準備が完了した際の Webhook 通知を備えた、XLSX、PDF、および JSON でのレポートエクスポート
機能を削ぎ落としたデモではなく、本番環境の動作をミラーリングするサンドボックス

技術的な打ち合わせでベンダーが最初の 3 つを実演できない場合、残りは重要ではありません。

私が最初に行うべきこと

マーケットプレイスがゼロからこの作業を開始する場合、最も苦痛を軽減できる手順は以下の通りです：

コードを書く前に、ホワイトボード上で実際の資金の流れをマッピングする。誰が誰に、どのタイミングで、どの通貨で、どのような VAT 処理で負っているのか。
そのマップから勘定科目表をドラフトする。セラー未払金、プラットフォーム売上、国別の未払 VAT、引当金。本番投入前に会計士にレビューを依頼する。
元帳レイヤーを選択する。自社開発するか、同期するか、組み込むか。チームが実際に提供・維持できる方法について正直になる。
1 つのフローをエンドツーエンドで実装する：注文から請求書、ペイアウト、消込まで。貸借が一致することを証明し、その後スケールさせる。
最初の月が綺麗に締まったらすぐに期間ロックを有効にする。規律が蓄積されていく。

これを正しく行うチームは、元帳を単なるレポートの後付けではなく、コアインフラストラクチャとして扱います。それがパラダイムシフトであり、監査法人、投資家、税務当局との財務に関する会話を、長いものではなく短いものにしてくれる要因なのです。

FAQ

複式簿記の帳簿 API は会計システム連携と同じですか？

いいえ。外部ツールとの連携は、通常タイムラグを伴って、プロダクトからのデータを外部の会計ツールに同期させるものです。元帳 API は会計システムそのものであり、そこに直接、リアルタイムで書き込みます。この違いは重要です。なぜなら、連携機能は部分的な支払い、多通貨、マーケットプレイスの分割といった境界領域で正確性を失うからです。元帳 API はこれらをネイティブに記録します。

Stripe や Adyen のレポートをそのまま使えないのですか？

決済プロセッサーのレポートは、プロセッサーを通過した資金を伝えているにすぎません。それらは複式簿記の帳簿ではありません。まだペイアウトされていないセラーへの未払金、国ごとの VAT 債務、決済プロセッサーを介さない経費については把握していません。それらは元帳への 1 つのインプットに過ぎず、元帳の代替にはなりません。

イミュータブル（変更不可）とは、実際にはどこまで変更できないのですか？

エントリは編集できません。修正を行うには、元のエントリを参照する新しいエントリを作成します。これは技術的な決定ではなく、設計上の決定です。まともな元帳であれば、これを強制します。「銀行口座と一致させるために編集した」という事実こそが、帳簿を信頼できないものにする典型的なパターンであるためです。

EU 以外のマーケットプレイスの場合はどうなりますか？

複式簿記のメカニズムは普遍的ですが、税務ロジックはそうではありません。EU の VAT に特化した元帳 API は EU 中心の運用をうまく処理し、EU 外の取引もサポートできますが、主要市場が米国の売上税やラテンアメリカの電子インボイス制度である場合は、導入を決定する前に特定のコンプライアンス対応範囲を確認してください。

実装には実際どれくらいの時間がかかりますか？

クリーンなイベントモデルを持つマーケットプレイスであれば、元帳 API の組み込みからエンドツーエンドで 1 つのフローを実行するまで、通常は数週間のエンジニアリングで完了します。過去データを含めたレガシー設定からの完全な移行には、より時間がかかります。変動要因は、API 自体ではなく、既存データの状態であることがほとんどです。