Inconsistency in tax application between returnLineItems and exchangeLineItems in returnCalculate query

Hi everyone,

I am encountering an unexpected behavior when using the returnCalculate GraphQL API and am hoping someone can shed some light on whether this is an intended feature or a potential issue.

Issue Description:
The returnCalculate query is sometimes returning different totalTaxSet values for exchangeLineItems compared to their corresponding returnLineItems, even when there are no address changes or obvious reasons for a tax rate difference.

Specific Scenario (Tax Exemptions):
I’ve observed scenarios where the original order had no tax applied due to Shopify’s built-in tax exemption rules (likely involving specific tax overrides). However, when we process an exchange for the same product but in a different variant (e.g., a different size), the returnCalculate response applies tax to the exchange item (exchangeLineItems.totalTaxSet) where we expect the same tax exemption rule to apply (resulting in $0.00 tax).

Expected Behavior:
If the original item being returned was tax-exempt, the replacement item in the exchange (given no address change and similar product attributes) should also be tax-exempt, resulting in a $0.00 tax amount in the exchangeLineItems.

Actual Behavior:
The exchange line item is being taxed (e.g., $2.90), while the return line item is correctly reported as tax-exempt ($0.00 tax).

Technical Details (Example Query & Response):

  • API Version: 2025-04
  • Store URL/Name: honey-buns-shapewear.myshopify.com

Input Query Snippet:

{
  "input": {
    "exchangeLineItems": [
      {
        "appliedDiscount": {
          "description": "Frate exchange discount",
          "value": { "amount": { "amount": 20.7, "currencyCode": "USD" } }
        },
        "quantity": 1,
        "variantId": "gid://shopify/ProductVariant/42777432260686"
      }
    ],
    "orderId": "gid://shopify/Order/6162115985486",
    "returnLineItems": [
      {
        "fulfillmentLineItemId": "gid://shopify/FulfillmentLineItem/13043183288398",
        "quantity": 1
      }
    ],
    "returnShippingFee": null
  }
}

Relevant Excerpt from the Response:

// ... (inside data.returnCalculate)

"exchangeLineItems": [
  {
    // ...
    "totalTaxSet": {
      "presentmentMoney": { "amount": "2.9", "currencyCode": "USD" }, // TAX APPLIED HERE
      "shopMoney": { "amount": "2.9", "currencyCode": "USD" }
    },
    // ...
  }
],
"returnLineItems": [
  {
    // ...
    "totalTaxSet": {
      "presentmentMoney": { "amount": "0.0", "currencyCode": "USD" }, // TAX EXEMPT HERE
      "shopMoney": { "amount": "0.0", "currencyCode": "USD" }
    }
  }
]

// ...

What I’ve Tried So Far:

  • I’ve reviewed the Shopify Help Docs on Tax Overrides.
  • I confirmed that the merchant’s address settings have not changed since the original order was placed.
  • I verified that both variants belong to the same product and should theoretically share the same tax profile.

Is this discrepancy intended behavior for exchanges via the API, or could there be an underlying issue with how returnCalculate handles existing tax exemption rules?

Thank you in advance for any insights!

Best,
Jake

1 Like

Hey @Jake_Goodman, Great to hear from you again!

I’ve been attempting to replicate this, but I’m realizing I need a little more context on how the order was created and how taxes were originally exempt to allow me to fully capture this as a bug.

Some additional details that can help:

  • Is the customer marked as tax-exempt in their profile ?
  • Is there a tax override on this specific product or collection?
  • Is this a jurisdiction where certain product categories are exempt (like clothing in NY)?
  • Have you been able to replicate this outside of this store?
  • x-request-id from the response headers of the calculate mutation.

This will help us reproduce the exact scenario or look at this in our logs if we can’t replicate.

Hey @KyleG-Shopify, thanks for the quick reply!

It is an issue quite in the weeds, so I’m happy to provide whatever additional context you need to help, I appreciate it a lot!

  • The customers are not marked as tax-exempt, they explicitly say “Collect tax” in the Customer profile.
  • No tax override on the Product itself.
  • Yes! There is a built-in tax exemption being applied here, but not applied through returnCalculate, I think this is precisely the issue.
  • This hasn’t come up on other stores
  • I’ll recover this if needed, but I think the problem is what you suggested: the tax exemption jurisdiction, this is probably the way to replicate it too.

I also discovered that in my example, the product is tagged with tax:clothing, as described in this guide on tax exemptions. This explains why the tax was not charged on the original order, and I suspect that returnCalculate is simply not aware of this rule. Maybe the solution is to patch the returnCalculate API itself to recognize built-in tax exemption rules, because perhaps there is a divergence in the tax logic between checkout and this API?

Let me know if that seems to be the answer, and if not, I’ll go ahead and recover some specific x-request-ids for you.

Cheers,
Jake

Hey @Jake_Goodman, thanks for the detailed follow-up!

After digging into this, we found the root cause looks to be different from what we initially suspected. It looks like the original order may not have collected the taxes as expected, and the exchange calculated them properly.

For context, when a store uses a third-party tax provider and that service experiences a transient issue during order creation, if there’s no fallback tax registration configured the order gets created with $0 tax. Later, when the exchange is processed and the tax service is working normally, taxes calculate correctly. This creates the discrepancy you’re seeing.

The merchant should configure fallback tax registrations for regions where they collect tax. This ensures that if the tax provider has issues, we can estimate taxes at the zip code level instead of defaulting to $0.

To confirm this is what happened, you could check whether the merchant has fallback registrations configured, and whether the original order’s $0 tax was intentional or unexpected. You can test that by creating an order for the product and same zip as the customer to see if taxes are typically collected.

Feel free to share any additional questions you might have!

Hey @Jake_Goodman, have you had a chance to see if what we are seeing aligns with what you’re seeing on the affected shop?

Hey @KyleG-Shopify , I did tell the merchant to add those fallback tax registrations, and they will let me know if the issue happens again. So feel free to close this for now, and I’ll reply again here if it happens again. Thanks!

Thanks for passing that on Jake! Happy New Year :partying_face: