Stripe Connect Marketplace Accounting Workflow

ほとんどのマーケットプレイスにおける会計上の問題は、1つの重大なミスに起因しています。それは、Stripeの銀行送金（Payout）の金額をそのまま売上として処理することです。送金データは、数十件に及ぶ個別の経済的取引の純残高であり、これを1つの収入科目として一括計上してしまうと、プラットフォームの手数料、出品者への債務、およびその中に埋もれているすべての決済手数料やチャージバックが隠蔽されてしまいます。正しいワークフローでは、元帳（ledger）に仕訳が記録される前に、送金の内訳を分解して処理します。

本ガイドでは、Stripe Connectの残高トランザクション（balance transaction）の各カテゴリを、売掛金、手数料収益、出品者債務、決済手数料費用、仮勘定といった適切な会計上の仕訳に割り当てる方法を解説します。Nordletが提供するインポートおよび決済エンドポイントを仕訳の仕組みとして利用し、実際の決済例を交えながら、決算前に実行すべき突合（reconciliation）チェックリストで締めくくります。

設計の前にConnectの課金モデルを特定する

決済フローでどの課金モデルが使用されているかを把握しない限り、会計ルールを定めることはできません。モデルによって、どのStripe残高に売上が計上されるか、誰が手数料を負担するか、返金や紛争が最初にどこに影響するかが決まります。

Connectモデル	課金先	Stripe手数料の負担者	返金・紛争の減額対象	会計上の影響
ダイレクトチャージ (Direct charges)	連携アカウント (Connected account)	当事者間で設定可能	連携アカウントの残高	プラットフォームはプラットフォーム手数料を収益として計上し、出品者の売上関連取引は主に連携アカウントの元帳で管理される
デスティネーションチャージ (Destination charges)	プラットフォーム（1つの連携アカウントへ即時送金）	プラットフォーム	プラットフォーム	プラットフォームが顧客に対する売掛金とStripe手数料を計上し、出品者分は収益ではなく買掛金となる
個別チャージとトランスファー (Separate charges and transfers)	プラットフォームによるチャージ、および1回以上の個別送金	プラットフォーム	プラットフォーム	チャージと出品者への送金が別個のイベントとなり、出品者債務は顧客チャージとは独立して追跡される

StripeのConnect連携における課金方法に関する公式ドキュメントでも確認されている通り、デスティネーションチャージおよび個別チャージとトランスファーの場合、プラットフォームの残高が決済手数料、返金、チャージバックを負担します。ダイレクトチャージの場合、連携アカウントがチャージを受け取り、手数料はどちらの当事者からも引き落とすことが可能です。

実務上の原則として、各フローの課金モデルを明確に把握するまでは、「Stripeの送金額を出品者の売上とする」あるいは「出品者が手数料を負担する」と決めつけてはなりません。そのモデルをすべての取引データと紐づけて保存してください。ダイレクトチャージとデスティネーションチャージを1つの仕訳ルールに混在させると、売上と負債の双方を誤って表示する原因になります。

本ガイドでは、プラットフォームの残高が会計上の重みを持ち、多くのマーケットプレイスの元帳が構築される基盤となる、デスティネーションチャージおよび個別チャージとトランスファーを前提として解説します。

1行もインポートする前に資金の流れをマッピングする

インポート作業を行う前に、フローごとに1枚のトランザクションマップを作成します。

顧客の支払い
  -> Stripeチャージ / 決済残高トランザクション
  -> Stripe手数料
  -> プラットフォーム手数料（コミッション）
  -> 連携アカウントへの送金
  -> 返金または紛争（該当する場合）
  -> Stripeの銀行送金
  -> 銀行口座への入金

