Las devoluciones son digitales hasta
que dejan de serlo

El problema de 850 mil millones de dólares que termina en un portapapeles

Las devoluciones minoristas en EE. UU. totalizaron $849.9 mil millones en 2025, según el informe Retail Returns Landscape 2025 de la National Retail Federation, copublicado con Happy Returns. Solo las devoluciones de comercio electrónico representan el 19.3% de las ventas en línea — aproximadamente uno de cada cinco pedidos regresa. La ropa alcanza el 25%, el calzado se acerca al 31% y durante el pico posterior a las fiestas, los volúmenes de devoluciones se disparan a tres o cinco veces el promedio diario. La encuesta de la NRF a 358 profesionales de comercio electrónico en comerciantes con ingresos superiores a $500 millones encontró que el 64% está priorizando actualizaciones en los procesos de devolución en los próximos seis meses.

Pero esos encuestados hablan principalmente de la capa orientada al cliente: portales de devoluciones, generación de etiquetas, redes de entrega, detección de fraude. La capa orientada al almacén — el momento en que una devolución física se convierte en un registro de datos en los sistemas de inventario y contabilidad — está notablemente ausente de la conversación. Una vez que el paquete llega al muelle, el rastro digital del portal se enfría.

En una estación de procesamiento de devoluciones estándar, un asociado recibe un paquete, lo abre y localiza la documentación de RMA: una página impresa del envío del cliente desde el portal, un PDF adjunto al envío o, en algunos contextos B2B y de fabricación, un formulario de autorización llenado a mano. Luego leen el número de RMA, número de pedido, SKU, código de motivo, condición e instrucciones de disposición — y vuelven a escribir cada campo en un WMS (sistema de gestión de almacenes), una hoja de cálculo de seguimiento, o ambos. Las estimaciones de la industria sitúan este paso de entrada manual en 60 a 90 segundos por devolución. Con 500 devoluciones al día — el volumen de un 3PL (logística de terceros) de tamaño mediano durante enero — eso son de 8 a 12 horas de pura reentrada de datos que no agrega nueva información al sistema. Es transcripción, no procesamiento.

Un proceso digital de seis segundos que termina en el muelle

Para entender por qué existe esta ruptura, tienes que seguir una devolución a través de toda la cadena — y marcar el momento preciso en que los datos dejan de moverse.

En los primeros 15 minutos de vida de una devolución, el flujo de datos es fluido. El cliente envía una solicitud de devolución a través de un portal — Loop Returns, ReturnGO, AfterShip o un formulario nativo de Shopify — y el sistema completa automáticamente el número de pedido, nombre del cliente, SKU y fecha de compra original desde la plataforma de comercio electrónico. Agrega un código de motivo de devolución desde un menú desplegable. Genera un número de RMA y una etiqueta de envío. Un webhook se dispara hacia el WMS o el sistema de gestión de pedidos, creando un registro de RMA pendiente. El paquete ingresa a la red del transportista con un número de seguimiento vinculado al RMA.

Luego, la caja llega al almacén — y el flujo de datos se fractura. Ese registro de RMA generado automáticamente ahora necesita ser enriquecido con los resultados de la inspección: la condición real del artículo, si coincide con el motivo declarado por el cliente, si los accesorios están presentes, si es reutilizable o necesita reparación. Estas observaciones viven en el propio formulario de RMA — notas garabateadas por un inspector, casillas marcadas en un resbalón impreso, un sello de "REFURB" en la esquina. Y ese formulario, ya sea papel físico o un PDF en una pantalla de tableta, habla un idioma diferente al del WMS. No tiene API. Requiere que un humano traduzca su contenido a pulsaciones de teclas.

Una publicación en r/Netsuite lo resumió perfectamente: «El proceso de RMA se ha convertido en un trabajo de tiempo completo para dos personas. Cada devolución comienza con un cliente enviándonos un correo, alguien lo aprueba manualmente y luego genera una etiqueta también a mano». En r/supplychain, un distribuidor en crecimiento fue más directo: su proceso de devoluciones los estaba «devorando vivos» — flujos de trabajo manuales de RMA, pesadillas de conciliación de créditos con proveedores y cuellos de botella en el almacén convergiendo a escala. Estas no son quejas sobre mal software. Describen una brecha estructural: el sistema de RMA frontal genera datos que el sistema de almacén trasero no puede ingerir sin un intermediario humano que vuelva a escribir cada campo.

