Missing ADJUSMENT in sales reports

GraphQL Admin API Troubleshooting
1

Hi,

We are a Shopify app that processes returns and refunds via the returnProcess GraphQL mutation.

When we issue a refund for an amount lower than the remaining refundable amount on an order (e.g., a return where items worth €50 are processed but only €30 is refunded via orderTransactions), Shopify previously generated an ADJUSTMENT line in the financial reports (Payouts) to account for the discrepancy between the item value and the actual refunded amount.

Since approximately February 26, 2026, we’ve noticed these ADJUSTMENT lines are no longer being created for partial refunds. Our refund logic has not changed — the only recent change on our end was upgrading from API version 2025-10 to 2026-01 on February 5.

We reviewed the migration guide for returnProcess and the 2026-01 changelog, but we couldn’t find any documentation addressing this specific behavior change.

Could you clarify:

1. Was there a change — either in API 2026-01 or in Shopify’s backend — to how returnProcess generates financial adjustments when the refunded amount differs from the returned item value?

2. Is this an intentional change? Should we expect ADJUSTMENT / refund_discrepancy entries to no longer appear in this scenario going forward?

3. If intentional, how are merchants expected to reconcile the discrepancy between item value and refund amount in their financial reports?

Any documentation or internal reference would be very helpful.

Thanks

1 Like
2

Moved this to GraphQL Admin API Troubleshooting.

1 Like
3

Hi @Reveni_Dev,

I’ve looked into this a bit and I’ve been able to replicate this behaviour on both 2026-01 and 2025-10, where on both API versions the returnProcess mutation is not creating any OrderAdjustments for partial refunds.

I do see that there was a fix for a similar issue with OrderAdjustments being created when they weren’t expected to, that was released around the same time you’re reporting. I’m still looking into this and will be discussing this with our developers internally to confirm if this is related or not.

In the meantime can I ask if you are also able to replicate this behaviour on 2025-10 now?

Additionally can you provide us with a specific example of the last returnProcess mutation that created an OrderAdjustment, for us to look into this further and compare the recent examples with the previous behaviour?

Specifically if you can provide us with the x-request-id from the last returnProcess that created the adjustment, if not the Order ID should be enough for us to look into this.

1 Like
4

Hi @Kellan-Shopify

I’ll try to replicate in shopify 2025-10 tomorrow.

In the meantime, I can provide you a couple Order Ids that are NOT creating OrderAdjustments after processing the return (I’m not able to provide you any x-request-id):
12609202618744
12629440070008

And here are a couple that DID create the OrderAdjustment:
12607654035832
12768345981302
12589328302456

Checking the values, we find that the adjustments are still being created, but sometimes, they just don’t get created.

5

Hi again @Kellan-Shopify

I’ve dug in a little bit more. I believe that adjustments are not being creating when the refund amount is exactly 0, for other quantities, the adjustments are being created correctly.

Our latest adjustment for 0 amount refunds was in order 12431428878681. The return was processed at 2026-02-27 around 8:30 AM UTC

Our latest return with amount bigger than 0 was in order 12319587172700. The return was processed at 2026-03-13 (today)

Our latest return with a 0 amount that did NOT trigger an adjusment was in order 13463649452417. The return was processed at 2026-03-13 (today)

I have also confirmed that returns processed using 2025-10 have the same behaviour. I processed the return for order 6726698139848 right now and no adjustment was created.

6

Hi @Reveni_Dev,

Thanks for the additional context on the behaviour you’re seeing with the various orders and API versions.

After further investigation into this behaviour, I can confirm that this is actually expected behaviour moving forward and is due to the fix that was released on February 26th that I mentioned in my previous post.

The short version: Those adjustment records were causing accounting issues. When partial or zero-amount refunds created refund_discrepancy adjustments, they were being picked up as “return” sales and inflating order balances. If merchants edited those orders later, the math would be wrong.

