Shopify and ERP returns: where margin leaks

A return looks small. In operational terms, it is not.

What the customer calls “a return” is really four different decisions.

A customer sends back a jacket because the size is wrong. In the online store, the case seems straightforward: approve the return, create the label, issue the refund. But operations sees four separate flows: the item may come back in sellable condition or not; cash may leave before or after inspection; stock may recover availability or become scrap; and support may solve the case or leave a trail of unanswered emails.

Here is the uncomfortable thesis: you should not force returns into one perfectly unified workflow if that means every step has to move at the same speed. In many SMEs, Shopify and the ERP do need to coordinate, but not as if they were one single machine. They should share facts, not necessarily make decisions at the same instant.

The mistake of treating a return as one flow

The usual advice says: “integrate Shopify with your ERP so nobody copies data by hand.” That advice is right when staff are typing the same information twice and no one trusts the current status. It falls short when the return serves different purposes.

Think in this order:

1. Product: has it physically arrived? Is it damaged? Does it need inspection?
2. Cash: full refund, partial refund, or no refund yet?
3. Stock: back to available inventory, pending review, or written off?
4. Support: who answers the customer, and within what timeframe?

Shopify lets merchants manage returns and exchanges from the Orders page, create a return, send shipping instructions and issue refunds after inspecting the item. It also supports self-serve returns and cancellations so customers can start the request from the order status page. (help.shopify.com)

That is helpful, but it does not answer the operational question: which system owns which decision. If Shopify owns the customer-facing experience while the ERP owns stock, finance and replenishment, the integration must respect that split. Otherwise you end up with two truths at once: one clean for the customer, and one painful for the warehouse.

Where margin leaks without anyone noticing

Margin rarely disappears in one dramatic failure. It leaks through small administrative mistakes.

• A refund is issued before the item condition is verified.
• Stock is returned to availability when it is still pending inspection.
• A support ticket is opened but the ERP never receives the update.
• Exchanges are processed by habit and nobody tracks the extra handling cost.

Shopify’s self-serve return and cancellation flows let customers submit requests directly, but the merchant still reviews and resolves them in the admin. Return and cancellation rules control who is eligible and how long they have to request a return. (help.shopify.com)

That matters because leakage is usually repetitive, not spectacular: one misclassified line, one premature restock, one refund done out of convenience. In a single week it looks harmless. Over a quarter, it becomes margin loss.

A small-company scenario with two different rules

Imagine a home décor SME handling 120 returns a month. Sales wants fast answers: if the customer is right, issue the refund quickly. The warehouse needs inspection because some items come back damaged, opened or incomplete.

For months, the company uses one rule for everything: approve the return, refund immediately, restock automatically. Customer service looks faster on paper, but inventory becomes polluted with items that are not actually sellable, and accounting discovers the real loss later than it should.

The fix was not “more automation”. It was less uniformity. The team separated three decisions:

• accepting the request,
• physical inspection,
• final financial resolution.

Shopify stayed the visible front end for the customer. The ERP took control of replenishment and write-offs. Support got a clear status so it would not promise something the warehouse had not yet confirmed.

The counterintuitive lesson: sometimes better integration means stopping the fiction that every return deserves the same path.

When the conventional advice is still right

The contrarian view does not mean you should fragment everything. If a business has few returns, a simple catalog and a small team, a straightforward flow may be better than a complex exception model. Stronger automation also makes sense when manual error is the main risk and the rule is always the same.

But when sizes, exchanges, damage checks, refurbished items or inspection-based goods enter the picture, the real question is not “can we automate this?” It is “which decision needs human verification, and which one does not?”

Shopify already separates refund, return and exchange as distinct actions. That distinction matters: not every closed case should automatically become a cash refund or a stock return. (help.shopify.com)

Three checks to run this week

Start with three concrete checks:

1. Take one recent return and map its four flows: product, cash, stock and support.
2. Decide which system is the source of truth for each flow: Shopify, ERP or a person.
3. Find one case where refund and restock are happening too early.

If the answer is “it depends on whoever usually handles it”, you have already found the problem.

A return is not a side topic. It is a coordination test. And for many companies, it is also a quiet way to lose margin if the process is not designed with discipline. In Codefuente, that is often where we start: less magic, more operational rules the team can actually follow.