A Stripe Invoice Resync Rebuilds Two QuickBooks Records

You fix a mapping, resync the transaction, and the QuickBooks record comes back correct. That is how a resync behaves for a charge. One row, one delete, one write.

Do the same thing to an invoice and the outcome is less predictable. You can end up with the invoice rebuilt but showing as unpaid, or with the old invoice still sitting there while everything around it has been replaced. Neither of those is a bug report. They are both the same fact showing through: a Stripe invoice is not one record in QuickBooks, so rebuilding it is never one delete and one write.

This post is about what actually happens when you resync an invoice, in the order it happens, and which of the surprising outcomes are designed. If what you need first is what each status in the feed is telling you, what each Acodei Data Feed status actually means covers that and the general rule that a resync is a delete rather than a retry. Everything below assumes you already know that much.

Want Stripe invoices, their payments, and their fees to land in QuickBooks correctly without a rebuild in the first place? Start a free trial.

An invoice is already two records before you resync anything

Acodei turns each syncable Stripe object into its own Transaction row, tagged with the Stripe event type that produced it. An invoice that was raised and then paid does not produce one of those rows. It produces two, and they are routed to different jobs.

invoice.created goes to the job that writes the QuickBooks Invoice: the document carrying the line items and the tax lines, reproduced as far as your mapping settings allow. invoice.paid goes to a different job entirely, and that one writes the Payment and applies it against the invoice that already exists. Void and uncollectible events go to the same second job and produce a void or a Credit Memo instead of a payment.

So one Stripe invoice, in the ordinary happy case, is two Data Feed rows, two jobs, and two QuickBooks documents. The invoice is the claim on the customer. The payment is the settlement of that claim. QuickBooks keeps them apart on purpose, because in the general case they are separated by weeks and the receivable has to exist in between.

Every strange thing a resync does to an invoice follows from that. "Rebuild the invoice" is a two-record operation being described with a one-record phrase.

What the feed is telling you when a resync is booked

The resync verb books the QuickBooks-side delete first and then re-books the transaction for its sync job. That much is the same for everything.

The detail that matters for invoices is in the statuses. A resync-booked row is not a single value. There are four, and they differ by what the row is coming back as: a plain record, a payment, an invoice, or a sales receipt. The feed distinguishes "this is being rebuilt as an invoice" from "this is being rebuilt as a payment" because those are separate units of work with separate outcomes, and one of them can succeed while the other does not.

Underneath, a resync moves rows through staging statuses before anything is written: one for the delete it is about to process, one for the resync itself, one for rows being re-dispatched through the main pipeline, and one for rows being closed out as not synced. Those changes are pushed back to the dashboard live, which is why the feed updates without a refresh. Invoices take a separate path through Acodei's Go service rather than running in the main worker, along with customer-balance-tracker accounts.

The practical reading: if you resync an invoice and watch only one row, you are watching half the operation.

The half-state where QuickBooks and the feed disagree

Acodei's documentation names one edge case explicitly, and it is the one worth recognising on sight. When a resync fails because the invoice is linked to a deposit, the child transactions are still dispatched.

Read that again, because the two halves of the sentence point in opposite directions. The parent invoice could not be deleted. Its children were rebuilt anyway. What you are left with is the original invoice still in QuickBooks, surrounded by records that have been torn down and written fresh.

That is the state where the Data Feed and QuickBooks can genuinely disagree about what exists, and it is why the habit of trusting the status column here is the expensive one. The feed will show you children that completed. QuickBooks will show you an invoice that was never replaced.

Acodei's docs name the condition and the behaviour. They do not spell out the linkage that causes it, so the useful move is to recognise the signature rather than to reason about the cause. If a resync on an invoice reports its children as done and the invoice itself looks untouched, open QuickBooks and check the invoice directly before doing anything else. In particular, do not resync a second time in the hope that it takes. The children will be rebuilt again, and the invoice still will not be.

The QuickBooks setting that decides whether the two halves reconnect

Here is the failure that looks most like a sync problem and is not one.

When Acodei writes the payment for an invoice, it applies that payment to the invoice automatically. That automatic application depends on QuickBooks' own automation preference being switched on. Intuit puts it under Settings, then Account and settings, then Advanced, in the Automation section, where it is called Automatically apply credits. Acodei's documented best practice is to leave it on, precisely so that payments and credit memos settle their invoices without anyone touching them.

Now put that inside a resync. Both halves get rebuilt. The invoice comes back. The payment comes back. If that QuickBooks preference is off, the part that does not happen is the link between them. You are looking at a correct invoice and a correct payment and an accounts receivable balance that says the customer still owes you.

Nothing in the sync failed, which is why nothing in the feed says so. The setting that joins the two records lives in QuickBooks, not in Acodei, and a resync is the moment you are most likely to notice it, because a resync is when both records are new at once.

What gets checked on the way back in

Acodei validates after writing rather than trusting the write, and for invoices there are four checks. It is worth knowing which is which, because two of them exist only for the payment half.

The first compares invoice numbers, to stop a duplicate invoice being created in QuickBooks. The second compares the finished QuickBooks invoice against the Stripe invoice amount and requires an exact match, and this one applies only when tax is enabled on the account. The third and fourth run only when a payment is being recorded: one confirms the correct amount was applied, the other confirms the payment is linked to the right invoice.

