Resyncing a Stripe Payout in QuickBooks

You found a Stripe payout that looks wrong in QuickBooks. You selected its row in the Data Feed, hit resync, watched the status change, and the deposit came back looking exactly as wrong as before. So you did it again.

That loop is one of the most common support conversations in Stripe-to-QuickBooks bookkeeping, and it almost never means resync is broken. It usually means the thing you resynced was not the thing that was wrong. A Stripe payout does not arrive in QuickBooks as one record, and whether it arrives as one record or as a parent with a dozen children depends on a setting you probably chose during onboarding and have not thought about since.

This post is about that structure, and about the question it forces: when a payout is wrong, what is the unit of repair? The row, the deposit and everything under it, or the whole day?

Get your Stripe payouts and their underlying activity into QuickBooks correctly the first time. Start a free trial.

A payout is not one record, and its shape is your choice

Before anything about resync makes sense, you need to know which of two shapes your payouts take in QuickBooks. Acodei records a payout differently depending on the holding account you picked, and the difference is not cosmetic.

If you use an asset holding account, sometimes called a clearing account, each payout becomes a single QuickBooks Transfer. It moves the payout's net amount out of the holding account and into the bank account you mapped. One Stripe payout, one QuickBooks record, and the revenue, refunds and fees that made up that payout are not lines on that Transfer.

If you use Undeposited Funds, each payout becomes a QuickBooks Deposit that itemizes the underlying activity. Its lines are built from the payout's balance transactions, grouped by type and by mapped product, and they move charges, refunds, fees and any mapped uncommon transaction types out of Undeposited Funds and into the bank account. One Stripe payout, one QuickBooks record with many lines, each of which corresponds to activity Acodei tracked separately.

That second shape is where the parent and child relationship lives, and it is the reason a payout can be half-repaired. The deposit is not an independent record that happens to agree with its transactions. It is assembled out of them.

The choice between the two is covered properly in the guide to holding accounts and clearing accounts for Stripe payouts, and this post assumes you already made it. What matters here is that you know which one you are on before you start repairing anything, because the same repair means two different things on the two setups.

Resync rebuilds, it does not retry

The second thing to be clear about is what the button does.

Resync is not a retry. It books the QuickBooks-side delete first, and then re-books the transaction for its sync job. The old record goes away and a new one is built from current data and current settings. That is why resync is the tool that applies a mapping change to history: settings are never applied retroactively on their own, so rebuilding is the only way to make an old record reflect a new rule.

The status vocabulary around all of this, including what half-synced and payout pending actually mean and why a row can look stuck without being stuck, is owned by our guide to reading the Acodei Data Feed and its statuses. Read that one if the status column is what is confusing you. This post picks up at the point where you understand the statuses and have to decide what to select.

Two details from that mechanic matter here more than they look.

The first is that because resync deletes and rebuilds, resyncing a record is a complete operation on that record, and only on that record. It does not reach sideways.

The second is that not every record type takes the same path. Invoices and customer-balance-tracker accounts are handed to a separate service rather than run in place, which is part of why the invoice case has its own shape and its own failure modes. If invoices are what you are repairing, resyncing a Stripe invoice into QuickBooks covers that path specifically.

Under Undeposited Funds, two records describe the same money

Here is the structure that explains the whole problem, and it is worth being precise about, because the obvious mental model is wrong in a way that costs people an afternoon.

The obvious model is that the deposit is computed from the QuickBooks records underneath it, the way a subtotal is computed from the rows above it. It is not. The deposit's lines are built from the payout's balance transactions on the Stripe side, grouped by type and by mapped product. The individual sales receipts, payments and refunds in QuickBooks are built from that same Stripe activity, by their own sync jobs.

So the deposit and its children are not a formula and its inputs. They are two independent renderings of the same underlying Stripe events, produced by different jobs at different times.

There is one real dependency between them, and it runs in a single direction. A deposit can only be built if every underlying transaction already exists in QuickBooks. That is enforced rather than hoped for. If a payout arrives and some of the activity inside it has not synced yet, the deposit is not built with gaps and it is not built wrong. It is blocked with a mismatch error, and each missing transaction is recorded so it can be retried. The payout is parked at the payout pending status, which means what it says: waiting for other transactions to be synced first. That is a queue position, not an error.

Now combine those two facts, because together they produce the failure this post is named after.

