Editing an order's shipping address will change its tax
“I corrected a customer's shipping address and now the order total does not match what they paid.”
A customer mistypes their address. Someone on your side fixes it. Until now, that saved the new address and left the order's tax exactly as it was, which meant the order was shipping to one place and taxed for another.
Shopify is fixing that, and the fix is worth understanding before it reaches you, because correcting an address is about to become an action that can move money.
What changes, and when it reaches you
From API version 2026-10, updating the shipping address on an unfulfilled order recalculates the order's taxes against the new destination.
| date | what it means |
|---|---|
| 1 October 2026 | version 2026-10 is released. Tools that adopt it start recalculating. |
| 16 July 2027 | version 2026-07 stops being accessible. Tools pinned to it get the new behaviour anyway. |
That second row is the one to note. Every tool that touches your orders speaks a particular API version, and until it moves, it keeps the old behaviour. So this does not switch on for your store on a single day. It arrives tool by tool, whenever each one updates, and the last possible moment is July 2027, because Shopify serves a retired version as the oldest one still current. Nobody has to change anything for the behaviour to change.
The part that actually matters
Shopify's own note says, accurately, that developers need to make no changes to adopt this. In the same note it says this:
Because recalculation can change the order's total, an already-paid order can be left with an outstanding refundable or payable balance.
Read those together, because that is the whole story for a merchant. Correcting an address on an order that has already been paid can leave the customer owing you a small amount, or you owing them one. Not because anything went wrong. Because the tax was recalculated correctly, and the payment was taken before that happened.
The amounts are usually small. That is exactly why this is worth knowing about in advance: a two dollar discrepancy on an order that looks otherwise complete is the kind of thing that is noticed at reconciliation, six weeks later, by which point nobody remembers that somebody fixed an address.
When it will not recalculate
Three cases, and the middle one is the most useful to understand:
The tool is on an older API version. Behaviour unchanged, until July 2027.
The order is partly or fully fulfilled. Taxes are left alone deliberately. Some units already shipped to the original destination, so recalculating the whole order against the new address would apply the new destination's tax to goods that never went there. The result would be a total that matches neither reality.
The order cannot be edited. Recalculation runs through order editing, so anything that makes an order uneditable also stops the recalculation. The address still saves.
The practical version: an address correction before anything ships can move the total, and the same correction after a partial shipment will not. Two orders, same action, different outcome, and the difference is invisible unless you know to look for it.
What to do about it
Nothing urgent, and three things worth doing before October.
- Decide who watches for the balance. When a recalculation changes a total, the order is left needing something: a small extra payment marked as received, an invoice sent for a larger one, or a refund issued if the tax went down. Good tooling handles the small cases automatically and flags the rest. Ask whoever supplies your order management or customer service tooling what theirs does, because "we recalculate correctly and leave the balance sitting there" is a defensible answer that will still surprise you.
- Add it to your reconciliation notes. If you match payouts against order totals, this is a new and legitimate reason for a small mismatch on an otherwise normal order. It helps to know that before you go looking for a fault.
- Notice it in your support process. If your team edits addresses routinely, the safer habit is to correct the address before fulfilment starts, which is when a recalculation is both possible and correct, rather than discovering afterwards that the window closed.
Why this is a good change
It is worth saying plainly, because the framing so far has been about what to watch: the old behaviour was wrong. An order that shipped to one country and carried another country's tax was a defect that stores had to notice and correct by hand, and most never did. Shopify is removing a quiet inaccuracy from every store's books.
The cost of that is a period where a familiar action has an unfamiliar consequence, spread across nine months, arriving in a different month for every tool you use. That is what makes it worth reading about now rather than meeting it in a reconciliation.
One boundary on all of this: what is described here is the behaviour of Shopify's order update APIs, which is what apps and integrations use. If you change an address by hand in your Shopify admin, that is a different path and this note does not claim to cover it.