That second check has a consequence people do not expect. On a tax-enabled account, when the finished invoice does not match the Stripe amount exactly, the QuickBooks invoice that was just written is deleted, and the transaction is failed with an amount-mismatch message. So a resync can legitimately end with no invoice in QuickBooks at all. That is the system refusing to leave a wrong number in your books, not a write that went missing. If you are chasing a total that will not agree, why a Stripe invoice does not match QuickBooks works through the reasons a total drifts in the first place.

Invoice numbers survive the rebuild, with one gap

Because a resync writes a new invoice rather than editing the old one, invoice numbering is a live question rather than a settled one.

Acodei appends a suffix to synced invoice numbers by default, in the form of -AC1, -AC2 and so on. The reason is collision: businesses that also hand-enter invoices directly in QuickBooks would otherwise hit duplicate-number errors, and the suffix keeps the two sets apart.

The documented gap is manual renaming. Automated suffixing does not protect against someone renaming a synced invoice by hand in QuickBooks. That is worth knowing before a resync rather than after, because a renamed invoice is outside what the numbering logic is designed to protect.

When the rebuild is three records rather than two

Two is the common case, not the maximum. Several ordinary invoice lifecycles put a third record in play, and each one is another thing a rebuild has to get right.

A voided invoice that has credit notes attached is the clearest example. The attached credit notes are deleted first, and only then is the invoice voided. An invoice marked uncollectible and then later paid unwinds even further: it is reopened, the void transactions are deleted, and the new payment is processed. Credit notes themselves become Credit Memos, linked to the invoice when that link can be made and posted to the customer when it cannot.

None of these are exotic. Refunding part of a subscription invoice or writing off a bad debt that later clears will produce them. The general point holds throughout: the number of QuickBooks records behind one Stripe invoice is whatever its history made it, and a resync rebuilds all of them.

When to resync an invoice, and when to fix something else first

Acodei's documentation is direct about when a resync is the right tool. Settings are never applied retroactively on their own, so if you changed a mapping, a fee method, or a tax setting and want history to reflect it, a resync is how that happens. If a record errored and you have fixed the underlying cause, a resync is how it gets rebuilt. If the Stripe side changed, a resync is how QuickBooks catches up.

The instruction that goes with it matters more than the list. Resync from the Data Feed rather than hand-editing the QuickBooks record, because manual edits break the linkage Acodei uses for reconciliation and reversal. A hand-corrected invoice is not a corrected invoice as far as the integration is concerned. It is a record that no longer matches what Acodei believes it wrote. If you have a backlog of those already, cleaning up Stripe transactions in QuickBooks is the audit-first version of this job.

One case that looks like it needs a resync and does not: a fee that seems to be missing from an invoice. Stripe fees are never added to invoices, because doing so would make the invoice total disagree with Stripe. They are recorded through sales receipts, deposits, or expenses depending on your fee settings. An invoice without a fee line is the design working.

Frequently asked questions

What does resyncing a Stripe invoice actually do in QuickBooks?

It deletes the QuickBooks side and adds the invoice and its payment again. It is not a retry of a failed write and it is not an edit of the existing record. Both halves of the invoice are removed and written fresh from the Stripe data, which is also why any manual change you made in QuickBooks in between is discarded rather than preserved.

Why did my invoice come back unpaid after a resync?

The most common cause is not the sync. When Acodei writes the payment it applies it to the invoice automatically, and that automatic application depends on QuickBooks' own Automatically apply credits setting, under Settings, Account and settings, Advanced, Automation. With it off, both records are created correctly and the link between them is what is missing, which shows up as an invoice that looks unpaid.

Why does the Data Feed show the resync finished when QuickBooks still has the old invoice?

That is the documented case where a resync fails because the invoice is linked to a deposit. The parent invoice cannot be deleted, but the child transactions are dispatched anyway, so the feed shows work completing while the original invoice stays in place. Check the invoice in QuickBooks directly rather than resyncing again.

Can a resync delete my invoice and not replace it?

Yes, on a tax-enabled account, and deliberately. Acodei re-reads the finished QuickBooks invoice and compares it to the Stripe amount. If they do not match exactly, the invoice it just wrote is deleted and the transaction is failed with an amount-mismatch message rather than leaving a wrong total in your books. This particular check runs only when tax is enabled for the account.

Will resyncing change my invoice number?

Acodei appends a suffix such as -AC1 to synced invoice numbers by default, which exists to prevent duplicate-number errors for businesses that also enter invoices directly in QuickBooks. The documented limitation is that this automated suffixing does not protect against an invoice that someone renamed by hand in QuickBooks.

Should I fix an invoice in QuickBooks or resync it?

Resync it. Manual edits break the linkage Acodei uses for reconciliation and reversal, so a hand-corrected record stops matching what the integration believes it wrote. Fix the cause first, whether that is a mapping, a tax setting, or the Stripe-side data, then resync so the rebuild picks the correction up.

The takeaway

A charge resync is one record. An invoice resync is at least two, sometimes three, and the halves succeed independently. That single fact explains the unpaid invoice, the invoice that survived its own rebuild, and the invoice that vanished on a tax-enabled account.

Three habits follow from it. Watch both rows in the feed rather than one. Check QuickBooks itself before resyncing a second time, because a repeated resync rebuilds the same children and leaves the same parent. And fix the cause before rebuilding the record, because the rebuild reads from Stripe and does not know what you fixed by hand.

Stop rebuilding invoices to find out whether the last rebuild worked. Acodei mirrors Stripe invoices, payments, and credit notes into QuickBooks Online, checks what it writes against the Stripe original, and shows you every synced and errored transaction in one feed you can resync from. Start a free trial.