Stripe Refund Tax in QuickBooks: Credit Note vs Refund

You refunded a Stripe invoice that had sales tax on it. The refund landed in QuickBooks. Revenue came down. But Sales Tax Payable did not move, and now the liability account on your balance sheet says you owe the government money you already gave back to a customer.

This is not a sync failure, and resyncing will not fix it. It is a consequence of one specific fact about Stripe's API: how you issue the refund decides whether the tax comes back with it. A credit note carries a line by line tax breakdown. A refund against the payment does not carry one at all. Everything below follows from that single difference.

Start a free trial and connect Stripe to QuickBooks, or keep reading to understand which refund path keeps your tax liability accurate.

The one difference that decides everything

Pull up the two objects side by side in Stripe's API reference and the asymmetry is immediate.

The credit note object carries tax at both the summary and the line level. It has total_taxes, documented as "the aggregate tax information for all line items," and each entry in it carries an amount, a tax_behavior of exclusive or inclusive, a taxable_amount described as "the amount on which tax is calculated," and tax_rate_details pointing at the specific rate. Every line inside lines.data carries its own taxes array and tax_rates array. The object even separates subtotal, "excluding exclusive tax and invoice level discounts," from subtotal_excluding_tax, "excluding all tax and invoice level discounts."

The refund object carries none of that. Its documented fields are amount, balance_transaction, charge, created, currency, customer, description, metadata, payment_intent, payment_method, reason, receipt_number, status, and a handful of others about failures and transfers. There is no tax field. There is no line item field. A refund is a single number and a pointer to the charge it came from.

So when a refund arrives at an accounting integration, what arrives is a dollar amount and a pointer, not a tax figure. Acodei's own documentation puts it in exactly those terms: without line level detail, it may not be possible to determine how much tax was refunded.

Stripe reduces your tax liability either way, and that is the trap

Here is the part that turns an API detail into a reconciliation problem.

Stripe's tax reports documentation lists the operations that decrease the balance of total tax reported. The list includes "voiding an invoice," "marking an invoice as uncollectible," "creating a credit note," and, critically, "creating a refund of a charge associated with an invoice or a Checkout Session."

Read that last one again. A plain payment refund does reduce your tax liability inside Stripe. Stripe knows the tax came back. Stripe's own reports will show the lower number.

What Stripe does not do is put that information on the refund object it hands to the outside world. So Stripe's internal number goes down, your QuickBooks number does not, and the gap between them is exactly the tax you refunded. The books drift precisely because both systems are behaving correctly and only one of them can see the tax.

That is the whole mechanism. Everything else is procedure.

Path A: refund with a credit note

When you issue a credit note in Stripe, the tax breakdown exists, and Acodei uses it.

Acodei replicates Stripe credit notes in QuickBooks with the correct tax lines. On the credit_note.created event, Acodei creates a QuickBooks Credit Memo, linked to the original invoice where that is possible, and posted to the customer where it is not. If the credit note is partial, and the line level breakdown is available, the partial tax portion is credited along with the partial revenue.

Acodei's documentation is direct about the requirement: tax refunds process correctly when the user is on Advanced Tax Mapping and credit memos. The summary is blunter still. Refunds require a credit note to accurately reduce tax in QuickBooks.

Stripe's own framing is worth knowing here, because credit notes are not simply a nicer refund button. Stripe defines them as "documents that decrease the amount of an open or paid invoice," and notes that "a credit note doesn't void and replace the original invoice." A credit note "reduces the amount due without recording any payment," and if it takes an open invoice's balance to zero, the invoice status changes to paid.

On a paid invoice, Stripe asks how you want the money to move: refund the customer's card, credit their customer balance, or record that you refunded it outside of Stripe, for example in cash. The credit note object tracks this split in pre_payment_amount, post_payment_amount, and out_of_band_amount, and its type field records whether it was pre_payment, post_payment, or mixed. This matters for your books because a card refund, a balance credit, and a cash refund are three different things in QuickBooks even when the tax treatment is identical.

Path B: refund the payment directly

