Stripe Inbound Transfer

A pull needs permission, and that shapes the setup

Creating an inbound transfer takes four things: an amount in cents, a currency, the financial account receiving the money, and an origin payment method that is the source of funds.

That last one carries all the setup. Stripe requires that you first attach the payment method for inbound flows and verify the bank account using a setup intent, or else use an existing bank account already set up as a verified external account. Either way, Stripe is explicit that you need the account holder’s permission to debit the funds. You are authorising a withdrawal from your own bank, and the mandate for it has to exist before the transfer does.

The constraints are narrower than people expect. The only payment method type Stripe documents for an inbound transfer is a US bank account, and usd is currently the only supported currency value. So an inbound transfer is a US ACH mechanism, not a general way to fund a balance from anywhere.

There is also a boundary worth reading twice, because getting it wrong is an expensive detour. Inbound transfers move funds from the financial account owner’s own bank account, and Stripe states they do not support moving funds from a third-party external account. If you want to accept money from somebody else into a financial account, Stripe routes you somewhere else entirely: take an ACH debit payment into the payments balance, then pay out from there to the financial account. Those are two different objects producing two different sets of records.

Funding a financial account is not topping up your balance

Stripe gives you two balances, and they are funded by different objects. This is the single most common place an inbound transfer gets confused with something else.

Acodei’s documentation separates them clearly. The payments balance is the classic Stripe balance, used for collecting payments, issuing refunds and receiving payouts from Stripe. The financial account balance is the one that behaves like a real bank account with its own ledger. An inbound transfer lands in the second one.

A top-up is the object that funds the first one. If you have read our note on recording Stripe top-ups, the distinction is worth holding onto: both are you sending your own money to Stripe, both are a Transfer in QuickBooks, and they arrive in different balances. The destination account in QuickBooks is what tells them apart, because a top-up lands in the Stripe payments holding account and an inbound transfer lands in the financial account holding account.

There is a third way money reaches the financial account, and it is not a funding decision at all. Acodei documents that a payout from the Stripe payments balance into the financial account is recorded as a Transfer between those two holding accounts. That one is internal: you are moving money you already had at Stripe from one Stripe balance to the other.

If you are scanning a financial account holding account at month end, those three sources look similar in the register and mean three different things. One is new money from your bank, one is money that was already at Stripe, and one never touches the financial account at all.

Two ways money arrives, booked from two different accounts

An inbound transfer is not the only object that puts money into a financial account, and the difference between it and its sibling is not cosmetic. It changes which QuickBooks account the money appears to come from.

Acodei’s documentation sets out both. For an inbound transfer, the Transfer is drawn from your external bank account as mapped on the Account Mapping page. For a received credit, which represents funds entering the financial account balance from an external source, the Transfer is drawn from your default payment bank account.

So two movements of the same size into the same financial account holding account can credit it from two different places, depending on which object Stripe recorded. That is worth knowing before you go looking for an error that is not there.

The distinction in substance is who initiated it. An inbound transfer is a pull you instructed, against an account you nominated. A received credit is money arriving, typically from an external bank transfer, which you did not have to initiate for it to land. Acodei adds one documented refinement on the received credit side: when the funds entering the financial account balance come from the Stripe payments balance, it is treated as a payout from Stripe Payments instead.

The mapping section these draw on is the same one outbound transfers use. Acodei’s Account Mapping page has a section for the external bank accounts connected to your financial account, which are owned by the business and used to send or receive money from the financial account balance. Inbound and outbound are documented there as the two directions on that same mapped pair.

The statuses, and the two that leave no record

Stripe’s API reference documents four statuses for an inbound transfer: processing, succeeded, failed and canceled. A transfer is processing while it is created and pending. It becomes succeeded once the funds are confirmed and a transaction is created and posted. It becomes failed if the transfer does not go through.

Two of those four produce nothing for your books, and that is the useful part. Stripe states that when an inbound transfer fails, no transaction is created and the payment method has not been debited. A canceled transfer was stopped before it reached the network, and Stripe voids the transaction so no funds move from the external bank account. In both cases the money never left your bank.

That is the answer to the question this object generates most often, which is why a transfer you are sure you initiated has produced no entry anywhere. If nothing moved, there is nothing to record. The place to check is the status rather than the sync.

Stripe’s Treasury guide documents one further holding state that the object reference does not list: requires_confirmation, which applies to financial accounts that have the platform review feature enabled. A transfer in that state has not been sent to the network and has to be explicitly confirmed before it is. The guide gives five business days to confirm or cancel, after which the transfer is automatically canceled. Because the two Stripe pages differ here, treat requires_confirmation as conditional on that feature rather than as part of the ordinary lifecycle.

When a transfer does fail, Stripe attaches a reason. The documented codes cover the bank account being closed, frozen or restricted, the account number being invalid or not existing, debits not being authorised on the account, insufficient funds, an unsupported currency, incorrect account holder name, address or tax ID, a branch ownership change, and a generic fallback. One of those is less obvious than it looks: a restricted bank account normally means the account is a savings or other non-checking account, which is a configuration problem rather than a transient failure.

A transfer that settled can still come back

This is the fact that makes an inbound transfer more than an outbound transfer in reverse, and it is the one worth designing a close around.

ACH debits can be returned. Stripe documents that inbound transfers can be returned after reaching the succeeded state if the external account pulls its funds back, and that when this happens the returned flag on the object becomes true and a received debit is added to the linked flows. The original transfer is not erased. A second, opposite movement is created alongside it.

The timing is what makes this awkward. A transfer can succeed, post to the financial account, and be reported in a period you have already reviewed, and the return can arrive days later inside the ACH return window. Stripe is direct about the risk in its guidance on faster settlement: a returned debit can leave a financial account negative if the funds were spent in the meantime. For the same reason, Stripe offers a funds availability delay on confirmation, and notes that holding funds past the return window stops the originating bank recalling money that has already been spent.

There is a limit to what we can tell you about the QuickBooks side of a return, and it is better to say so than to guess. Acodei’s documentation describes received debits as money taken out of the financial account, usually from a card payment made with a Stripe-issued card, recorded as a Purchase or Expense from the financial account holding account. It does not describe the return case specifically. A returned inbound transfer is therefore a case to verify against your own books rather than assume, because treating returned funding as an expense and treating it as a reversed transfer produce very different profit and loss.

The practical close step is small. If you funded a financial account near period end, check the transfer still reads succeeded and that its returned flag is still false before you rely on the balance.