Refunding a Stripe Connect Charge in QuickBooks

A customer books a $200 service on your marketplace. You keep $30, the seller gets $170, Stripe takes $6.10, and $23.90 lands in your bank. That sequence is well understood, and we have walked the journal entries for it end to end.

Then the customer asks for their money back.

Now answer this: whose balance pays the $200? Does the seller give back the $170? Do you keep the $30? Does Stripe return the $6.10?

Every one of those has a different answer, three of them are configurable, and QuickBooks will not work any of it out for you. A refund on a Connect platform is not one event reversing one event. It is up to four separate money movements, and if you post the refund without posting the other three, your books say you personally absorbed $200 of somebody else's revenue.

Running a Connect platform on QuickBooks? Acodei posts Stripe charges, transfers, platform fees, and payouts into QuickBooks Online as they happen. Start a free trial.

The refund comes out of your balance, not the seller's

Start here, because it inverts most people's intuition.

On direct charges, where the payment was created on the connected account, Stripe is straightforward: refunds and chargebacks reduce the connected account's balance. The seller took the money, the seller gives it back.

On destination charges and separate charges and transfers, which is what most marketplaces run, Stripe says the opposite. From the Connect charges documentation: "Stripe debits your platform balance for the refund amount. You can reverse the transfers made to your connected accounts to recover your refund cost."

Read that second sentence carefully. Can. Not does.

The refund is automatic and immediate against your balance. Clawing it back from the seller is a separate action you have to take, and if you never take it, the $170 stays with the seller and you are $170 poorer. Stripe will not stop you. There is no error, no warning, and nothing in your QuickBooks file that looks obviously wrong until someone asks why platform margin went negative in a month with normal volume.

There is one guard worth knowing. If your platform balance is short when you issue the refund, Stripe marks the refund pending and processes it automatically once funds arrive. But if the refund request also attempts a transfer reversal and the connected account has an insufficient balance, Stripe returns an error instead of creating a pending refund. The combined operation fails rather than half-completing, which is the behaviour you want.

Two parameters decide everything

When you create the refund, two optional parameters control the other three money movements. They are the whole ballgame, and most platforms set them once during implementation and never think about them again.

refund_application_fee decides whether your platform fee comes back to the customer's side of the ledger. Set it and Stripe creates an Application Fee Refund object, which carries the fr_ prefix and an object type of fee_refund, pointing at the original fee it reverses. Your $30 of platform revenue goes away.

reverse_transfer decides whether you claw the money back from the seller. Set it and Stripe creates a Transfer Reversal, prefixed trr_. The object records source_refund, documented as "ID of the refund responsible for the transfer reversal", and destination_payment_refund for the corresponding record on the connected account's side. The seller's $170 comes back to your balance.

Those two flags are independent, which produces four different commercial outcomes from the same customer-facing refund:

reverse_transfer	refund_application_fee	Who absorbs the $200
Yes	Yes	Nobody. Seller returns $170, you forgo $30. Both parties unwound.
Yes	No	The seller alone. They return $170 and you still keep $30 on a sale that did not happen.
No	Yes	You alone, twice over. You pay $200 and forgo $30 revenue.
No	No	You pay $200 and keep $30, so you are down $170 net.

Row two is a real business model, not a mistake. Plenty of platforms keep their fee on refunded transactions because the work of facilitating the sale was already done. What matters is that it is a decision, and that whoever maintains your chart of accounts knows which row you are on.

Row four is the one that is almost always an accident. It looks fine in Stripe, because the refund succeeded. It is only visible in QuickBooks, as a slow leak in margin.

The Stripe processing fee is the fourth movement, and it is the simple one, because it is not a choice. Stripe states it plainly in the refunds documentation: "Stripe's processing fees from the original transaction aren't returned." The same page notes a refund itself "might incur a fee". That cost stays on your P&L whatever you do with the other three.

What each piece becomes in QuickBooks

Each of these movements is a balance transaction with its own type, and Acodei's documentation covers the family directly.

