Stripe Refund After Payout: Where the Money Comes From

A customer bought a $400 annual plan on March 3. The money paid out to your bank on March 5, and your bookkeeper matched that deposit the same week. On March 19 the customer asks for their money back, and you click Refund in Stripe.

Nothing in your bank account moves on March 19. The original deposit is already reconciled and it is not going to change. So where does the $400 actually come from, which deposit shows it, and what should your QuickBooks file look like when the dust settles?

The short answer: Stripe pays the refund out of whatever is sitting in your Stripe balance on the day you issue it, so it shows up as a smaller amount in the next payout, not as a change to the old one. If the balance cannot cover it, the outcome depends on the payment method, and the gap can end up being pulled from your bank. This post works through that timing case with numbers, and shows which QuickBooks records carry it on each kind of setup.

If you would rather have late refunds land on the right date, against the right account, without anyone touching a reconciled deposit, start a free trial.

Why the old deposit never changes

Stripe does not reach back into a payout that has already landed. A refund is a new movement of money, and Stripe's refund documentation is explicit about where it is funded from: "Refunds use your available Stripe balance (not including pending amounts)."

Two consequences follow, and both matter for your books.

First, the refund belongs to the period in which you issued it. The March 3 sale and the March 5 payout are finished events. The March 19 refund is a new event with its own date, and it is paid for with money that arrived in your Stripe balance around March 19, which is usually other customers' payments.

Second, the processing fee is gone for good. Stripe states that its "processing fees from the original transaction aren't returned." So the refund is the full $400, even though only $388.10 of the original sale ever reached your bank (assuming an $11.90 fee on that charge). The $11.90 stays on your books as a real cost of a sale you no longer have.

The Stripe refund glossary entry covers the refund object itself: its statuses, its fields, and what pending means. This post is about the calendar: a refund in a later payout period than its sale.

One refund, two payout periods, worked through

Here is the example laid out as Stripe sees it. Assume a normal automatic payout schedule and a busy enough account that there are always new sales in the balance.

Period 1

Date	Stripe activity	Amount
Mar 3	Charge, annual plan	+$400.00
Mar 3	Stripe fee on that charge	-$11.90
Mar 5	Payout to bank	-$388.10

Period 2

Date	Stripe activity	Amount
Mar 19	Three new charges	+$1,200.00
Mar 19	Stripe fees on those charges	-$35.70
Mar 19	Refund of the Mar 3 charge	-$400.00
Mar 21	Payout to bank	-$764.30

The refund is simply one more line inside Period 2. Stripe's payout reconciliation documentation shows this directly: the list of balance transactions behind a payout carries a type for each line, and a refund appears in it as its own negative entry with type refund, next to the charges and fees it netted against.

So the answer to "where did the money come from" is: from the three March 19 sales. The March 21 deposit is $400 smaller than it would otherwise have been, and nothing about the March 5 deposit changes.

This is also why a late refund makes the next deposit look wrong to anyone matching bank lines to sales. Period 2 had $1,200 of new sales and a deposit of $764.30. The $400 gap is a sale from two weeks earlier, and you only see it if you look at the payout's balance transactions rather than at the day's sales.

When the balance cannot cover the refund

Now take the same refund on a quiet account. There were no new sales between the March 5 payout and March 19, so the available balance is $0 when you click Refund.

Stripe splits the outcome by payment method: "If your available balance doesn't cover the amount of the refund, Stripe holds the refund as pending for card transactions (refunds for other payment method types fail) until your Stripe balance becomes sufficient."

In practice that gives you three possible paths:

1. The refund waits. On a card payment, the refund sits as pending until enough new money arrives. It then comes out of those new payments, and the picture is the same as the worked example, just a few days later. A refund that waits too long can still fail: one of the failure reasons Stripe documents is insufficient_funds, meaning the refund "is pending due to insufficient funds and has crossed the pending refund expiry window."
2. You fund the balance. Stripe's guidance is that "You can resolve a negative Stripe balance by collecting payments or topping up your account balance." A top-up moves money from your bank into Stripe on purpose, so the refund is paid from your bank, just deliberately.
3. Stripe takes it from your bank. Stripe also says that "In regions where applicable, Stripe might debit your bank accounts automatically to recover a negative Stripe balance." That debit is a negative payout: a withdrawal from your bank instead of a deposit.

