Stripe Connect Accounting for Platforms and Marketplaces

If you run a marketplace or platform on Stripe Connect, you have a bookkeeping problem most accountants don't know exists.

Standard Stripe is simple: a customer pays you, Stripe takes a fee, you keep the rest. One payer, one payee, one set of books.

Stripe Connect adds a third party. A customer pays through your platform, the connected account (a seller or service provider on your platform) gets most of that money, and you keep a cut called an application fee. Now you have three parties, three cash flows, and most bookkeepers record only one of them correctly.

This article shows you the right way to book Stripe Connect transactions. You'll see actual journal entries with numbers, the difference between the two revenue models, and where the GL breaks down for multi-entity platforms.

What is Stripe Connect accounting?

Stripe Connect accounting is the process of recording transactions where your platform collects a payment on behalf of a connected account (a third-party seller or provider). Your platform earns application fees or a split of each charge. The connected account earns the rest. Each side requires its own journal entries. Merging both into one set of books overstates platform revenue and understates the liability owed to connected accounts.

Key Takeaways

• Stripe Connect creates two revenue streams: application fees (your cut) and the connected account's share. They go to different GL accounts.
• Application fee model vs. destination charge model have different merchant-of-record rules. The journal entries are not interchangeable.
• The platform owes money to connected accounts until Stripe pays them out. That payable must appear on your balance sheet.
• Each payout report line item needs a type check. The fields charge, application_fee, transfer, and refund each hit a different account.
• Multi-entity platforms need intercompany entries when connected accounts are subsidiaries, not independent third parties.
• Automation tools that handle standard Stripe often fail on Connect because they don't separate platform fees from pass-through amounts.

How Stripe Connect Changes the Bookkeeping Problem

With standard Stripe, one entity collects money. The journal entry is straightforward:

1Debit:  Cash (net payout)               $970.00
2Debit:  Stripe Processing Fees          $30.00
3Credit: Revenue                         $1,000.00
Copy

Stripe Connect breaks that assumption. Now the $1,000 customer charge splits three ways:

• Stripe takes its processing fee ($30)
• Your platform keeps an application fee ($50)
• The connected account gets the rest ($920)

You did not earn $1,000. You earned $50. The $920 passed through your platform and you owe it to the seller. If your bookkeeper records the full $1,000 as your revenue, you've overstated income by $920 and understated liabilities by the same amount.

This is the core error. It happens constantly, especially when a bookkeeper pulls the Stripe payout report and sees a large gross deposit without knowing which transactions were Connect charges.

The Two Revenue Models and Their GL Impact

Stripe Connect has two ways to structure who collects the money. The accounting treatment differs by model.

Application Fee Model

The connected account is the merchant of record. The customer pays the connected account. Your platform collects an application fee on top of or as a deduction from that charge.

From your platform's perspective:

• You never own the gross charge
• You earn only the application fee
• You have no revenue recognition obligation on the full amount

Destination Charge Model

Your platform is the merchant of record. The customer pays your platform. You transfer the connected account's share to them after the fact.

From your platform's perspective:

• You collect the full gross charge
• You recognize gross revenue (or net, depending on your accounting policy)
• You have a payable to the connected account

The model matters because it changes what hits your income statement. Getting this wrong affects the P&L. It also changes your revenue recognition timeline and deferred revenue calculations.

Journal Entry for the Application Fee Model

Scenario: A $1,000 service sold on your marketplace. Your application fee is $50. Stripe's processing fee is $29.

Step 1: Customer pays the connected account:

1Debit:  Stripe Clearing (platform escrow)    $1,000.00
2Credit: Payable to Connected Account          $1,000.00
Copy

Step 2: Application fee collected:

1Debit:  Payable to Connected Account          $50.00
2Credit: Platform Fee Revenue                  $50.00
Copy

Step 3: Stripe deducts processing fee:

1Debit:  Stripe Processing Fees                $29.00
2Credit: Stripe Clearing                       $29.00
Copy