それぞれの矢印は、独自のID、カテゴリ、金額、日付を持つ別個の残高トランザクションです。Stripeの残高は、銀行口座のようなクリアリング口座（clearing account）として扱います。チャージが流入し、手数料や送金が流出し、送金によって残りの金額が実際の銀行口座に移動します。Nordletの銀行および決済のインポートに関するドキュメントでは、通常のStripeの活動に対してまさにこの処理方法を推奨しています。

適切なStripeソースレポートを選択する

自動送金の決済バッチについては、Stripeの**「送金の突合、明細つき (Payout reconciliation, itemized)」**レポートを使用します。このレポートは残高トランザクションごとに1行のデータを出力し、reporting_category（報告用カテゴリ）ごとに行をグループ化し、それぞれにautomatic_payout_idを関連付け、総額、手数料、純額の合計を提供します。Stripeのレポート選択ガイドにはこのレポートに関する記載があり、Connectの利用可能なフィールドとしてcharge_id、connected_account_id、destination_payment_idが含まれていることが確認できます。

自動送金が有効になっていない場合（手動送金を採用している場合など）は、代わりに残高（Balance）レポートを使用してください。ダッシュボードの送金サマリーだけで仕訳の十分な根拠とするべきではありません。サマリーが証明するのはバッチの総額のみであり、個々の構成要素を説明できるのは明細つきレポートのみです。

Stripeでは、古いtypeフィールドではなくreporting_categoryによる分類を推奨しており、各行には基となるオブジェクトに紐づくsource IDが付与されています。タイミングに関する制約として、日次レポートデータは通常、翌日の正午までに利用可能になり、インスタントペイアウト（即時送金）は個々の取引にきれいに割り当てることはできないため、個別の取引履歴突合が必要になる点に注意してください。

すべての残高トランザクションをカテゴリ別に分類する

reporting_categoryを主要な分類基準として使用し、その上でsource_id、charge_id、および説明（description）を確認します。押さえておくべきマッピングは以下の通りです。

Stripeの処理	報告用カテゴリ (reporting_category)	会計上の解釈
顧客チャージ、カードまたはローカル決済手段	charge	顧客負担の売掛金または売上決済
返金	refund	当初の顧客支払いの取消
Stripeによって差し引かれた処理手数料	fee	決済処理費用
プラットフォーム手数料	platform_earning	コミッション収益
返金されたプラットフォーム手数料	platform_earning_refund	コミッション収益の減少
連携アカウントへの送金	transfer	出品者債務の減少
取消された送金	transfer_reversal	連携アカウントからの回収
チャージバック	dispute	チャージバックによる損失。元の紛争オブジェクトを確認する
勝訴または取消されたチャージバック	dispute_reversal	以前に計上したチャージバックの回収
銀行への送金	payout	銀行口座間の資金移動であり、売上ではない
取消された送金	payout_reversal	Stripe残高への資金の返還
留保されたリザーブ	connect_reserved_funds / risk_reserved_funds	制限された資金であり、デフォルトでは費用ではない
長期化しているマイナス残高の回収	connect_collection_transfer	リスクポリシーに基づく資金調達または回収イベント

用語に関する注意点として、旧式の残高トランザクションのtypeフィールドでは、同じイベントに対してpayment、application_fee、adjustmentなど異なるラベルが使用されます。Stripeの残高トランザクションタイプのドキュメントには両方の語彙が記載されています。typeの値をreporting_categoryのルールに混在させたり、Stripeがエクスポートしないdispute_lossのような独自のカテゴリを勝手に作成したりしないでください。エクスポートされたデータに馴染みのないラベルが含まれている場合は、エクスポートされた値をそのまま保持し、元のオブジェクトと照らし合わせて検証してください。

通常のマーケットプレイス取引を元帳に計上する

デスティネーションチャージ、または個別チャージとトランスファーを採用しているプラットフォームの場合、概念的な仕訳は以下のようになります。

顧客チャージ（顧客の資金がStripeのクリアリング残高に流入）：

借方: Stripeクリアリング残高       顧客チャージ総額
    貸方: 売掛金                   顧客チャージ総額