On an ACH, SEPA or other non-card payment, path 1 does not exist. With too little available balance, the refund fails instead of waiting, and you have to fund the balance and issue it again.

Which path you get matters for your books. In path 1 the refund still comes out of later sales. In paths 2 and 3 real money leaves your bank account, and that movement needs its own record. Our guide to negative Stripe payouts in QuickBooks works through that debit line by line. The refund entry itself is the same whichever way it gets funded.

What your books should look like

Forget any particular tool for a moment. On a Stripe clearing account setup (an asset account that stands in for your Stripe balance), the late refund produces this shape:

Date	Record	Stripe clearing	Bank
Mar 3	Sale of $400, less $11.90 fee	+$388.10
Mar 5	Payout 1 transfer	-$388.10	+$388.10
Mar 19	New sales of $1,200, less $35.70 fees	+$1,164.30
Mar 19	Refund of the Mar 3 sale	-$400.00
Mar 21	Payout 2 transfer	-$764.30	+$764.30

The clearing account ends each payout cycle back at zero, the bank shows exactly the two deposits it actually received, and the refund sits on March 19 where it happened. Nothing is booked against March 3 or March 5 after the fact.

On the profit and loss, the refund lands in the period of March 19. If March 3 and March 19 fall in the same month, the sale and refund cancel out within it. If the sale was in February and the refund in March, February keeps its revenue and March absorbs the reversal. That is the correct result for a refund dated when it happened. Whether your business should also accrue for expected refunds at month end is an accounting policy question for your accountant, not something the sync decides.

Which QuickBooks records Acodei creates for a late refund

Here is what Acodei records for each piece of it. What you get depends on your sync mode and your holding account type.

Real-time accounts. The refund syncs on its own, when Stripe reports it with the charge.refunded event. Acodei creates a Refund Receipt against the customer, drawing from the resolved holding account, with line items mirroring what was refunded. Whether the refund is full or partial is detected by comparing the refund amount to the original charge amount. It is the offsetting record for the sale, created when the refund happens, rather than an edit to the March 3 Sales Receipt.

The later payout, with a clearing (non-Undeposited Funds) holding account. When the March 21 payout is paid, Acodei records a single Transfer from the holding account to your mapped deposit bank account for the payout's net amount: $764.30. The refund needs no special handling at payout time. It already reduced the holding account on March 19, and the transfer is exactly what is left.

The later payout, with Undeposited Funds as the holding account. Here the payout becomes a QuickBooks Deposit that itemizes the underlying activity, including charges, refunds and fees, out of Undeposited Funds into your bank. The March 19 refund is one of the itemized lines on the March 21 deposit, which is exactly where a bookkeeper matching that deposit needs to see it. There is one precondition: a deposit like this can only be built once every underlying transaction already exists in QuickBooks. If the refund had not synced, the payout would be blocked with a mismatch error rather than posted with a hole in it.

Daily summary accounts. These get no per-charge or per-refund records. Instead, the payout's balance transactions are aggregated by day and currency, and each day becomes one Sales Receipt when it nets positive or one Refund Receipt when it nets negative. The March 19 refund falls into March 19's group. On a busy day it simply reduces that day's summary. On a quiet day where the refund outweighs the sales, that day's record is a Refund Receipt.

If the refund forces a negative payout. When Stripe debits your bank to cover a negative balance, Acodei records a Transfer in the reverse direction, from the bank account into the holding account, for the absolute amount. That applies to both holding account types. A top-up is also recorded as a Transfer from the bank into the holding account. Either way, the bank movement gets its own record and the Refund Receipt stays as it is.

Refunds of invoice payments are different. If the original charge paid a Stripe invoice that Acodei had synced, the refund can instead reverse the original records rather than produce a new Refund Receipt. If your late refunds are mostly against invoices, read how to record Stripe refunds in QuickBooks Online for when a Credit Memo is the right record rather than a Refund Receipt.

The fixes that make it worse

Late refunds generate a few instinctive repairs. Each of them breaks something that was already right.

Editing or re-matching the old deposit. The March 5 deposit happened, for $388.10, and your bank statement says so. Reducing it to $0 or re-coding it to make the refund "disappear" leaves QuickBooks disagreeing with the bank for a period that was already reconciled.

