マーケットプレイス向け複式簿記台帳（ダブルエントリーレジャー）APIとは

複式簿記台帳APIは、マーケットプレイスの資金移動をバランスのとれた変更不可能な仕訳として記録し、誰にどのような理由でいくらの支払い義務があるかを常に把握できるようにします。

マーケットプレイスの orders テーブル上の数値が健全に見えていても、実際の資金状況とは乖離している場合があります。注文データには「支払済み」と記録され、セラー（出品者）のダッシュボードには残高が表示されています。しかし、そのテーブルのどこを見ても、プラットフォームが実際に保有している現金、各セラーに対する未払金、売上手数料の正確な金額、そして納税が必要な消費税額を証明することはできません。このような財務上の結果を、1件ずつバランスの取れた取引として正確に記録するために存在するのが、複式簿記台帳（ダブルエントリーレジャー）APIです。

分かりやすく言えば、複式簿記台帳APIとは、プログラムで操作可能な会計システムです。アプリケーション側から決済の確定や出金の承認といった財務イベントを送信すると、台帳側でそのイベントを勘定科目に基づいた借方と貸方が同額の仕訳として記録します。このAPIは資金を実際に移動させるものではなく、別の場所で移動した資金に関する真実を記録します。

ここでいう「複式簿記台帳」の意味とは

台帳（レジャー）とは、最新の残高を保持する単なるテーブルではなく、勘定科目の変動履歴の記録です。実用的な台帳には、次の3つの相互に関連する概念があります。

勘定科目（Account）: 決済代行会社の未収金、セラーへの未払金、売上手数料、未払消費税などの名前が付けられた財務上の位置づけ。
取引／仕訳（Transaction / Journal）: 複数のバランスの取れた行を含む、1つの不可分の財務イベント。
エントリ／明細（Entry / Posting）: その取引内における個別の借方または貸方の行。

あらゆる設計の根底にある不変の原則は単純です。それは、すべての取引およびすべての通貨において、借方の合計と貸方の合計が常に一致するということです。台帳APIは通常、ストレージに保存される前に、貸借不一致の書き込みを拒否します。Modern Treasury社のドキュメントでは、レジャー取引には2つ以上の勘定科目が関与し、同額の借方と貸方がそれぞれ少なくとも1つずつ存在することが定義されており、記帳済みの取引は変更不可として扱われます。

複式簿記とは、必ずしも「行数がちょうど2行である」という意味ではありません。マーケットプレイスでの1回の売上には、通常1つの借方と複数の貸方が必要になります。これが、最も誤解されやすいポイントです。

マーケットプレイスに決済テーブルだけでなく台帳が必要な理由

マーケットプレイスでは、複数の財務上の関係が同時に発生します。購入者が支払いを行い、決済代行会社がそれを決済し、プラットフォームが一時的に資金を管理する場合もあります。セラーはその一部を獲得し、プラットフォームは手数料を差し引き、税金が発生し、リザーブ（留保金）が差し引かれることもあります。その後、出金によって資金が移動し、返金やチャージバックによってその一部が相殺されます。

payments テーブルがあれば注文の商用ステータスは分かりますが、次の項目を確実に把握することはできません。

決済代行会社の未収金や現金の正確な額
各セラーに対する未払金の額
プラットフォーム自身の売上高
どの国でいくらの消費税（VAT）の納税義務が発生しているか
返金や紛争に備えていくら留保されているか
出金によって適切なセラーに対する債務が減少したか
決済代行会社の清算額がプラットフォームの予想と一致しているか

Nordletのマーケットプレイス会計における複式簿記台帳APIガイドでは、明確な線引きを示しています。つまり、アプリケーションのテーブルは商品の状態を表すものであり、台帳はその状態がもたらす財務的影響を記録するものであるということです。また、決済代行会社のレポートは完全な複式簿記の帳簿そのものではなく、あくまで突合のための入力データに過ぎないという点も、繰り返し言及する価値があります。

マーケットプレイスの売買取引の具体例

購入者が100ユーロ支払い、セラーが85ユーロを受け取る権利があり、プラットフォームの手数料が15ユーロである場合を想定します。分かりやすくするため、消費税と決済手数料は無視します。

勘定科目	借方	貸方	理由
決済代行会社未収金	100ユーロ		決済代行会社が確定した決済額をプラットフォームに支払う義務
セラー未払金		85ユーロ	プラットフォームがセラーに支払う義務
売上手数料		15ユーロ	プラットフォームが獲得した手数料
合計	100ユーロ	100ユーロ	貸借一致