Stripe決済手数料：

借方: Stripe手数料費用           Stripe手数料
    貸方: Stripeクリアリング残高       Stripe手数料

会計方針で純額表示が明示的に求められ、かつサポートされている場合を除き、Stripe手数料を売上から相殺して純額で計上しないでください。

プラットフォーム手数料（出品者に対して本来支払うべき金額から差し引かれる、自社の収益）：

借方: 出品者買掛金               手数料金額
    貸方: 手数料収益               手数料金額

出品者への送金（未払金の決済であり、費用ではありません）：

借方: 出品者買掛金               送金額
    貸方: Stripeクリアリング残高       送金額

送金が自動的に費用になることはありません。出品者の取り分はチャージが発生した時点で負債となり、送金によってその負債が解消されます。Nordletの決済仕訳ルールもこれに倣っており、platform_earningの行は手数料収益として計上され、transferの行は出品者債務を減少させます。ドキュメントに記載されているデフォルトの仕訳キーは、settlements.commissionRevenue（デフォルトは 5001）、settlements.sellerPayable（デフォルトは 4499）、settlements.fees（デフォルトは 6800）、settlements.suspense（デフォルトは 4440）であり、Nordlet APIの仕訳ルールを通じて企業ごとにオーバーライド（上書き）が可能です。

返金を通常の銀行取引としてではなく、元の売上のマイナスとして処理する

返金は、元のチャージまたは請求書（invoice）に紐づきます。概念的には以下の通りです。

借方: 返金 / 売上取消             返金額
    貸方: 売掛金                   返金額

実際の仕訳は、売上がすでに認識されているか、税金の取り消しが必要か、プラットフォーム手数料が返金されたかによって異なります。1件の返金により、売掛金の取消、税金の取消、プラットフォーム手数料の返金、送金の取消または出品者買掛金の減少、そして確認が必要なStripe手数料の影響が発生する可能性があります。

タイミングの落とし穴として、返金は元のチャージよりも後の送金バッチで実行されることがよくあります。チャージレベルのエクスポートから生成された疑似的な返金データよりも、明細つきの送金突合レポートを使用することを推奨します。Nordletのドキュメントでは、ペイメントのエクスポートから合成された返金データは、返金が後日行われる場合には単なる近似値に過ぎないと明確に警告しています。決済インポーターは返金行を取り込み、元の売上と突合し、バッチが計上された時点で売掛金を取り消すことができます。

紛争（Dispute）を返金とは区別して処理する

紛争はカードホルダーまたは発行銀行からの異議申し立てであり、Stripeは解決前に係争中の金額と紛争手数料の両方を引き落とすことがあります。デスティネーションチャージ、および個別チャージとトランスファーの場合、Stripeの返金と紛争に関するガイドに従い、プラットフォームの残高から両方が引き落とされます。プラットフォームは、出品者への送金を取り消すことで回収を試みることができます。

プラットフォーム側の視点による、敗訴した紛争の仕訳：

借方: チャージバック損失 / 再オープンされた売掛金   係争金額
借方: 紛争手数料費用                             紛争手数料
    貸方: Stripeクリアリング残高                   合計額

出品者が損失を負担し、回収が確認された場合：

借方: 出品者買掛金 / 回収勘定                     回収可能額
    貸方: チャージバック回収                     回収可能額

送金の取消を依頼したという理由だけで、出品者からの回収を計上してはなりません。取消が作成され、成功し、Stripeの残高に反映されていることを確認してください。紛争に勝訴した場合、Stripeはdispute_reversal行を通じて係争中の金額を返金します。チャージバック損失を取り消し、Stripeが返金しなかった紛争手数料については別途処理します。Nordletは、同じファイル内または以前のインポートから、事前に照合されたチャージのcharge_idを使用してチャージバック行を突合します。

実際の決済例

1つの自動送金バッチを例にとります。明細つきレポートには以下のデータが含まれています。