Voiding or deleting the original sale. That moves the refund back to March 3, a date on which nothing was refunded, and it erases the fee that Stripe did charge. If the sale fell in a closed period, it also reopens that period.

Reversing the fee. The refund is $400, not $388.10, because Stripe keeps its fee. Backing out the $11.90 to make the numbers look symmetrical understates your processing cost and leaves your clearing account $11.90 off from Stripe's balance.

Recording the refund against your bank account. The money came out of your Stripe balance on March 19, not out of your checking account. Recording it against the bank double-counts it once the March 21 deposit arrives $400 short.

Waiting to book it until you can see which deposit took it. The refund is dated to when you issued it, whichever payout ends up carrying it. On an Undeposited Funds setup, waiting also blocks the next deposit, because the payout cannot be built while one of its lines is missing from QuickBooks.

When the late refund fails

A customer who closed a card or a bank account since March 3 may never receive the March 19 refund.

Stripe describes what happens next: "the bank returns the refunded amount to Stripe, and Stripe adds it back to your Stripe account balance. This process can take up to 30 days from the post date." The refund object then carries failure_balance_transaction, the ID of the balance transaction for the money coming back.

That can put a refund and its return in two different months. Acodei's documented guidance for a failed refund is to resync the affected refund or payout. Resyncing a refund that is already booked updates the existing QuickBooks record rather than creating a second one, so chasing the discrepancy this way will not leave duplicates. You also still owe the customer, and Stripe notes that "you need to arrange an alternative way to provide your customer with a refund." When a Stripe refund fails and the money comes back covers the full sequence.

A check for the next late refund

When a customer asks for money back weeks after they paid:

1. Look at your available balance before you click Refund. If it will not cover the amount, decide now whether to wait, top up, or accept a bank debit. On a non-card payment, a thin balance means the refund fails.
2. Confirm the refund's status in Stripe the same day. succeeded means it has gone; pending means it is waiting for balance or processing.
3. Expect the next deposit to be short by the refund amount, not by the refund minus the fee.
4. When you match that deposit, read the payout's balance transactions, not the day's sales. The refund line explains the gap.
5. Leave the original sale and the original deposit alone. Both are correct.
6. If the customer says the money has not arrived, tell them to allow time. Stripe says customers see the refund as a credit "approximately 5-10 business days later, depending upon the bank."

For the full reconciliation pattern around this, including disputes, reserves and failed payouts, see the Stripe payout reconciliation guide.

Ready to stop working out which deposit a refund landed in? Start a free trial.

Frequently asked questions

Where does the money come from when I refund a Stripe charge that has already paid out?

From your current Stripe balance. Stripe says refunds use your available balance, not including pending amounts. On an active account that means other customers' recent payments, so the refund shows up as a smaller next payout. The earlier payout is not reversed or changed.

Will Stripe take a refund out of my bank account?

It can. If your available balance does not cover a card refund, Stripe holds the refund as pending until the balance is sufficient, and refunds on other payment methods fail instead. Stripe also says that in regions where it applies, it might debit your bank account automatically to recover a negative balance. That debit is a negative payout and needs its own record in QuickBooks.

Should I adjust the original deposit in QuickBooks when I refund after a payout?

No. The original deposit happened for the amount your bank received, and it should stay reconciled. Record the refund on the date you issued it, against the account that represents your Stripe balance, and let the next payout carry the reduced amount.

Why is my next Stripe payout smaller than my sales for the period?

Usually because a refund, a dispute or a fee from earlier activity was netted against it. A refund of an older sale is funded from new payments, so the payout covering the refund date is smaller by the full refund amount. The balance transactions list behind that payout shows the refund as its own negative line with type refund.

Do I get the Stripe fee back if I refund weeks later?

No. Stripe states that processing fees from the original transaction aren't returned, whether you refund the same day or weeks later. The refund is the full amount the customer paid, and the original fee stays on your books as an expense.

What does Acodei create in QuickBooks when I refund an old Stripe charge?

On real-time accounts, a Refund Receipt against the customer, drawing from your holding account, with lines mirroring what was refunded. It is a new record, not an edit to the original sale. The payout that later carries the refund is recorded as a Transfer from a clearing holding account, or as a Deposit that itemizes the refund if you use Undeposited Funds. Daily summary accounts get the refund inside that day's summary record instead. Refunds of synced invoice payments can reverse the original records instead.