Returns Are Digital Until
They're Not

The $850 Billion Problem That Lands on a Clipboard

U.S. retail returns totaled $849.9 billion in 2025, according to the National Retail Federation's 2025 Retail Returns Landscape report, co-published with Happy Returns. E-commerce returns alone account for 19.3% of online sales — roughly one in five orders comes back. Apparel runs 25%, footwear approaches 31%, and during the post-holiday peak, return volumes spike to three to five times daily averages. The NRF's survey of 358 e-commerce professionals at merchants exceeding $500 million in revenue found that 64% are prioritizing returns process updates in the next six months.

But those survey respondents are largely talking about the customer-facing layer: return portals, label generation, drop-off networks, fraud detection. The warehouse-facing layer — the moment a physical return becomes a data record in inventory and accounting systems — is conspicuously absent from the conversation. Once the package lands on the dock, the digital exhaust trail from the portal goes cold.

At a standard returns processing station, an associate receives a package, opens it, and locates the RMA paperwork: a printed page from the customer's portal submission, a PDF attached to the shipment, or in some B2B and manufacturing contexts, a hand-filled authorization form. They then read the RMA number, order number, SKU, reason code, condition, and disposition instructions — and retype each field into a warehouse management system (WMS), a tracking spreadsheet, or both. Industry estimates place this manual entry step at 60 to 90 seconds per return. At 500 returns per day — the volume of a mid-size 3PL during January — that's 8 to 12 hours of pure data re-entry that adds no new information to the system. It's transcription, not processing.

A Six-Second Digital Process That Dead-Ends at the Dock

To understand why this break exists, you have to follow one return through the entire chain — and mark the precise moment the data stops moving.

In the first 15 minutes of a return's life, the data flow is seamless. The customer submits a return request through a portal — Loop Returns, ReturnGO, AfterShip, or a Shopify-native form — and the system auto-populates the order number, customer name, SKU, and original purchase date from the e-commerce platform. It appends a return reason code from a dropdown. It generates an RMA number and a shipping label. A webhook fires off to the WMS or order management system, creating a pending RMA record. The package enters the carrier network with a tracking number linked to the RMA.

Then the box arrives at the warehouse — and the data flow fractures. That auto-generated RMA record now needs to be enriched with inspection results: the actual condition of the item, whether it matches the customer's stated reason, whether accessories are present, whether it's resellable or needs refurbishment. These observations live on the RMA form itself — notes scribbled by an inspector, boxes checked on a printed slip, a "REFURB" stamp in the corner. And that form, whether physical paper or a PDF on a tablet screen, speaks a different language than the WMS. It has no API. It requires a human to translate its contents into keystrokes.

One post on r/Netsuite captured this exactly: "The RMA process has turned into a full-time job for two people. Every return starts with a customer emailing us, someone manually approving it, then manually generating a label." On r/supplychain, a growing distributor put it more bluntly: their returns process was "eating them alive" — manual RMA workflows, vendor credit reconciliation nightmares, and warehouse bottlenecks converging at scale. These aren't complaints about bad software. They're describing a structural gap: the front-end RMA system generates data that the back-end warehouse system can't ingest without a human middleman retyping every field.

Why the Digital Chain Was Never Completed

This isn't a story of negligence. It's a story of two halves of a system evolving at different speeds, and the seam between them becoming invisible from both sides. The customer-facing half of returns has undergone three waves of digitization in the last decade: first, the migration from email-and-phone RMA to self-service portals; second, the integration of those portals with shipping carriers for automatic label generation; third, the layering of AI for fraud detection and exchange incentivization. Loop Returns, ReturnGO, and Happy Returns are each part of this evolutionary stack.

The warehouse-facing half followed a different cadence. Warehouse management systems (WMS) — Cin7, Fishbowl, ShipBob, SkuVault — were built to optimize picking, packing, and shipping, with returns handling added as a secondary module. The returns workflow in most WMS platforms assumes someone is going to key in the data or scan a barcode whose information was already entered. Neither assumption holds for an RMA slip pulled out of a box.

