Devoluções são digitais até
deixarem de ser

O Problema de US$ 850 Bilhões que Cai em uma Prancheta

As devoluções no varejo dos EUA totalizaram US$ 849,9 bilhões em 2025, de acordo com o Relatório de Cenário de Devoluções no Varejo de 2025 da National Retail Federation, copublicado com a Happy Returns. Apenas as devoluções de e-commerce representam 19,3% das vendas online — aproximadamente um em cada cinco pedidos retorna. O vestuário chega a 25%, os calçados se aproximam de 31% e, durante o pico pós-feriado, os volumes de devolução disparam para três a cinco vezes as médias diárias. A pesquisa da NRF com 358 profissionais de e-commerce em comerciantes com receita superior a US$ 500 milhões descobriu que 64% estão priorizando atualizações no processo de devoluções nos próximos seis meses.

Mas esses respondentes da pesquisa estão falando principalmente sobre a camada voltada para o cliente: portais de devoluções, geração de etiquetas, redes de pontos de entrega, detecção de fraudes. A camada voltada para o armazém — o momento em que uma devolução física se torna um registro de dados nos sistemas de inventário e contabilidade — está conspicuamente ausente da conversa. Assim que o pacote chega à doca, o rastro digital do portal se esfria.

Em uma estação de processamento de devoluções padrão, um funcionário recebe um pacote, abre-o e localiza a documentação do RMA: uma página impressa do envio do cliente no portal, um PDF anexado à remessa ou, em alguns contextos B2B e de manufatura, um formulário de autorização preenchido à mão. Em seguida, eles leem o número de RMA, número do pedido, SKU, código do motivo, condição e instruções de destinação — e redigitam cada campo em um WMS (sistema de gerenciamento de armazém), uma planilha de rastreamento ou ambos. Estimativas do setor colocam esta etapa de entrada manual em 60 a 90 segundos por devolução. A 500 devoluções por dia — o volume de um 3PL (logística terceirizada) de médio porte durante janeiro — isso representa 8 a 12 horas de pura redigitação de dados que não adiciona nenhuma informação nova ao sistema. É transcrição, não processamento.

Um Processo Digital de Seis Segundos que Morre na Doca

Para entender por que essa quebra existe, você precisa acompanhar uma devolução por toda a cadeia — e marcar o momento exato em que os dados param de se mover.

Nos primeiros 15 minutos de vida de uma devolução, o fluxo de dados é contínuo. O cliente envia uma solicitação de devolução por meio de um portal — Loop Returns, ReturnGO, AfterShip ou um formulário nativo do Shopify — e o sistema preenche automaticamente o número do pedido, nome do cliente, SKU e data de compra original da plataforma de e-commerce. Ele anexa um código do motivo da devolução de um menu suspenso. Gera um número de RMA e uma etiqueta de envio. Um webhook é disparado para o WMS ou sistema de gerenciamento de pedidos, criando um registro de RMA pendente. O pacote entra na rede da transportadora com um número de rastreamento vinculado ao RMA.

Então a caixa chega ao armazém — e o fluxo de dados se fragmenta. Esse registro de RMA gerado automaticamente agora precisa ser enriquecido com os resultados da inspeção: a condição real do item, se corresponde ao motivo declarado pelo cliente, se os acessórios estão presentes, se é revendável ou precisa de reforma. Essas observações vivem no próprio formulário de RMA — anotações rabiscadas por um inspetor, caixas marcadas em um recibo impresso, um carimbo de "REFORMA" no canto. E esse formulário, seja papel físico ou um PDF na tela de um tablet, fala uma língua diferente do WMS. Ele não tem API. Ele exige que um humano traduza seu conteúdo em digitação.

Um post no r/Netsuite capturou isso perfeitamente: "O processo de RMA se tornou um trabalho em tempo integral para duas pessoas. Toda devolução começa com um cliente nos enviando um e-mail, alguém aprovando manualmente e, em seguida, gerando uma etiqueta manualmente." No r/supplychain, um distribuidor em crescimento foi mais direto: o processo de devoluções estava "devorando eles" — fluxos de trabalho manuais de RMA, pesadelos de reconciliação de créditos com fornecedores e gargalos no armazém convergindo em escala. Estas não são reclamações sobre software ruim. Elas descrevem uma lacuna estrutural: o sistema de RMA de front-end gera dados que o sistema de back-end do armazém não consegue ingerir sem um intermediário humano redigitando cada campo.

