Glossary

Stripe Transfer

A Stripe transfer is a movement of funds from a Connect platform’s own Stripe balance into a connected account’s Stripe balance, recorded as its own object with its own balance transaction, and involving no bank account on either side.

Also called: Connect transfer, transfer object, platform transfer, transfer to connected account

Start a free trial View Pricing

Definition

A transfer is money changing hands between two Stripe balances. Yours and somebody else’s.

That is the whole idea, and it is worth stating plainly because almost every confusion about transfers comes from expecting a bank to be involved. Nothing leaves the banking system when a transfer happens. Your Stripe balance goes down, a connected account’s Stripe balance goes up, and both of those balances are still sitting at Stripe afterwards.

Stripe describes the destination as "ID of the Stripe account the transfer was sent to", and the flow it belongs to as one where you "create a charge on your platform’s account and also transfer funds to your connected accounts", with those transfers "withdrawn from your account balance". A marketplace collects one payment from a buyer and then splits it, and the splitting step is the transfer.

The word is unfortunate. QuickBooks has a record type called Transfer, and it means moving money between two accounts you own, which is what a bank deposit from Stripe looks like. So the same word points in opposite directions depending on which system you are standing in. A Stripe transfer sends money to somebody else and touches no bank. A QuickBooks transfer moves your own money between your own accounts. Keeping those apart is most of what it takes to read a Connect platform’s books correctly.

Key points

+A transfer moves funds from the platform’s Stripe balance to a connected account’s Stripe balance. No bank account is involved.
+It is not a payout. A payout is the movement from a Stripe balance to a real bank account.
+Stripe records the receiving side separately: destination_payment is "the ID of the payment that the destination account received for the transfer".
+source_transaction is "ID of the charge that was used to fund the transfer. If null, the transfer was funded from the available balance."
+Stripe: "The default behavior is to transfer funds from the platform account’s available balance. Attempting a transfer that exceeds the available balance fails with an error."
+Stripe "doesn’t automatically retry failed transfer requests", and adding funds later does not retry them for you.
+transfer_group "only identifies associated objects. It doesn’t affect any standard functionality."
+reversed is "Whether the transfer has been fully reversed. If the transfer is only partially reversed, this attribute will still be false."
+amount_reversed carries the real figure, and "can be less than the amount attribute on the transfer if a partial reversal was issued".
+source_type names the balance the money came from: "One of card, fpx, or bank_account."

One movement, two objects, two sets of books

A transfer produces a record on each side, and they are different objects with different IDs.

On your side there is the Transfer itself, with a balance_transaction that Stripe describes as the entry that "describes the impact of this transfer on your account balance". On the connected account’s side there is a payment, and the Transfer points at it: destination_payment is documented as "If the destination is a Stripe account, this will be the ID of the payment that the destination account received for the transfer".

So a single business event, paying a seller their share, exists as an outgoing record in your ledger and an incoming record in theirs. Neither account sees both halves. If a connected account asks why their Stripe balance went up with no customer attached, this is the answer: the customer paid the platform, and what reached the seller was a transfer.

This also explains a reconciliation trap. The gross payment a buyer made and the amount a seller received are different numbers on different objects, and the difference is not only the platform’s cut. Stripe states that in this flow "Your account balance is debited for the cost of the Stripe fees, refunds, and chargebacks", so processing costs land on the platform rather than being netted out of the seller’s transfer. A platform that reads its own balance as revenue is reading a figure that has already absorbed somebody else’s money and its own costs at the same time.

source_transaction is the field that does something, transfer_group is not

These two fields look similar in an API call and behave nothing alike. Getting them the wrong way round is the most common way a transfer fails.

transfer_group is documentation. Stripe is blunt about it: "The transfer_group only identifies associated objects. It doesn’t affect any standard functionality." You can put any string in it, though Stripe asks that "it must represent a single business action". It is a label for finding related records later, and it changes no behaviour at all. Stripe fills it in even when you do not: if the source charge has a transfer_group, the transfer inherits it, and if it does not, Stripe generates one in the format "group_" plus the associated PaymentIntent ID and assigns it to both the charge and the transfer.

source_transaction is the one with teeth. It is documented as "ID of the charge that was used to fund the transfer. If null, the transfer was funded from the available balance." Setting it changes what happens, and Stripe points at it directly for this purpose: "To prevent a transfer from executing before the funds from the associated charge are available, use the transfer’s source_transaction attribute."

