What Each Acodei Data Feed Status Actually Means

Something in Stripe did not turn up in QuickBooks, so you open the Data Feed, find the row, and it is sitting on a status you have never seen before. Half-synced. Payout pending. Delete booked.

The natural way to read that column is as a progress bar: the row is somewhere between started and finished, and if you leave it alone it will get to the end. That reading is wrong often enough to cost you an afternoon. Most of these values are not positions on a track. They are records of a decision the sync already made, and two of them exist specifically to stop something bad from happening to your books.

This post is about what each one is telling you. If your problem is that there is no row in the Data Feed at all, that is a different question with four different answers, and Stripe webhook events that never reach QuickBooks covers it. Everything below assumes the row exists.

Want Stripe activity in QuickBooks without learning to read a status column at all? Start a free trial.

What a status is actually recording

Acodei turns each syncable Stripe object into a Transaction row: one per charge, refund, payout, invoice, or credit note, carrying the Stripe event type, the extracted amounts, the currency, and the balance-transaction detail flattened into columns. The Data Feed is the dashboard view of those rows, and the status column renders one field on them.

That field answers a narrow question. Not "how far along is this" but "what did the pipeline decide to do with it, and did that work". A row that says half-synced is not partway to synced. It is a row that a job deliberately stopped touching.

Here is the full set.

Status	What it means
In progress / not synced	The row exists and has not been written to QuickBooks yet
Synced	Written to QuickBooks successfully
Sync failed	The write was attempted and rejected. The row carries an error_msg
Delete booked	The QuickBooks side is queued for deletion
Resync booked	Queued to be rebuilt. There are four flavours, depending on whether it comes back as a plain record, a payment, an invoice, or a sales receipt
Payout pending	The payout is waiting on other transactions to sync first
Delete failed	The deletion was attempted and did not complete
Pending update	Queued for an update to an existing QuickBooks record
Purchase pending	A purchase record is queued
Half-synced	The QuickBooks entity was created but the job died before finishing. The row is parked so a retry cannot duplicate it
Transition delete	Part of an Undeposited Funds to non-Undeposited-Funds migration

Nine of those are self-explanatory once you know the sync writes records rather than syncing state. Two are not, and they are the ones worth understanding properly.

Half-synced looks like the worst one and is the one to panic about least

A job that dies mid-write is the classic distributed-systems problem, and it has exactly two bad resolutions. Either you never retry, and the work is lost. Or you retry blindly, and because the QuickBooks entity was already created before the job died, you get a second one. Duplicated revenue in a bookkeeping system is worse than missing revenue, because missing revenue announces itself at reconciliation and duplicated revenue quietly ties out.

Half-synced is the third option. When Acodei detects that the QuickBooks entity was created but the job did not finish, the row is moved to that status and left there deliberately, precisely so that a retry cannot pick it up and write a second entity. It is a parking space, not a failure.

The practical consequence is that a half-synced row usually has a real QuickBooks record behind it. Before you do anything, go and look. Search QuickBooks for the amount and date on the row. Most of the time you will find the sales receipt or the deposit sitting there, complete, and the only thing that is wrong is that Acodei does not have it marked as finished.

That changes what you should do next, and it is the opposite of the instinct. The instinct is to resync, because the row looks unfinished. Resync is a delete and rebuild, which is covered below, and it is a reasonable choice here precisely because it removes the orphaned entity rather than adding a sibling to it. What is not reasonable is doing anything that creates a second record while the first is still there.

Payout pending is not an error, and under Undeposited Funds it is structural

Payout pending means the payout is waiting on other transactions to sync first. Read on its own that sounds like a queue backup. It is usually a sequencing rule doing its job, and whether you ever see it depends on a setup choice you made months ago.

If your holding account is Undeposited Funds, a payout does not become a simple Transfer. It becomes an itemized Deposit that sweeps the individual payments into the bank, and every one of those underlying transactions has to already exist in QuickBooks for the Deposit to be built. If they are not all there, the payout fails with a mismatch error rather than posting a Deposit that is missing lines.

Put those two facts next to each other and the status stops looking like a backlog. Under Undeposited Funds, a payout genuinely cannot be built until its parts exist, so a payout that waited is a payout that refused to post a Deposit missing lines. That is the outcome you want. The alternative is a Deposit that does not match the bank line.

On a non-Undeposited-Funds holding account there is no such prerequisite. The payout becomes a single Transfer for the net amount, and the Transfer is independent of whether the individual sales have posted. So if you are on a clearing account and looking at a payout pending row, the interesting question is not why the payout is waiting but which underlying transactions have not synced, because that is the actual problem and the payout is just the thing that noticed.

Either way the row is pointing at something other than itself. Treat payout pending as a reference to the transactions it is waiting on, and go and look at those.

Why a row can look stuck without being stuck

There is a second layer under the status column that the Data Feed does not show you, and it explains the most confusing case: a row that has sat on the same status for a while with nothing apparently happening.

Each Transaction carries two flags separate from its status. One records whether it has been dispatched to the queue, with a distinct value for rows reserved for batch processing. A transaction already marked as dispatched is never dispatched again, which is a duplicate guard at the queue level. The other is set while a job is actually mid-run, so that if a second worker picks up the same transaction it returns early instead of writing the record twice.

Those two flags are why status alone can mislead. A row on "in progress" might be genuinely waiting in a queue, or it might have a worker inside it right now. And when a job does fail, part of what the failure path does is clear both flags, along with recording the error_msg and pushing an update to your dashboard. Some failures also send an email.

The useful heuristic: status tells you what was decided, and the decision does not change while a job is running. If a row has been on the same non-terminal status through a period when other rows on the same connection have moved, that is the signal worth acting on. A single row on "in progress" for ten minutes is not.

