Skip to main content

Return Reporting in Redo vs Shopify

Understand key differences between Shopify and Redo return reporting

Updated over 2 weeks ago

When reconciling Redo return reporting with Shopify or deciding what to use as your source of truth, there are two main factors to consider.

#1 Shopify struggles to recognize the difference between a refund and a return.

Shopify recognizes any item that is marked “Returned” as a refund. In reality, a return in Shopify might mean the customer got an exchange, opted for store credit, or received a refund. You’ll also see that cancelled orders, or partially cancelled orders, will find their way into your Shopify return report. These issues often cause Shopify to largely overstate Refund reporting.

To solve this, we’d recommend one of the following options:

  1. Using Redo as your source of truth for return reporting

  2. Ask support@getredo.com or your Redo Rep to prevent Shopify from marking exchanges and store credit as “returned”

  3. Ask support@getredo.com or your Redo Rep to help you enable the Shopify Exchange API noting that there are three design flaws. First, Shopify did not configure exchange API exchange orders to be mapped into most Fulfillment systems (ie, if you fulfill orders outside of Redo, this likely won’t work well for you). Second, the Exchange API is not configured to properly handle upsell exchanges or on hold exchanges.

#2 Shopify tracks return rate using “return date” rather than “order date”

Understanding what percent of orders are returned, and how that percent changes with sizing, product, seasons and sales/discounts is key to the success of a brand. Shopify return rate fails to correctly align returns with orders and can create inconsistencies.

Due to changing order volume, the clearest picture of purchase to return ratios is provided by utilizing order date rather than return date. Using an example to outline this, assume a brand with the follow sales data:

Sep: 100 orders

Oct: 100 orders

Nov: 500 orders

Dec: 200 orders

Jan: 100 orders

Feb: 100 orders

If we view returns based on the date each order was placed we might see:

10 of the orders placed in Oct are returned: 10% return rate

60 of the orders placed in Nov are returned: 12% return rate

15 of the orders placed in Dec are returned: 7.5% return rate

12 of the orders placed on Jan are returned: 12% return rate

This data displays a fairly consistent return rate and would allow us to identify fluctuations which are not correlated with changes in number of orders.

Now let’s look at the same data but view return rate based on the date each return is processed. We’ll assume the order to return lifecycle is roughly 30 days. Meaning it takes about 30 days for a customer to place their order, receive their item, request their return, send the item back, receive their refund, store credit or exchange.

October: 10 returns are received - 10% return rate

Nov: 10 returns are received - 2% return rate

Dec: 40 returns received - 20% return rate

Jan: 40 returns received - 40% return rate

As you can see. The major changes in return rate are artificially created. This example illustrates that viewing return rate by return processed date skews data.

Did this answer your question?