Why that matters is a timing problem. By default a transfer draws on your available balance, and Stripe states that "Attempting a transfer that exceeds the available balance fails with an error". Card money is not available the instant a customer pays. So a platform that transfers a seller’s share immediately after checkout is spending money it does not yet have, and the request fails. Tie the transfer to the charge and, in Stripe’s words, "the transfer request returns success regardless of your available balance if the related charge hasn’t settled yet".

Read the next sentence carefully, because it is the part people miss: "However, the funds don’t become available in the destination account until the funds from the associated charge are available to transfer from the platform account." The transfer succeeding and the seller being able to spend the money are two different moments. You have bought yourself a successful API call and a clean record, not instant settlement.

One more operational detail worth knowing before it bites: Stripe "doesn’t automatically retry failed transfer requests", and spells out that "If a transfer fails due to insufficient funds in your platform balance, adding funds doesn’t automatically retry the failed action. After adding funds, you must repeat any failed transfers or payouts." A failed transfer stays failed until a human or a job does it again.

The reversed flag hides partial reversals

If you are reading transfer data to work out what a seller actually kept, one boolean will mislead you.

Stripe documents reversed as "Whether the transfer has been fully reversed. If the transfer is only partially reversed, this attribute will still be false." That second sentence is the whole warning. A transfer of 500 dollars with 400 dollars clawed back reports reversed as false, exactly like a transfer nothing has happened to.

The number you want is amount_reversed, "Amount in the smallest currency unit reversed", which Stripe notes "can be less than the amount attribute on the transfer if a partial reversal was issued". Alongside it, reversals is "A list of reversals that have been applied to the transfer", so the individual events are there if you need to date them rather than total them.

The practical rule is to treat reversed as a shortcut for one specific question, whether the whole thing was undone, and never as an answer to whether anything was undone. For any figure that ends up in your accounts, compare amount against amount_reversed. A filter written as "reversed is false" will quietly include every partially reversed transfer in your totals at full value.

Why a transfer is not a payout, and why that matters at month end

Both words describe money leaving your Stripe balance, which is why they get used interchangeably, and they settle in completely different places.

A payout ends at a bank account you own. Cash arrives, the bank feed shows it, and it can be matched. A transfer ends at another Stripe account. Nothing appears in any bank feed you can see, because no bank was involved on either side.

That difference decides how each one behaves in your books. A payout is a movement between two accounts you control, which is exactly what an accounting transfer is. A transfer to a connected account is money going to somebody else, which makes it a cost or a settlement of an obligation, not a movement of your own funds.

It also decides what happens when they go wrong. A failed payout returns funds to your Stripe balance and no deposit appears at the bank. A failed or reversed transfer returns funds to your Stripe balance too, but the counterparty’s balance is the other side of it, and Stripe records that as its own type rather than editing the original.

For anyone reconciling a Connect platform, the useful mental model is that transfers never change the total amount of money sitting in the banking system. They only change whose Stripe balance holds it. The only line that moves real cash is the payout.

What Acodei documents about Connect transfers

Acodei’s balance transaction documentation covers the transfer family directly, and the treatment follows from the fact that no bank is involved.

A transfer is described as a "Direct transfer of funds from platform to connected account", and is imported and "Recorded as an Expense or Transfer out of Stripe holding", usually logged as an expense on the daily summary, debiting the Stripe holding account. The documentation is explicit about why it looks the way it does: this is "money out to a connected party" with "No bank movement".

That has a consequence worth stating for anyone reconciling. Because transfers to connected accounts do not involve your bank, the documentation notes they only affect the Stripe clearing or holding account in QuickBooks. Your holding account balance goes down when transfers go out and up if any come back, and none of it appears in a bank feed.

The reversal types are documented alongside it. 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. For transfer_cancel and transfer_failure, the documented intent is that they offset the original so the net effect in QuickBooks is zero, either by not creating the original expense or by creating an equal opposite entry. Acodei’s own documentation flags that these two types were not explicitly in earlier allowed lists, so it treats manual adjustment as a possibility rather than promising the offset in every case. If you find a transfer expense with no matching credit after a known failure, that is the documented situation to resync rather than to assume.