• charge行：総額 100.00、Stripe手数料 3.20、純額 96.80
• platform_earning行：15.00（プラットフォームの手数料）
• transfer行：81.80（連携出品者への送金）
• 過去の売上に対するrefund行：総額 20.00（このバッチで決済）
• payout行：銀行に移動するバッチの合計額

Stripeの決済の等式に従った、送金の構成：

チャージ総額                 100.00
- 返金                        20.00
- Stripe手数料                3.20
- 送金額                      81.80
= プラットフォーム残高への純額     -5.00

platform_earning行によって資金が二重に移動することはありません。手数料と出品者への送金が行われた後にプラットフォームの残高に残る15.00を指定しているため、プラットフォームは推計に頼ることなくコミッション収益を正確に認識できます。

この例では、出品者への送金と返金の合計が、チャージによる純収入を上回っているため、バッチ全体で少額のマイナスとなり、次回の送金から差し引かれるか残高から引き落とされます。計上される仕訳では、返金された売掛金の取り消し、15.00のコミッション収益の認識、3.20の手数料費用の計上、送金による出品者買掛金の減少、および返金取消の記帳が行われます。銀行口座の明細額は口座に到達した純額と一致します。どれか一つの数字が「売上」に等しくなるわけではないという点が重要です。

Nordletの決済エンドポイントを通じたインポートと計上

送金レベルでの突合には、次のエンドポイントを使用します。

POST /v1/bank/settlements/import

Stripeプロバイダーと明細つきCSVを指定して実行します。Nordletはautomatic_payout_idごとに行をグループ化し、各送金を総額、手数料、純額を持つ決済バッチに変換し、すでに計上された送金の再インポートをスキップし、送金構成からpayout行をスキップし、注文、請求書、PaymentIntent、チャージ、ソース、またはメタデータの参照を使用してチャージ、返金、紛争行を自動照合します。Stripeは明細つきレポートをセクションごとに1つのファイルに分割して出力するため、チャージ、返金、手数料のファイルを同時にインポートしてください。すでにインポートされているものの未計上の送金に属する行は、既存のバッチにマージされます。これはライブのStripeコネクターではなく、ファイルと決済エンドポイントによって駆動されるインポートおよび計上のワークフローです。機能ページには、銀行および決済関連機能の対応範囲が記載されています。

次の順序で照合を行います：チャージと請求書の照合、返金と元のチャージの照合、紛争と元のチャージの照合、コミッション行とコミッション処理の照合。Stripe手数料、調整金、リザーブ、送金行は請求書の照合から除外してください。Nordletの決済突合の用語集には、手数料や調整の行は設計上請求書と照合できないと記載されています。未解決の資金関連項目は仮勘定（suspense）にルーティングしてください。手動での修正には bank/settlements/match { lineId, invoiceId } を使用し、invoiceId に null を指定することで照合を解除できます。

その後、1つのバランスの取れたバッチを計上します。

POST /v1/bank/settlements/post

これにより、バランスの取れた1つの仕訳が作成され、照合済み請求書が決済され、純送金額について銀行口座の元帳口座が借方に記入され、手数料が借方に記入され、チャージについて売掛金が貸方に記入され、返金およびチャージバックについて売掛金が取り消され、commissionPercent が指定された場合に未処理のマーケットプレイスチャージが手数料収益と出品者買掛金に分割され、未解決の金額が仮勘定に送られます。認識できないカテゴリもすべて仮勘定に振り向けられ、そのレスポンスには、黙って吸収するのではなく、該当したカテゴリ名が警告として記載されます。

突合チェックリスト

決算の前に必ず以下の点を確認してください。