The structural mismatch is this: returns portals output data in formats built for customer experience — branded emails, portal dashboards, carrier tracking APIs. WMS platforms consume data in formats built for inventory operations — SKU-level transactions, bin-location updates, accounting journal entries. There is no standard adapter between these two worlds, so every warehouse builds its own: a person with a keyboard.

The NRF's returns report notes that 64% of merchants say updating their returns process is a priority. But the report focuses almost exclusively on the customer side — return fees, drop-off convenience, fraud detection. The warehouse data handoff is the returns problem that doesn't appear on customer-facing surveys, so it doesn't appear on roadmaps. It only shows up on a P&L, buried in labor costs and inventory write-downs.

What the Typing Actually Costs

If you process 500 returns per day at 75 seconds of manual data entry each, that's 10.4 hours of labor dedicated to a task that produces no new information. At the U.S. Bureau of Labor Statistics' March 2026 warehousing average wage of $25.83 per hour, that's roughly $269 per day, $70,000 per year — for a single shift. For a 3PL running two shifts seven days a week, the number approaches $200,000 annually, before accounting for overtime during peak season.

But labor is only the visible cost. The invisible ones compound silently:

Entry errors cascade downstream. A mistyped reason code — "defective" instead of "didn't fit" — sends the item to a returns-to-vendor lane instead of back to stock, triggering unnecessary freight costs and delaying restocking by days. A transposed SKU digit routes the wrong product to the wrong shelf. Industry data suggests manual data entry error rates hover around 1-4%, depending on form complexity. For an RMA form with 8-12 fields (RMA number, order number, customer name, SKU, quantity, reason code, condition, disposition), a 2% error rate means ten mistakes per 500 returns — each one requiring an exception-handling loop that takes longer than the original entry.

Refunds are delayed by data latency. The customer expects a refund within days of the carrier scan showing "delivered." But if the RMA data hasn't been entered into the system, the finance team has no trigger to initiate the refund. The return sits in processing limbo — physically received, digitally invisible. According to the NRF and Happy Returns data, 82% of consumers say free returns are important; 57% have abandoned a retailer after a poor returns experience. A bad return experience is one where the package disappeared into a black hole. That black hole is often just a paper form sitting in an inbox tray waiting for data entry.

Supplier chargebacks rely on RMA data that was never digitized. Many returns trace back to manufacturer defects. When a product fails under warranty, the RMA form's inspection notes — reason code, condition, photos — become the supporting documentation for a debit memo to the supplier. If those notes remain on paper, or sit in a PDF that no one extracts into the ERP, the chargeback doesn't get filed. According to Appriss Retail's 2026 Total Retail Loss Benchmark, roughly $100 billion in preventable fraud and abuse loss occurred in 2025, with returns abuse alone accounting for $86 billion. A paper-based RMA process that can't flag suspicious return patterns in real time is a gap that fraud exploits.

Inventory accuracy degrades. Only about 48% of returned items are resold at full price, according to Eightx 2026 data. The other 52% need routing decisions — refurbish, liquidate, return-to-vendor, donate, destroy — that depend on inspection data recorded on the RMA form. If that data isn't in the system, routing decisions default to the slowest, safest path: "hold for review," which in practice means the item sits in a returns staging area, losing value by the day. Optoro, a reverse logistics platform that has processed over 100 million returns, estimates that processing costs consume 20-39% of an item's original price — and a significant share of that cost is the labor and delay introduced by manual data handling.

The Fix Is Not Another Portal

If you trace the entire RMA data flow — customer portal → carrier scan → warehouse receipt → inspection → WMS update → accounting entry → refund trigger → inventory adjustment — every step except one has been digitized and API-connected. The single step that remains manual is the extraction of data from the RMA form itself into the warehouse or accounting system. The form, regardless of its origin (portal PDF, scanned paper slip, handwritten authorization), is what sits between the digital return and the digital warehouse. Close that gap, and the entire chain becomes automatic.

This is not an integration problem. Integration assumes both sides speak a common protocol. The RMA form doesn't speak any protocol — it's a visual artifact. The solution is an extraction layer between the form and the system: something that reads the form's contents as a human would, but outputs them as structured data that the WMS, ERP, or spreadsheet can consume directly.

