マーケットプレイス出品者の補助元帳: 売上と買掛金

マーケットプレイス会計における最も一般的な誤りは、買い手からの総支払額をプラットフォームの売上として計上してしまうことです。顧客が100ユーロ支払い、その100ユーロが決済代行会社のアカウントに着金した際、その全額を売上として起票してしまいます。しばらくの間は帳簿の貸借が一致し、売上高も好調に見えますが、ある日監査人が出品者に対する債務はどこにあるのかと尋ねてきます。その金額が未払金として一度も記録されていないため、債務は存在しないのです。

この問題の解決策は、表面的なものではなく構造的なものです。マーケットプレイスでは、最初の仕訳の段階から、以下の5つの異なる資金プールを明確に分離する台帳モデルが必要となります。それは、トランジット中の顧客の現金、プラットフォームの手数料売上、出品者買掛金、各種手数料、そして留保金（リザーブ）です。ペイアウトは、それ自体が売上や費用を発生させるイベントではなく、買掛金を決済（消し込み）する6番目のイベントとなります。本ガイドでは、これら資金プールを個別に管理するための、貸借が一致する仕訳とデータモデルについて解説します。

まずプリンシパル（本人）かエージェント（代理人）かの判断から始める

勘定科目の構成を検討する前に、プラットフォームが何を販売しているのかを定義する必要があります。ASC 606（収益認識に関する会計基準）では、これは指定された商品またはサービスごとに評価され、その結果によって売上を総額（グロス）で計上するか純額（ネット）で計上するか決まります。ある取引フローではプリンシパルとして機能し、別のフローではエージェントとして機能することもあります。

出品者の商品を販売する一般的なマーケットプレイス取引の場合、プラットフォームは通常エージェントとして機能します。プラットフォームは出品者の商品を買い手に届ける手配をしますが、在庫リスクは負わず、対価として手数料を受け取ります。DeloitteのASC 606に基づくプリンシパルとエージェントのガイダンス（principal-versus-agent guidance under ASC 606）では、判断基準の中心を「支配権（control）」に置いています。約束の履行責任、在庫リスク、価格設定の裁量はあくまで判断の指標であり、根底にある支配権の評価に優先するチェックリストではありません。

この判断を単なるメモ書きではなく台帳設計に組み込むべき理由は、その結論が下流のすべての仕訳に直結するためです。プラットフォームがエージェントである場合、出品者の取り分は発生した瞬間に負債となります。配送や保証サービスについてプリンシパルである場合、その部分はプラットフォームの売上となります。この判断結果はデータとして保持します。

• principal_agent_role（プリンシパル・エージェントの役割）
• specified_good_or_service（指定された商品またはサービス）
• commission_rule_id（手数料ルールID）
• control_assessment_version（支配権評価のバージョン）
• effective_from / effective_to（有効開始日 / 有効終了日）

2年後に純額の手数料行をレビューする担当者は、なぜ総額（グロス）ではなく純額が使用されたのかを即座に確認できなければなりません。BillingPlatformのASC 606プリンシパル対エージェントに関する解説（BillingPlatform on ASC 606 principal vs agent）が指摘しているように、「マーケットプレイス」というラベル自体が疑問を解決するわけではありません。支配権の分析こそがそれを決定します。

仕訳ルールを記述する前に出品者残高を定義する

「出品者残高」は単一の数値ではありません。出品者の生涯取引残高（lifetime balance）が健全であっても、資金が未確定であるかリザーブとして保持されている場合、出金可能な金額はゼロであることがあります。これらの状態を混同すると、出品者が出金できる金額や、プラットフォームがまだ支払うべき金額の報告に誤りが生じます。

最低限、以下の状態を追跡する必要があります。