• 重複する balance_transaction_id がないこと
• 重複する (provider, payout_id) の決済バッチがないこと
• 明細行の net（純額）の合計がバッチの純額と一致していること
• タイミングおよび通貨方針を条件として、バッチの純額が銀行の送金額と一致していること
• すべての返金に元のチャージまたは記録された例外が存在すること
• すべての紛争に紛争またはチャージの参照が存在すること
• すべての送金に連携アカウントIDが存在すること
• すべての platform_earning 行に定義されたコミッション処理が存在すること
• 仕訳計上の警告に記載された未認識カテゴリも含め、仮勘定がゼロであるか、完全にレビューされていること
• 承認された前渡金や回収ポリシーがない限り、出品者買掛金がマイナスになっていないこと
• 計上されたバッチがサイレントに再インポートまたは再計上されないようになっていること
• 企業の基本通貨以外の通貨での送金は、送金日のレートで換算され、各請求書自身のレートとの差額が実現為替差損益として計上されること。複数の通貨が混在する送金はインポート時に拒否されること

突合は、行レベル（各取引が保持するID、カテゴリ、金額、通貨、ソース）、送金レベル（明細つきの純額がStripeの送金および銀行入金と一致する）、元帳レベル（計上された仕訳の貸借が一致し、意図した売上、手数料、売掛金、出品者債務、仮勘定の残高を生成する）の3つのレベルで実施します。特に出品者残高については、期首の出品者買掛金に新しい出品者の取り分を加え、送金および有効な取消を差し引いた金額が、期末の出品者買掛金と一致していることを確認してください。

すべてのマーケットプレイスの元帳で繰り返し発生する問題は、最初に述べた問題と同じです。それは、構造化された送金データを1つの数字にまとめてしまうことです。構成要素を個別に保持し、それぞれを安定したStripe識別子に紐づけ、まだ説明できないものは仮勘定で保留してください。クリーンな決算こそが、監査人が信頼するものです。

FAQ

Stripeの送金はプラットフォームの売上ですか？

いいえ。送金は、同じバッチ内で発生したチャージ、返金、決済手数料、出品者への送金、紛争、および調整の純額です。これを1つの収入科目として計上すると、その中にある出品者への債務や決済手数料が隠蔽されてしまいます。エージェント型マーケットプレイスの場合、売上とはコミッションであり、それを特定するのが platform_earning 行です。

どのStripeレポートと突合すべきですか？

「送金の突合、明細つき (Payout reconciliation, itemized)」レポートです。このレポートでは、残高トランザクションごとに1行のデータが出力され、reporting_category、automatic_payout_id、および総額、手数料、純額が含まれているためです。ダッシュボードの送金サマリーではバッチの合計額しか証明できません。自動送金が有効になっていない場合は、代わりに残高レポートを使用してください。

出品者への送金は費用として計上すべきですか？

いいえ。出品者の取り分は顧客チャージが発生した瞬間に負債となり、送金によってその負債が解消されます。送金を費用として計上すると、コストが二重計上され、出品者買掛金が過大に計上されたままになってしまいます。

インポーターが認識できないカテゴリのStripe行はどう処理されますか？

決済の仮勘定（デフォルトでは 4440）に計上され、計上時のレスポンスには、該当したカテゴリ名を挙げる警告が返されます。リザーブや特殊な調整金は通常このように処理されますが、これは意図的なものです。誰かがその帰属先を決定するまで、資金の所在が可視化された状態で元帳の貸借バランスが維持されます。

後日の送金で決済される返金はどのように処理されますか？

後日の送金の明細つきレポートに refund 行として現れ、以前に照合されたチャージの charge_id を通じて元のチャージに突き合わされます。チャージレベルのペイメントのエクスポートから合成された返金データはこの場合近似値に過ぎないため、明細つきレポートの方がより安全なソースとなります。

関連ドキュメント

• 銀行および決済のインポート（Stripe決済の突合を含む）
• 決済の突合：PSPの送金データと元帳の照合
• マーケットプレイス出品者の補助元帳：売上対買掛金
• Connect連携における課金方法（Stripe）