Refunding a Foreign-Currency Stripe Charge in QuickBooks

On March 3 a customer in Berlin pays you €500 by card. Your Stripe account settles in US dollars, so Stripe converts the payment and $550.00 lands in your balance. On March 24 the customer asks for their money back and you refund in full. The customer gets exactly €500. Your Stripe balance loses $565.00. Nobody made a mistake, and yet the refund took $15 more out of the business than the sale put in, before you even count the Stripe fee you don't get back.

That $15 is the part that trips up QuickBooks. A refund is normally a clean mirror of the sale, so bookkeepers (and most sync setups) expect the refund to cancel the sale to the cent. With a converted charge it can't, because Stripe prices the refund at a different exchange rate than the sale. This post walks through what Stripe records for each side, why the difference is an exchange loss (or gain) and not a fee, and how to book it so your Stripe clearing account still reconciles. If you would rather have the sales, refunds and fees posted for you and spend your time on the one line that needs judgment, start a free trial.

Why Stripe refunds a converted charge at a new rate

Stripe states the rule plainly in its documentation on conversions for disputes and refunds: if a currency-converted payment is refunded, "the amount you received is converted to the presentment currency at the current exchange rate." The rate at refund time can differ from the rate at payment time, so "the amount deducted from your merchant balance depends on the current rate and this amount might be more or less than the original payment." And on the customer side: "We always refund the customer the exact amount they paid and in the currency they paid in, regardless of any rate fluctuations."

Two terms matter here:

• Presentment currency is the currency the customer paid in. In the example, EUR.
• Settlement currency is the currency of the balance the money lands in. In the example, USD.

When the two differ and you don't hold a balance in the presentment currency, Stripe converts. The customer is protected from the exchange rate twice, once on the way in and once on the way out. You carry the risk on both legs, and the refund is where it shows.

Stripe's own example runs the other direction: a business settling in EUR takes a 60 USD payment at 0.88 EUR per dollar (52.80 EUR), then refunds when the rate is 0.86 and has 51.60 EUR deducted. That one came out 1.20 EUR in the merchant's favor. The rate can move either way, so the difference is sometimes a loss and sometimes a gain.

The one exception is Adaptive Pricing. When the customer saw a local price through Stripe's Adaptive Pricing, Stripe says "the refund uses the same exchange rate as the original transaction, so there are no extra costs for you." Those refunds do mirror the sale, and the QuickBooks side is different. The Adaptive Pricing guide covers that case. Everything below is about the ordinary kind: a charge created in a foreign currency (a Price in EUR, a Payment Link in EUR, a currency_options price) settling into a balance in another currency.

What Stripe's balance history shows for the charge and the refund

Every movement in your Stripe balance is a balance transaction, and each one carries the numbers you need. According to Stripe's API reference, a balance transaction's exchange_rate is set when money converts from one currency to another: "the amount in currency A, multiplied by the exchange_rate, equals the amount in currency B."

For the Berlin example, the two rows look like this (fee figures are illustrative, see the note below):

Date	Type	Customer sees	Balance amount (USD)	Exchange rate	Stripe fee	Net (USD)
Mar 3	charge	€500.00	550.00	1.10	30.00	520.00
Mar 24	refund	€500.00 back	-565.00	1.13	0.00	-565.00

Three things to read off that table.

The two amounts don't match. The charge brought in $550.00. The refund took out $565.00. The euro amount is identical on both rows. Only the dollar translation differs.

The fee stays. Stripe's pricing page says that for most payment methods "there are no fees for issuing refunds," and also that "the payment processing, Connect and currency conversion fees from the original transaction are not returned." So the $30.00 from March 3 is a permanent cost of a sale that no longer exists.

The fee is not the gap. It is tempting to treat the whole $45.00 hole ($565.00 out, $520.00 net in) as "Stripe fees." It isn't. $30.00 is a processing fee you would have paid on any card sale. $15.00 is the rate moving between March 3 and March 24. They belong in different accounts, and if you lump them together your fee expense stops matching your Stripe statements.

A note on the fee figure: under Stripe's US standard pricing, a card payment costs 2.9% + 30¢, plus 1.5% for an international card and 1% if currency conversion is required. On $550.00 that is 5.4% plus 30¢, or $30.00. Your real fee and rate will differ, so take both from the balance transaction rather than recomputing them.

Where the difference belongs: an exchange loss, not a fee and not a refund

Put the whole story in dollars and it is three separate events:

1. A sale of $550.00, the dollar value of €500 on March 3.
2. A processing fee of $30.00, which Stripe keeps.
3. A refund of the sale. The customer is owed back what they paid, €500. On March 24 that costs $565.00.

