Changing Your Stripe Payout Deposit Account in QuickBooks

Every other mapping change in Acodei rewards the same instinct: fix the setting, resync the affected history, and the old records come back correct. The deposit account is the one place where that instinct is wrong, and it is wrong in a way that moves real money into the wrong bank account in your books without erroring, warning, or failing a single sync.

The whole post in two sentences. Changing the deposit account applies to payouts that have not synced yet. The payouts that already synced are not stale records waiting to be corrected, they are accurate history, because the money genuinely did land in the old bank account.

Ready to stop guessing which bank account a payout landed in? Start a free trial.

What the deposit account actually controls

A payout has two ends, and Acodei asks you to name a QuickBooks account for each.

The holding account stands in for your Stripe balance: it is where sales accumulate before Stripe pays out. The deposit account is the other end, the QuickBooks bank account that represents the real bank account Stripe sends the money to. Acodei's documentation calls the same thing the Stripe Payouts Account, defined as the bank account into which Stripe deposits your sales proceeds.

The deposit bank account is assigned in Account Mapping, per Stripe account, and per currency for multicurrency users. It is not optional: a payout with no assigned deposit account errors with a prompt to assign one, rather than guessing or posting to a default.

If you are setting this up for the first time, or running several Stripe balances into one QuickBooks file, the two mappings and how they resolve independently is the post that covers the structure. This one is about what happens when you change the destination end after you are already live.

The change takes effect forwards

Acodei never applies a settings change to history on its own. The documented rule is general and it covers mapping, fee method and tax alike: settings are not applied retroactively, so records written before a change keep the treatment they were written with.

That means the change you just made does exactly one thing. The next payout that syncs resolves the deposit account fresh, finds the new bank account, and posts there. Nothing else in your file moves.

Most people read that as a limitation and start looking for the button that fixes the rest. Here is why there is nothing to fix.

Your old payouts are not wrong

This is the part that inverts the usual advice, so it is worth being concrete.

Suppose you switched business banking on 1 March. February's Stripe payouts arrived in the old bank account. They are recorded in QuickBooks against the old bank account. When your accountant reconciles February, the old bank account's statement carries those deposits, and the QuickBooks records match them line for line.

Now compare that to the mapping changes where a resync genuinely repairs something. If your product mapping sent subscription revenue to the wrong income account, every historical record is wrong, because the revenue always belonged somewhere else. If you changed your fee method, the old records describe a treatment you have decided against. In both cases history was written under a rule you now consider incorrect, so rebuilding it under the correct rule makes the books more accurate.

A bank change is not that. The old rule was not incorrect. It was correct at the time, and it is still correct about the period it describes. February's money is in the old bank account no matter what your mapping says today, and a record that says so is the only honest one you can have.

The deposit account is the setting where history and configuration are supposed to disagree.

What a resync would actually do

It is worth knowing precisely, because the mechanic is what makes this a hazard rather than a no-op.

Resync is not a retry. It books the QuickBooks-side delete first, then re-books the transaction for its sync job, and the replacement is built from current data and current settings. That is why resync is the correct tool for applying a mapping change to history: rebuilding is the only way an old record can reflect a new rule. Resyncing a Stripe payout covers that mechanic in full, including what it can and cannot repair.

Compose those two facts and the outcome is not ambiguous. A Non-UF payout posts as a Transfer from the holding account to the mapped deposit bank account. Resync rebuilds against the current mapping. So resyncing a February payout after a March bank change produces a Transfer into the March bank account.

You now have a deposit recorded in a bank account that never received it, and a hole in the bank account that did. Two reconciliations break instead of one, and neither of them reports an error, because from the software's point of view every step did exactly what it was told.

The rebuilt record is a new record

There is a second cost that catches people even when the mapping is unchanged.

Because a resync deletes the QuickBooks record before writing the replacement, anything you had attached to the old one is attached to something that no longer exists. A bank feed match made against that deposit was made against a record that has been deleted. The replacement is a different QuickBooks object, and your feed will want it matched again.

The instinct to skip all of this by editing the deposit in QuickBooks by hand is worse, not better. Hand edits break the linkage Acodei uses for reconciliation and reversal, so the record stops connecting back to the Stripe activity it represents. Acodei's documentation is direct about the alternative: repair from the Data Feed rather than in the QuickBooks register.

Every shape the destination end can take

Changing the deposit account changes the destination of more records than the word payout suggests, and two of them run backwards.

On an asset holding account, a payout is a single Transfer from the holding account to the deposit bank account for the net amount. On Undeposited Funds, it is a Deposit that itemizes the underlying charges, refunds and fees out of the holding account into the bank account. Same destination setting, different document.

A negative payout reverses the direction. When refunds and disputes exceed sales, Stripe pulls money from the bank, and Acodei records a Transfer from the bank account into the holding account for the absolute amount, in both modes. A top-up does the same thing for a different reason: money you send to fund your Stripe balance posts as a Transfer from the bank account into the holding account.

