When a Stripe Payout Fails: What QuickBooks Should Show

Payday came and went. Your bank account shows no Stripe deposit. Stripe shows the money sitting in your balance, as if it never left. QuickBooks shows nothing at all: no transfer, no deposit, no error.

Three systems, three different pictures, and the natural conclusion is that something is broken and you should go fix it by hand.

Almost always, nothing is broken. A failed payout is one of the few Stripe events where the correct number of QuickBooks entries is zero, and the damage in these situations is nearly always self-inflicted: someone records a correcting deposit for money that never arrived, and then the replacement payout lands a week later and books the same dollars a second time.

Reconciling Stripe by hand every month? Acodei posts payouts, fees, refunds, and disputes into QuickBooks Online automatically, with the accounts and the direction already right. Start a free trial.

What Stripe actually does when a payout fails

A payout object carries a status, and Stripe documents the path it takes: "A payout is pending until it's submitted to the bank, when it becomes in_transit. The status changes to paid if the transaction succeeds, or to failed or canceled (within 5 business days)."

So a failure is not instant. Stripe hands the payout to the banking network, the network takes days to reject it, and the rejection comes back to Stripe on the network's schedule rather than yours. Five business days is the documented outer edge, which in practice means a payout that failed on a Friday can surface the following Friday.

When it does fail, the money comes back. Stripe records that on the payout object in a field called failure_balance_transaction, described as "the ID of the balance transaction that reverses the initial balance transaction and returns the funds from the failed payout back in your balance."

Read that carefully, because the whole accounting answer follows from it. Stripe does not create a new deposit and then claw it back. It reverses the original balance transaction. The payout is unwound, not compensated for. Your Stripe balance ends up exactly where it was before the payout was attempted, and your bank account was never touched.

Stripe also tells you why it failed, in a failure_code field with eighteen documented values. They divide cleanly into three groups by what you have to do about them:

Wrong account details, fixable by you. no_account, invalid_account_number, invalid_account_number_length, incorrect_account_holder_name, incorrect_account_holder_address, incorrect_account_holder_tax_id, incorrect_account_type. Stripe's note on account type is worth knowing before you argue with it: the value "can only be checking or savings in most countries. In Japan, it can only be futsu or toza."

The bank will not cooperate, fixable by your bank. account_closed, account_frozen, bank_account_restricted, bank_account_unusable, bank_ownership_changed, could_not_process, declined, debit_not_authorized, unsupported_card, invalid_currency. Two of these mislead people. bank_account_restricted "normally indicates that the bank account is a savings or other non-checking account." And debit_not_authorized catches businesses off guard because Stripe requires bank accounts "to be set up for both credit and debit payouts," not just to receive money.

Not the bank's fault at all. insufficient_funds, which Stripe defines as "Your Stripe account has insufficient funds to cover the payout." This one is a Stripe-side condition, and it usually means refunds or disputes ate the balance between the moment the payout was created and the moment it was submitted.

That last group matters for your books more than the other two, because it tends to travel with a negative balance, and a negative balance produces its own kind of payout. If Stripe ends up pulling money out of your bank instead of sending money to it, that is a different event with a different entry, covered in negative Stripe payouts in QuickBooks.

What QuickBooks should show: nothing

Acodei's documented behavior on a failed or canceled payout is that the payout is closed out without a QuickBooks record being created. The reasoning in the product documentation is one sentence long: nothing to book, because the money never moved.

That is the correct answer, and it is worth sitting with for a second because "the integration did nothing" is an uncomfortable thing to read when you are staring at a missing deposit.

Work the double entry. A successful payout moves value from one asset account to another: out of the account standing in for your Stripe balance, and into your real bank account. Both sides of that entry are conditional on the money arriving. If the payout fails, the bank side never happened, and the Stripe side never happened either, because Stripe reversed the balance transaction. There is no economic event. There is no journal entry that represents "we tried."

The books are already correct. Your holding account still carries the funds, because the funds are still at Stripe. Your bank account shows no deposit, because there was no deposit. Those two statements agree with reality, and any entry you add to "fix" them will make them disagree with it.

The three reasons a payout is missing, and only one is a problem

"My payout isn't in QuickBooks" is a symptom, not a diagnosis. Three quite different conditions produce it, and telling them apart takes about a minute.

One: Stripe failed or canceled the payout. Nothing posts, and nothing should. Your evidence is the payout's status in the Stripe Dashboard reading failed or canceled, with a failure code attached. There is no error to clear on the Acodei side, and no action beyond fixing whatever the failure code points at. The funds are back in your Stripe balance and leave with a later payout.

Two: the payout is waiting on other transactions. This one only happens on Undeposited Funds. An itemized deposit can only be built if every underlying charge, refund, and fee already exists in QuickBooks, so a payout containing a transaction that has not synced yet gets blocked with a mismatch error, and each missing transaction is recorded for retry. Acodei parks the payout at a status that says exactly this, "Waiting for other transactions to be synced," rather than failing it. It is not lost. It is queued, and it clears when its dependencies do. This is the sequencing cost of the Undeposited Funds model, and it is the main reason a regular asset clearing account is recommended for higher-volume accounts.

