October 26, 2026 · Ahmed · More by Ahmed
Shopify Now Recalculates Taxes on Address Edits
Editing an unfulfilled order's shipping address now recalculates its taxes as of API 2026-10 — and apps must reconcile the resulting balance change themselves.
What changed in API 2026-10
As of API version 2026-10, changing the shipping address on an unfulfilled order through the orderUpdate GraphQL mutation or the REST Admin API order update endpoint recalculates that order's taxes against the new destination. Previously, orderUpdate saved the new address but left the original tax lines untouched, so an order's totals could silently stop matching the destination it was actually shipping to. Shopify flags this as a breaking, action-required change, and it applies with no opt-in: any app on API 2026-10 or later gets the new behavior automatically.
When it does — and doesn't — fire
Recalculation only runs under specific conditions. It doesn't happen when the request uses an API version earlier than 2026-10 — the address is saved and the old tax lines stay as they were. It doesn't happen when the order is partially or fully fulfilled, since Shopify would otherwise be applying the new destination's tax rate to units that already shipped to the old one. And it doesn't happen when the order isn't eligible for order editing at all — the address still saves, but taxes are left alone. Where it does apply, subscribers to the orders/edited webhook get a notification that an address change triggered a tax recalculation.
The reconciliation workflow this forces
Because recalculation can change the order total, an order that's already been paid can come out of the update with an outstanding balance in either direction — and Shopify puts the job of resolving that balance on the app or merchant, not on the platform. Shopify names three specific mutations for three outcomes: if the balance went up within whatever tolerance the app defines, mark the order as paid with orderMarkAsPaid; for a larger increase, send the customer an invoice with orderInvoiceSend; and if the balance decreased, refund the difference with refundCreate.
For anyone running order-editing, address-correction, or exchange automation — Shopify Flow, a custom app, or an ERP-driven address correction — this means every shipping-address change on an unfulfilled order is now implicitly a tax and payment event, not just a logistics one. The practical build-out is straightforward but non-optional: after any shipping-address update, query the order's updated taxLines, totalTaxSet, and totals, diff them against the pre-update balance, and route the result into the right one of those three mutations. Since this requires no opt-in and is already live on the current stable API version, any automation touching unfulfilled-order addresses today is running against this behavior whether or not it's been accounted for yet.