If you refund on the payment or the charge, without an item breakdown, Acodei may not be able to determine how much tax was refunded. Acodei's documentation states this plainly, including the status: handling refunded tax on the payment refund route has not been implemented, and cases are handled individually until more comprehensive logic ships. The internal support guidance is equally direct that Acodei currently syncs sales tax on new sales, with refunded tax support in development.

We would rather write that sentence than imply a capability that is not there. If you take the payment refund route today, the refunded tax will not come out of your QuickBooks liability account on its own, and you will need the journal entry below.

The manual correction, step by step

This is Acodei's documented procedure for a customer whose Sales Tax Payable is overstated after a payment level refund.

1. Confirm this is actually the cause. Two questions settle it. Was the refund issued directly on the payment instead of as a credit note? And was automatic tax turned on for the original invoice or Checkout Session, so that a tax transaction exists in Stripe at all? If both answers are yes, this is the situation.

2. Get the correct number from Stripe. In the Stripe Dashboard, go to Tax, then Reports, or run the Sigma template "Tax liability by month." Find the period containing the refund and note the new tax liability total after the refund. The difference between what was originally synced into QuickBooks and what Stripe now reports is the tax that should have been reversed. If QuickBooks was told 10,000.00 and Stripe now reports 9,000.00, the adjustment is 1,000.00.

3. Make a two line journal entry in QuickBooks Online.

Line	Account	Debit	Credit
1	Sales Tax Payable (liability)	1,000.00
2	Revenue (income)		1,000.00

Use a memo that your future self will understand, such as "Adjust tax for refund, Stripe automatic tax not yet synced."

4. Verify. Sales Tax Payable in QuickBooks should now match the figure in the Stripe tax report, and revenue should reflect the net effect of the refund, which is the original revenue minus the refunded tax.

One caution on timing. Stripe records tax calculations on the date transactions finalize and, in Stripe's words, "we don't recalculate taxes afterwards," with transactions appearing in reports typically within one day. Pull the report after the refund has settled into it, not the same minute you issue the refund.

Partial refunds deserve their own warning

Partial refunds are where this gets genuinely messy, and the warning comes from Stripe rather than from us.

In its tax reporting documentation, Stripe writes: "If you refund a tax amount such that the total tax is no longer proportional to the subtotal, your tax reporting can be unreliable. It won't automatically adjust the taxable and nontaxable amounts, and won't reflect the reason for the tax reversal (such as product exempt, customer exempt, or reverse charge). We recommend not refunding partial line item tax amounts. Instead, fully reverse the transaction and create a new one with appropriate inputs for an accurate tax calculation."

That is a strong recommendation about your Stripe data before QuickBooks is even involved. If a customer is keeping part of an order, the cleaner path is usually to credit the original transaction in full and issue a new one for what they actually kept, rather than shaving a percentage off the tax on the original.

The setup that makes the credit note path work

Choosing credit notes is necessary but not always sufficient, because the tax has to have somewhere accurate to land in QuickBooks. Acodei supports three approaches, and the one you are on changes what a credit memo can express.

Tax Product. All Stripe tax amounts roll into a single line item mapped to a non inventory product pointing at a liability account. You then use Stripe's reports for the jurisdiction by jurisdiction breakdown at filing time.

QuickBooks Tax Rate, also called Advanced Mapping. Each Stripe tax rate ID, the txr_ values, is mapped to a QuickBooks tax code such as "GST 5%," and each line on the synced document is assigned the matching rate. Where two or more Stripe rates apply to a single line, they can be mapped to a QuickBooks group tax code so the total tax matches Stripe exactly. This is the mapping mode Acodei's documentation names for correct tax refunds.

Admin QBO Tax Mapping. For non US companies that do not use Stripe Tax but still need tax on every line for QuickBooks reporting.

There is a geographic catch worth stating plainly. QuickBooks' US Sales Tax Center does not allow third party creation of official tax rates, so advanced mapping is often not fully usable in US QuickBooks, and Tax Product is usually the only workable method there. Since the Tax Product approach rolls all Stripe tax into a single mapped liability line rather than into itemized jurisdiction codes, US filers should expect to keep using Stripe's reports for the jurisdiction by jurisdiction breakdown at filing time.