Three: the payout errored on sync. Two documented cases. A payout with no deposit bank account assigned errors with a prompt to assign one, which happens most often right after a new Stripe account is connected and Account Mapping has not been completed for it. And a payout whose line items cannot be resolved errors with "No line items" rather than closing silently. Both of these need you. Neither has anything to do with Stripe failing a payout.

The distinction that saves the most time: case one produces no record and no error, and that is success. Case three produces no record and an error, and that is a job for you. If you are looking at a missing payout and there is no error anywhere, you are almost certainly in case one, and you are done.

The case the documentation does not cover, and you should know about

Here is where I have to be straight with you about a boundary.

Acodei creates the payout record when Stripe sends the payout.paid event. Stripe's own description of that event is more careful than most people notice: "Occurs whenever a payout is expected to be available in the destination account. If the payout fails, a payout.failed notification is also sent, at a later time."

Expected. Not confirmed. And the payout object documentation says the same thing from the other direction: "Some payouts that fail might initially show as paid, then change to failed."

So there are two orderings, not one. In the common ordering, the payout fails before it is ever marked paid, no QuickBooks record was ever created, and everything above applies cleanly. In the other ordering, payout.paid arrives first, the QuickBooks record is created (a Transfer on a clearing account, an itemized Deposit on Undeposited Funds), and the failure notification lands days later against a payout that has already been booked.

What happens to that already-created record when the late failure arrives is not something Acodei's product documentation currently states. I am not going to guess at it for you. The documented behavior covers the failed or canceled payout that closes out without a record; the paid-then-failed sequence is a genuinely different situation, and the honest answer today is to verify rather than assume.

Verifying is not hard, and the next section is how.

How you would catch it, and why it depends on your holding account

Your holding account setting decides both the shape of a payout record and the method you use to check it, and those two things are more connected than they look.

On a regular asset clearing account, the correct reconciliation method is balance reconciliation: the QuickBooks clearing-account balance should equal the Stripe balance. Because every sale, fee, and payout posts against that account as it happens, the two can be compared daily, which the product documentation calls the gold standard, and monthly at absolute minimum.

This is not just advice. Acodei runs a daily balance tracker built specifically for this mode and scoped only to non-Undeposited-Funds connections. It fetches the Stripe balance and the QuickBooks holding-account balance into per-day rows and records whether they matched.

Now apply that to a paid-then-failed payout. A Transfer was written out of the clearing account for money that came back to Stripe. The Stripe balance is higher than the clearing account by exactly the payout amount, and the day that happens is a day the tracker records as not matching. That is precisely the drift a daily balance comparison exists to surface, and it surfaces within a day.

On Undeposited Funds, the method is narrower: match each payout deposit against the bank feed, then reconcile the bank account. Acodei's documentation is explicit that balance-reconciling the Undeposited Funds account itself is not supported, and gives the reason. Sales sit in Undeposited Funds until a payout sweeps them, and some items such as deferred fees and mapped uncommon types are only added at deposit time, so the account's balance can legitimately diverge from the Stripe balance at any given moment. A point-in-time comparison is not meaningful there the way it is for a clearing account.

Which sounds like bad news for this scenario and is actually fine, because the check that does exist catches it directly. A deposit was recorded for a payout the bank never made. There is no bank line for it. It will sit in your bank feed unmatched, month after month, and an unmatched deposit is the single most visible artifact in QuickBooks reconciliation. You do not need a balance comparison to find it. You need to not ignore it.

Both modes catch the problem. They just catch it with different instruments, and the underlying reason a clearing account is recommended for more complicated accounts is right here: drift is caught within a day, rather than at the next reconciliation.

If you want the full method for either mode, Stripe payout reconciliation in QuickBooks is the complete walkthrough, and the Undeposited Funds entry covers what the account is and when to skip it.

What not to do

Do not hand-enter a deposit for a payout that failed. There is no money to record. When the replacement payout arrives and syncs normally, you will have the amount twice, and the second copy is much harder to find than the first because by then it looks like ordinary history.

Do not delete or edit records for the underlying charges. The sales that were supposed to be in that payout are real sales. They happened, the revenue is earned, and the money is genuinely sitting in your Stripe balance. Nothing about a failed payout makes the sales inside it less real.

Do not force a resync hoping to make the entry appear. The entry is absent by design. The sync did what it should.

Do not journal the funds into a suspense or receivable account while you wait. Your holding account already is the account that represents "money at Stripe." Moving it somewhere else adds a reconciling item to every future period until somebody remembers to move it back.

The one thing worth doing is going back to the failure code and fixing whatever it names. The funds are already back in your Stripe balance, so once the blockage is cleared they go out on your normal payout schedule with everything else that has accumulated since.

Canceled payouts and manual payouts