ここで重要な分類は、セラーに対する85ユーロの支払いはプラットフォームの売上ではなく、負債であるという点です。IFRS（国際財務報告基準）の概念フレームワークにおいて、負債とは経済的資源を移転する現在のおおもとの義務です。マーケットプレイスは、購入者がプラットフォーム経由で支払ったという理由だけで、セラーの売上総額を自社の収入として計上すべきではありません。自社が代理人（エージェント）、本人（プリンシパル）、あるいはみなし供給者（deemed supplier）のいずれの立場にあるかによって処理は異なりますが、台帳の仕組み自体は変わりません。

セラーへの出金が可能になった時点では、新たな売上は認識されません。債務の決済を行います。

勘定科目	借方	貸方
セラー未払金	85ユーロ
銀行口座または出金クリアリング		85ユーロ
合計	85ユーロ	85ユーロ

決済代行会社が清算前に3ユーロの手数料を差し引く場合、資金移動の仕訳は3行になります。銀行口座への現金が97ユーロ、処理費用が3ユーロ、そして決済代行会社未収金からのマイナス100ユーロです。財務上の位置づけのあらゆる変更には、必ず発生源（ソース）と宛先（デスティネーション）が存在します。

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

1. アプリケーションがビジネスイベントを検知する。 決済が完了し、注文が履行され、出金が承認され、返金が行われ、チャージバックが発生し、決済が着金します。データベースは引き続き業務上の状態を管理し、台帳は金銭的影響を記録します。

2. 構造化されたリクエストを送信する。 通常、イベントの種類、金額と通貨、注文または決済のID、購入者とセラーの識別子、手数料、税金データ、関連する勘定科目、有効日および記帳日、べき等性キー（idempotency key）、そして決済代行会社や商品レコードに紐づくメタデータが含まれます。Nordletの公開APIの例では、セラーID、販売タイプ、金額、通貨、VATの国・税率を含む概念的な売上リクエストが示されています。

3. APIが検証を行う。 借方と貸方が一致しているか、勘定が存在し記帳可能か、サポートされている通貨か、金額に正確な補助単位（マイナーユニット）が使用されているか、異なる結果に対してべき等性キーが再利用されていないか、期間がオープンか、必要なメタデータが含まれているかがチェックされます。検証に失敗した場合、不完全な仕訳が残ることはありません。

4. アトミック（不可分）に記帳される。 取引全体がひとまとまりとして書き込まれます。借方が記録された一方で対応する貸方の記録に失敗するような事態は決して起こり得ません。マーケットプレイスにおいて、分割された中途半端な記録は、対応する現金がない見せかけのセラー残高を生み出したり、セラーへの債務を伴わない売上手数料を計上したりする原因になります。

5. 残高とレポートが台帳から導出される。 記帳後、勘定残高、セラーの保留中および利用可能な残高、試算表、総勘定元帳の履歴、VATの集計、過去の日付時点での履歴などを読み取ることができます。セラーの残高は、変更可能なフィールドの値を鵜呑みにするのではなく、記帳データから再構築できるべきです。

6. Webhookでプロダクトに通知する。 sale_invoice.paid（売上請求書支払済み）、記帳された仕訳、出金可能額、リコンシリエーションの例外といったイベントが通知されます。これらはべき等を担保して処理してください。Webhookは通知であり、財務イベントを2回適用するための許可ではありません。APIの規約（API conventions）では、スコープ、べき等性キー、エラーの形式、Webhookの署名について詳細に解説しています。

セラー残高は単一の数値ではない

多くのマーケットプレイスが直面するトラブルの原因は、セラーの残高を1つの数値として管理してしまうことにあります。資金は次のようなステータス（状態）に分けて管理されるべきです。

ステータス	意味
保留中（Pending）	セラーが受け取る権利を持つ可能性があるが、解放条件が満たされていない状態
利用可能（Available）	出金対象となる状態
留保中（Reserved）	返金、返品、紛争に備えて差し押さえられている状態
出金済み（Paid out）	移転によって義務が決済された状態
マイナス（Negative）	返金、チャージバック、または手数料が利用可能資金を超過している状態