The platform fee posts as income. An application_fee is imported and recorded as income to the platform, appearing on daily summary as a separate positive line on that day's summary deposit, using a product mapped to an income account where one is available and the default sales item otherwise. Worth knowing: these do not arrive by real-time webhook. Acodei's documentation notes that Stripe does not fire an explicit webhook to the platform for its fee unless the platform listens for application_fee.created, so the daily payout or balance summary is what catches them.

The platform fee refund reverses it. An application_fee_refund is posted as negative income offsetting the original fee income, shown on daily summary as a negative line reducing that day's income. If you are on row one or three of the table above, this is the line that makes your revenue tell the truth.

The transfer out is an expense. A transfer is imported and recorded as an Expense or Transfer out of the Stripe holding account, usually logged as an expense on the daily summary. Acodei's documentation is direct about why it looks that way: this is money out to a connected party, with no bank movement.

The transfer reversal is a credit back. A transfer_refund is imported and recorded as a credit, a negative expense returning funds, which adds to that day's total on the daily summary and offsets the earlier transfer entry.

Put together, a fully unwound refund on our $200 example leaves the P&L showing no platform revenue, no transfer expense, and a $6.10 processing cost you cannot recover. Your clearing account absorbs the $200 and the $170 coming back, and the net $30 reduction flows through to a smaller future payout. Nothing in that sequence touches your bank feed, which is exactly why it goes unnoticed. If your clearing account is not set up to mirror the Stripe balance, none of these movements have anywhere to live; our walkthrough on the Stripe clearing account covers the structure.

Two limits to design around

Acodei does not create individual connected account records in QuickBooks. Transfers are recorded generally against the platform's books rather than per counterparty, so if you want amounts owed to each seller tracked as separate payables, that is a manual structure you build yourself.

There is also typically no dedicated mapping for these transfer types, so they use defaults. Where uncommon balance transaction types do get a specific home, it is under Account Mapping and then Balance Transaction Mapping, a section that stays hidden until you toggle Customize. A platform doing frequent transfers may want them in a named expense account rather than a default, and today that means reassigning after sync.

When the reversal itself fails

A transfer reversal is a request against somebody else's balance, and it can fail. The intended behaviour is that a transfer_cancel or transfer_failure offsets the original so that the net effect in QuickBooks is zero, either by never creating the expense or by creating an equal opposite entry.

Acodei's own documentation is careful here rather than confident, and it is worth repeating the caution rather than smoothing it over: these two types were not explicitly in earlier allowed lists, and the documentation treats manual adjustment as a possibility rather than promising the offset in every case. What it commits to is the net effect and the remedy. If you find a transfer expense with no matching credit after a known failure, resync the affected date from the Data Feed rather than assuming the offset happened, and rather than hand-journalling a correction that a later resync would double.

The dispute case is the same problem with less time

A chargeback on a Connect platform behaves like a refund you did not choose, and Stripe removes the optionality: for disputes on destination charges or separate charges and transfers, with or without on_behalf_of, your platform balance is automatically debited for the disputed amount and the fee. Recovery is again yours to initiate, by reversing the transfer through the Dashboard or the API.

So the default outcome of a dispute is that the platform eats the whole thing, seller share included, plus a dispute fee that no reversal recovers. If the connected account ends up negative, Stripe attempts to debit its external account on file only when debit_negative_balances is set to true, which is a setting worth confirming before you need it rather than after.

In QuickBooks, the dispute itself does not appear as its own record. Acodei imports the balance adjustment but does not create a standalone QuickBooks transaction for it; instead it reverses or removes the original entry, so a disputed invoice payment is deleted and the invoice reopens as unpaid. On daily summary the adjustment folds into that day's deposit as a negative. And a won dispute is not automatically re-posted as a new payment, so an invoice left open after a chargeback you later won is expected, and recording the recovered payment is a manual step.

That is the never-regress rule for this whole area, and it is worth stating plainly: disputes reach your books through balance transaction mapping onto the daily balance summary or the payout deposit. There is no per-dispute journal entry to go looking for.