A canceled payout is treated the same way as a failed one: closed out, no QuickBooks record. Cancellation typically happens with a manual payout that was withdrawn before the bank processed it, and the funds simply stay in your balance.

Manual payouts carry one wrinkle worth knowing if you are trying to reconstruct history rather than watch it live. Stripe's payout object has a reconciliation_status field, and the value not_applicable means, in Stripe's own words, "We don't support listing Balance Transactions for this payout. We only support this for standard automatic payouts."

That is a Stripe-side limitation and it explains something that otherwise looks like a gap on the accounting side: for a manual payout, you cannot ask the API what was in it. The composition has to be assembled from the date range instead. If you have ever wondered why a manual payout is harder to tie out than an automatic one, that is the reason, and it starts at Stripe rather than at your books.

Worth adding: manual payouts themselves are not universal. Stripe documents them as "available in all regions except Brazil and India, where payouts are always automatic and daily."

A close checklist

Five minutes, at close, when a payout is missing.

1. Open the payout in the Stripe Dashboard and read its status. failed or canceled means no QuickBooks entry is expected.
2. Read the failure code. Fix what it names, whether that is bank details on your side or a call to your bank.
3. Confirm your holding account still carries the funds. On a clearing account, its balance should equal the Stripe balance. Under Undeposited Funds, confirm no deposit was created for the failed payout.
4. Check the bank feed for unmatched deposits. A deposit with no bank line is the signature of the paid-then-failed ordering.
5. Do nothing else. In particular, do not post a correcting entry.

Frequently asked questions

Why is there no QuickBooks entry for my failed Stripe payout?

Because no money moved. Acodei's documented behavior is to close out a failed or canceled payout without creating a QuickBooks record, on the reasoning that there is nothing to book. Stripe reverses the original balance transaction and returns the funds to your Stripe balance, so your holding account correctly still shows the money sitting at Stripe.

How long does it take for a Stripe payout to be marked failed?

Up to five business days. Stripe's documentation says a payout's status "changes to paid if the transaction succeeds, or to failed or canceled (within 5 business days)." The delay is the banking network returning the payment, not Stripe being slow.

Can a Stripe payout show as paid and then fail?

Yes. Stripe documents this directly: "Some payouts that fail might initially show as paid, then change to failed." The payout.paid event fires when a payout is expected to arrive, not when arrival is confirmed, and Stripe sends a separate payout.failed notification later if it does not.

What happens in QuickBooks if a payout was already recorded and then failed?

Acodei's product documentation covers the failed payout that closes out without a record. It does not currently state what happens to a record that was already created when a late failure arrives, so the safe move is to verify rather than assume. On a clearing account, the daily balance comparison against Stripe will show the discrepancy. Under Undeposited Funds, the deposit will sit unmatched in your bank feed.

Should I record a journal entry for a failed payout?

No. The books are already correct without one. The funds are in your Stripe balance, your holding account already represents that balance, and your bank shows no deposit because there was none. A journal entry would introduce an error rather than correct one.

Does a failed payout mean my sales did not sync?

No. The individual charges, refunds, and fees sync on their own path and are unaffected. A payout is a separate event that moves already-recorded money to the bank. A failed payout leaves those sales exactly where they were, in your holding account.

What causes a Stripe payout to fail?

Stripe publishes eighteen failure codes. Most describe bank account problems: closed, frozen, restricted to non-checking use, wrong account or routing number, wrong holder name or address, or a bank that declined the transfer. One is different, insufficient_funds, which means your Stripe balance could not cover the payout, usually because refunds or disputes landed after it was created.

Will Stripe try the payout again?

Once the underlying problem is fixed, the funds go out on your normal payout schedule. Correcting the bank details is what unblocks it. The failed payout itself is not resurrected; a new payout carries the money instead.

Is a failed payout the same as a negative payout?

No, and they are easy to confuse because both leave you without the deposit you expected. A failed payout is money that tried to reach your bank and came back. A negative payout is Stripe pulling money out of your bank because refunds and disputes exceeded sales, and it does produce a QuickBooks entry: a transfer running from the bank back into your holding account.

The point

A failed payout is one of the rare cases where a bookkeeping system doing nothing is the system being right. Stripe reverses its own balance transaction, your bank was never touched, and the funds are already sitting in the account your books say they are sitting in.

That leaves you with two jobs and neither of them is data entry. Fix whatever the failure code names, because until you do, every payout after this one fails the same way. And know which ordering you are in, because a payout that was marked paid before it failed is the one case that leaves a real record behind, and the check that finds it is the one you should already be running: a daily balance comparison on a clearing account, or an honest look at unmatched deposits in the bank feed.

Acodei handles the payout side so the only thing left is the part that needs a human, which is deciding what a missing deposit actually means.

Stop hand-keying Stripe activity into QuickBooks. Acodei syncs payouts, fees, refunds, and disputes into QuickBooks Online, and knows which Stripe events should produce an entry and which should not. Start a free trial.