Glossary

Stripe Separate Charges and Transfers

Separate charges and transfers is the Stripe Connect flow in which a platform creates a charge on its own account and then creates one or more independent transfers to connected accounts, so the payment and the split are separate API calls whose amounts and timing the platform decides.

Also called: separate charges and transfers, charges and transfers, manual transfers Connect, split payment between connected accounts

Start a free trial View Pricing

Definition

Stripe puts the design in one sentence, and the sentence is the whole thing: with this flow you "create charges on your platform and split funds between multiple connected accounts, or hold them when you don’t know the specific user at the time of the charge", and "The charge on your platform account is decoupled from the transfers to your connected accounts."

Decoupled is the operative word. With a destination charge the split is a parameter on the payment and Stripe performs it for you at the moment of the charge. Here there is no such parameter. You take the money, and then, as a separate decision at a time of your choosing, you move some of it onward. Stripe describes the first step plainly: "You create a charge on your platform’s account first. Create a separate transfer to move funds to your connected account."

Stripe files both under indirect charges, payments "made to your platform" where funds then move "to Stripe as fees and to the connected account as its portion of the payment", and notes that the two indirect types "differ in the way they transfer funds from your platform to connected accounts". Destination charges differ by doing it automatically. This one differs by not doing it at all until you say so.

What the freedom buys is the ability to express things no other charge type can: one payment divided between several sellers, a payment taken before you know who will fulfil it, or a payout to a seller larger than the payment that funded it. What it costs is that nothing settles itself. Stripe is unusually direct about the trade, saying these "require a more complex Connect integration. Use them only if your business use case requires them".

Key points

+Stripe: "The charge on your platform account is decoupled from the transfers to your connected accounts."
+Stripe: "You create a charge on your platform’s account first. Create a separate transfer to move funds to your connected account."
+The transfer amount is "determined by you", and is "withdrawn from your account balance".
+Stripe: "You can transfer funds to multiple connected accounts."
+Stripe: "Your account balance is debited for the cost of the Stripe fees, refunds, and chargebacks."
+Stripe recommends against it by default: these "require a more complex Connect integration. Use them only if your business use case requires them".
+Stripe: "In some cases, the transfer amount can be greater than the charge amount, or the transfer is made before the payment is processed. You must monitor your account balance carefully to make sure it has enough available funds to cover the transfer amount."
+Stripe: "Charges use your platform’s payment method configurations, unless they use on_behalf_of."
+On a refund, "Stripe debits your platform balance for the refund amount. You can reverse the transfers made to your connected accounts to recover your refund cost."

The five cases Stripe says justify the complexity

Stripe does not leave the decision to taste. It lists the situations that warrant this flow, and if yours is not among them the recommendation is to use a destination charge instead.

The first is a one-to-many relationship. Stripe’s example is "a payment made to a delivery service needs to be split between the store (the source of the items being delivered) and the delivery person". One customer payment, two recipients, which no single charge parameter can describe.

The second is many-to-one, illustrated as "a carpool trip with a ride-hailing service". Several payments converging on one recipient.

The third is charges created before the destination account is known. Stripe’s example is that "a janitorial service could process a payment before deciding which janitor to assign to the job". The money is collected while the answer to who gets paid is still open.

The fourth is needing "to transfer funds before receiving a payment, or while the charge is pending", for which Stripe describes "an ad network [that] needs to purchase ad space before they can sell ad time or before receiving any payment from customers". The outgoing leg comes first.

The fifth is transfer amounts greater than the associated payments, where "a platform provides a discount to its customer but pays its user the full amount". The seller is made whole and the platform absorbs the difference.

Read as a set, these are all cases where the relationship between one payment and one payout is not one to one, not simultaneous, or not even the same size. That is the real test. If your payments map cleanly onto single recipients at predictable percentages, this flow gives you extra work and no extra capability.

Either order, which is exactly what makes reconciliation harder

Because the two legs are independent, a platform on this flow has two streams of objects to account for rather than one, and nothing in the data model guarantees they line up in time or in amount.

With a destination charge there is a single object that knows both halves. Here the charge knows nothing about the transfer by default, and the transfer knows nothing about the charge unless you tell it. That is a design freedom during integration and a joining problem afterwards, because the answer to "what did we keep on this sale" is not on either record by itself.

Stripe flags the cash-flow consequence rather than the bookkeeping one, and the warning is worth quoting in full: "In some cases, the transfer amount can be greater than the charge amount, or the transfer is made before the payment is processed. You must monitor your account balance carefully to make sure it has enough available funds to cover the transfer amount." It then offers the mitigation: "You can also associate a transfer with a charge so the transfer doesn’t occur until the funds from that charge are available."

That association is the field that ties the legs back together, and the timing behaviour it produces is specific enough to deserve its own treatment. The transfer object, the field that funds it, the label that only looks like it does, and the reversal flag that hides partial clawbacks are all covered under the Stripe transfer itself.

For month-end purposes the practical shape is this. Your platform balance is the account where every leg meets: charges increase it, transfers decrease it, and Stripe’s fees, refunds and chargebacks come out of it. So the platform balance, not any individual charge, is the thing your books have to agree with.

Refunds and disputes hit your balance first, and recovery is a second action

This flow puts the platform in front of everything that goes wrong, and getting money back from a connected account is always a separate step you have to take.

On refunds, Stripe states that "Stripe debits your platform balance for the refund amount. You can reverse the transfers made to your connected accounts to recover your refund cost." Note the order: you are out the money first, and recovery is optional and manual. Stripe also documents what happens when you cannot cover it, saying that if your platform balance lacks the funds when you issue the refund, "we set the refund status to pending", and when the balance has enough, "Stripe automatically processes pending refunds and updates their status to successful".