Step 4: Stripe pays out connected account ($921 net):

1Debit:  Payable to Connected Account          $921.00
2Credit: Stripe Clearing                       $921.00
Copy

End result: Your P&L shows $50 in revenue. Your balance sheet shows zero liability (paid out). Your cash account reflects only your $50 cut minus Stripe's fee allocation.

Journal Entry for the Destination Charge Model

Same scenario: $1,000 charge. Your platform is merchant of record. You transfer $920 to the connected account. Stripe's fee is $29.

Step 1: Customer pays your platform:

1Debit:  Stripe Clearing                       $1,000.00
2Credit: Gross Revenue                         $1,000.00
Copy

Step 2: You record connected account share as cost:

1Debit:  Connected Account Payouts (COGS)      $920.00
2Credit: Payable to Connected Account          $920.00
Copy

Step 3: Stripe processing fee:

1Debit:  Stripe Processing Fees                $29.00
2Credit: Stripe Clearing                       $29.00
Copy

Step 4: Transfer to connected account:

1Debit:  Payable to Connected Account          $920.00
2Credit: Stripe Clearing                       $920.00
Copy

End result: Your P&L shows $1,000 gross revenue minus $920 COGS = $80 net margin. This matches your platform's $80 total (the $50 fee plus a $30 processing fee reimbursement built into the model).

Note: some platforms prefer net revenue recognition, crediting only $80 to revenue instead of grossing up. Either method is acceptable under GAAP, but you must be consistent and you must document the policy. Gross recognition is more common when the platform controls the customer relationship.

The Three Ledger Problem

A Stripe Connect platform actually has to think about three ledgers simultaneously.

Ledger 1: Your platform books. What did you earn? What are your liabilities? This is what we covered above.

