Stripe Multiple Bank Accounts and QuickBooks Payout Routing

A payout of $18,402.11 left your Stripe balance on Tuesday. In QuickBooks the clearing account was relieved for exactly that, so the sync clearly worked. The money landed in the wrong bank account.

Nothing failed. No error was raised. The transfer did what it was configured to do, and the configuration had two halves that nobody said had to agree.

That is the thing worth understanding about a Stripe payout: it is a movement with two ends, and each end is a separate mapping. Most guidance, including most of ours, spends its time on the first end. This post is about the second one, and about the fact that the two ends behave very differently when you have not finished setting them up.

Want your payouts landing in the right QuickBooks bank account from the first sync? Start a free trial.

A payout is a two-ended movement

Every Stripe payout has an origin and a destination, and in QuickBooks they are different accounts of different types doing different jobs.

The origin is your holding account, the account that stands in for the Stripe balance. Sales are deposited into it as they sync, and it carries the money that Stripe is holding on your behalf.

The destination is your deposit account, which is the real bank account in your chart of accounts. This is the account your bank statement is about.

What Acodei writes between them depends on your holding account mode. On a non-UF setup, where the holding account is an ordinary asset clearing account, each payout becomes a single QuickBooks Transfer from the holding account to the mapped deposit bank account, for the payout's net amount. On an Undeposited Funds setup, each payout becomes a QuickBooks Deposit that itemizes the underlying charges, refunds, fees, and mapped uncommon types out of Undeposited Funds and into the bank account.

Two different record shapes, and one thing in common. Both of them end at the deposit account, and the deposit account is assigned separately from the holding account.

The two mappings resolve independently

Here is where the trouble starts, because the two ends are not resolved by the same logic and do not have the same shape.

The holding account is resolved per transaction, in a fixed order. First the connection's default holding account. Then, if you have multiple holding accounts turned on, each connected Stripe account maps to its own holding account through its Stripe-account mapping row. Then, only if three conditions all hold at once, the mapping is resolved further by the transaction's currency. Those three conditions are multiple holding accounts turned on, Multicurrency Support turned on, and the Stripe account flagged as multi-currency.

That last one is worth reading twice, because it is a conjunction rather than a list of options. Per-currency holding accounts do not engage because you set up per-currency rows. They engage when all three flags are on together.

The deposit account is assigned in Account Mapping, per Stripe account, and per currency for multicurrency users.

So you have two ladders that both branch on Stripe account and on currency, maintained in different parts of the setup, and nothing forces them to branch the same way. You can have three holding accounts and one deposit account. You can have per-currency holding rows resolving correctly while every payout lands in the same checking account. Neither of those is a malfunction. They are two mappings you filled in to different depths.

The asymmetry that decides what you see

This is the part that earns the post, and it is the answer to why one misconfiguration is loud and the other is silent.

When the holding-account ladder runs out, it falls back. If per-currency resolution is active but no per-currency row exists for the transaction's currency, resolution falls back to the account-level holding account. The sync proceeds. Your books get a real record. It just goes to the more general account rather than the specific one you thought you had configured.

When the deposit account is missing, the payout errors. A payout with no assigned deposit account fails with a prompt telling you to assign one. It does not fall back to a default, and it does not guess at a bank account.

That difference in behavior is not arbitrary once you see what each end represents. The holding account is an internal clearing account, so your account-level one is a defensible place to land: the money is still notionally sitting with Stripe either way, and a balance in the wrong clearing account is a bookkeeping annoyance you can see and correct. The deposit account is a claim about which real bank account received real money. There is no safe default for that, so the sync refuses to invent one.

The practical consequence is the one you should take away. A silent holding-account fallback is the failure mode you will not notice. An unassigned deposit account announces itself the first time a payout runs. A missing per-currency holding row does not announce anything at all. It quietly consolidates activity you intended to keep separate, and you find out when you try to tie out a clearing balance that was never going to tie out.

Stripe's end of the wire

The QuickBooks side of this only matters because Stripe genuinely can pay out to more than one bank account, and it is worth being precise about when.