• 保留中（Pending）: 獲得または回収されたが、まだ出金の対象となっていないもの
• 利用可能（Available）: プラットフォームのルールに基づき出金の対象となっているもの
• 留保中（Reserved）: 予想される返金、異議申し立て、またはチャージバックに備えて差し控えられているもの
• 出金済み（Paid out）: 送金された、または決済のために申請されたもの
• マイナス（Negative）: 出品者が負っている金額で、将来の売上から回収されるもの
• サスペンス（Suspense）: 受領されたが、出品者やその処理がまだ確定していないもの

決済代行会社ではすでにこの区別がモデル化されています。Stripeでは、各コネクトアカウントの残高を「保留中（pending）」と「利用可能（available）」に分離し、特定のマイナス残高に対してプラットフォームレベルの留保残高を保持しています。決済事業者がこれらを分離している場合、照合（リコンシエーション）を成立させるためには、元帳側でも同様に分離する必要があります。

勘定科目と重要なディメンション

実用的な初期構造では、クリアリング勘定、負債、売上を別々に管理し、すべての主要な仕訳において出品者ディメンションを付与します。

目的	勘定科目またはディメンション	処理
決済待ちのプロセッサ資金	決済プロセッサクリアリング	クリアリング資産
銀行口座に入金されたプロセッサ出金	銀行口座	資産
獲得済みだが未払いの出品者金額	出品者買掛金	負債
出品者レベルの詳細	seller_id ディメンション	負債の詳細（売上ではない）
プラットフォーム手数料	手数料売上	売上
付加価値税（VAT）または売上税	未払税金	負債
プロセッサ手数料	決済手数料	費用
出品者留保金	留保負債	契約条件に依存
返金	売上値引きまたは返金	当初の処理を逆仕訳
チャージバック	損失、未収金、または出品者からの回収	損失の負担者による
銀行確認待ちのペイアウト	出品者ペイアウトクリアリング	クリアリング勘定
未割当金額	サスペンス	一時的な例外処理

すべての主要な仕訳には、出品者、注文、ペイアウトバッチ、決済プロセッサ、通貨、法人のエンティティ、税務処理、イベントタイプ、外部参照、および逆仕訳のリンクを付与する必要があります。これらがない場合、出品者補助元帳は個別の残高を証明できず、総勘定元帳は総額を証明できません。

補助元帳の実装方法としては、出品者ごとに1つの負債勘定を設ける方法、seller_id をディメンションとして持つ集計買掛金勘定とする方法、あるいは買掛金・留保金・ペイアウトクリアリングに分割する方法があります。数十を超える出品者を超える規模になると、集計＋ディメンションのアプローチの方が拡張性が高くなります。資金の表示方法には資金保全規則や現地の決済規制が影響する場合があるため、会計士と相談の上でモデルを選択してください。仕訳のメカニズムについては、マーケットプレイス会計における複式簿記台帳APIを解説したマーケットプレイス会計向け複式簿記元帳APIに関する解説記事も参照してください。

出品者とプラットフォームの行を分けて売上を起票する

エージェント販売の例で考えてみます。顧客が100ユーロ支払い、プラットフォーム手数料が10ユーロ、出品者の取り分が90ユーロの場合、手数料と出品者の受給権が発生した時点の仕訳は以下のようになります。

勘定科目	借方	貸方
決済プロセッサクリアリング	€100
出品者買掛金 - 出品者A		€90
手数料売上		€10

ここで重要な点は、90ユーロが売上ではなく負債の貸方に記帳されるということです。プラットフォームは10ユーロを認識します。これは、プラットフォームが出品者の全売上額ではなく自らの手数料を認識するという、エージェントに関するASC 606のマーケットプレイスの例が到達する結果そのものです。

税金が別途徴収される場合は、税金未払金行を追加し、税務上の結論に従って出品者またはプラットフォームの金額を調整します。利便性を理由に税金を手数料や出品者買掛金に含めて処理してはなりません。

プロセッサ手数料を売上および買掛金の計算から除外する