Ledger 2: Connected account books (if they're a subsidiary or you file combined returns). What did each connected account collect? What fees did they pay to your platform? If your connected accounts are independent third parties, you don't book their ledger. But if they're subsidiaries, you'll need intercompany eliminations at consolidation.

Ledger 3: Stripe's ledger. This isn't your book, but it's the source of truth for reconciliation. Stripe's payment reconciliation reports show every charge, transfer, application fee, and refund by reporting category. This is what you match against your platform's Stripe clearing account.

Most tools built for standard Stripe treat everything as Ledger 1 entries. They pull in the gross charge and call it revenue. For Connect, that works only if every charge is a destination charge and you're using gross revenue recognition. Even then, they often miss the payable to connected accounts.

Multi-Currency and International Connected Accounts

If your connected accounts operate in different currencies, add foreign exchange complexity to the mix.

Connected accounts sometimes receive payouts in EUR while your platform books are in USD. The EUR payable needs a USD-equivalent entry at the transaction date. At settlement, the difference between the recorded rate and the actual payout rate is a foreign exchange gain or loss.

1Debit:  Payable to Connected Account (USD equivalent)    $921.00
2Credit: Stripe Clearing                                  $918.50
3Credit: FX Gain                                          $2.50
Copy

The exact amounts depend on the EUR/USD rate at charge time vs. payout time. Stripe provides both amounts in the payout report. You need to capture both to book this correctly. Most bookkeepers skip the FX gain/loss entry and just match the bank deposit. That's a reconciling difference that compounds over time.

SaaS Plus Marketplace Setups

A common pattern: a SaaS company that also runs a marketplace. Think of a project management platform that also lets contractors find work. The SaaS side collects subscription fees (direct Stripe charges, no Connect). The marketplace side collects service fees via Stripe Connect.

Both run through the same Stripe account. In your payout report, subscription charges and Connect charges look similar. You have to separate them by charge type.

How to split them:

• Direct charges (subscriptions, one-time software sales): Revenue hits your main revenue account
• Connect charges with application fees: Only the application fee hits revenue; the rest is pass-through
• Connect charges with destination model: Gross to revenue, COGS to connected account payout

You need separate GL accounts for each stream. A single "Stripe Revenue" account doesn't work. Minimum setup:

• 4000 - SaaS Subscription Revenue
• 4010 - Marketplace Application Fee Revenue
• 4020 - Marketplace Gross Revenue (destination charge model only)
• 5000 - Connected Account Payouts (COGS) (destination charge model only)
• 2100 - Payable to Connected Accounts
• 1500 - Stripe Clearing

If you're recording Stripe payouts in QuickBooks or Xero and merging SaaS + Connect revenue into one account, see our guide on recording Stripe in QuickBooks for the setup steps. You'll need sub-accounts or classes to split the streams correctly.

1099-K Obligations for Connected Accounts

If your connected accounts process more than $600 through your platform in a calendar year (2026 threshold), Stripe will issue 1099-Ks on your behalf. Your platform is responsible for collecting TINs (Tax Identification Numbers) from each connected account before they hit that threshold.

This isn't just a tax filing obligation. It's a compliance risk. If you don't collect TINs and a connected account hits the threshold, you may be required to withhold 24% backup withholding from their payouts.

Stripe handles 1099-K issuance for connected accounts on your platform. But you have to configure this in your Stripe Dashboard and make sure connected accounts complete their tax information during onboarding. If you built a custom Connect integration, this requires explicit implementation.

For the GL impact: backup withholding amounts need their own liability account until remitted. This is a separate payroll-adjacent obligation, not just a reconciling item.

Where Automation Tools Fall Short

Most Stripe accounting integrations handle standard Stripe well. They pull transactions, categorize fees, and push journal entries. Tools like A2X, Synder, and the native Stripe-QuickBooks connector all work reasonably well for standard setups. Our comparison of Stripe accounting tools covers each one in detail.

The problem is Connect. None of these tools natively split application fees from gross charges and route them to different GL accounts. They see a charge and post it to revenue. They see a transfer and post it to... somewhere. The payout report gets imported but the reporting categories don't drive separate account mapping.

What you actually need is a tool that reads the reporting_category field in Stripe's payout report and routes:

• charge → your platform clearing account
• application_fee → platform fee revenue
• transfer → payable to connected account (debit side)
• refund → reverse the original entries

When you deal with Stripe refunds and chargebacks, Connect adds another layer: which party absorbs the chargeback? If the connected account is merchant of record (application fee model), the chargeback hits their balance. If your platform is merchant of record (destination charge model), it hits yours first and you may claw back from the connected account.

How Growthy Handles Stripe Connect

Growthy reads the reporting_category in Stripe's payout export and routes each transaction type to a separate GL account. Application fees go to platform fee revenue. Transfers to connected accounts post to the payable account. Gross charges under the destination model gross up to revenue with the connected account share hitting COGS.

For platforms with multiple connected accounts, the per-seller breakdown replaces one aggregate line. Marketplace operators get revenue by seller. Platforms with subsidiary connected accounts get the intercompany detail they need for consolidation.

Each payout matches to its component charges and fees without custom bank rules per transaction type. See automated vs. manual reconciliation for how that works end-to-end.

No Stripe Connect setup is identical. If your structure involves subsidiary entities, multi-currency payouts, or a SaaS-plus-marketplace hybrid, the chart of accounts setup described above is the starting point. The journal entry logic stays the same across models.

Growthy is bookkeeping software, not a CPA firm. This content is educational, not professional advice. Full disclaimer.

Stripe Connect creates the exact category of transaction where flags instead of guessing matters most. A platform fee that should hit a liability account, a connected account payout that crosses entities, a refund that reverses a split transaction — these are the entries standard tools miscategorize silently. Growthy surfaces them for review instead of posting a wrong answer at close. Built by a CPA firm partner who's unwound Connect mistakes under audit pressure. 85% of transactions categorize automatically. The rest you review.

Get Started with Growthy

Related: Stripe Payout vs. Transactions | Stripe Refunds and Chargebacks | Stripe Accounting Tools Compared