Por que a Cadeia Digital Nunca Foi Completada

Esta não é uma história de negligência. É uma história de duas metades de um sistema evoluindo em velocidades diferentes, e a costura entre elas se tornando invisível de ambos os lados. A metade voltada para o cliente das devoluções passou por três ondas de digitalização na última década: primeiro, a migração de RMA por e-mail e telefone para portais de autoatendimento; segundo, a integração desses portais com transportadoras para geração automática de etiquetas; terceiro, a camada de IA para detecção de fraudes e incentivo a trocas. Loop Returns, ReturnGO e Happy Returns fazem parte dessa pilha evolutiva.

A metade voltada para o armazém seguiu um ritmo diferente. Os sistemas de gerenciamento de armazém (WMS) — Cin7, Fishbowl, ShipBob, SkuVault — foram construídos para otimizar a separação, embalagem e expedição, com o tratamento de devoluções adicionado como um módulo secundário. O fluxo de trabalho de devoluções na maioria das plataformas WMS pressupõe que alguém vai digitar os dados ou escanear um código de barras cujas informações já foram inseridas. Nenhuma das suposições se sustenta para um comprovante de RMA retirado de uma caixa.

A incompatibilidade estrutural é esta: os portais de devoluções geram dados em formatos criados para a experiência do cliente — e-mails personalizados, painéis do portal, APIs de rastreamento de transportadoras. Os sistemas WMS consomem dados em formatos criados para operações de inventário — transações em nível de SKU, atualizações de localização de bins, lançamentos contábeis. Não existe um adaptador padrão entre esses dois mundos, então cada armazém constrói o seu próprio: uma pessoa com um teclado.

O relatório de devoluções da NRF observa que 64% dos comerciantes dizem que atualizar seu processo de devoluções é uma prioridade. Mas o relatório foca quase exclusivamente no lado do cliente — taxas de devolução, conveniência de entrega, detecção de fraudes. A transferência de dados para o armazém é o problema das devoluções que não aparece nas pesquisas voltadas para o cliente, então não aparece nos roadmaps. Ele só aparece no P&L, enterrado nos custos de mão de obra e nas baixas de estoque.

Quanto a Digitação Realmente Custa

Se você processa 500 devoluções por dia com 75 segundos de entrada manual de dados cada, são 10,4 horas de trabalho dedicadas a uma tarefa que não produz nenhuma informação nova. Com base no salário médio de armazenagem de US$ 25,83 por hora do Bureau of Labor Statistics dos EUA de março de 2026, isso representa cerca de US$ 269 por dia, US$ 70.000 por ano — para um único turno. Para um 3PL operando dois turnos sete dias por semana, o valor se aproxima de US$ 200.000 anuais, sem considerar horas extras durante a alta temporada.

Mas a mão de obra é apenas o custo visível. Os invisíveis se acumulam silenciosamente:

Erros de digitação geram consequências em cascata. Um código do motivo digitado incorretamente — "defeituoso" em vez de "não serviu" — envia o item para a rota de devolução ao fornecedor em vez de devolvê-lo ao estoque, gerando custos de frete desnecessários e atrasando a reposição em dias. Um dígito de SKU trocado direciona o produto errado para a prateleira errada. Dados do setor sugerem que as taxas de erro na entrada manual de dados giram em torno de 1 a 4%, dependendo da complexidade do formulário. Para um formulário de RMA com 8 a 12 campos (número de RMA, número do pedido, nome do cliente, SKU, quantidade, código do motivo, condição, destinação), uma taxa de erro de 2% significa dez erros a cada 500 devoluções — cada um exigindo um ciclo de tratamento de exceção que leva mais tempo do que a entrada original.

Os reembolsos são atrasados pela latência dos dados. O cliente espera um reembolso em poucos dias após a leitura da transportadora indicar "entregue". Mas se os dados do RMA não foram inseridos no sistema, a equipe financeira não tem nenhum gatilho para iniciar o reembolso. A devolução fica em um limbo de processamento — fisicamente recebida, digitalmente invisível. De acordo com dados da NRF e da Happy Returns, 82% dos consumidores consideram as devoluções gratuitas importantes; 57% já abandonaram um varejista após uma experiência ruim de devolução. Uma experiência ruim de devolução é aquela em que o pacote desapareceu em um buraco negro. Esse buraco negro geralmente é apenas um formulário de papel em uma bandeja de entrada esperando pela digitação dos dados.