Por qué la cadena digital nunca se completó

No es una historia de negligencia. Es la historia de dos mitades de un sistema que evolucionan a diferentes velocidades, y la costura entre ellas se vuelve invisible desde ambos lados. La mitad orientada al cliente de las devoluciones ha pasado por tres oleadas de digitalización en la última década: primero, la migración de RMA por correo electrónico y teléfono a portales de autoservicio; segundo, la integración de esos portales con las empresas de envío para la generación automática de etiquetas; tercero, la superposición de IA para la detección de fraudes y el incentivo de cambios. Loop Returns, ReturnGO y Happy Returns son parte de esta pila evolutiva.

La mitad orientada al almacén siguió un ritmo diferente. Los sistemas de gestión de almacenes (WMS) — Cin7, Fishbowl, ShipBob, SkuVault — se construyeron para optimizar la preparación, el embalaje y el envío, con la gestión de devoluciones añadida como un módulo secundario. El flujo de trabajo de devoluciones en la mayoría de las plataformas WMS asume que alguien va a ingresar los datos o escanear un código de barras cuya información ya fue introducida. Ninguna de las dos suposiciones se cumple con un comprobante de RMA sacado de una caja.

El desajuste estructural es este: los portales de devoluciones generan datos en formatos diseñados para la experiencia del cliente — correos electrónicos con marca, paneles de control del portal, API de seguimiento de transportistas. Los WMS consumen datos en formatos diseñados para las operaciones de inventario — transacciones a nivel de SKU, actualizaciones de ubicación en contenedores, asientos contables. No existe un adaptador estándar entre estos dos mundos, por lo que cada almacén construye el suyo propio: una persona con un teclado.

El informe de devoluciones de la NRF señala que el 64% de los comerciantes dice que actualizar su proceso de devoluciones es una prioridad. Pero el informe se centra casi exclusivamente en el lado del cliente — tarifas de devolución, conveniencia de entrega, detección de fraudes. La transferencia de datos al almacén es el problema de las devoluciones que no aparece en las encuestas orientadas al cliente, por lo que no aparece en las hojas de ruta. Solo se manifiesta en el estado de resultados, enterrado en costos laborales y amortizaciones de inventario.

Lo que realmente cuesta escribir

Si procesas 500 devoluciones al día con 75 segundos de entrada manual de datos cada una, eso son 10,4 horas de trabajo dedicadas a una tarea que no produce información nueva. Con el salario promedio de almacén de marzo de 2026 de la Oficina de Estadísticas Laborales de EE. UU. de $25,83 por hora, eso equivale a unos $269 al día, $70,000 al año, para un solo turno. Para un 3PL (logística de terceros) que opera dos turnos siete días a la semana, la cifra se acerca a los $200,000 anuales, sin contar las horas extra en temporada alta.

Pero la mano de obra es solo el costo visible. Los invisibles se acumulan en silencio:

Los errores de entrada se propagan río abajo. Un código de motivo mal escrito — «defectuoso» en lugar de «no le quedó» — envía el artículo al carril de devolución al proveedor en lugar de devolverlo al inventario, generando costos de flete innecesarios y retrasando la reposición por días. Un dígito de SKU transpuesto dirige el producto equivocado al estante equivocado. Los datos del sector sugieren que las tasas de error en la entrada manual de datos rondan el 1-4%, según la complejidad del formulario. Para un formulario de RMA con 8-12 campos (número de RMA, número de pedido, nombre del cliente, SKU, cantidad, código de motivo, condición, disposición), una tasa de error del 2% significa diez errores por cada 500 devoluciones, cada uno requiriendo un bucle de manejo de excepciones que lleva más tiempo que la entrada original.

Los reembolsos se retrasan por la latencia de los datos. El cliente espera un reembolso en cuestión de días desde el escaneo del transportista que muestra «entregado». Pero si los datos del RMA no se han ingresado en el sistema, el equipo financiero no tiene un desencadenante para iniciar el reembolso. La devolución queda en un limbo de procesamiento — recibida físicamente, invisible digitalmente. Según datos de NRF y Happy Returns, el 82% de los consumidores dice que las devoluciones gratuitas son importantes; el 57% ha abandonado un minorista tras una mala experiencia de devolución. Una mala experiencia de devolución es aquella en la que el paquete desapareció en un agujero negro. Ese agujero negro suele ser solo un formulario en papel esperando en una bandeja de entrada para ser ingresado.