決済代行会社のモデルもこれに類似しています。Stripeの個別チャージと送金（Transfers）のフローでは、プラットフォームが自社アカウントで売上を受け取り、その後手数料、返金、チャージバックをプラットフォーム側の残高に反映させながら、接続されたアカウントに資金を分割送金することができます。Adyenのマーケットプレイスモデルでは、出金まで資金を保持するユーザー残高アカウントと、返金やチャージバックによるマイナス残高を吸収できる債務残高アカウントが区別されています。これらは自社の台帳モデルを構築する上で有用なインプットとなりますが、完全な会計モデルそのものではありません。

出金とセラーの収益発生のタイミングは異なる

セラーは月曜日に収益を上げ、その翌週の月曜日に支払いを受けることができます。その間には、注文の履行、留保金の設定、出金バッチの作成、手数料を差し引いた決済代行会社の清算、そして銀行口座への入金といったプロセスが存在します。台帳では、注文データを最終的な「支払済み」というステータスで上書きするのではなく、各ステージを保持する必要があります。これにより、注文の発生、セラーの受給権、決済、出金の開始、銀行入金の間におけるタイムラグを説明できるようになります。

返金とチャージバック：上書きではなく「逆仕訳」を行う

返金やチャージバックは、元の決済に紐づく新しいイベントです。変更不可能な台帳においては、元のデータを監査のために残すため、逆仕訳（リバーシング・エントリ）とその後の修正仕訳によって処理を行います。Modern Treasury社では、記帳された取引を変更不可として扱い、再試行時の重複オブジェクトを防ぐためのべき等性キーをサポートしています。

通常、返金は現金または買掛金を減少させ、セラー未払金を逆仕訳し、方針に応じて手数料の一部を取り消し、税金を調整し、返金リザーブを取り崩します。チャージバックは現金または決済代行会社未収金を減少させ、セラーまたはプラットフォームが負う金額を復活させ、紛争費用と処理手数料を記録し、留保勘定を通じて資金を移動させます。

リコンシリエーション（突合）：台帳と現実の現金の接続

台帳の貸借が内部で一致していても、現実世界の状況と一致しているとは限りません。リコンシリエーションは、内部の記録と外部のエビデンス（決済代行会社の清算レポート、銀行の明細、出金ファイル、返金および紛争の記録）を照合する作業です。

実用的なループの例：

清算データまたは銀行のバッチをインポートする。
各行を注文、決済、返金、手数料、出金、または紛争データにマッチングする。
予想される総額、控除額、留保額、純額を比較する。
確認された移動を台帳に記帳する。
マッチしなかった項目を「未決算勘定（サスペンス勘定）」に送る。
例外事項を調査する。
期間を締め切る。

Nordletのリコンシリエーションに関する資料には、まさにこのプロセスが記載されています。清算バッチのインポート、売上と返金の明細のマッチング、そして請求書を推測で処理するのではなく、マッチしない受取金をサスペンス勘定にルーティングする手法が示されています。次の2つのチェックが重要であり、どちらか一方がもう一方の代わりになることはありません。つまり、複式簿記の検証は「各仕訳が貸借一致しているか」を問い、リコンシリエーションは「それが決済代行会社、銀行、ビジネスイベントの実態と一致しているか」を問うものです。

正しく実装するための設計上の詳細

べき等性（Idempotency）。 キーを payment_captured:pi_123 のような安定したイベントに紐づけます。再試行時には、2つ目の仕訳が作成されるのではなく、元の結果が返されます。

アトミック性（Atomicity）。 1つのイベントに含まれるすべての行が同時に記帳されるか、全く記帳されないかのどちらかにします。

変更不可能性（Immutability）と逆仕訳。 記帳済みの履歴は通常の更新操作では編集できません。修正を行う場合は、元の金額、日付、分類、理由、作成者を保持したまま、紐づく逆仕訳エントリを作成します。

正確な金額（Precise money）。 バイナリの浮動小数点数は使用しません。整数の補助単位または正確な小数、明示的な通貨、および分割時の決定論的な端数処理ルールを使用します。ルールなしで100ユーロをセラーと手数料に分割すると、わずか1セントの端数によって残高が破綻します。

有効日（Effective date）と記帳日（Posting date）。 購入者が支払った日、セラーが稼いだ日、銀行が清算した日、そしてエントリが記帳された日はそれぞれ異なります。これらを混同すると、期間ごとのレポートや納税のタイミングが信頼できなくなります。

マルチカレンシー。 借方と貸方は同一通貨内でバランスしている必要があります。通貨換算には、手数料、端数処理、および為替差益・差損のための勘定科目を含む、明示的な為替レートイベントが必要です。currency フィールドを受け入れるだけで、台帳が外国為替（FX）エンジンになるわけではありません。

