Changing Your Stripe Holding Account in QuickBooks

You picked your holding account during onboarding, in a setup wizard, before you had reconciled a single month. A year later you know something you did not know then: that choice did not just decide what your Stripe records look like in QuickBooks. It decided how you reconcile them, and whether you can check your books against Stripe daily or only when a payout lands.

So now you want to change it. You go looking for the setting, and either you cannot find it or you find it and are not sure whether flipping it will quietly rewrite a year of history.

Here is the short version. Changing your Stripe holding account after you have synced real transactions is a migration, not a setting. There are two supported routes through it, they cost very different amounts of work, and the one most people find first is the more expensive of the two.

Want the reconciliation method sorted out before you have a year of records to move? Start a free trial.

The thing the setup wizard did not tell you

A holding account is the QuickBooks account that stands in for your Stripe balance. Every synced sale is deposited into it. Every payout moves money out of it into your real bank account. It is the single most consequential setup choice in Acodei, because it determines the shape of nearly every record downstream.

There are two modes.

On Undeposited Funds, the holding account is QuickBooks' own built-in one. Intuit describes it as "a temporary lockbox (or drawer) to keep your payments in until you record a formal bank deposit," and that is exactly how the sync uses it. Payouts become itemized Deposits that sweep the individual payments into the bank.

On non-Undeposited-Funds, the holding account is a regular asset account you create, usually called something like Stripe Clearing. Payouts become a single Transfer for the net amount, out of the clearing account and into the bank. If you have never set one up, the clearing account setup guide covers the account itself.

Most comparisons of the two stop at record shape: itemized Deposit versus simple Transfer, and which one your bookkeeper prefers to look at. That framing is what makes the choice feel cosmetic during onboarding, and it is the reason people pick one and move on.

The part that actually matters is that the reconciliation method is part of the mode choice, not a separate decision you make later.

The two reconciliation methods, and why only one of them can run daily

With a non-Undeposited-Funds clearing account, the method is balance reconciliation: the QuickBooks clearing balance should equal your Stripe balance. Every sale, fee, and payout posts against the clearing account as it happens, so the two balances can be compared daily. Daily is the gold standard, and monthly is the minimum.

That is not just doctrine. Acodei has automated tracking built for it, and built only for it: a daily tracker that fetches the Stripe balance and the QuickBooks holding balance, records them as per-day rows, and records whether they matched. The tracker is scoped explicitly to non-Undeposited-Funds connections.

With Undeposited Funds, the method is narrower: match each payout Deposit against the bank feed, then reconcile the bank account. Did the payout land, and is the amount right? If yes, that is the end of the reconciliation work, and it is the end of what Acodei supports. Balance-reconciling the Undeposited Funds account itself is not supported.

Acodei's documentation states the limitation plainly in its holding account guide: under Undeposited Funds the daily balance will not equal Stripe, because fees, disputes, Stripe Capital activity and currency conversion only post on payout day.

The reason is timing, and it is worth understanding because it is not a limitation someone forgot to remove. Sales sit in Undeposited Funds until a payout Deposit sweeps them out. Some items, like deferred fees and mapped uncommon balance-transaction types, are only added at deposit time. So the Undeposited Funds balance can legitimately diverge from the Stripe balance at any given moment, which means a point-in-time comparison of the two does not tell you anything. It is not that nobody built the check. It is that the number it would produce would not mean what you want it to mean.

Stripe's own balance behaviour compounds this. Stripe's documentation describes funds moving through two states, pending and available, with settlement time between them: "when a customer makes a card payment, the charge amount (minus Stripe's fee) appears in your pending balance until settlement." A clearing account gives you a stable place to see that whole picture accrue. A lockbox that empties on payout does not.

This is the underlying reason non-Undeposited-Funds is recommended for more complicated accounts. Under a clearing account, drift is caught within a day. Under Undeposited Funds, a discrepancy inside the balance is invisible between payouts, and the only checkpoint is whether each payout landed correctly. If you want the full comparison of those two approaches before you commit, balance report versus payout reconciliation is the piece that covers it.

If you are reading this because you are on Undeposited Funds and you want to balance-check your books against Stripe, you have now found the real reason you cannot. It is the mode, and the mode is what you would be changing.

Why it is not a setting

Acodei tracks a one-shot permission flag for changing the holding account, and its conditions tell you most of what you need to know about the change.

The permission is granted only when a connection has zero transactions at synced status across all of its Stripe accounts. The only thing that calls the granting function is the bulk QuickBooks-delete job. In practice, that means the permission becomes available after you have deleted everything Acodei booked. It is revoked once a transaction reaches synced status.