Los contracargos a proveedores dependen de datos de RMA que nunca se digitalizaron. Muchas devoluciones se remontan a defectos del fabricante. Cuando un producto falla bajo garantía, las notas de inspección del formulario de RMA — código de motivo, condición, fotos — se convierten en la documentación de respaldo para un débito al proveedor. Si esas notas quedan en papel, o en un PDF que nadie extrae al ERP, el contracargo no se presenta. Según el Informe de Referencia de Pérdida Total Minorista 2026 de Appriss Retail, aproximadamente $100 mil millones en pérdidas prevenibles por fraude y abuso ocurrieron en 2025, solo el abuso de devoluciones representó $86 mil millones. Un proceso de RMA en papel que no puede detectar patrones sospechosos de devolución en tiempo real es una brecha que el fraude explota.

La precisión del inventario se degrada. Solo alrededor del 48% de los artículos devueltos se revenden a precio completo, según datos de Eightx 2026. El otro 52% necesita decisiones de enrutamiento — reacondicionar, liquidar, devolver al proveedor, donar, destruir — que dependen de los datos de inspección registrados en el formulario de RMA. Si esos datos no están en el sistema, las decisiones de enrutamiento se reducen a la ruta más lenta y segura: «retener para revisión», lo que en la práctica significa que el artículo permanece en un área de almacenamiento temporal de devoluciones, perdiendo valor día a día. Optoro, una plataforma de logística inversa que ha procesado más de 100 millones de devoluciones, estima que los costos de procesamiento consumen entre el 20 y el 39% del precio original de un artículo — y una parte significativa de ese costo es la mano de obra y la demora introducidas por el manejo manual de datos.

La solución no es otro portal

Si rastreas todo el flujo de datos de RMA — portal del cliente → escaneo del transportista → recepción en almacén → inspección → actualización del WMS → registro contable → activación del reembolso → ajuste de inventario — cada paso excepto uno ha sido digitalizado y conectado por API. El único paso que sigue siendo manual es la extracción de datos del propio formulario de RMA hacia el sistema de almacén o contable. El formulario, independientemente de su origen (PDF del portal, nota de papel escaneada, autorización manuscrita), es lo que se interpone entre la devolución digital y el almacén digital. Cierra esa brecha, y toda la cadena se vuelve automática.

Esto no es un problema de integración. La integración asume que ambas partes hablan un protocolo común. El formulario de RMA no habla ningún protocolo — es un artefacto visual. La solución es una capa de extracción entre el formulario y el sistema: algo que lea el contenido del formulario como lo haría un humano, pero que lo genere como datos estructurados que el WMS, ERP u hoja de cálculo pueda consumir directamente.

Ahí es donde la Extracción de Columnas Personalizadas cambia las reglas del juego. En lugar de dibujar cuadros alrededor de los campos del formulario o entrenar un modelo con diseños de muestra de RMA — enfoques que fallan en cuanto un proveedor cambia el formato de su formulario — defines lo que quieres extraer nombrando las columnas: «Número de RMA», «Número de Pedido», «SKU», «Código de Motivo», «Condición», «Disposición». La IA lee el formulario semánticamente — entiende que «RMA #» y «Número de Autorización» significan lo mismo, sin importar dónde aparezcan en la página. No le importa si el formulario es un PDF generado por Shopify, una nota manuscrita escaneada o una autorización de devolución propia de un proveedor con un diseño completamente diferente. El resultado es una hoja de cálculo estructurada cuyos encabezados de columna coinciden con tus convenciones de nomenclatura, lista para importar a cualquier WMS o sistema contable.

Para un almacén que procesa 500 devoluciones al día, esto reduce el paso de ingreso de datos de 10 horas al tiempo que lleva subir un lote de formularios de RMA escaneados o fotografiados y hacer clic en «procesar». Los datos extraídos no necesitan ser reescritos, no acumulan errores de transcripción y fluyen hacia la misma hoja de cálculo de seguimiento o WMS que el equipo ya usa. Para una mirada más profunda sobre cómo encaja esto en un flujo de trabajo de conciliación de reembolsos, consulta el desglose en procesamiento por lotes de formularios de RMA en una sola hoja de conciliación.

