Shopify is about to change what happens when you edit an order's shipping address. As of August 31, 2026, the orderUpdate mutation recalculates an order's taxes against the new destination instead of leaving the old tax lines in place. For any store running a custom order-management flow, a headless Shopify Plus build, or an app that lets a support agent fix a mistyped address, this is a silent behavioral change with a hard date on it. The address edit still succeeds. What moves is the money attached to it.
What changes on August 31, 2026
Changing the shipping address on an unfulfilled order through the orderUpdate mutation will recalculate that order's taxes against the new destination, starting August 31, 2026. Shopify frames this as a financial-accuracy fix, and it applies across every Admin GraphQL API version rather than a single new version you could pin away from, per the Shopify developer changelog. There is no opt-in and no code change required to adopt it, so the recalculation is simply on by default from that date. Shopify posted the notice on July 30, 2026, which gives roughly a month of warning for a change that alters totals on live orders. That is a short runway for something this quiet.
Before vs after August 31: how orderUpdate behaves
Before August 31, orderUpdate saved the new shipping address but left the original tax lines untouched, so an order's totals no longer matched where it was shipping. After August 31, the tax lines and totals are corrected as part of the same update. The old behavior was a latent bug more than a feature. An order edited from a high-VAT destination to a zero-rated one kept the tax from the first address, so the total overcharged or undercharged relative to where the parcel was actually going. The fix is the right call. The catch is that correctness arriving silently is still a change your integration has to expect. Any code that reads the order total or the tax set immediately after an address edit will now see different numbers than it did the day before. Reconciliation jobs, accounting exports, and confirmation emails that cached a pre-edit total will drift the moment they assume that total is stable across an address change.
When taxes recalculate, and when they do not
Taxes recalculate only when the order is entirely unfulfilled and eligible for editing, and they are left alone otherwise. The conditions are specific, and this is a genuine enumeration rather than one rule:
- Entirely unfulfilled, editable order: the address changes and the taxes recalculate against the new destination.
- Partially fulfilled order: the address saves, but the taxes stay unchanged, because some units already shipped to the original destination.
- Order not eligible for editing: the address updates while the taxes are left alone, following standard order-editing rules.
In all three cases the address change itself always succeeds, per the changelog. The conditionality sits only on the tax side. That is the detail most integrations will miss, because it means the same call produces different financial outcomes depending on fulfillment state, and your code cannot assume a recalculation happened just because the address update returned cleanly. To know, you query the order afterward and read the updated tax lines and totals, the same way you would after any order edit, per the orderUpdate mutation reference.
What we would change this quarter
Audit every place your systems change a shipping address through the API before August 31, and make each one re-read the order's tax lines and totals instead of trusting the value it held before the edit. Three concrete moves follow. First, inventory the callers, because the change touches all of them at once: support tools, address-correction apps, subscription and order-management syncs, and any headless recovery flow that edits an order. Most teams do not have that list written down. Second, stop caching order totals across an address edit, since any invoice, confirmation email, or accounting export that reads a total, then edits the address, then reuses the earlier figure will now be wrong for unfulfilled orders. Re-query after the edit. Third, decide how you handle the partially fulfilled gap on purpose, because those orders will keep tax calculated for the original destination even after the address moves, and that is a reconciliation question your finance side should answer rather than a surprise it finds in a quarterly close. We treat order-management and API-integration work as systems and automation rather than storefront theming, and we fold destination and tax behavior into how we scope Shopify Plus and headless commerce. It also connects to the destination-driven logic we covered around market-driven shipping and the Markets API, because taxes, shipping, and duties all key off the same thing, which is where the order is actually going. Deferring is the expensive option here. The failure mode is not an error you will see in your logs. It is a total that quietly stops matching the destination, found weeks later in a reconciliation report.