The fix suppresses these adjustments for under-refunds and zero-refunds, but still creates them for over-refunds (since that represents actual unattributed money that needs tracking). This applies to both API versions since it was a platform-level change, not tied to a specific API version.

Additionally the under and zero refund order adjustments are no longer required for most stores as previously the Return creation resulted in a new Return Sales record, and when the partial or zero refund was actually processed, the Adjustment was needed to account for that. For most new stores the Return creation no longer results in an immediate Refund Sales record, leading to the issue described above.

Some older stores may still be creating the refund sales record on immediate return creation, and you may still see the refund order adjustment on these older stores at this time, but moving forward you will see more stores experiencing the expected behaviour you’re reporting in this thread.

For reconciliation: The discrepancy is still tracked, just through order edits instead of adjustment records. You can calculate it directly as returnLineItem.totalPrice - refundedAmount or access it via the order’s currentTotalPriceSet. You can also access the actual Refund transactions for reconciliation via the order.transactions connector.

If your app’s reporting depends on those adjustment records being present, you’ll need to adjust your logic to calculate the discrepancy yourself rather than looking for the OrderAdjustment.

I hope this helps and if you have any further questions with this behaviour, please let us know, otherwise we’ll go ahead and mark this thread as solved.

8

Hi @Kellan-Shopify ,

Thanks for the detailed explanation regarding the changes to adjustment records. It’s very helpful to understand the reasoning behind the platform-level fix from February 26th.

However, we are still seeing some discrepancies between the described expected behavior and the actual output we are receiving. Specifically, regarding your note: “The fix suppresses these adjustments for under-refunds and zero-refunds, but still creates them for over-refunds.”

In our tests, we’ve observed inconsistent outcomes depending on the refund type:

  • Under-refunds: Contrary to the fix description, the refund_discrepancy adjustment is still being created.

    • Example: Order 7434827039048 had a refund processed yesterday that generated an adjustment record.

  • Zero-refunds: In these cases, the refund_discrepancy is indeed not being created.

Could you please clarify if this “mixed” behavior is intentional?

Furthermore, to maintain consistency in our app’s reporting, we would ideally like to replicate the previous behavior where a refund_discrepancy was created whenever the refund amount did not match the item amount. Is there any specific API configuration that would allow us to opt back into the legacy behavior?

Thanks.

9

Hi @Reveni_Dev,

I can confirm that this mixed behaviour is still expected, and both under and zero refunds can create a refund discrepancy still, depending on the store.

Essentially this behaviour is due to a change in how refund transactions are created on our end internally, with stores created prior to July 2025 with pre-existing exchange records from the API, still using the previous refund transaction method internally, resulting in the refund adjustments being created for these stores, and newer stores not creating the refund adjustments.

Can I ask why you are relying on the refund discrepancy adjustment records specifically, perhaps there’s a workaround we can recommend using Order Transactions or other API objects to accomplish the same goal?

10

Hi @Kellan-Shopify ,

Thank you for sharing the specific conditions that make the refund discrepancy adjustments being created or not. That’s why we were seeing different behaviors across our stores.

We know we can access these calculations using the information provided in the API (using the returnLineItem.totalPrice and refundedAmount fields), but we are looking at how to reflect the refund discrepancy adjustment records in the Shopify reports.

The OrderTransactions object is read-only, so we don’t know if there is an alternative approach in order to ensure that these records are always created for under-refunds and zero-refunds.

Thanks.

11

Hi @Reveni_Dev,

The Refund Adjustment records are read-only as well. Can you share more about how you were using them exactly, and in what surface, and why using OrderTransactions wouldn’t work instead?

Since Refund OrderAdjustments were an artifact of the inefficient way refund transactions were created previously, with the full refund transaction being created when the refund was initially created, and after the refund was processed an adjustment was created to offset if the full refund wasn’t applied. Now it’s a more correct and efficient way, with the actual refund transaction not being created until after the refund is processed, so there’s no need for an adjustment.

Due to this, there’s no way to force a refund adjustment to be created in all instances.