Returns Management Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the policy engine scope blow up so often?

Every brand says its return policy is simple, then describes it. Final sale on markdowns above forty percent, except store credit for customers above a lifetime spend threshold. Bundles returnable only as complete sets. Wholesale orders placed through Shopify B2B excluded. Serial numbered items requiring a warranty registration check before a return authorisation is issued. That is four systems of record and three exceptions before you reach the first reason code.

The scope blows up because the written policy and the enforced policy are different documents, and nobody has ever reconciled them. Support agents have been making judgment calls at ten to five on a Friday for years, and those calls have quietly become policy. When you start writing rules, you surface decisions that no one can currently justify, and the project stalls in a meeting about whether a customer at a certain spend level really does get store credit on final sale.

The fix is to run that reconciliation before the build rather than during it. Pull ninety days of exception tickets, sort them by what the agent actually did, and you will have the real policy in a morning. Then design eligibility as a rule set that logs which rule fired on every request, with an override screen that requires a reason code. A monthly report on the most overridden rules tells you which parts of the policy are wrong, which is how the policy gets fixed instead of quietly ignored.

What goes wrong migrating Loop history and warehouse spreadsheets?

Two data sets, two different problems. Loop exposes returns through its interface and exports, so the structured part is tractable, but the states do not map one to one onto a unit level model. Loop thinks in return authorisations. A warehouse system has to think in units, because a three item return has three different outcomes and three different locations. Migrating a return authorisation with a single status into a model that expects per unit state produces records that look complete and cannot be graded.

The spreadsheet is worse and more valuable. RETURNS MASTER with fourteen tabs and three owners contains your only history of what was actually restocked, refurbished or written off, and the columns changed three times as people improvised. Older rows have free text where later rows have codes, a disposition column that was reused for a different purpose in the second year, and dates in two formats.

Handle it in that order. Migrate open return authorisations with their states intact, because those are live customer promises. Normalise spreadsheet history into the new ledger with an explicit unknown value rather than guessing, since a fabricated disposition is worse than a blank. Budget one to two weeks of data work, and validate the migrated totals against past refund journals in your accounting system before anyone trusts a report built on them.

Why do the Shopify, NetSuite and warehouse integrations break after launch?

These three connections are the build, and each fails in a way that is easy to miss in testing and painful in production. Shopify webhooks are delivered at least once, not exactly once, so any handler that is not idempotent will eventually process the same event twice. On a refund path that is a duplicate refund, and it will happen during a peak week rather than in a quiet one.

Refund calls themselves need the same discipline. A timeout is not a failure, it is an unknown outcome, and a naive retry on an unknown outcome is how a customer receives two refunds and a chargeback follows anyway. Use an idempotency key on every refund request and reconcile against the processor rather than assuming your own record is authoritative.

Accounting posting fails on the last day of the month, which is the only day it really matters. A journal that cannot post needs a queue with visible failures and a replay path, not a log line. And the warehouse system, whether that is ShipHero, Extensiv or a third party logistics portal, will change its interface or its rate limits without telling you, usually right before a seasonal peak.

The concrete fixes are boring: idempotency keys everywhere money moves, deduplication on webhook identifiers, a visible failure queue with replay, and a daily three way reconciliation between Shopify refunds, the returns ledger and the accounting journal so a break is found the next morning rather than at month end.

What happens when refund fraud and inspection evidence are not covered?

Most brands refund on carrier scan to keep customers calm, and serial abusers know it. The box arrives empty, or holds a worn item, or a cheaper substitute, or on electronics the same model with a different serial number. By the time the inspection bench reaches it the refund cleared two weeks earlier, and the only place the pattern shows up is the chargeback report, where it is too late to act.

The gap is that off the shelf refund timing is a global setting. It has no memory of the customer who has returned nineteen orders in twelve months with four inspection mismatches, so the choice is instant refunds for everyone or delayed refunds for everyone, and delaying everyone costs you good customers.

Score at the customer level instead: return frequency, inspection mismatch count, empty box claims, and bracketing patterns such as ordering three sizes and returning two. Trusted customers, which is nearly all of them, keep instant refunds. Flagged customers have refunds held until inspection automatically, so no support agent has to make the awkward call. Capture grading photographs at the bench and attach them, with the scan timeline, to the record. When a dispute arrives, that evidence goes into the chargeback response in the format the processor expects, which is frequently the difference between winning and eating the loss.

Should you build custom or configure what you already own?

Stay on Loop if you run one fulfilment node, process under roughly 2,000 returns a month, can fit your real policy on one page, and your main objective is converting refunds into exchanges. That is the job Loop was built for and it does it well. The same applies to Happy Returns and AfterShip Returns at that scale, and at that volume no custom build recovers its cost. Spend the money on photography and size guides instead, because that reduces the returns rather than processing them faster.

Even above that volume, the first move is usually not a replacement. Loop's customer portal is a commodity and it is cheap to keep. The expensive gaps sit behind it: grading, disposition, refund timing and reconciliation, none of which Loop touches. Building the operational layer and leaving Loop as the front door gets you most of the value for a fraction of the work, and you can replace the portal later if per return fees justify it.

Build when you have headcount whose real job is reconciling systems, when more than one return in ten becomes a support ticket because the portal cannot express the policy, when you run multiple receiving nodes or a refurbishment channel with genuine recovery value, or when platform fees plus reconciliation labour plus unaudited leakage approach the cost of a first release.

How do hidden costs get into the quote?

Warehouse hardware is the classic omission. Scanners and cameras behave differently on a concrete floor under industrial lighting than they do on a demonstration laptop, and a grading station that needs a photograph of every unit needs a working camera, a mount, decent light and a network that reaches the bench. That is a small capital and setup line that is never in the software quote and always in the actual project.

Every additional receiving node and every distinct warehouse system is its own integration with its own testing, so two nodes on the same system is not the same as two nodes on two systems. Accounting depth is the next multiplier: multi entity or multi currency posting roughly doubles the finance work, because the mapping and the reconciliation both grow.

Cross border returns bring duties and customs paperwork into scope and should be quoted separately rather than assumed. And the quiet one is parallel running. If the new receiving flow runs in shadow alongside Loop for a few weeks, which it should, the warehouse is doing some work twice during that period, and that is an operational cost your warehouse manager needs warned about in advance rather than discovered.

What separates a build that works from one that fails here?

The builds that work model the unit, not the return authorisation. Every unit carries its own state, grade, location and disposition, and an exchange creates a real order rather than a note. If the data model stops at the authorisation level, none of the warehouse features you are paying for can be built on top of it, and you will discover this in month four rather than week two. Ask any candidate developer to draw the model before you sign.

They assume volume never stops. There is no cutover weekend for a live returns operation. Run the new receiving flow in shadow, migrate open authorisations with their states, and cut over one node at a time. A developer who proposes a single weekend switch has not run one.

They close the finance loop early. One returns ledger where every event, request, receipt, grade, refund, restock, write off, is journalled once and posted to your accounting system automatically is what turns a month end reconciliation into a review. That is usually what convinces the finance side to fund the rest.

And ownership is settled before kickoff. You should own the repository, the infrastructure accounts and the data from day one, with source, deployment pipelines and documentation handed over at delivery. Any developer who resists that, or who hosts your returns ledger only on accounts they control, is building you a dependency at the exact point where your refund liability lives.