Read those two conditions together and the design is clear. The unrestricted version of this change is a thing you do on a connection with no history, because with no history there is nothing to be inconsistent with. That is the case the flag is built for.

Which leaves the question of what to do on a connection that has a year of history. There are two answers, and it is worth knowing both before you start, because they are not equally expensive.

Route one is the documented self-serve procedure. Acodei's documentation is direct about it: if you move from Undeposited Funds to a non-Undeposited-Funds asset account or the other way, delete all Acodei-created transactions tied to the old account first, then pick the new account in Acodei and rerun the sync. That sequence is not arbitrary. It is the permission conditions above, described from the outside: deleting everything Acodei booked is what brings a connection back to zero synced transactions, which is the state in which the change is unrestricted. The documentation gives the reason for the ordering too, which is that mixing records from both modes is what produces duplicate revenue and mismatched balances.

Route two is the migration job. Switching modes mid-life is also supported as a migration: a dedicated job reverses and re-books the affected records, working against a saved backup of your settings, and it is driven by a support command rather than a button in your dashboard. You ask Acodei support to run it. That is the honest description, and it is not a workaround or an undocumented favour. It is a supported path with its own job and its own command, and the thing it buys you is not having to empty a year of books to change a setup choice.

One detail in that job is worth pointing at, because it shows how carefully the edge cases were handled. Payouts caught mid-transition are given their own status, specifically so that the normal delete cron does not pick them up and act on them while the migration is in flight.

Before you go down either route, read how deletes and resyncs actually behave in the Data Feed status guide. It covers the bulk-delete and resync mechanics and the one rule that governs both of these routes, which is worth having in front of you before you start rather than halfway through.

What changes in your books on the other side

The migration is not the interesting part for most people. This is.

Your payout records change shape. Itemized Deposits that list each charge, refund, and fee become single Transfers for the net amount. Everything that was on the face of the Deposit is still in your books. It just lives on the sales records instead, and the Transfer is what matches the bank line.

A whole class of payout failure disappears. Under Undeposited Funds, every underlying transaction has to already exist in QuickBooks before the Deposit can be built, and a payout whose parts are missing fails with a mismatch error instead of posting a Deposit with holes in it. Under a clearing account there is no such prerequisite, because the Transfer is for a net amount and does not need to enumerate anything. If you regularly find payouts waiting on the transactions underneath them, this is the constraint you are feeling, and a migration removes it.

Bank-feed matching moves but does not get harder. Under Undeposited Funds, the Deposit matches the bank line and shows its own composition. Under a clearing account, the Transfer matches the bank line and the composition lives on the sales records that posted into the account.

Fee placement may be forced to change, and this is the one that surprises people, so it gets its own section.

The fee-method trap

Where Stripe fees can appear in QuickBooks depends on your holding account and on whether Invoice Sync is on. There are three placements: a line item on the Sales Receipt, a line item on the Bank Deposit, or a separate Expense.

The Bank Deposit placement only exists under Undeposited Funds, for the obvious reason that a non-Undeposited-Funds workflow has no deposit step to put a line on. And the combination that catches people is non-Undeposited-Funds with Invoice Sync enabled, where fees can only be shown as an Expense. Not on the invoice, which would throw the invoice total off against the payment, and not on a deposit, which does not exist in that workflow.

So if you are on Undeposited Funds with Invoice Sync on and your fees currently land on the Deposit, migrating to a clearing account does not just change your payout records. It moves your fees to expense records, because that is the only placement left.

Then the second half, which is the part that actually costs time: changing your fee method does not update historical transactions. Records already written reflect the configuration in place when they were written, and they stay that way until they are resynced. Nothing about waiting changes them.

Put those together before you start rather than after. A migration that changes your fee placement leaves you with a fee-method change of your own to think about on the records that did not move with it, and resyncing transactions is how records get rebuilt against current settings.

What to work out before you ask

The migration is supported and it has a job behind it. That does not make it free, and the questions worth answering are the ones about your account rather than about the mechanism.

Is the reconciliation method actually why you want this? If the honest answer is that you want to be able to check your Stripe balance against QuickBooks without waiting for a payout, a clearing account is the mode that supports it and Undeposited Funds is not. That is a real reason and it does not get better by waiting.