「プラットフォーム手数料」、「プロセッサ手数料（決済手数料）」、および「ペイアウト金額」の3つは常に混同されがちです。これらは別のものであり、影響を与える勘定科目も異なります。

顧客が100ユーロ支払い、手数料が10ユーロ、プロセッサが3ユーロを差し引いた場合：

• 契約通りであれば、手数料売上は10ユーロのままとなります。
• 3ユーロのプロセッサ手数料は費用となります。
• 出品者契約に「出品者が決済手数料を負担する」と明記されていない限り、出品者買掛金は90ユーロのままです。出品者負担である場合のみ、87ユーロに減額され、対応する3ユーロが出品者に課金されます。

銀行に着金したネットの97ユーロのみを記帳すると、総売上、手数料、および費用が一度に消去されてしまいます。決済リコンシエーションの解説（payment reconciliation reference）でも同じ点が指摘されています。つまり、決済を分解し、プロセッサ手数料を費用として扱い、実際の受取純額を売上の代わりにしてはならないということです。

利用可能性、リザーブ、ペイアウトを個別のイベントとしてモデル化する

資金は、キャプチャ（売上確定）から決済完了までの間に何度もステータスが変化します。それぞれの遷移には独自の仕訳が必要であり、リザーブは、理由の説明がつかない売上の削減であってはなりません。

利用可能な資金がリザーブに移動する場合の仕訳：

勘定科目	借方	貸方
出品者買掛金 - 出品者A	€15
出品者留保負債		€15

リザーブが解除された場合は、この仕訳を逆仕訳します。出品者の総債務は変わっておらず、そのステータスが変化しただけだからです。Stripeは、リザーブを増加および解除するリザーブ取引や、長期化するマイナス残高に対する回収送金を文書化しています。そのため、単一の相殺仕訳ではなく、識別可能な勘定科目が必要となります。

ペイアウト（出金）は2ステップで処理します。承認時：

勘定科目	借方	貸方
出品者買掛金 - 出品者A	€90
出品者ペイアウトクリアリング		€90

銀行決済が確認された時：

勘定科目	借方	貸方
出品者ペイアウトクリアリング	€90
銀行口座		€90

ペイアウトが失敗した場合は、クリアリングを出品者買掛金に戻す逆仕訳を行います。ペイアウトは負債の決済であり、費用ではありません。これを費用として扱うと、すでに買掛金を記録した売上に対して二重計上になってしまいます。Stripeは、ペイアウトのステータス（pending、in_transit、paid、failed、canceled）や予想到着日を開始時点から分離して管理しており、これらの日付を単一のタイムスタンプに統合してはなりません。

受注からペイアウトまでのデータモデル

補助元帳は、アプリケーションの現在の注文ステータスではなく、イベントに基づいて動作します。出品者に影響を与えるすべてのイベントには、共通のエンベロープ（封筒モデル）を持たせます。

• seller_id、event_id、order_id
• event_type（sale、refund、chargeback、reserve_hold、reserve_release、payout、adjustment）
• effective_date、posting_date
• currency、direction、gross、commission、fees、reserve
• refund_ref / dispute_ref
• payout_batch_id
• reversal_of
• source_status、idempotency_key

変更可能なフィールドを直接保持するのではなく、これらのイベントから期末残高を算出します。

出品者期末残高
= 期首残高
+ 出品者クレジット
− 出品者デビット
− ペイアウト
± 留保金の変動
± 修正

リトライや重複するウェブフックによって出品者への二重クレジットや二重ペイアウトが発生しないよう、外部イベントにはそれぞれ永続的なべき等キー（idempotency key）が必要です。効果的なパターン：

• 出品者仕訳イベント: seller_id:order_id:event_type:version
• ペイアウトバッチ: processor:payout_id
• プロセッサイベント: processor:event_type:processor_event_id

Stripeのウェブフックに関するガイドでも、イベントの重複が発生することが警告されているため、重複検知は必須です。起票された仕訳は変更不可能なイミュータブルとして保持します。修正を行う場合は、逆仕訳と修正後の仕訳を別途行い、reversal_of のリンクとその理由をイベントエンベロープ自体に持たせます。Nordletでは、APIリファレンスに記載されているように、仕訳トランザクションに対して作成（create）、取得（get）、一覧取得（list）のエンドポイントのみを提供しており、更新や削除は提供していません。そのため、修正は常に既存データの編集ではなく、新しいトランザクションとして行われます。

返金とチャージバックは元データに紐付け、宙ぶらりんにしない

来週のペイアウトに現れる返金を、そのペイアウトに紐づく新たなマイナスの売上として扱ってはなりません。必ず元のトランザクションに紐付け、元の出品者の配分を維持します。契約内容に応じて以下のように処理します。

• 契約により返金対象となる場合は、手数料を逆仕訳する
• 出品者が返金を負担する場合は、出品者買掛金を借方に記帳する
• プラットフォームが負担する場合は、プラットフォーム損失勘定を借方に記帳する
• 異議申し立て（ディスプート）のオープン中は留保金を増加させ、解決時に解除または消費する

ペイアウト後のチャージバックは、マイナス残高が発生する原因となります。出品者の資金はすでに手元にないため、プラットフォームは将来の売上から回収するか、損失を被ることになります。このモデルでは、出品者のマイナス残高を許可し、回収ルールを定義しておく必要があります。Adyenのマーケットプレイスレポートでは、口座保有者ごとに返金やチャージバックが個別の借方行として出力されます。これこそが目指すべき粒度です。

月次ではなくペイアウトごとに照合を行う

月次で集計するのではなく、決済プロセッサからの入金は起票前に必ずすべて分解し、ペイアウトごとに照合を行います。

総売上（Gross charges）
− 返金
− プロセッサ手数料
− チャージバック
± 留保金および調整額
= 純プロセッサペイアウト

その後、各出品者および通貨ごとに、以下の4つの残高が一致していることを証明します：出品者補助元帳、プロセッサの出品者残高、ペイアウトレポート、および銀行クリアリングです。差異が生じた場合は、その差異を分類します（タイミングのずれ、イベントの欠落、重複、帰属先の誤り、通貨の誤り、ペイアウトの失敗、誤った当事者に起因するチャージバックなど）。差異を相殺して見えなくすることは、エラーが蓄積して次回の決算まで生き残る原因となります。

月次全体を集計すると、タイミングのずれが相殺されて隠れてしまい、実際の不整合が見えなくなってしまいます。金額と日付ではなく、ペイアウトIDとトランザクション参照をキーとしたペイアウトごとのマッチングを行うことで、これらの不整合を検知できます。

一般的な失敗パターン

失敗パターン	悪影響	統制（コントロール）
顧客の総支払額を売上として起票する	売上の過大計上、出品者負債の隠蔽	発生イベント時に買掛金と手数料を分割する
純額の入金のみを起票する	総額、手数料、返金、リザーブが失われる	すべての決済を細分化して分解する
ペイアウトを費用として計上する	負債の決済を誤って表現する	ペイアウト時に出品者買掛金を借方に記帳する
出品者残高のフィールドが1つだけ	保留中、利用可能、留保中、出金済みが混ざる	残高のステータスを明示的に追跡する
ペイアウト時に手数料を計算する	ペイアウトのスケジュールに売上が依存する	手数料は発生時に認識する
リザーブを売上のマイナスとして扱う	タイミングとリスクが不明瞭になる	保留、解除、消費を個別に追跡する
直近のペイアウトに返金を適用する	注文の紐付けが破壊される	元のトランザクションに返金を紐付ける
起票済みの仕訳を直接編集する	監査証跡が破壊される	逆仕訳と再起票を行う
リプレイされたウェブフック	クレジットやペイアウトの二重計上	べき等キー、重複検知を使用する
金額と日付のみでマッチングする	異なるアイテム同士が衝突する	ペイアウトID、トランザクションID、出品者、通貨でマッチングする