Os estornos de fornecedores dependem de dados de RMA que nunca foram digitalizados. Muitas devoluções são atribuídas a defeitos do fabricante. Quando um produto falha dentro da garantia, as notas de inspeção do formulário de RMA — código do motivo, condição, fotos — tornam-se a documentação de suporte para um débito ao fornecedor. Se essas notas permanecerem em papel, ou em um PDF que ninguém extrai para o ERP, o estorno não é registrado. De acordo com o Total Retail Loss Benchmark 2026 da Appriss Retail, cerca de US$ 100 bilhões em perdas evitáveis por fraude e abuso ocorreram em 2025, com o abuso de devoluções representando sozinho US$ 86 bilhões. Um processo de RMA baseado em papel que não consegue sinalizar padrões suspeitos de devolução em tempo real é uma lacuna que a fraude explora.

A precisão do estoque se degrada. Apenas cerca de 48% dos itens devolvidos são revendidos pelo preço total, de acordo com dados da Eightx de 2026. Os outros 52% precisam de decisões de roteamento — reformar, liquidar, devolver ao fornecedor, doar, destruir — que dependem dos dados de inspeção registrados no formulário de RMA. Se esses dados não estiverem no sistema, as decisões de roteamento seguem o caminho mais lento e seguro: "segurar para revisão", o que na prática significa que o item fica em uma área de espera de devoluções, perdendo valor a cada dia. A Optoro, uma plataforma de logística reversa que já processou mais de 100 milhões de devoluções, estima que os custos de processamento consomem 20 a 39% do preço original de um item — e uma parcela significativa desse custo é a mão de obra e o atraso introduzidos pelo manuseio manual de dados.

A Solução Não É Outro Portal

Se você rastrear todo o fluxo de dados do RMA — portal do cliente → leitura da transportadora → recebimento no armazém → inspeção → atualização do WMS → lançamento contábil → gatilho de reembolso → ajuste de estoque — cada etapa, exceto uma, já foi digitalizada e conectada por API. A única etapa que permanece manual é a extração de dados do próprio formulário de RMA para o sistema de armazém ou contabilidade. O formulário, independentemente de sua origem (PDF do portal, ficha de papel escaneada, autorização manuscrita), é o que se interpõe entre a devolução digital e o armazém digital. Feche essa lacuna, e toda a cadeia se torna automática.

Isso não é um problema de integração. Integração pressupõe que ambos os lados falem um protocolo comum. O formulário de RMA não fala protocolo algum — é um artefato visual. A solução é uma camada de extração entre o formulário e o sistema: algo que leia o conteúdo do formulário como um humano faria, mas que os produza como dados estruturados que o WMS, ERP ou planilha possam consumir diretamente.

É aí que a Extração de Colunas Personalizadas muda a equação. Em vez de desenhar caixas ao redor dos campos do formulário ou treinar um modelo em layouts de RMA de amostra — abordagens que quebram no momento em que um fornecedor altera o formato do formulário — você define o que deseja extrair nomeando as colunas: "Número de RMA", "Número do Pedido", "SKU", "Código do Motivo", "Condição", "Destinação". A IA lê o formulário semanticamente — ela entende que "RMA #" e "Número de Autorização" significam a mesma coisa, independentemente de onde na página cada um aparece. Ela não se importa se o formulário é um PDF gerado pelo Shopify, um ficha manuscrita escaneada ou uma autorização de devolução proprietária de um fornecedor com um layout completamente diferente. A saída é uma planilha estruturada cujos cabeçalhos de coluna correspondem às suas convenções de nomenclatura, pronta para importar em qualquer WMS ou sistema contábil.

Para um armazém que processa 500 devoluções por dia, isso reduz a etapa de entrada de dados de 10 horas para o tempo necessário para carregar um lote de formulários de RMA escaneados ou fotografados e clicar em "processar". Os dados extraídos não precisam ser redigitados, não acumulam erros de transcrição e fluem para a mesma planilha de rastreamento ou WMS que a equipe já usa. Para uma análise mais aprofundada de como isso se encaixa em um fluxo de trabalho de reconciliação de reembolsos, veja a análise em processamento em lote de formulários de RMA em uma única planilha de reconciliação.