The economic loss from the rate movement is $15.00. Under ordinary accrual accounting that is a foreign exchange loss: the cost of having an obligation in euros while your books run in dollars. If the euro had weakened to 1.07 instead, the refund would have cost $535.00 and you would have a $15.00 exchange gain.

What it is not:

• Not a reduction of revenue beyond the sale. You sold €500 of goods and gave €500 back. Net revenue from this customer is zero. If the full $565.00 hits your income account, your revenue for March is understated by $15.00.
• Not a Stripe fee. Stripe charged no refund fee. Booking the $15.00 to Stripe Fees overstates what you paid Stripe.
• Not a rounding error to write off. It's $15 on one refund. On a business with a few hundred foreign refunds a quarter, it becomes a real line.

QuickBooks has a home for this. A file with Multicurrency turned on carries an Exchange Gain or Loss account that QuickBooks creates for exactly this kind of difference. A single-currency file doesn't have one by default, so you create an ordinary expense account for it (something like "Foreign exchange gain/loss", typed as Other Expense if you want it below operating income).

How to book it in a single-currency QuickBooks file

This is the common case: a US business on QuickBooks Online without Multicurrency, where every Stripe transaction lands in dollars because Stripe already converted it. Your Stripe clearing account (the asset account that stands in for your Stripe balance) is where the gap surfaces.

The sale, March 3. A sales receipt for $550.00 deposited to Stripe Clearing, with the $30.00 fee either as a negative line on the receipt or as a separate expense. Clearing is up $520.00, matching Stripe.

The refund, March 24. Here there are two ways the refund record can be built, and you need to know which one you have.

Option A: the refund mirrors the sale at $550.00. This is what you get if the refund receipt is built from the original sale's dollar lines. Income goes back down by $550.00, which is correct. But Stripe Clearing only drops by $550.00 while Stripe's balance dropped by $565.00. Clearing is now $15.00 higher than your Stripe balance, and it will stay that way until someone finds it. The next payout reconciliation will be off by exactly $15.00.

The fix is one journal entry dated March 24:

Account	Debit	Credit
Foreign exchange gain/loss	15.00
Stripe Clearing		15.00

Memo it with the refund ID (re_...) and both rates. Clearing now matches Stripe, income nets to zero, and the $15.00 sits where your accountant will look for it.

Option B: the refund is recorded at what Stripe actually deducted, $565.00. Stripe Clearing matches Stripe to the cent, which is good. But the refund receipt's lines put $565.00 against your income account, so revenue is $15.00 lower than it should be. The fix is a reclassification rather than a cash correction:

Account	Debit	Credit
Foreign exchange gain/loss	15.00
Sales (the income account on the refund)		15.00

Both options end in the same place: clearing reconciles, net revenue on the sale is zero, the fee stays in fees, and the rate movement sits in its own account. Option B is easier to live with day to day, because the clearing account is always right and the correction is a month-end reclass you can batch. Option A leaves the clearing account wrong until you fix it.

How to tell which one you have. Open the refund in QuickBooks and compare its total to the refund's balance transaction in Stripe (Balance, then the refund row, then the amount in your settlement currency). If they match, you have Option B. If the QuickBooks total matches the original sale, you have Option A.

Partial refunds follow the same arithmetic. Refund €200 of the €500 on March 24 and Stripe deducts €200 × 1.13 = $226.00, against the $220.00 that €200 was worth on March 3. The exchange difference is $6.00.

Batch it at month end if volume is high. You don't need a journal entry per refund. Export the month's refund balance transactions from Stripe, compute each one's difference against its original charge (refund amount in settlement currency minus the charge's settled amount, pro rata for partials), and post one entry for the total. Keep the export as the support. The refund-after-payout walkthrough covers the payout timing side, which matters when the charge and the refund land in different payouts.

How it looks in a Multicurrency QuickBooks file

If QuickBooks Multicurrency is on and the sale was recorded in euros, the mechanics change, because QuickBooks now knows both the euro amount and the rate.

The sale is a sales receipt for €500.00 to a euro customer, with an exchange rate of 1.10, so QuickBooks carries it at $550.00 in home currency.

The refund is a refund receipt for €500.00 to the same customer, with its own exchange rate of 1.13, so QuickBooks carries it at $565.00.

A refund receipt in QuickBooks is a standalone transaction. It isn't applied against the original sales receipt the way a payment is applied against an invoice, so QuickBooks has no pairing from which to compute a realized gain or loss. The refund's home-currency value simply lands on the lines it posts to. In practice that means the euro amounts net to zero and the home-currency amounts don't: $550.00 in and $565.00 out on the income line. That is the same $15.00, sitting in revenue again. If you want it in Exchange Gain or Loss, it is the same reclassification as Option B above.

