Executive summary
What: From August 31, 2026, changing the shipping address on an unfulfilled order via the orderUpdate GraphQL mutation recalculates the order's taxes against the new destination.
Why: Previously the address changed and the original tax lines stayed put, leaving totals that no longer matched where the order was actually shipping.
Who: Any merchant whose ERP, OMS, customer service tooling or address-correction workflow edits orders through the Admin API.
What changed
The address change always succeeds. The tax recalculation is conditional, and the conditions matter. On entirely unfulfilled orders, taxes are recalculated against the new destination. On partially fulfilled orders, the address is saved but tax lines are left alone, because some units already shipped to the original destination and recalculating the whole order would apply the new destination's rate to units that never went there. Recalculation runs through order editing, so orders that are not eligible for editing also keep their original tax lines. This applies across all Admin GraphQL API versions, so there is no version to pin and no upgrade to schedule. Subscribers to the orders/edited webhook receive a notification when an address change does trigger a recalculation.
Why it matters
The stated benefit is financial accuracy, and that is real: an order shipping to a different tax jurisdiction should carry that jurisdiction's tax. The operational point is sharper. This is a behaviour change for integrations that treated orderUpdate as a metadata write. If your middleware calls the mutation and then reports totals it captured beforehand, it will now report stale figures, and the divergence shows up at month end rather than at the point of the call. Anything that performs its own compensating tax correction should be reviewed too, or you risk applying the adjustment twice. Merchants running order data through finance systems will recognise this as the class of problem covered in our guidance on ERP and Shopify integration: the failure is rarely the API call itself, it is the assumption downstream of it.
Role-specific impact
Marketers: limited direct impact, though reported order value on edited orders can move slightly. Note it as a caveat in revenue reporting so a small variance is not mistaken for a tracking fault.
Developers: stop assuming totals are unchanged after orderUpdate. Re-query the order and read taxLines, totalTaxSet and the order totals, or subscribe to orders/edited if you need an event rather than a poll.
Store admins: agents correcting an address in admin should expect the total to move on unfulfilled orders, and should know it will not move on partially fulfilled ones. That asymmetry will otherwise generate escalations.
Use-case example
Real-world scenario
A B2B distributor pushes roughly 300 address corrections a month from its ERP, mostly buyers who ordered to a billing address rather than a receiving warehouse. Under the old behaviour, an order moved from a zero rate jurisdiction to one charging 8.25 percent kept its original tax lines, so Shopify and the ERP disagreed and the finance team reconciled the gap by hand each month. After August 31, 2026, Shopify performs the recalculation, and the integration's job changes from correcting totals to reading them back. The right response is to update the sync to re-query the order after the mutation, remove the local correction step, and treat Shopify as the source of truth for tax on those orders.
Implementation checklist
Inventory every integration and internal tool that calls orderUpdate with a shipping address.
Update each caller to re-query the order after the mutation and read taxLines, totalTaxSet and totals.
Remove any local tax correction that existed to compensate for the old behaviour, or it will now double up.
Subscribe to the orders/edited webhook where you need an event signal instead of polling.
Handle the partially fulfilled case: the address saves, taxes do not change, and your system should not assume otherwise.
Confirm behaviour for orders that are not eligible for editing, where the same rule applies.
Test against a destination with a materially different tax rate well before August 31, 2026.
Brief finance so month end reconciliation expectations change alongside the platform behaviour.
FAQ
Q: Does this require an Admin API version upgrade?
A: No. The change applies to all Admin GraphQL API versions, so pinning an older version will not preserve the previous behaviour. Plan the integration work on the calendar date rather than on a version bump.
Q: How do we know whether taxes were actually recalculated?
A: Do not infer it, because recalculation is conditional. Re-query the order after the update and compare the tax lines, or subscribe to orders/edited, which fires when an address change results in a recalculation.
Resources
orderUpdate mutation reference
Need guidance? Talk to Makro.