E como os dados de RMA extraídos já estão estruturados — com SKUs, códigos de motivo e campos de destinação padronizados — alimentá-los em um sistema de inventário é uma importação direta, não um exercício de redigitação. O pipeline do formulário de RMA para o sistema de inventário se torna um feed, não um funil.

O ponto central: o problema do papel no RMA não é resolvido comprando um portal melhor ou atualizando seu WMS. Ele é resolvido desacoplando "ler o formulário" de "agir sobre os dados". Uma vez que essas duas etapas são separadas, o formulário pode ser qualquer coisa — PDF, escaneamento, foto, manuscrito — e os sistemas downstream não se importam, porque eles nunca veem o formulário. Eles veem uma planilha.

Onde os Dados Extraídos São Armazenados

A saída de uma extração de RMA não está vinculada a um único sistema. É uma planilha — XLSX, CSV ou direto para o Google Sheets. Para onde ela vai depende da sua pilha de tecnologia:

O padrão consistente: a camada de extração desacopla "ler o formulário" de "agir sobre os dados". Se os dados vão parar no NetSuite, ShipStation ou em um Google Sheet compartilhado é uma decisão downstream que não altera a configuração da extração. Uma única configuração de extração funciona em todos os destinos. Para complementar os dados de RMA com o processamento de faturas de fornecedores no mesmo fluxo de trabalho, veja processamento em lote de faturas de fornecedores em um livro-razão de estoque de e-commerce para entender como um único pipeline de extração pode lidar com vários tipos de documento alimentando o mesmo sistema de inventário.

Perguntas Frequentes

Funciona com formulários de RMA manuscritos?

Sim. A IA lê caligrafia — incluindo cursiva e letra de forma mista — compreendendo o conteúdo do que está escrito, não apenas reconhecendo caracteres. Um número de RMA ou código do motivo manuscrito em um formulário de papel é lido da mesma forma que um impresso. Dito isso, caligrafia extremamente ruim (ilegível para um humano) desafiará a IA, assim como desafiaria qualquer leitor. Caligrafia legível — do tipo que um funcionário de armazém consegue ler e redigitar — está dentro do alcance.

Posso importar os dados extraídos diretamente para o NetSuite / Shopify / meu WMS?

Sim, através do caminho de importação padrão de cada plataforma. A saída da extração é uma planilha estruturada (XLSX ou CSV), que todo WMS e ERP importantes suportam como formato de importação. Não é necessária integração de API personalizada. Mapeie suas colunas uma vez — Número de RMA → campo RMA do NetSuite, SKU → registro de inventário, Destinação → fila de roteamento — e reutilize o mesmo mapeamento para cada lote.

E se cada fornecedor usar um formato de formulário de RMA diferente?

Esse é o valor central da extração semântica. Como a IA lê pelo significado — e não pela posição ou modelo — o formato do formulário não importa. Se o Fornecedor A coloca o número de RMA no canto superior direito e o Fornecedor B o coloca em uma linha de cabeçalho de tabela, a lógica de extração é a mesma: encontrar os dados que correspondem ao conceito de "Número de RMA". O mesmo princípio se aplica ao processamento de faturas de fornecedores, onde a variação de formato entre fornecedores é a norma.

E quanto a fotos de RMA tiradas em um tablet ou celular do armazém?

Fotos são suportadas, assim como digitalizações e PDFs. Um funcionário do armazém pode fotografar o formulário de RMA com um tablet ou celular e enviar a imagem diretamente — a extração funciona a partir de fotografias, não apenas de digitalizações de alta resolução. Isso significa que a etapa de entrada de dados pode acontecer no cais de recebimento, na hora, sem encaminhar formulários de papel para uma central de entrada de dados.

Qual a precisão da extração em comparação com a entrada manual?

Textos impressos em layouts de formulários limpos atingem até 99% de precisão de reconhecimento. Formulários manuscritos e fotografias de baixa qualidade terão menor precisão, mas a comparação principal é com a entrada manual — que por si só tem uma taxa de erro estimada de 1 a 4%. A diferença é que os erros de extração são consistentes e revisáveis: você vê exatamente o que foi extraído campo por campo, e as correções são sinalizadas para revisão humana, em vez de se propagarem silenciosamente pelo sistema como um dígito digitado incorretamente faria.