Two limits are worth knowing before you design a chart of accounts around this. Acodei does not create individual connected account records in QuickBooks, so transfers are recorded generally against the platform’s books rather than per counterparty. And there is typically no dedicated mapping for these types, so they use defaults. Where uncommon balance transaction types do get a home, it is under Account Mapping then Balance Transaction Mapping, which stays hidden until Customize is toggled.

One naming point closes the loop with the section above. The QuickBooks Transfer record type does appear in Acodei, just not for this. It is what a payout and a top-up produce, both of which move money between your bank and your Stripe holding account. A Connect transfer, which sends money to somebody else entirely, is the documented Expense or Transfer out of holding. Same word, two jobs.

Whichever direction the money went, the account it moves through is the same one, which is how the Stripe clearing account stays tied to the Stripe balance.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What is a Stripe transfer?

It is a movement of funds from a Connect platform’s own Stripe balance into a connected account’s Stripe balance. Stripe documents the destination as "ID of the Stripe account the transfer was sent to". No bank account is involved on either side, and both balances remain at Stripe afterwards.

What is the difference between a Stripe transfer and a Stripe payout?

A payout moves money from a Stripe balance to a bank account you own, so cash arrives and appears in your bank feed. A transfer moves money from your Stripe balance to somebody else’s Stripe balance, so no bank is involved and nothing appears in any bank feed. A payout changes where your money sits. A transfer changes whose money it is.

Why did my Stripe transfer fail?

The most common documented reason is available balance. Stripe states that "The default behavior is to transfer funds from the platform account’s available balance. Attempting a transfer that exceeds the available balance fails with an error." Card payments are not available immediately, so a transfer created right after checkout can exceed the available balance. Stripe also notes it "doesn’t automatically retry failed transfer requests", and that adding funds afterwards does not retry them, so a failed transfer has to be repeated.

What does source_transaction do on a Stripe transfer?

It ties the transfer to the charge that funds it. Stripe documents it as "ID of the charge that was used to fund the transfer. If null, the transfer was funded from the available balance", and recommends it "To prevent a transfer from executing before the funds from the associated charge are available". With it set, "the transfer request returns success regardless of your available balance if the related charge hasn’t settled yet", though Stripe adds that "the funds don’t become available in the destination account until the funds from the associated charge are available to transfer from the platform account".

Does transfer_group affect how a transfer behaves?

No. Stripe states that "The transfer_group only identifies associated objects. It doesn’t affect any standard functionality." It is a label for grouping related records, and Stripe populates it automatically when you do not: the transfer inherits the source charge’s transfer_group, or Stripe generates one in the format "group_" plus the PaymentIntent ID and assigns it to both objects. If you want to change behaviour, source_transaction is the field that does that.

Why does reversed say false on a transfer that was partly clawed back?

Because it only reports full reversals. Stripe documents reversed as "Whether the transfer has been fully reversed. If the transfer is only partially reversed, this attribute will still be false." Use amount_reversed for the actual figure, which Stripe notes "can be less than the amount attribute on the transfer if a partial reversal was issued", and the reversals list for the individual events.

How does Acodei record a Stripe transfer in QuickBooks?

Acodei’s documentation describes a transfer as a direct transfer of funds from platform to connected account, imported and recorded as an Expense or Transfer out of Stripe holding, usually logged as an expense on the daily summary and debiting the Stripe holding account. Because there is no bank movement, the documentation notes it only affects the Stripe clearing or holding account in QuickBooks.

Does Acodei track which connected account a transfer went to?

Not as separate records. Acodei’s documentation states it does not create individual connected account records in QuickBooks, so transfers are recorded generally against the platform’s books, and it notes there is typically no dedicated mapping for these types, so they use defaults. Tracking amounts by counterparty is something to handle in your own chart of accounts.

What happens in QuickBooks if a transfer fails or is reversed?

A transfer_refund is documented as imported and recorded as a credit, a negative expense returning funds, which offsets the earlier transfer entry. For transfer_cancel and transfer_failure the documented intent is a net effect of zero, either by not creating the original expense or by creating an equal opposite entry, with Acodei’s own documentation noting these types were not explicitly in earlier allowed lists and that manual adjustment may be needed. If one side is missing after a known failure, resync that date.

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