最初に行うべきこと

勘定科目に触れる前に、資金の流れを図式化します。決済キャプチャからリザーブ解除までのすべてのイベントを書き出し、どれが売上を発生させ、どれが負債を発生させ、どれが単にステータスを移動させるだけなのかを明確にします。

次に、通常の販売、一部返金、ペイアウト後のチャージバック、留保金の保持と解除、ペイアウトの失敗という一連のエンドファイルを作成し、貸借が一致することを証明します。既知の期待残高を用いてこれらを実行します。出品者買掛金コントロール勘定が補助元帳の合計と一致し、プロセッサクリアリングが決済レポートと一致し、銀行入金がペイアウトIDと一致していれば、機能する基盤が完成しています。

未処理のサスペンス残高がゼロの状態で最初の月次が綺麗に締まった後にのみ、期間ロックを有効にします。早すぎるロックは間違いを凍結するだけです。

Nordletは、こうした要件に沿った決済処理を標準機能として提供しています。プラットフォームの手数料は手数料売上へ、出品者の取り分は出品者買掛金へ、プロセッサ手数料は決済手数料へ、そしてまだ帰属先が定まっていないものはサスペンス勘定へと自動的に仕訳されます。元帳の期間は明示的にロックするまでオープンな状態を維持するため、サスペンスがゼロになった段階で初月を締めくくることができます。提供機能の詳細については、機能ページをご覧ください。

FAQ

買い手の支払いがプラットフォームの売上になることはありますか？

プラットフォームがプリンシパル（本人）となる特定の商品やサービスの場合にのみ売上となります。出品者の商品を販売するエージェント型のマーケットプレイス取引においては、売上は手数料であり、出品者の取り分は負債となります。同一の注文内であっても、プラットフォームが配送サービスについてはプリンシパルとして機能し、基礎となる商品についてはエージェントとして機能する場合があるため、企業単位ではなく、指定された商品またはサービスごとに評価が行われます。

リザーブは売上を減少させるべきですか？

いいえ。リザーブはタイミングとリスクの配分であり、売上の調整ではありません。資金を保持する際には出品者買掛金から留保負債へ資金を移動し、解除する際に逆仕訳を行います。出品者の資金が現在留保されているかどうかによって、売上や手数料が影響を受けることはありません。

ウェブフックのリトライによる二重ペイアウトを防ぐにはどうすればよいですか？

ペイアウトバッチに対する processor:payout_id などのべき等キーをすべての外部イベントに付与し、書き込み時に重複イベントを検知します。決済事業者からは重複したウェブフックの配信が発生することが明示的に警告されているため、元帳側では再度起票するのではなく、2回目の試行を拒否する必要があります。

出品者の残高がマイナスになることはありますか？

はい、モデルとしてもそれを許可する必要があります。出品者への支払いが行われた後にチャージバックが発生した場合、プラットフォームには出品者に対する未収金が発生するか、あるいはプラットフォームが損失を負担することになります。マイナス残高を非表示にすることは、未記録の債務を隠すことにほかなりません。

月次合計ではなく、なぜペイアウトごとに照合を行うのですか？

月次で集計するとタイミングのずれやエラーが相殺されてしまうため、個々のトランザクションに誤りがあっても合計値としては一致してしまうからです。ペイアウトIDとトランザクションIDで照合を行うペイアウトごとのリコンシエーションにより、締めの前に欠落したイベント、重複、および帰属先の誤ったチャージバックを検出し表面化させることができます。

関連資料

• マーケットプレイス会計向け複式簿記元帳API
• 決済リコンシエーション：PSPのペイアウトを元帳に照合する
• ASC 606におけるプリンシパルとエージェントの考慮事項（Deloitte）