Resync rebuilds one record against current settings. If you change a product mapping and resync only the underlying charges, those charges get the new treatment and the deposit above them does not, because the deposit was not rebuilt. If instead you resync only the deposit, the deposit's lines get the new treatment and the individual charge records keep the old one, because they were not rebuilt.

Both halves of that are the same bug wearing different clothes. You have two QuickBooks records describing the same Stripe money, one rebuilt and one not, and they now disagree. Every row in the Data Feed is green. Nothing errored. The only symptom is that a number is wrong somewhere you were not looking.

That is the half-fixed state, and it is convincing precisely because nothing looks broken.

Three units of repair, and only one of them is a button

Acodei's own tooling treats this as three separate operations, which is the clearest evidence that the distinction is real rather than theoretical.

From the dashboard, the Data Feed's bulk action accepts exactly two verbs, delete and resync, and they act on the rows you selected. That is the unit of repair you can reach yourself: a row, or a set of rows you chose.

Underneath, the service that carries out bulk actions handles more than those two. It also handles deposit-aware variants that pull a payout deposit and its children together as one operation, date-scoped delete and resync that work on a day rather than a list of rows, and a date-scoped mark-as-not-synced. Those exist for support work rather than as dashboard buttons, and Acodei's own documentation describes them that way.

So the honest picture is this. There are three real units of repair. You can reach one of them directly. The other two exist, they are used, and knowing they exist changes what you ask for when a row-by-row repair is not the right shape for your problem.

That is a more useful thing to know than it sounds. A bookkeeper who does not know the deposit and its children are rebuilt separately will resync one of them, see green rows, and spend an afternoon looking for a bug that is really an unrebuilt record. A bookkeeper who does know will rebuild both, in that order, and get a consistent result on the first pass. And on a genuinely bad day, where a settings change needs to reach everything that posted on a particular date, they will ask for the day rather than trying to select two hundred rows by hand.

The order matters for a mechanical reason rather than a stylistic one. Because a deposit cannot be built until every transaction inside it exists in QuickBooks, rebuilding the children first and the parent second is the sequence that does not run into its own precondition.

When resync is the right tool at all

Resync is a rebuild, so it is the right answer when the inputs to the record have changed and the record has not caught up. Acodei's documentation names three cases.

Settings changed and history should reflect them. A mapping change, a fee-method change or a tax setting change applies from the moment you make it. Records written before that moment keep the treatment they were written with. Resync is what makes an old record reflect a new rule, and it is the only thing that does. If you have just reorganized your product mapping and your historical revenue is still landing in the old accounts, nothing is broken and nothing will fix itself.

A record errored and the cause is fixed. A deleted fee product, a customer conflict, a validation mismatch. The record failed for a reason, you removed the reason, and now the write can succeed. Note the order: fix first, resync second. Resyncing before the cause is fixed reproduces the same failure, which is the second most common version of the loop at the top of this post.

Stripe-side data changed. A refund failed, an invoice reopened, something on Stripe's side is no longer what it was when the QuickBooks record was written. The QuickBooks side has to be rebuilt against current data.

What these three have in common is that the record is not merely absent or stuck. Something that feeds it is different now. If nothing that feeds a record has changed, resyncing it rebuilds the same record and you have spent a QuickBooks write for nothing.

A missing record is a different problem with a different diagnosis, and the case where a whole day never posted is covered in what to do when a Stripe daily summary is missing from QuickBooks.

The repair resync cannot undo

There is one action that takes a record permanently outside this system, and it is the action people reach for first because it feels fastest.

If you open the QuickBooks record and fix it by hand, you break the linkage Acodei uses for reconciliation and reversal. The record still exists and still looks right in your register. What it no longer has is the connection back to the Stripe activity it represents, so the next operation that needs to find it cannot. Acodei's documentation is direct about this: repair from the Data Feed, not by editing the QuickBooks record.

This matters most on exactly the records this post is about. A payout deposit is the record a hand edit is most tempting on, because it is one line item in a deposit and QuickBooks will happily let you retype it. It is also the record where the linkage does the most work, because that deposit is the thing your bank feed matches against and the thing a later reversal has to find.

It is worth knowing what that linkage buys you, because the protection it provides is real but bounded. It covers the records Acodei created, which is the subject of duplicate protection between Stripe and QuickBooks. A record you retyped by hand is no longer one of them.

A decision procedure

If a Stripe payout is wrong in QuickBooks, work in this order.