That's where Custom Column Extraction changes the equation. Instead of drawing boxes around form fields or training a model on sample RMA layouts — approaches that break the moment a supplier changes their form format — you define what you want extracted by naming the columns: "RMA Number," "Order Number," "SKU," "Reason Code," "Condition," "Disposition." The AI reads the form semantically — it understands that "RMA #" and "Authorization Number" mean the same thing, regardless of where on the page each appears. It doesn't care whether the form is a Shopify-generated PDF, a scanned handwritten slip, or a vendor's proprietary return authorization with a completely different layout. The output is a structured spreadsheet whose column headers match your naming conventions, ready to import into any WMS or accounting system.

For a warehouse running 500 returns per day, this cuts the data entry step from 10 hours to the time it takes to upload a batch of scanned or photographed RMA forms and click "process." The extracted data doesn't need rekeying, doesn't accumulate transcription errors, and flows into the same tracking spreadsheet or WMS the team already uses. For a deeper look at how this fits into a refund reconciliation workflow, see the breakdown on batch-processing RMA forms into a single reconciliation sheet.

And because the extracted RMA data is already structured — with standardized SKUs, reason codes, and disposition fields — feeding it into an inventory system is a direct import, not a retyping exercise. The pipeline from RMA form to inventory system becomes a feed, not a funnel.

The broader point: the RMA paper problem isn't solved by buying a better portal or upgrading your WMS. It's solved by decoupling "reading the form" from "acting on the data." Once those two steps are separated, the form can be anything — PDF, scan, photo, handwriting — and the downstream systems don't care, because they never see the form. They see a spreadsheet.

Where the Extracted Data Lands

The output of an RMA extraction isn't tied to any one system. It's a spreadsheet — XLSX, CSV, or direct-to-Google Sheets. Where it goes next depends on your stack:

The consistent pattern: the extraction layer decouples "reading the form" from "acting on the data." Whether the data ultimately lands in NetSuite, ShipStation, or a shared Google Sheet is a downstream decision that doesn't change how the extraction is set up. One extraction configuration works across all destinations. For supplementing RMA data with supplier invoice processing in the same workflow, see batch-processing supplier invoices into an e-commerce inventory ledger to understand how a single extraction pipeline can handle multiple document types feeding the same inventory system.

Frequently Asked Questions

Does this work on handwritten RMA slips?

Yes. The AI reads handwriting — including cursive and mixed hand-print — by understanding the content of what's written, not just recognizing characters. A handwritten RMA number or reason code on a paper slip is read the same way a printed one is. That said, extremely poor handwriting (illegible to a human) will challenge the AI as it would challenge any reader. Legible handwriting — the kind a warehouse associate can read and retype — is well within range.

Can I import the extracted data directly into NetSuite / Shopify / my WMS?

Yes, through the standard import path of each platform. The extraction output is a structured spreadsheet (XLSX or CSV), which every major WMS and ERP supports as an import format. There is no custom API integration required. Map your columns once — RMA Number → NetSuite RMA field, SKU → inventory record, Disposition → routing queue — and reuse the same mapping for every batch.

What if every supplier uses a different RMA form format?

That is the core value of semantic extraction. Because the AI reads by meaning — not by position or template — the format of the form doesn't matter. Whether Vendor A puts the RMA number in the top-right corner and Vendor B puts it in a table header row, the extraction logic is the same: find the data that matches the concept of "RMA Number." The same principle applies to supplier invoice processing, where format variance across vendors is the norm.

What about RMA photos taken on a warehouse tablet or phone?

Photos are supported as well as scans and PDFs. A warehouse associate can photograph the RMA slip with a tablet or phone and upload the image directly — the extraction works from photographs, not just high-resolution scans. This means the data entry step can happen at the receiving dock, on the spot, without routing paper forms to a centralized data entry desk.

How accurate is the extraction compared to manual entry?

Printed text on clean form layouts reaches up to 99% recognition accuracy. Handwritten forms and low-quality photographs will have lower accuracy, but the key comparison is to manual entry — which itself has an estimated 1-4% error rate. The difference is that extraction errors are consistent and reviewable: you see exactly what was extracted field by field, and corrections are flagged for human review rather than silently propagating through the system as a mistyped digit would.