台帳APIが代行してくれないこと

勘定科目表（チャート・オブ・アカウント）の決定は代行しません。自社が本人（プリンシパル）か代理人（エージェント）か、手数料がいつ発生するか、決済手数料をどちらが負担するか、返金が手数料にどう影響するか、そして消費税がどのように計算され報告されるかを決定するのはユーザー自身です。Nordlet自身のガイダンスでは、まず資金の流れをマッピングし、勘定科目表の草案を作成し、会計士にレビューを依頼してから、注文から出金、リコンシリエーションに至るまでの完全な1つのフローを実装し、その後にスケールさせることが推奨されています。

税金に関する疑問の解決も代行しません。消費税は購入者とセラーの所在地、商品の種類、登録状況、みなし供給者ルールによって異なります。EU消費税（VAT）ガイドでは、エンジンが自動算出するものと、人間による確認が必要なフラグが立てられるものが定義されています。NordletのVAT対応はEUおよびEEA（欧州経済領域）に特化しているため、米国の売上税やラテンアメリカの電子インボイスには対応していません。また、返品期間が終了したかどうか、出金をブロックすべきか、決済が不正であるかといった業務上の曖昧さを解決することもありません。これらはユーザー自身が決定する事項であり、台帳はその財務的結果を記録するものです。

Nordletの位置づけ

Nordletは、変更不可能な複式簿記台帳、出金機能、EUのVAT対応、RESTエンドポイント、型付きSDK、および単一のインターフェースからアクセス可能なWebhookを備えた、プラットフォームおよびマーケットプレイス向けに構築された会計APIです。[2026-08-29時点]の製品仕様として、サードパーティのチェックアウト機能ではなく自社プロダクト内に組み込む会計機能に強みを持っています。執筆時点では、デザインパートナー向けのサンドボックスを備えたアーリーアクセス段階にあるため、このカテゴリの優れた事例として評価しつつ、自社のユースケースに向けて本番環境の成熟度、稼働時間、管轄地域のカバー範囲を事前に評価してください。

マーケットプレイスおよびプラットフォームの開発者にとって有用なメンタルモデルは、資金の物理的な移動と財務的な真実の間の切り分けです。決済代行会社が資金を移動させ、複式簿記台帳APIが「誰にいくらの支払い義務があり、いくらの売上を獲得し、どのような税金や留保金を保持しており、現実世界の帳簿と一致しているか」を記録します。

FAQ

複式簿記台帳APIは決済代行会社と同じものですか？

いいえ。決済代行会社は、支払いの承認、売上の確定、清算、および場合によっては出金を行います。一方、台帳APIは、それらのイベントがもたらす会計上の結果を記録します。ほとんどのマーケットプレイスでは、資金移動のためにStripeやAdyenのような決済代行会社を使用し、帳簿のために台帳を使用するという両者を組み合わせて利用します。

決済代行会社のダッシュボードを総勘定元帳の代わりに使ってもよいですか？

試すことは可能ですが、最終的に監査を通過できなくなります。決済代行会社のレポートには、チャージ、手数料、送金、清算が表示されますが、通常はセラーに対する完全な債務、税金負債、決済代行会社以外の経費、あるいは会計上の調整は反映されません。これはあくまでリコンシリエーションのための入力データとして扱ってください。

貸借が一致していれば、帳簿は正確だと言えますか？

いいえ。それは単にエントリが借方・貸方のルールを満たしているというだけです。完全にバランスの取れた取引であっても、間違った勘定科目、間違ったセラー、あるいは間違った税務処理で記帳されている可能性があります。バランスは必要条件であって十分条件ではありません。残りの部分をキャッチするのがリコンシリエーションです。

台帳が変更不可（イミュータブル）である場合、間違いを修正するにはどうすればよいですか？

逆仕訳エントリを投稿し、その後に正しい仕訳を追加します。元のデータがそのまま可視化される状態が維持されますが、それこそがまさに台帳の本質です。変更不可能性は監査証跡を保護するためのものであり、エラーの修正を不可能にするものではありません。

会計APIを導入すれば自動的にコンプライアンスを満たせますか？

いいえ。会計の構造を強制し、実用的な記録を作成することはできますが、法的なコンプライアンスは、管轄地域、契約上の役割、税務処理、決済規制、KYCおよびAMLのプロセス、報告義務によって異なります。