Stripe's payouts documentation puts it this way: in some countries "you can enable settlements and payouts in additional currencies by adding one bank account per supported settlement currency. If you use multiple bank accounts, you must select a default settlement currency, which you can change at any time."

The routing then happens automatically on Stripe's side. Charges presented in a currency you have enabled as a settlement currency settle without conversion into that currency's balance. Payments presented in a currency you have not configured a bank account for convert into your default currency instead.

Stripe's own worked example is a UK business with GBP and USD bank accounts and GBP as the default. USD payments pay out to the USD bank account with no conversion, and everything else converts to GBP.

Read that next to the QuickBooks side and the setup requirement writes itself. Stripe is going to produce payouts in more than one currency, arriving at more than one real bank account. If your deposit-account mapping has one row, those separate real deposits all get booked to the same QuickBooks bank account, and no reconciliation you attempt afterwards will make the statements agree.

Two constraints belong here, because they change what is available to you. Zero-decimal currencies such as JPY are not supported. And Multicurrency Support and Invoice Multicurrency are both enabled by the Acodei team rather than being self-serve toggles you can switch on yourself, so a multi-balance setup starts with a conversation rather than with a settings page. The broader currency mechanics are covered in Stripe multicurrency in QuickBooks Online.

The third destination most setups never hit

There is one more place a payout can land, and it overrides the deposit-account mapping entirely.

If the payout's destination is a Stripe Financial Account that you have mapped, the Transfer's destination becomes that mapped QuickBooks account rather than the default deposit account. Money moving into a Stripe Financial Account has not reached your outside bank, so booking it to your checking account would be wrong, and the mapping reflects that.

A related slot exists for the same reason. Stripe V2 Financial Account money movement uses a separate Storage Holding Account rather than your ordinary holding account. If you have never seen either setting, you almost certainly do not use Financial Accounts, and neither applies to you.

The same wire, running backwards

Money moves toward Stripe as well as away from it, and both directions use the accounts you just mapped.

A top-up, where you deliberately fund your Stripe balance, is recorded as a Transfer from the bank account into the holding account. It is the mirror image of a payout, and Stripe top-ups in QuickBooks covers when you would use one.

A negative payout, where refunds and disputes exceeded sales and Stripe pulled money out of your bank, is recorded as a Transfer in the reverse direction, bank into holding, for the absolute amount. This is the same branch in both UF and non-UF modes, which is a small surprise given how differently the two modes treat ordinary payouts. Negative Stripe payouts in QuickBooks covers what to expect on the books.

And a payout that never happened creates nothing. A failed or canceled payout is closed out without a record, because no money moved. A payout that produces no resolvable line items errors with a "No line items" message rather than closing quietly. Both are the sync declining to write something it cannot stand behind, which is the same instinct as refusing to guess a deposit account.

What the recommended setup actually is

For a business running more than one Stripe balance, Acodei's documented recommendation is short and has two halves that match the two ends of the payout.

Multiple deposit accounts, so different Stripe balances can be assigned to different bank accounts, whether those balances sit in one Stripe account or several.

Multiple holding accounts, so different Stripe balances get different holding accounts, and non-UF is the recommended mode for these.

The non-UF recommendation is not a style preference. With an asset clearing account, the correct reconciliation method is balance reconciliation: the QuickBooks clearing balance should equal the Stripe balance, and comparing them daily is the gold standard, monthly at minimum. Under Undeposited Funds the method is narrower, because you match each payout Deposit against the bank feed and then reconcile the bank account, and Acodei does not support balance-reconciling the Undeposited Funds account itself. Sales sit in UF until the payout sweeps them, so a point-in-time UF balance is not meaningful the way a clearing balance is.

Put those together and you get the real reason non-UF is recommended for complicated setups. On a clearing account, drift is visible within a day. Under UF, a discrepancy inside the balance is invisible between payouts, and the only checkpoint you have is whether each payout landed correctly. When you are running several balances into several bank accounts, that checkpoint is doing a lot of work.

There is a documented exception, and it is the one people miss. If you have two or more Stripe balances but only actually use one, the recommendation is to consider removing the extra balance and running the simpler one-balance setup. Multiple balances are worth the mapping work when they carry real activity. Carrying a dormant second balance buys you the configuration surface without the benefit.