Outside those approaches, tax tracking from Stripe to QuickBooks is not possible. Either Stripe Tax is enabled so rates and amounts can be retrieved, or tax is applied in QuickBooks after the fact.

Edge cases that surprise people

Voiding an invoice that has credit notes attached. Acodei deletes the attached credit notes before voiding the invoice. If you were expecting both records to survive side by side, that is why only one does.

A credit note that pays via customer balance. There is a known case where the credit note is applied to the customer rather than linked to the invoice. The credit exists and is available to the customer, but it will not appear as a line against that specific invoice.

Daily summary versus real time. In real time sync, each Stripe invoice's distinct tax lines map one to one into QuickBooks, which is where advanced mapping performs best. In daily summary mode, lines are split by product and tax rate, so a day with several rates produces several lines.

Inclusive tax. Inclusive scenarios require manual overrides, handled in the backend, and partial or daily summary scenarios can sometimes produce rounding differences. If you are on inclusive VAT or GST and a refund is a few cents off, that is the documented behavior rather than a mystery. Our guide to inclusive versus exclusive tax on Stripe invoices covers why the same price produces two different revenue figures.

Fees are not part of this. Stripe fees are never added to invoices, because doing so would make the invoice total disagree with the payment total. Fee handling runs through sales receipts, deposits, or expenses instead, under the fee management rules rather than the invoice.

Fixing a synced record. The documented best practice is to resync from the Data Feed rather than manually altering the transaction in QuickBooks.

What to do going forward

The decision is small and it is made before the refund, not after.

If the sale had tax on it and you want the tax to come back correctly, issue a credit note. If you already refunded on the payment, do the journal entry above, then treat the credit note as your default from now on. If you are refunding part of an order, consider fully reversing and re issuing rather than partially refunding tax, per Stripe's own recommendation.

For the mechanics of credit notes and proration credits generally, see our guide to Stripe credit notes in QuickBooks Online. For recording the tax Stripe collects in the first place, see Stripe Tax in QuickBooks Online. For refunds where tax is not involved at all, recording Stripe refunds in QuickBooks covers the full and partial cases.

Frequently asked questions

Why did my Sales Tax Payable stay the same after a Stripe refund? Because the refund was almost certainly issued against the payment rather than as a credit note. Stripe's refund object carries no tax breakdown, so there is no refunded tax figure for the sync to post to QuickBooks. Stripe's own tax liability drops, QuickBooks' does not, and the gap equals the refunded tax.

Does a credit note fix this automatically? Yes, when the credit note is the refund mechanism. Acodei replicates Stripe credit notes in QuickBooks with the correct tax lines, creating a Credit Memo linked to the original invoice where possible. Tax refunds process correctly on Advanced Tax Mapping with credit memos.

Can Acodei figure out the tax on a payment level refund? Not today. Handling refunded tax on that route has not been implemented, and those cases are handled individually. The documented workaround is a two line journal entry debiting Sales Tax Payable and crediting Revenue for the difference shown in Stripe's tax report.

Is this a problem for US QuickBooks companies too? Yes, though it looks different. QuickBooks' US Sales Tax Center does not expose custom rates to third parties, so US accounts typically use the Tax Product approach and see tax as a single mapped liability line. The credit note still returns the liability. The jurisdiction breakdown still comes from Stripe's reports at filing time.

What about partial refunds? Stripe recommends against refunding partial line item tax amounts, because tax reporting can become unreliable when total tax is no longer proportional to the subtotal. Its guidance is to fully reverse the transaction and create a new one with the correct inputs.

Where do I find the number for the journal entry? Stripe Dashboard, then Tax, then Reports, or the Sigma template "Tax liability by month." Compare the post refund liability there against what was synced into QuickBooks. The difference is your adjustment.

Get the refund path right from the start

Most of the tax reconciliation work described above disappears if credit notes are your default refund mechanism and your tax mapping is configured to match how you actually file. Acodei syncs Stripe invoices, payments, credit notes, fees, and payouts into QuickBooks Online with the tax detail Stripe makes available, and is candid in its documentation about the one path where that detail does not exist.

Start a free trial to connect Stripe and QuickBooks, or read more about how Acodei handles Stripe Tax.