What returns management software actually does

Returns management software handles the mechanical parts of a return: a self-service portal where a customer requests one, a rules engine that approves or denies it against a policy, a shipping label, and a trigger back to inventory and refund systems. That's the job, and platforms like Loop, ReturnGO, Narvar, and Blue Yonder do it well for the use case they were built for: a single-channel DTC brand with a standard policy and a clean product catalog. The category's live vendor landscape on G2 gives a good sense of how crowded and mature this layer of the stack already is.

The pitch is almost always the same: cut support tickets, automate label generation, give the customer a self-service flow instead of an email thread. For a brand selling one product line through one storefront, that's a real win and a cheap one. The problem shows up the moment a retailer adds a second sales channel, a wholesale arm, or a catalog with bundles and serialized items. The rules engine that handled "return within 30 days, unworn, with tags" starts hitting cases it was never designed for, and someone on the ops team ends up back in spreadsheets and email threads anyway.

How much returns actually cost a growing retailer

Returns are not a rounding error. The National Retail Federation projects $849.9 billion in US retail merchandise returns for 2025, at an average return rate of 15.8%, down slightly from 16.9% in 2024 (NRF, 2025 Retail Returns Landscape). Online is worse: NRF puts the online return rate at 19.3% of sales, and category-level data from Capital One Shopping's 2026 research shows some online categories running as high as 24.5%, against roughly 8.7% in-store.

A separate read from the Bank of America Institute, based on card transaction data rather than NRF's survey methodology, puts the 2025 return rate closer to 4.5% across all retailers. The gap between that number and NRF's isn't a contradiction, it's a reminder that "return rate" gets measured differently depending on whether you count transactions, units, or dollar value, and any vendor quoting you a single clean benchmark is simplifying more than they're telling you.

Run the arithmetic for a mid-market retailer doing $20M a year online. At a 19.3% return rate, that's roughly $3.86M in merchandise coming back annually. Even at a modest handling cost per return (restocking labor, return shipping, re-grading, repackaging), the operational drag adds up to a real line item, before you count the margin lost on items that get written off because nobody can tell whether they're resellable. That's the number that should be driving the build-or-buy conversation, not the software's monthly subscription fee.

Where off-the-shelf returns software breaks down

Standard RMS platforms are built around a single assumption: one catalog, one policy, one channel. Break any of those and the rules engine stops being able to make a confident decision on its own, which means a human has to.

The most common break points we see:

• Multi-marketplace selling. A return initiated on Amazon, fulfilled through a 3PL, and reconciled against a Shopify order record needs three systems to agree on what happened. Most RMS tools integrate with one or two of these cleanly; the third gets handled by someone exporting a spreadsheet.

• Wholesale and B2B terms. A wholesale buyer's return policy rarely matches the DTC policy in the same platform, and most rules engines have no clean way to run two policies on the same SKU without manual overrides.

• Non-standard SKU structures. Bundles, kits, and serialized or warrantied items (electronics, appliances, anything with a registration number) need matching logic a flat SKU-to-SKU rules engine wasn't built for.

• Cross-border returns. Duties, re-import rules, and the cost math on whether it's even worth bringing an item back versus destroying it locally add a layer of decisioning most returns software treats as an edge case.

• Return fraud and abuse. Wardrobing, serial returners, and "bracketing" (ordering multiple sizes with intent to return most) are pattern-detection problems. A static rules engine can flag "more than 3 returns this month," but it can't catch the customer who spreads abusive behavior across accounts, payment methods, and channels. That takes a model looking at behavior over time, not a threshold.

Genta worked through a version of this complexity on the pre-purchase side with a 1M+ SKU e-commerce catalog, detailed on the case studies page, where the real problem was never the software category, it was the messiness of the underlying data. Returns have the same shape: the software isn't wrong, the data and policy logic it's being asked to run on has outgrown what a generic rules engine can hold.

Should you build or buy returns management software?

Buy, if you're selling through one or two channels, running a single return policy, and your catalog doesn't involve bundles, serialized goods, or wholesale terms. At that scale a $500 to $3,000/month platform will outperform anything custom, because the integration work and ongoing maintenance of a build aren't worth it against a simple problem. This is most DTC brands under $10M in revenue, and there's no honest argument for building here.

Build, or at minimum augment, once two or more of the following are true: you sell across three or more channels with different return terms, more than roughly 10-15% of your return volume requires manual exception handling because the rules engine can't decide, you carry serialized or warrantied SKUs that need individual tracking, or return fraud has become large enough that catching it would meaningfully move margin. None of these thresholds are arbitrary vendor marketing, they're the point where a rules engine's decision tree has more exceptions than rules, and every exception becomes a ticket for an ops person.

The decision isn't really "software vs. agent." It's "deterministic rules vs. judgment." Rules engines are cheap and predictable because they only have to be right about things you can write down in advance. The moment your business needs judgment calls (is this bundle actually resellable, is this customer a pattern of abuse, does this cross-border return clear the cost-to-recover bar), you need something that can reason over messy data, which is a different kind of system entirely.

What a custom AI returns/reverse-logistics agent does differently

A custom agent earns its cost by handling the judgment calls a rules engine punts on, not by replacing the parts of RMS software that already work fine (labels, portals, basic refund triggers can usually stay as-is).

In practice that looks like: matching a returned item against messy or incomplete SKU and serial data instead of requiring an exact barcode match, running model-based fraud detection that looks at account, device, and behavioral patterns across channels instead of a static threshold rule, making the restock/liquidate/dispose decision automatically based on item condition, cost-to-recover, and resale channel value, and reconciling the return event across the ERP, the 3PL, and whichever marketplaces were involved, so finance isn't manually matching refund records at month end.

That last point matters more than it sounds. A lot of "returns" pain that gets blamed on the returns process is actually a reconciliation problem that shows up on the finance side, which is the same failure mode covered in our piece on why accounts receivable software stops working once billing gets complex: the software category is fine, the cross-system data matching is what breaks. For a broader read on where agents genuinely deliver in retail operations versus where they're overbuilt for the problem, see AI agents in retail operations.

What this actually costs and how long it takes

Custom returns/reverse-logistics agents at the scale described above typically run in the same range we see across other mid-market operational builds, roughly 6 to 16 weeks depending on how many systems need to talk to each other. The cost driver isn't the AI model, it's the integration surface: how many ERPs, 3PLs, and marketplace APIs the agent needs to reconcile against, and how clean the underlying SKU master data already is.

The single most common reason these projects stall isn't the model or the build, it's data readiness. If your SKU master has duplicate entries, your return policies live in three different spreadsheets instead of one documented source, or nobody can tell you the warranty/serial data structure for a third of your catalog, no amount of AI engineering fixes that on day one. The diagnosis phase of any project like this should surface that gap before a single line of code gets written, because building a clever reconciliation agent on top of a broken SKU master just automates the mess faster. Our notes on agents running in live production environments, in agentic commerce in production, cover a version of this same lesson for commerce systems generally.

A rough planning number: expect data cleanup and policy documentation to take as long as the build itself if nobody has touched it recently. Retailers that have already standardized their SKU structure (often the same companies that went through a PIM cleanup, see our companion piece on product information management breaking down past 200,000 SKUs) move faster here, because half the prerequisite work is already done.

What to ask before you buy or build

Whether you're evaluating a vendor contract or scoping a custom build, the same four questions separate a decision that holds up at scale from one you'll be revisiting in 18 months:

• Where exactly does the SKU/channel complexity ceiling sit, and what happens to your data the day you cross it?

• What's the actual fraud-detection methodology, a static rules threshold or something that learns from behavior over time?

• Who owns the data and the exported history if you switch vendors or bring the function in-house later?

• What does customizing for a non-standard return policy (wholesale terms, serialized warranties, cross-border) actually cost, and is that quoted up front or discovered mid-contract?

Most vendor sales conversations answer the first three vaguely and skip the fourth entirely. If you're working through this decision, this is exactly what our Discovery phase at Genta AI Solutions maps out before any build starts, and we're happy to compare notes.

Frequently asked questions

What is the definition of return management?

Return management is the set of processes and systems a retailer uses to handle a customer sending back merchandise: approving the return against policy, generating a shipping label, triggering the refund or exchange, and updating inventory. Software in this category automates the parts that follow a predictable rule; everything outside that rule still needs a human or an agent to decide.

What is RMA in ecommerce?

RMA stands for return merchandise authorization, the approval a retailer issues before accepting a returned item. It confirms the item qualifies under policy and gives the customer a reference number and label. RMA software automates the approval step for standard cases, but non-standard items (serialized goods, bundles, wholesale orders) usually still require manual review.

How do I return an online order?

From a customer's view, it's simple: request a return through a portal, print a label, ship it back, and wait for the refund. On the operations side, that simple flow has to reconcile across the storefront, the 3PL, the ERP, and sometimes a marketplace, which is exactly where off-the-shelf returns software starts breaking down for multi-channel sellers.

Should we build or buy returns management software?

Buy if you sell through one or two channels with a single return policy and a straightforward catalog. Build or augment once multiple channels, non-standard SKUs, wholesale terms, or meaningful return fraud push more than roughly 10-15% of returns into manual exception handling. At that point a rules engine is costing you more in ops labor than a custom system would cost to run.

How much do retail returns actually cost a growing e-commerce business?

The National Retail Federation projects $849.9 billion in US merchandise returns for 2025 at a 15.8% average return rate, with online returns running closer to 19.3% (NRF, 2025). For a retailer doing $20M online, that rate implies roughly $3.86M in returned merchandise a year, before counting handling labor, shipping, and write-offs on unresellable stock.