Is something else on your roadmap going to force it anyway? Non-Undeposited-Funds is the recommended default for multicurrency users, for Invoice Sync users who want cleaner behaviour, for high-volume accounts, and for anyone who would rather have one Transfer per payout than an itemized Deposit. Invoice Multicurrency is the hardest version of this: once it is on, the interface stops offering Undeposited Funds as a holding account at all. If multicurrency invoicing is coming this year, you are choosing between migrating on your own schedule and migrating on its schedule.

Do you know where your fees will land afterwards? See the previous section. Work it out first.

Have you got a close coming? A migration reverses and re-books records. Doing that in the middle of a period you are trying to close is a choice you will regret for reasons that have nothing to do with Acodei.

What does your accountant need to see? Undeposited Funds suits people who want the classic QuickBooks workflow where the Deposit itself documents which payments it contains. That is a legitimate preference, and if it is the one your accountant holds, the cost of the migration is that they lose that view. The trade is a daily balance check in exchange for the per-deposit itemization.

None of these are reasons not to migrate. They are the things that decide whether you migrate this month or next quarter, and they are much cheaper to think about before a job has started reversing records than after.

Frequently asked questions

Can I change my Stripe holding account in QuickBooks after I have started syncing?

Changing it on a connection with synced history is handled as a migration rather than as a settings change, and there are two routes. The documented self-serve one is to delete all Acodei-created transactions tied to the old account, select the new account, and rerun the sync. The other is a dedicated migration job that reverses and re-books the affected records against a saved backup of your settings, run by support rather than from your dashboard. The one-shot permission that allows an unrestricted change is granted only while a connection has zero transactions at synced status, and it is revoked once a transaction syncs.

What happens to the QuickBooks records I have already synced?

That depends on the route. Under the migration job they are reversed and re-booked, so they end up in the shape the new mode produces rather than being left in the old one, and payouts caught mid-transition are parked on their own status so the normal delete cron does not act on them while it runs. Under the documented self-serve procedure they are deleted and rebuilt by the rerun instead. Either way they do not stay as they are, which is the point: records from two different modes sitting side by side is the outcome both routes exist to avoid.

Why can I not reconcile my Undeposited Funds balance against Stripe?

Because the balance is not meant to be comparable at a point in time. Sales sit in Undeposited Funds until a payout sweeps them out, and some items such as deferred fees are only added at deposit time, so the balance can legitimately diverge from the Stripe balance on any given day. Balance reconciliation is the method for an asset clearing account, where every sale, fee, and payout posts as it happens. Under Undeposited Funds the supported method is matching each payout against the bank feed and reconciling the bank account.

Will migrating change where my Stripe fees appear?

It can, and it is the most commonly missed consequence. A Bank Deposit fee line only exists under Undeposited Funds. With a clearing account and Invoice Sync enabled, fees can only be shown as an Expense. Changing the fee method does not update transactions that are already written, so historical records keep their old fee placement until they are resynced.

Is deleting everything and starting over the same thing as migrating?

They are two different routes to the same destination. The documented self-serve procedure is to delete all Acodei-created transactions tied to the old account, then select the new account and rerun the sync, and the ordering matters because mixing records from both modes is what creates duplicate revenue and mismatched balances. Deleting is also what returns a connection to zero synced transactions, which is the state in which the permission to change the account is unrestricted. The migration job is the other route, and what it buys you is not having to empty a year of books first. Ask support which one fits your account before you delete anything.

Which mode should I have picked in the first place?

A clearing account, if you are a multicurrency user, an Invoice Sync user, a high-volume account, or anyone who values a simple Transfer per payout. Undeposited Funds, if you want the classic QuickBooks flow where the Deposit documents its own contents and you can accept the stricter sequencing that comes with it. If you are reading this post, you have probably already worked out which one you are.

The takeaway

The holding account is presented as a setup question and it behaves like an architectural one. It sets your record shapes, your payout prerequisites, where your fees can live, and, most consequentially, whether your books can be balance-checked against Stripe every day or only inspected one payout at a time.

Changing it later is supported, by a documented delete-and-rerun procedure and by a migration job that a person runs against a saved settings backup. Neither one is a checkbox, and the difference between them is whether your existing records get reversed and re-booked or deleted and rebuilt. The work worth doing yourself is upstream of both: know whether reconciliation is your real motive, know where your fees will land afterwards, and do not start in the middle of a close.

Get the mode right and the reconciliation follows. Acodei syncs Stripe charges, refunds, fees, and payouts into QuickBooks Online against the holding account you choose, and tracks your clearing balance against Stripe daily when you are on one. Start a free trial.