First, establish the shape. Are you on Undeposited Funds or an asset holding account? On an asset holding account a payout is a single Transfer for the net amount, so there are no children and the parent and child problem does not apply. If the Transfer amount is right and your revenue detail is wrong, the problem is in the revenue records, not in the payout. Note that a negative payout is a Transfer in the reverse direction in both setups, which is its own case worth reading separately.

Second, check whether anything that feeds the record has actually changed. If you have not changed a setting, not fixed an error cause and not seen Stripe-side data change, a resync will faithfully rebuild what you already have. This is the single most common wasted repair.

Third, list every record that describes the money in question. On Undeposited Funds that is at least two: the deposit, and the individual transactions inside it. Both were built from the same Stripe activity by different jobs, so both carry the treatment that was in force when they were written, and both need rebuilding for the fix to be consistent.

Fourth, rebuild children first, then the parent, then confirm against a number. The order avoids the deposit's own precondition. The confirmation matters because the status column tells you an operation completed, not that the total is right.

Fifth, if the unit is a day rather than a row, say so. If a settings change needs to reach everything that posted on a particular date, that is a date-scoped operation rather than two hundred manual selections. Ask for it by shape: the date, the connection, and what you changed.

And do not hand-edit the QuickBooks record. It is the one repair that makes every later repair harder.

Where this leaves your close

The general version of this is short. One movement of money on the Stripe side can be described by more than one record on the QuickBooks side, and a rebuild acts on records, not on movements. So the question to ask before any repair is not "which record is wrong" but "which records describe this money", and the answer on an Undeposited Funds setup is always more than one.

A payout deposit is the clearest case because the structure is visible, but the principle covers the whole system. Enumerate the records first, rebuild all of them, then verify against a number rather than a status.

If reconciling Stripe payouts against QuickBooks is where your month-end time goes, the complete guide to reconciling Stripe fees and payments in QuickBooks Online covers the ongoing process rather than the repair case, and Acodei's reconciliation between Stripe and QuickBooks is built to keep the two sides describing the same movements so that repairs stay rare.

Stripe's own balance transactions reference is worth a look if you want to see the raw activity a payout is assembled from, since that list is exactly what a deposit's lines are built out of.

Frequently asked questions

Why does resyncing a Stripe payout leave the numbers inconsistent?

Because on an Undeposited Funds setup the deposit and the individual transactions inside it are separate QuickBooks records, built from the same Stripe activity by different jobs. Resync rebuilds whatever you selected and nothing else, so rebuilding one of them against a new setting while the other keeps the old one leaves two records describing the same money differently. Rebuild both.

Does resync retry a failed sync?

No. Resync books the QuickBooks-side delete first and then re-books the transaction for its sync job, so it is a rebuild rather than a retry. That is why it picks up mapping and settings changes, and also why resyncing before you have fixed the cause of an error just reproduces the error.

What is the difference between resyncing a payout and resyncing its transactions?

They are different operations on different records. The Data Feed's bulk action acts on the rows you select, so selecting a deposit rebuilds the deposit and selecting its underlying transactions rebuilds those. Neither reaches the other. Acodei's tooling also has deposit-aware operations that pull a payout deposit and its children together, used for support work rather than exposed as a dashboard button.

Why is my payout stuck on payout pending?

Because a deposit can only be built once every transaction inside it exists in QuickBooks. When some of that activity has not synced yet, the payout is parked at payout pending rather than failed, and it is waiting on those other transactions. The thing to look at is the activity it is waiting for, not the payout row itself.

Will resyncing apply a mapping change I made last month?

Yes, and it is the only thing that will. Settings are never applied retroactively on their own, so records written before the change keep the treatment they were written with. Resyncing rebuilds them against current settings.

Can I just fix the deposit in QuickBooks by hand?

You can, and it causes a problem you will meet later. A hand edit breaks the linkage Acodei uses for reconciliation and reversal, so the record no longer connects back to the Stripe activity it represents. Repair from the Data Feed instead, which rebuilds the record with the linkage intact.

I use a clearing account rather than Undeposited Funds. Does any of this apply?

The parent and child part does not. On an asset holding account a payout is a single Transfer for the net amount, with no itemized lines, so there are no children to repair. The rest still applies: resync is a rebuild rather than a retry, it is what applies settings changes to history, and hand-editing the QuickBooks record still breaks the linkage.

---

Acodei syncs Stripe payouts, charges, refunds and fees into QuickBooks Online, and gives you a Data Feed that shows what synced, what did not, and what is waiting on something else. Start a free trial.