Y debido a que los datos de RMA extraídos ya están estructurados — con SKUs, códigos de motivo y campos de disposición estandarizados — alimentarlos a un sistema de inventario es una importación directa, no un ejercicio de reescritura. El conducto del formulario de RMA al sistema de inventario se convierte en un flujo de alimentación, no en un embudo.

El punto general: el problema del papel en las RMA no se resuelve comprando un mejor portal o actualizando tu WMS. Se resuelve separando «leer el formulario» de «actuar sobre los datos». Una vez que esos dos pasos están separados, el formulario puede ser cualquier cosa — PDF, escaneo, foto, manuscrito — y los sistemas posteriores no se preocupan, porque nunca ven el formulario. Ven una hoja de cálculo.

Dónde Aterrizan los Datos Extraídos

El resultado de una extracción de RMA no está vinculado a un solo sistema. Es una hoja de cálculo — XLSX, CSV o directo a Google Sheets. A dónde va después depende de tu stack:

El patrón consistente: la capa de extracción separa "leer el formulario" de "actuar sobre los datos". Que los datos terminen finalmente en NetSuite, ShipStation o una hoja de Google compartida es una decisión posterior que no cambia cómo se configura la extracción. Una configuración de extracción funciona para todos los destinos. Para complementar los datos de RMA con el procesamiento de facturas de proveedores en el mismo flujo de trabajo, consulta procesamiento por lotes de facturas de proveedores en un libro mayor de inventario de comercio electrónico para entender cómo un solo pipeline de extracción puede manejar múltiples tipos de documentos que alimentan el mismo sistema de inventario.

Preguntas Frecuentes

¿Funciona con formularios de RMA escritos a mano?

Sí. La IA lee escritura a mano, incluyendo cursiva y letra de imprenta mixta, comprendiendo el contenido de lo escrito, no solo reconociendo caracteres. Un número de RMA o código de motivo escrito a mano en un formulario de papel se lee igual que uno impreso. Dicho esto, una escritura extremadamente mala (ilegible para un humano) desafiará a la IA como lo haría con cualquier lector. La escritura legible, del tipo que un empleado de almacén puede leer y reescribir, está dentro del rango de acción.

¿Puedo importar los datos extraídos directamente a NetSuite / Shopify / mi WMS?

Sí, a través de la ruta de importación estándar de cada plataforma. El resultado de la extracción es una hoja de cálculo estructurada (XLSX o CSV), que todos los principales WMS y ERP admiten como formato de importación. No se requiere una integración de API personalizada. Mapea tus columnas una vez — Número de RMA → campo RMA de NetSuite, SKU → registro de inventario, Disposición → cola de enrutamiento — y reutiliza el mismo mapeo para cada lote.

¿Qué pasa si cada proveedor usa un formato de formulario de RMA diferente?

Ese es el valor central de la extracción semántica. Debido a que la IA lee por significado, no por posición o plantilla, el formato del formulario no importa. Ya sea que el Proveedor A coloque el número de RMA en la esquina superior derecha y el Proveedor B lo coloque en el encabezado de una tabla, la lógica de extracción es la misma: encontrar los datos que coinciden con el concepto de "Número de RMA". El mismo principio se aplica al procesamiento de facturas de proveedores, donde la variación de formato entre proveedores es la norma.

¿Qué pasa con las fotos de RMA tomadas con una tableta o teléfono en el almacén?

Las fotos son compatibles, al igual que los escaneos y PDFs. Un empleado del almacén puede fotografiar el formulario de RMA con una tableta o teléfono y subir la imagen directamente; la extracción funciona a partir de fotografías, no solo de escaneos de alta resolución. Esto significa que el paso de ingreso de datos puede ocurrir en el muelle de recepción, en el acto, sin necesidad de enviar formularios en papel a un escritorio centralizado de ingreso de datos.

¿Qué tan precisa es la extracción en comparación con el ingreso manual?

El texto impreso en formularios con diseño limpio alcanza hasta un 99% de precisión de reconocimiento. Los formularios escritos a mano y las fotografías de baja calidad tendrán una precisión menor, pero la comparación clave es con el ingreso manual, que de por sí tiene una tasa de error estimada del 1-4%. La diferencia es que los errores de extracción son consistentes y revisables: ves exactamente lo que se extrajo campo por campo, y las correcciones se marcan para revisión humana en lugar de propagarse silenciosamente por el sistema como lo haría un dígito mal escrito.