From 23 October 2026, if you're on Shopify Tax or Shopify's Tax Platform in the US, the return shipping fee you deduct from a customer's refund stops being a flat dollar amount and starts carrying sales tax wherever your state treats that charge as taxable. Shopify flagged it in a changelog entry dated 25 September. The practical effect is small per order and annoying at scale: the number your returns policy page promises the customer and the number Shopify actually deducts will no longer match unless you change one of them. That's the job. The Shopify tax on return shipping fees change is a settings-and-copy problem for most stores and a reconciliation problem for a few.
What actually changes on 23 October
Today, when you charge a return shipping fee through Shopify's native returns flow, it comes off the refund as a clean deduction. No tax line. After the switchover, Shopify's tax engine evaluates that fee the way it evaluates any other taxable charge: against the jurisdiction on the order, against your registrations, against the state's rule on shipping and delivery charges. If the state says it's taxable, tax gets added and lands in your liability.
Two things follow from that. First, you are now collecting a small amount of tax you weren't collecting before, which means it has to be remitted, which means your filings for the period that straddles 23 October will have a seam in them. Second, the customer-facing number changes. A $8.95 return fee is no longer $8.95 off the refund.
This applies to merchants using Shopify Tax or the Tax Platform. If you run Avalara AvaTax through Shopify, your return-fee treatment is governed by how Avalara maps that charge, not by this change, and you should ask your Avalara rep directly rather than assuming the behaviours line up.
Are return shipping fees taxable? The state decides, not Shopify
Shopify is only applying the rule. Whether a return shipping fee is taxable in Ohio and not in Missouri is a question of state law and it has not changed because of a changelog.
Broadly, US states fall into three camps on delivery and shipping charges. Some treat shipping as part of the sale price and tax it whenever the goods are taxable. Some exempt it when it's separately stated on the invoice and the customer could in principle have arranged their own carrier. And a handful have rules that turn on whether the shipping is "necessary" to complete the sale. A return fee is a slightly different animal from outbound shipping in all three camps, because the sale has already happened and what you're charging for is the cost of getting the goods back.
We don't give tax advice and you shouldn't take it from an agency blog. What we will say: if you're registered in fifteen or twenty states on economic nexus and you've never once looked at how each of them treats a post-sale shipping charge, now is the moment to put that question to your CPA in writing. The answer determines whether this change costs you ninety seconds of settings work or a conversation about back-filing.
A worked refund, before and after
Take an order shipping to Dallas. Two items at $60 each, outbound shipping $6.95, combined rate 8.25%. Taxable base $126.95, tax $10.47, order total $137.42.
The customer returns one item. You refund $60 plus the $4.95 of tax that sat on it, so $64.95 goes back before any deduction. Your return fee is $8.95.
- Before 23 October: $64.95 − $8.95 = $56.00 refunded.
- After: the fee attracts $0.74 of tax (8.95 × 0.0825 = 0.738). Deduction becomes $9.69. Refund is $55.26.
Seventy-four cents. Nobody's margin moves. But run 1,200 returns in a month and you've collected roughly $890 of tax that is not yours, sitting in a liability account that your bookkeeper may or may not have a mapping for. And 1,200 customers have seen a refund that doesn't match the figure on your policy page, which is where the support tickets come from.
Restocking fees and sales tax are a separate conversation
People conflate the two and they shouldn't. A return shipping fee is a charge for a service you're performing. A restocking fee is compensation for the cost of putting an item back into sellable stock, and several states treat it as a non-taxable charge precisely because no tangible property changes hands. Others disagree. New York, for instance, has taken a narrower view of what counts as part of the receipt than some of its neighbours.
In Shopify, a restocking fee has never been a native field. Most stores apply it as a manual adjustment on the refund, or their returns app applies it, which means Shopify's tax engine was never evaluating it in the first place. That hasn't changed on 23 October. If your state does tax restocking fees and you've been deducting them as flat adjustments, that exposure already exists and it predates all of this. Worth raising with your accountant in the same conversation.
One practical note: if you deduct a restocking fee as a straight refund adjustment, Shopify records it as a reduction in the amount refunded, not as new revenue. Your P&L will show it as a smaller refund rather than fee income. That's fine for most merchants and infuriating for anyone trying to report on returns cost as a line item. Tagging the adjustment reason consistently is the cheap fix.
How Shopify calculates refund tax in the US
Useful to know before you start testing, because the behaviour surprises people.
Shopify refunds tax proportionally at the line level. Refund one of two units on a line and you get half that line's tax back. Where a discount was applied across the order, Shopify allocates the discount to each line first and computes tax on the discounted amount, so the tax refunded on a $60 item that carried $12 of an order-level discount is calculated on $48, not $60. Shipping tax is refunded only if you explicitly refund shipping, which is a separate checkbox and a separate amount field in the refund screen.
Rounding happens per line, not on the order total. On a multi-line refund you will sometimes be a cent off against a hand calculation. That's expected and it's not worth chasing.
Here's the awkward one: which jurisdiction's rate applies to a return fee is not self-evident. Most engines source it to the original order's ship-to address, which is sensible. But if the customer has moved, or you've since added a nexus state, or the return is routed to a different warehouse than the one that shipped it, you may get a rate you didn't expect. If you have more than one fulfilment location, test this specifically rather than assuming.
Refunds already issued at the old treatment, and how they reconcile
Orders placed in September and returned in November are the messy cohort. Our expectation, and the one we'd design around, is that the engine keys off the date the refund is processed rather than the date the order was placed, because that's how Shopify handles rate changes generally. We would not bet a filing on it.
So do this instead of assuming. In the first week after 23 October, process one real return from a pre-cutover order and one from a post-cutover order, export both as transaction-level data from your tax reporting, and look at whether the fee line carries tax in each case. Ten minutes of work that settles the question for your own store rather than for a hypothetical one.
Refunds you already issued before the cutover don't need restating. No tax was due on the fee under the old treatment and none became due retroactively. What you do need is a clean break in your records: a note in your reconciliation that says fee tax begins on this date, so that when the October return gets prepared in November, the person preparing it understands why the fee column suddenly has a tax amount beside it. We've watched a reconciliation stall for two days over less.
Your returns app is where this usually breaks
If you process returns natively in the Shopify admin, this change flows through on its own. Most US merchants above a certain volume don't. They run Loop, AfterShip, Narvar, ReturnGO or something similar, and those platforms compute the fee in their own UI, display it to the customer in their own portal, and push a refund to Shopify.
Three failure modes we'd check for:
- The app quotes the customer a fee in its portal that doesn't include tax, then the Shopify refund comes through 74 cents short. Customer-facing mismatch on every single return.
- The app sends the fee as a flat negative adjustment rather than as a return fee object, in which case Shopify never evaluates it for tax and you're not collecting at all. Quiet, and the kind of thing that surfaces in an audit.
- The app charges the fee as a separate transaction against the customer's card instead of netting it off the refund. Different tax treatment entirely, and your reconciliation now has two records where it used to have one.
Ask your returns vendor, in writing, what they're doing on 23 October. If the answer is vague, build a test return before the date and another after it.
The fix list, in the order we'd work through it
- Confirm which tax engine you're on. Settings → Taxes and duties will tell you whether you're on Shopify Tax, the Tax Platform, or a third party. If it's Avalara, most of this post is background reading.
- Pull your state registrations and get a written answer on return-fee taxability for each from your CPA. This is the only step with real money attached.
- Decide whether you absorb the tax or pass it on. If your brand promise is "$8.95 flat return shipping", you can reduce the fee so the tax-inclusive total lands near the old number. $8.26 at 8.25% comes to $8.94. Of course your rates differ by state, so a single inclusive number is approximate by design.
- Rewrite the returns policy page and the portal copy. "A return shipping fee of $8.95 plus applicable sales tax will be deducted from your refund" takes ten seconds to write and removes a whole category of ticket.
- Update the email templates. The refund notification is the one customers actually read.
- Map the new tax amount to the right liability account in QuickBooks, NetSuite or whatever sits downstream. If your integration maps by line type, a new line type will land in a suspense account and sit there.
- Run the two test returns described above and keep the exports.
Do this in October, not in December
23 October 2026 sits about five weeks ahead of Black Friday. Return volume from BFCM orders lands in January, and January is when a mis-mapped tax line becomes a four-figure reconciliation headache rather than a settings tweak. Anything you can test on low volume in late October costs you a tenth of what it costs in the second week of January.
There's a second reason. If you're planning theme or checkout work before peak, the returns copy change is trivial to bundle into that deploy. Doing it as a standalone emergency fix in December means pushing to a live theme during the highest-traffic fortnight of your year, which is a thing we try very hard to avoid for clients we work with on US store builds and maintenance.
Questions that keep coming up
Does Shopify charge tax on shipping? On outbound shipping, yes, where the destination state requires it. Shopify Tax applies each state's rule automatically and it has done for years. What's new is the same logic reaching the return leg.
Where do I find the returns settings that this affects? Settings → Policies for the returns policy text, and Settings → Returns for the return shipping fee and the self-serve portal rules. The tax behaviour itself has no toggle. You cannot opt out of taxing a charge your state says is taxable, and you shouldn't want to.
Will my refund totals change in reporting? The net refunded amount goes down slightly, and tax collected goes up by the same amount. Gross sales are untouched. If you report returns rate as a percentage of revenue, the number moves by a rounding error.
Does this apply outside the US? This particular change is a US sales tax one. VAT and GST regimes already have their own rules on post-sale charges and they aren't affected by the October date.
What if I don't charge a return fee at all? Then nothing happens on 23 October. Free returns remain free. Though if you're running free returns on a category with a 30%+ return rate, the fee conversation is probably overdue for reasons that have nothing to do with tax.
Start with the CPA question, because every other decision depends on the answer. If you'd rather someone else ran the two test returns and checked how your returns app pushes the fee through, that's the kind of thing our team does inside a store audit, and if the fix turns out to need template or app-side work, a developer on retainer will do it faster than your returns vendor's support queue will.