One case where the documentation stops, and so should you

If a connected account stays negative long enough, Stripe stops waiting. At the 180-day mark it permanently sweeps funds from the platform balance to cover that account's debt, producing a connect_collection_transfer. That is Stripe's behaviour and it is well established.

What happens to it in QuickBooks is a different question, and the honest answer is that Acodei's documentation does not currently state one. The type was reviewed during code verification in August 2026 and no implementing handling was found in the line builders, the allowed-type seeders, or Balance Transaction Mapping. The treatment previously described could not be confirmed, so it is flagged unverified rather than documented.

We are telling you that instead of describing a treatment, because a permanent loss of platform funds is precisely the kind of number you should not book on the strength of a guess. If you are carrying negative connected balances toward the 180-day mark, ask support how the sweep lands in your configuration before it happens. Reserve holds, which are the temporary version of the same story and behave very differently, we cover in Stripe reserves and holds.

Frequently asked questions

Who pays for a refund on a Stripe Connect platform?

It depends on the charge type. On direct charges, refunds and chargebacks reduce the connected account's balance, so the seller pays. On destination charges and separate charges and transfers, Stripe debits your platform balance for the refund amount, and recovering the seller's share is a separate action you have to take by reversing the transfer.

Does the platform fee come back automatically when I refund?

No. It comes back only if you set refund_application_fee on the refund. Doing so creates an Application Fee Refund object, which reverses the original fee. Leave it unset and you keep your platform fee on a sale that did not happen, which is a legitimate business model but needs to be a deliberate one.

What is the difference between reverse_transfer and refund_application_fee?

They control two different money movements and are independent of each other. reverse_transfer claws back the amount you sent to the connected account, creating a Transfer Reversal. refund_application_fee gives back the fee you earned, creating an Application Fee Refund. You can use either, both, or neither, and the four combinations produce four different answers to who absorbs the cost.

Does Stripe refund its processing fee?

No. Stripe's refunds documentation states that "Stripe's processing fees from the original transaction aren't returned", and notes that issuing a refund might itself incur a fee. That cost stays on your profit and loss statement no matter how you handle the transfer and the platform fee.

Why does my QuickBooks show a transfer expense with no matching credit?

That pattern is what a failed or canceled transfer reversal looks like when only one side posted. The documented intent is that the two offset to a net effect of zero, but Acodei's documentation is explicit that these types may require manual adjustment rather than promising the offset in every case. Resync the affected date from the Data Feed rather than hand-journalling a correction, since a later resync would double it.

Where does a chargeback on a Connect platform appear in QuickBooks?

Not as its own record. Acodei imports the balance adjustment but does not create a standalone QuickBooks transaction for it. Instead the original entry is reversed or removed, so a disputed invoice payment is deleted and the invoice reopens as unpaid. On daily summary the adjustment folds into that day's deposit. A dispute you later win is not automatically re-posted as a payment, so recording the recovered money is a manual step.

The short version

• On destination and separate charges, a refund hits your balance first. Recovering the seller's share is an action you take, not a thing that happens.
• reverse_transfer and refund_application_fee are independent, and their four combinations are four different answers to who absorbs the loss.
• Stripe's processing fee is not returned. That cost is yours regardless.
• A fully unwound refund produces four QuickBooks movements, and none of them appear in your bank feed.
• Disputes are the same shape with the optionality removed and a fee attached.
• If a number depends on a behaviour nobody has verified, leave it out of the ledger and go ask.

If you would rather not track four movements per refund by hand, that is the job Acodei does: Stripe events become QuickBooks records as they happen, including the reversal side. Start a free trial.

Sources: Stripe's refunds documentation and Connect charges documentation for charge types, refund liability by type, pending refund behaviour, and dispute debits; the Transfer Reversal object and Application Fee Refund object API references, all fetched 9 September 2026. Acodei behaviour from the Balance Transaction Handling product documentation, code-verified 8 August 2026.