If you hold a euro balance at Stripe, the picture is different again. With multi-currency settlement, a euro charge settles into a euro balance and no conversion happens on either leg. The refund takes exactly €500.00 out of the euro balance. There is no Stripe-side gap at all. The exchange exposure moves into QuickBooks instead, where your euro clearing account is revalued at period end. The home currency adjustment guide covers that side.

If you don't hold a euro balance and don't have Multicurrency, you are in the single-currency case above, even though the customer paid in euros. QuickBooks never sees the euro amount. The foreign balance guide covers the case where Stripe holds a foreign balance but QuickBooks can't.

What to check at month end

A short routine catches every one of these before it compounds:

1. Filter Stripe for refunds where the currency differs from the charge's settlement currency. In the balance history export, look for refund rows with a populated exchange rate.
2. For each, compare the refund's settlement amount with the original charge's settlement amount. Any difference is exchange gain or loss, not fee and not revenue.
3. Check your clearing account against Stripe's balance for the month. If it's off by roughly the sum of those differences, your refunds are Option A and you need the correcting entry.
4. Check your income account for refunds recorded above the original sale. If the refunds are Option B, reclass the differences to exchange gain or loss.
5. Leave the original Stripe fees where they are. They aren't refundable and they aren't part of the gap.

The month-end close checklist puts this step in context with the rest of the close.

Where Acodei fits

The check above is easier when every refund already exists in QuickBooks as its own record that you can hold up against Stripe's balance history. That is the part Acodei automates.

• Refunds become Refund Receipts. For real-time accounts, each Stripe refund is booked as a Refund Receipt against the customer, drawn from your holding account, with line items mirroring what was refunded. Full and partial refunds are detected by comparing the refund to the original charge.
• Multicurrency, enabled by the Acodei team. Acodei has two levels of multicurrency support, Multicurrency Support and Invoice Multicurrency. Both are turned on by the Acodei team on request, not by a self-serve toggle, and QuickBooks Multicurrency has to be on before any non-home-currency transaction can sync. With Invoice Multicurrency on, a refund in a currency other than your home currency is recorded with an exchange rate attached, taken from Stripe when Stripe provides one and from QuickBooks otherwise.
• One customer record per currency, by design. With Multicurrency Support on, a customer who pays in a currency other than their QuickBooks record's currency gets a second record named like "Acme - EUR". That's how QuickBooks requires foreign-currency customers to work, not a duplicate to clean up.
• One holding account per balance. If you hold more than one Stripe balance, Acodei's recommended setup gives each balance its own holding account and deposit account, using a regular clearing account rather than Undeposited Funds.

Two limits to know. Zero-decimal currencies such as JPY are not supported today, so plan yen refunds separately. And the exchange difference on a refund is still a judgment call for you or your accountant: whether it stays in income or moves to an exchange gain or loss account is a presentation choice, and the reclass above is how you make it.

Foreign customers are good business, and an occasional refund is part of the deal. The $15 is only a problem when nobody knows where it went. To get your Stripe sales, fees and refunds into QuickBooks so the only thing left at month end is the exchange line, start a free trial.

Frequently asked questions

Why did my Stripe refund cost more than the original payment?

Because the charge was converted into your settlement currency, and Stripe converts the refund at the exchange rate on the refund date, not the rate on the payment date. The customer always gets back exactly what they paid in their own currency. If their currency strengthened against yours in between, the refund costs you more in your currency. If it weakened, it costs you less.

Is the extra refund amount a Stripe fee?

No. Stripe charges no fee to issue most refunds. The difference comes from the exchange rate moving between the payment and the refund, so it's a foreign exchange loss (or gain). Keep it out of your Stripe fee account so that account keeps matching Stripe's fee totals.

Does Stripe return the processing fee when I refund a converted charge?

No. Stripe's pricing page says the payment processing, Connect and currency conversion fees from the original transaction aren't returned when you refund. That fee stays as an expense on the original sale.

Do Adaptive Pricing refunds have the same exchange rate problem?

No. For payments made through Stripe's Adaptive Pricing, Stripe refunds at the same exchange rate as the original transaction, so the refund mirrors the sale and there is no exchange difference to book. The exposure described here applies to ordinary foreign-currency charges that Stripe converts into your settlement currency.

Where do I record the exchange difference in QuickBooks Online?

In a Multicurrency file, use the Exchange Gain or Loss account QuickBooks already created. In a single-currency file, create an expense account such as "Foreign exchange gain/loss" and post the difference there with a journal entry, either per refund or as one monthly entry supported by a Stripe balance history export.