Resync is not a retry

This is the one to get right before you use it, because the Data Feed's bulk action offers exactly two verbs, delete and resync, and resync is the one people reach for reflexively.

Resync does not re-attempt a failed write. It books the QuickBooks-side delete first, and then re-books the transaction for its sync job. Invoices and customer-balance-tracker accounts take a separate path through the Go service rather than running in-process, but the shape is the same: the existing QuickBooks record is removed, and a new one is written.

That matters for two reasons.

The first is that the delete is real, and QuickBooks does not undo it. Intuit is direct about this: "Once a transaction is deleted in QuickBooks Online, it can't be restored." The audit log keeps the details so you can re-enter them by hand, and Intuit notes that the "Audit log only works for transactions that were saved", but there is no restore button. If you resync a row and the rebuild fails for a reason you did not anticipate, you are not back where you started. You are one record down with a failure to fix.

The second is that this is exactly why resync is the right tool for the job it was built for. Mapping changes, fee-method changes, and tax settings are not applied retroactively on their own. A record written last month reflects the configuration that existed last month, and no amount of waiting will update it. Resync is the mechanism that rebuilds it against current settings, and it works because it genuinely rebuilds rather than patching.

It is also the reason to resync from the Data Feed rather than fixing the QuickBooks record by hand. A hand-edited record breaks the linkage Acodei uses for reconciliation and reversal, so the next thing that needs to touch that record cannot find the version it expects.

One related behaviour worth knowing: bulk deleting is what unlocks a change of holding account. The permission to change it is granted when a connection has no synced transactions left, which in practice means after you have deleted everything Acodei booked. If you are trying to move between Undeposited Funds and a clearing account, that is a supported migration handled by a dedicated job against a saved settings backup, not a settings toggle you flip.

Reading the feed in practice

Work in this order.

Sync failed. Read the error_msg on the row. This is the only status that hands you the cause directly, and the causes cluster into a few recognisable families: a fee product that was deleted, a customer conflict, a validation mismatch. Stripe fee product sync errors is a worked example of the first. Fix the cause first, then resync. Resyncing before fixing the cause deletes a record and rebuilds it into the same error.

Half-synced. Look in QuickBooks before touching anything. If the entity is there and correct, resync is safe and is what clears the row. If it is not there, you have a different problem than the status suggests.

Payout pending. Do not act on the payout. Filter the feed for the same connection and date range and find the transactions that have not reached synced. Those are the work.

Delete failed. The QuickBooks side did not come off. Check whether the record still exists in QuickBooks, because a delete that failed because the record was already gone and a delete that failed because QuickBooks rejected it need different responses.

In progress, on a row that is genuinely old. Check whether anything else on that connection has moved recently. If nothing has, the problem is the connection rather than the row.

One record, wrong values. Do not edit it in QuickBooks. Change the mapping or the setting that produced it, then resync, so the record and Acodei agree about what it is.

Two habits make all of this shorter. Fix causes before rebuilding records, because resync is a delete. And check QuickBooks before you assume a row's status describes what is in QuickBooks, because on exactly one status it deliberately does not.

Frequently asked questions

What does half-synced mean in the Acodei Data Feed?

It means the QuickBooks entity was created but the job died before finishing, so the row was parked at that status on purpose. The parking exists so a retry cannot pick the transaction up and write a second QuickBooks entity. In most cases the QuickBooks record is present and complete, and only Acodei's own bookkeeping about the row is unfinished.

Why is my Stripe payout stuck on payout pending?

Because it is waiting on other transactions to sync first. On an Undeposited Funds holding account this is a hard prerequisite: the payout becomes an itemized Deposit, and every underlying transaction has to exist in QuickBooks before that Deposit can be built. Find the transactions on the same connection that have not reached synced. The payout will follow once they do.

Does resyncing a transaction delete the QuickBooks record?

Yes. A resync books the QuickBooks-side delete first and then re-books the transaction for its sync job, so the existing record is removed and a new one is written. It is a rebuild, not a retry. QuickBooks cannot restore a deleted transaction, so fix whatever caused the original failure before you resync.

Why did my mapping change not update older QuickBooks records?

Because settings are not applied retroactively on their own. Records already written reflect the configuration in place when they were written. Resync is the mechanism that rebuilds them against current settings, which is the main reason it exists.

Can I just fix the record in QuickBooks by hand?

You can, but it breaks the linkage Acodei uses for reconciliation and reversal, so anything that later needs to touch that record cannot find the version it expects. Changing the setting and resyncing leaves both sides agreeing about what the record is.

What is the difference between sync failed and delete failed?

Sync failed means the write into QuickBooks was attempted and rejected, and the row carries an error_msg explaining why. Delete failed means the removal of an existing QuickBooks record did not complete. They sit at opposite ends of the resync sequence, since a resync deletes before it rebuilds.

The takeaway

The status column is not a progress bar, and reading it as one is what turns a five-minute check into an afternoon. Each value records a decision: this was written, this was rejected and here is why, this is waiting on something else by design, this was stopped deliberately so it could not be duplicated.

Two of those decisions are protective rather than informational. Half-synced exists so a dead job cannot become a duplicate, and payout pending exists so a Deposit cannot post without the lines that belong in it. Both look like problems and are mostly the system refusing to make one.

The single most useful habit is to check QuickBooks before assuming the status describes it, and to fix causes before rebuilding records, because a resync deletes the record it is rebuilding and QuickBooks does not hand deleted records back.

Stop reading status columns to find out whether your books are right. Acodei syncs Stripe charges, refunds, fees, and payouts into QuickBooks Online with the accounts and the direction already correct, and tells you loudly when it cannot. Start a free trial.