ERPClaw Stripe Connect Fees: Fields, Flows, and Events

If you run a marketplace or platform on Stripe Connect, you have an extra layer of complexity in your accounting: application fees, transfers, reverse transfers, and connected account payouts.

This page documents the three Stripe Connect patterns and the accounting for each.

What ERPClaw does for a Connect platform

Mark the Stripe account as a Connect platform (--is-connect-platform 1 on stripe-add-account, with a platform revenue account set through stripe-configure-gl-mapping). Then:

• Application fees are synced and posted: stripe-post-connect-fee-gl debits Stripe Clearing and credits your platform revenue account.
• Charges, refunds, disputes, and payouts post per Stripe account, the same as for any Stripe account.
• Transfers to connected accounts are synced and reported (stripe-list-transfers, stripe-connect-payout-report sums them by month, leaving out fully reversed transfers). They are not posted to the GL automatically; the transfer entries in the tables below are the treatment to post as journal entries.
• stripe-connect-revenue-report sums application fees by month, and stripe-connect-fee-summary summarizes them.

The worked entries below show the accounting for each pattern.

Use this reference for Stripe objects, ERPClaw configuration, events, refund flags, and ledger flow. For the accounting analysis and worked journal logic, read the Stripe Connect accounting guide.

Primary Stripe references: direct charges, destination charges, separate charges and transfers, the Connect charge types overview, and refund and dispute handling.

The three Connect patterns

Stripe Connect supports three ways to split a payment between your platform and a connected account.

Pattern 1: Direct charges

The customer’s payment is charged on the connected account’s books. Your platform takes a cut as application_fee_amount. Stripe deducts its processing fee from the connected account in this worked example, where that account is configured as the Stripe fee payer.

Customer pays $100. Your application fee is $10. Stripe fee is $3.20.

Connected account’s books:

Your platform’s books (separate ERPClaw account):

In ERPClaw, the platform side is the application fee entry, posted with stripe-post-connect-fee-gl.

Pattern 2: Destination charges

The customer’s payment is charged on your platform’s books. You specify a transfer_data.destination (the connected account) and a transfer_data.amount (how much to transfer).

Customer pays $100. You transfer $90 to the connected account (retaining $10 as platform revenue). Stripe’s processing fee comes off your platform’s side.

Your platform’s books:

The transfer is a separate event:

The transfer is a separate event that hits clearing and connect transfer.

Connected account’s books:

In ERPClaw, the charge posts from the synced charge; the transfer is synced and reported, and its entry is posted as a journal entry.

Pattern 3: Separate charges and transfers

You charge on your platform first, then transfer separately at any later time. Maximum control.

Customer pays $100, charged on your platform:

Later, you transfer $90 to the connected account:

When the transfer settles on the connected side, the connected account records:

And on the platform side, the pending transfer becomes an actual transfer:

In ERPClaw, the charge posts from the synced charge; the transfer entries are posted as journal entries, with the synced transfers as your source.

Refunds in each pattern

Direct charge refund

The refund happens on the connected account. Application fee may or may not be refunded depending on refund_application_fee=true.

If application fee refunded:

Connected account:

The customer refund is a separate event:

The original $3.20 processing fee remains in Stripe Fees. It is not reversed under standard pricing.

Platform:

If application fee NOT refunded (you keep your cut even on refund):

Platform: no journal entry. The $10 stays on your books.

Destination charge refund

Refund happens on platform. Optionally reverse_transfer=true to also reverse the transfer to the connected account.

If reverse_transfer=true:

Platform:

Then a Connect Transfer reversal moves the $90 back from the connected account to platform clearing. The original $3.20 processing fee remains in Stripe Fees, so the platform still bears that cost.

If reverse_transfer=false: connected account keeps the $90; platform absorbs the loss.

Separate refund

Reverse the charge first, then optionally reverse the transfer. Most flexible but requires more discipline.

Application fee refund only

Stripe lets you refund only the application fee without refunding the charge itself. This is useful when you over-charged a marketplace fee.

Platform:

The $5 is moved from your platform back to the connected account.

Multi-account dashboard

If you connect multiple Stripe accounts (your platform plus several connected accounts), each gets its own ERPClaw stripe_account row with its own GL account mapping. Reports run per account.

erpclaw stripe-list-accounts
erpclaw stripe-revenue-report --stripe-account-id <platform-id>
erpclaw stripe-revenue-report --stripe-account-id <connected-id>

When to choose which pattern

Direct charges: when each connected account has its own customer relationship, brand, and tax ID. Marketplace style (Etsy, Airbnb).

Destination charges: when your platform handles the customer relationship, your tax ID is on the receipt, and the connected account is just a payee. SaaS marketplace style (your platform sells, splits revenue with vendor).

Separate charges and transfers: when you need full control over when transfers happen (delayed payouts, escrow, hold-and-release flows).

ERPClaw records all three the same way (application fees posted, transfers synced and reported), so the pattern is a choice you make in Stripe, not a setting in ERPClaw. Mixing patterns within one platform is technically possible but produces messy books.

Source

• Stripe Connect docs: stripe.com/docs/connect
• ERPClaw Connect handler: github.com/avansaber/erpclaw-addons