So after a deposit account change, a negative payout comes out of the new bank account, because the new bank account is the one Stripe is now pulling from. That is correct, and it is worth knowing before it appears.

The two exceptions that override the default

The first is Stripe Financial Accounts. If a payout's destination is a Financial Account you have mapped, the Transfer's destination becomes the mapped QuickBooks account instead of the default deposit account. A business routing some payouts to a Financial Account can change its default deposit account and correctly see no change at all on those.

The second is currency. Holding and deposit accounts are resolved per currency, so changing the USD deposit account does not touch the CAD one. If you configured per-currency deposit accounts, a bank change is a per-currency edit, and a change made only at the Stripe-account level will not reach the currencies you mapped individually. That asymmetry is the most common way a change looks like it did not take effect.

Why a historical fix is not a self-serve button

If you do have a genuine mis-mapping in history, a real error rather than a bank change, the shape of the tooling is worth understanding before you start selecting rows.

The Data Feed's bulk action accepts exactly two verbs: delete and resync. That is the whole self-serve surface. The service behind it dispatches seven action types, including date-scoped variants and one that pulls a payout deposit and its children together rather than leaving them to be selected separately. Acodei's own documentation notes that those deposit-aware and date-scoped variants matter for support work.

That is the honest answer to "can I just bulk-fix last year?". The operations that would do it safely, in the right order, with a payout's children moving alongside it, are support-side rather than dashboard buttons. A row-by-row resync from the Data Feed is a fine tool for one broken record and the wrong tool for a year of them.

If the status column is what is confusing you rather than the mapping, reading the Acodei Data Feed and its statuses covers what each state means, including the payout-pending state that means a payout is waiting on other transactions to sync first.

Doing it in order

1. Make the change on the Stripe side first, and note the date Stripe starts paying out to the new account. Your books should follow Stripe, not lead it.
2. Create the new bank account in QuickBooks before you map it.
3. Update the deposit account in Account Mapping, per Stripe account, and per currency if you run more than one balance. Check every currency you configured individually.
4. Let one payout sync and read where it landed. The destination is the only thing you changed, so it is the only thing worth checking.
5. Leave the history alone. It is right.
6. If you find a historical payout that is genuinely mis-mapped, treat that as its own repair rather than as part of the bank change, and take a bulk one to support.

A bank change is one of the few Acodei settings changes where the correct amount of cleanup is none. The instinct to reach for a resync is a good instinct that most of the product rewards, which is exactly why it is worth naming the one case that punishes it.

For tying the payouts out afterwards in either bank account, the Stripe payout reconciliation guide has the method. And if the setting you actually want to change is the other end of the wire, changing your Stripe holding account is a different operation with a different constraint, and it is a migration rather than a mapping edit.

Stripe's own payouts documentation is the place to confirm which bank account Stripe is paying out to and from what date, which is faster than inferring it from what has already arrived.

Want your Stripe payouts to land in the right QuickBooks account without hand-correcting deposits? Start a free trial.

Frequently asked questions

I changed my bank account. Do I need to resync my old Stripe payouts?

No, and you should not. Acodei does not apply settings changes retroactively, so your already-synced payouts keep pointing at the bank account they actually landed in. That is accurate history rather than a stale record. Resyncing rebuilds a transaction against current settings, so it would move those old payouts into the new bank account and break the reconciliation on both.

Does changing the deposit account move payouts that already synced?

No. The change resolves when a payout syncs, so it applies to payouts that have not synced yet. Records written before the change keep the treatment they were written with, and nothing already in QuickBooks moves on its own.

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

Because the deposit bank account is required rather than defaulted. It is assigned in Account Mapping per Stripe account, and per currency for multicurrency users. A payout with no assigned deposit account errors with a prompt to assign one, which is usually a currency or a Stripe account you added after the original setup.

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

Yes. The deposit bank account is assigned per Stripe account, and per currency where you run multiple settlement currencies. Changing it for one Stripe account or one currency does not change it for the others, which is also the most common reason a change looks like it did not take.

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

They are opposite ends of the payout. The deposit account is the destination bank, and changing it is a mapping edit that applies to future payouts. The holding account stands in for the Stripe balance itself, and changing it is a migration rather than a toggle, with its own constraints.

Will a negative payout come out of the new bank account?

Yes. A negative payout is recorded as a Transfer from the bank account into the holding account for the absolute amount, so it resolves the same deposit account mapping as a normal payout and uses whichever one is current. A top-up funding your Stripe balance takes the same shape for the same reason.

Can I just edit the deposit in QuickBooks to point at the new bank account?

You can, and it causes a problem later. Hand edits break the linkage Acodei uses for reconciliation and reversal, so the record no longer connects back to the Stripe activity it represents. If a record genuinely needs repair, do it from the Data Feed so the replacement is built with that linkage intact.

I use a Stripe Financial Account for some payouts. Does this apply to them?

Partly. If a payout's destination is a Financial Account you have mapped, the Transfer's destination becomes that mapped QuickBooks account instead of the default deposit account. Changing the default deposit account correctly leaves those payouts unchanged.