One more thing about the holding account specifically. Switching between UF and non-UF later is a supported migration run by a dedicated job against a saved settings backup, not a toggle you flip in settings. That is a good reason to decide the mode before your first sync rather than after your first quarter.

Getting it right, in order

1. Settle your Stripe balances first. Decide which settlement currencies you actually want, and add one bank account per currency on Stripe's side. If you would not use a balance, do not keep it.
2. Choose the holding account mode before the first sync. Non-UF for multicurrency, invoice sync, and high volume. Changing it later is a migration.
3. Create the holding accounts, one per Stripe balance you intend to track separately.
4. Create the deposit accounts to match the real bank accounts, one for each bank account Stripe actually pays out to.
5. Fill in both mappings to the same depth. This is the step this whole post exists for. If you configured per-currency holding accounts, configure per-currency deposit accounts too.
6. Run one payout per balance and read where it landed. The origin and the destination are both worth checking, because only one of them would have told you if it were wrong.

If you run several Stripe accounts into one QuickBooks file, multiple Stripe accounts in QuickBooks Online covers the mapping rules and the chart-of-accounts question that sits underneath all of this. For tying payouts out afterwards, the Stripe payout reconciliation guide has the method.

Stripe's payouts documentation is the place to confirm which settlement currencies your account has actually enabled, which is usually faster than reasoning about it from the payouts you have received.

Ready to stop hand-correcting payouts that landed in the wrong account? Start a free trial.

Frequently asked questions

Can Stripe pay out to more than one bank account?

Yes, in supported countries. Stripe lets you enable settlements and payouts in additional currencies by adding one bank account per supported settlement currency, and you choose one of them as your default settlement currency. Charges presented in an enabled settlement currency settle into that currency's balance without conversion, and anything in a currency you have not configured converts into your default currency.

What is the difference between a holding account and a deposit account?

They are the two ends of a payout. The holding account is the QuickBooks account that stands in for your Stripe balance, and sales are deposited into it as they sync. The deposit account is the real bank account the payout lands in. Acodei writes the payout as a movement from the first to the second, and the two are configured separately.

Why did my Stripe payout fail with a message about assigning a deposit account?

Because the Stripe account, or the currency, that produced the payout has no deposit bank account assigned in Account Mapping. The deposit account has no safe default, so the payout errors rather than guessing which bank account received the money. Assign it in Account Mapping and the payout can be processed.

Can different Stripe balances pay out to different QuickBooks bank accounts?

Yes. That is what multiple deposit accounts are for, and it is Acodei's documented recommendation for anyone running more than one Stripe balance, alongside multiple holding accounts. The deposit account is assigned per Stripe account, and per currency for multicurrency users.

Why did my transaction land in the general holding account instead of the currency-specific one?

Most likely because per-currency resolution did not engage, or because no per-currency row existed for that currency. Per-currency holding requires three things at once: multiple holding accounts turned on, Multicurrency Support turned on, and the Stripe account flagged as multi-currency. If per-currency resolution is active but the currency has no row, resolution falls back to the account-level holding account rather than failing.

Does a payout in a foreign currency get an exchange rate in QuickBooks?

Yes. When the payout currency differs from the QuickBooks home currency, the Transfer is recorded with the relevant exchange rate attached. The holding and deposit accounts for that payout are resolved per currency as well.

What happens to a top-up or a negative payout?

Both move money toward Stripe rather than away from it, and both are recorded as a Transfer from the bank account into the holding account. A top-up is you funding your Stripe balance deliberately. A negative payout is Stripe pulling money back because refunds and disputes exceeded sales, and it is recorded for the absolute amount, using the same branch in both UF and non-UF modes.

Do I need multiple bank accounts if I have multiple Stripe balances?

Stripe requires a bank account per settlement currency for the balances you actually settle in, so in practice yes. If you have an extra balance you never really use, Acodei's documented guidance is to consider removing it and running the simpler one-balance setup rather than maintaining mapping rows for activity that never arrives.