Disputes work the same way and cost more. For payments created on your platform using this flow, "with or without on_behalf_of, your platform balance is automatically debited for the disputed amount and fee". Recovery again runs through reversing the transfer, which Stripe says a platform "can attempt" either through the Dashboard or using the API. If that leaves the connected account negative, Stripe "attempts to debit the external account on file for the connected account only if debit_negative_balances is set to true".

The accounting consequence is that a chargeback on a sale you have already transferred out is a two-sided event: a debit you definitely take, and a recovery you might not get. Booking the debit and the reversal as one net number assumes an outcome that is not yet decided.

Two constraints that decide whether you can use this at all

Both are easy to miss until an integration is built, and one of them is geographic.

Stripe supports "cross-region funds flows between platforms and connected accounts only in certain regions" for this flow. Outside those, "the platform and connected account must be in the same region unless using on_behalf_of". So a platform paying sellers in another region may find the parameter it was avoiding is the one thing that makes the flow legal for it.

The second is whose payment methods apply. Stripe says "Charges use your platform’s payment method configurations, unless they use on_behalf_of". Because the charge is created on your account, the customer is transacting with your configuration and, absent on_behalf_of, your account is the one the statement and the fee treatment follow. Stripe notes that destination charges and separate charges and transfers "typically use the platform’s pricing plan and are assessed on the platform", and that when on_behalf_of is set, "the country of the connected account is used to determine the country specific fees charged to your platform account".

What Acodei records when a platform runs this flow

Connect activity reaches QuickBooks as balance-transaction types rather than as a reconstruction of the Connect flow that produced it. Acodei documents each type as bucketed by day and currency, becoming a line item whose QuickBooks account is determined by the product you map to that type under Account Mapping, then Balance Transaction Mapping.

For this flow the types that matter have their own handling. The transfer type is bucketed as its own line and signed by the direction of the amount, so outgoing movement and anything coming back net within the type rather than landing in unrelated places. Application fees are bucketed as their own line on the same signed basis, and application fee refunds are handled as their own type in payout line building. Reserve movements are bucketed together as one line type.

The important point for anyone designing a chart of accounts around this: the account is your choice, not a fixed treatment. Acodei’s documentation is explicit that per-type accounting treatments are consequences of how you map the type, so the same transfer line can land in a cost of sales account on one company file and a liability account on another, and the mapping is where that gets decided.

One consequence of the daily bucketing is worth planning for. Because lines are grouped by day and currency, a day with six transfers to six sellers arrives as transfer volume for that day rather than as six separately identifiable movements, so per-counterparty detail is something to keep on the Stripe side or in your own subsidiary records.

Whichever leg you are looking at, the account they all pass through is the same one, which is which QuickBooks account each leg of a split payment lands in.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What are separate charges and transfers in Stripe Connect?

It is the Connect flow where you create a charge on your own account and then create independent transfers to connected accounts. Stripe describes it as letting you "create charges on your platform and split funds between multiple connected accounts, or hold them when you don’t know the specific user at the time of the charge", and states that "The charge on your platform account is decoupled from the transfers to your connected accounts."

How is this different from a destination charge?

Both are indirect charges, so the payment lands on your platform either way. The difference is who performs the split and when. A destination charge carries the destination as a parameter and Stripe transfers the funds automatically at the time of the charge. With separate charges and transfers there is no such parameter: you create the transfer yourself, for an amount "determined by you", at a time you choose, and you can send it to more than one connected account.

When should I use separate charges and transfers?

Only when your use case requires it. Stripe says these "require a more complex Connect integration" and lists the justifying cases: a one-to-many relationship such as splitting a delivery payment between a store and a courier, a many-to-one relationship such as a carpool trip, charges created before the destination account is known, needing to transfer funds before receiving payment or while a charge is pending, and transfer amounts greater than the associated payments.

Can one charge be split between several connected accounts?

Yes, and this is the main reason the flow exists. Stripe states plainly that "You can transfer funds to multiple connected accounts", and gives the example of "an e-commerce marketplace that allows a single shopping cart for goods sold by multiple businesses". Each transfer is its own object withdrawn from your account balance.

Can I transfer more than the customer paid?

Stripe allows it and treats it as one of the justifying use cases, describing a platform that "provides a discount to its customer but pays its user the full amount". It also warns about the consequence: "In some cases, the transfer amount can be greater than the charge amount, or the transfer is made before the payment is processed. You must monitor your account balance carefully to make sure it has enough available funds to cover the transfer amount."

Who pays for refunds and chargebacks on this flow?

Your platform, first. Stripe states that "Your account balance is debited for the cost of the Stripe fees, refunds, and chargebacks", and for disputes that "your platform balance is automatically debited for the disputed amount and fee". Recovery is a separate action: you can reverse the transfer through the Dashboard or the API, and if that leaves the connected account negative, Stripe attempts to debit its external account only when debit_negative_balances is set to true.

What happens if my platform balance cannot cover a refund?

Stripe holds it rather than failing it. If your platform balance does not have the funds when you issue the refund, Stripe documents that "we set the refund status to pending", and that once the balance has enough, "Stripe automatically processes pending refunds and updates their status to successful".

Can my platform and connected accounts be in different countries on this flow?

Sometimes. Stripe supports "cross-region funds flows between platforms and connected accounts only in certain regions" for separate charges and transfers, and states that for other regions "the platform and connected account must be in the same region unless using on_behalf_of".

How does Acodei post this activity to QuickBooks?

As balance-transaction lines rather than as a reconstruction of the flow. Acodei documents Connect types as bucketed by day and currency, with the transfer type and application fees each bucketed as their own line signed by the direction of the amount. Which QuickBooks account a line reaches is set by the product you map to that type under Account Mapping, then Balance Transaction Mapping, so the treatment is your configuration rather than a fixed rule.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy