Worldwide Express entrega contas contestadas a agentes de IA e reduz dívida em 75%

A Worldwide Express, corretora americana de fretes com faturamento de cerca de $5 bilhões por ano, 130 000 clientes e 75 transportadoras de cargas fracionadas (LTL, em que o caminhão leva lotes de vários embarcadores ao mesmo tempo), passou a análise de faturas contestadas para agentes de IA. O problema era bem concreto. Cerca de 14% das faturas das transportadoras não passam na "conciliação tripla" (three-way match): a fatura precisa bater com o pedido e com o comprovante de recebimento da carga.

Cada fatura nessa situação vira uma disputa, e enquanto a disputa não é encerrada, o dinheiro fica parado. Nessas "exceções", a empresa tinha cerca de $15 milhões de fluxo de caixa livre travados. Com a AWS e a integradora LTM, ela montou um sistema multiagente no Amazon Bedrock, integrado ao seu sistema de gestão de transportes, o SpeedShip.

Seis meses depois, o volume de disputas em aberto caiu para $4 milhões.

Por que as faturas das transportadoras não batem

As disputas se dividem em três tipos:

• Divergências por linha. A quantidade ou o código do serviço na fatura não coincide com o registro do embarque.
• Desvios de preço. A transportadora cobrou uma tarifa diferente da contratada.
• Taxas adicionais inesperadas. Plataforma elevatória, entrega em endereço residencial, recálculo de peso. Essas taxas não estavam no orçamento inicial.

Antes, cada caso passava por cinco etapas: identificar o tipo, encontrar a causa nos registros do fornecedor, escrever para a transportadora ou para o armazém, esperar a resposta e lançar a decisão no sistema. O trabalho era feito por uma equipe terceirizada, caso a caso, com ligações telefônicas. Cada transportadora tem tarifas e um procedimento de disputa próprios, e por isso o setor de operações financeiras (FinOps) se afogava em tarefas repetitivas.

A automação robótica de processos (RPA) não serve aqui: ela funciona bem para cenários rígidos. Neste caso, é preciso ler a política da transportadora, comparar a taxa com o que de fato aconteceu na entrega e decidir se a cobrança é legítima para aquele valor. É um trabalho de texto e contexto, e por isso a escolha recaiu sobre agentes baseados em modelos de linguagem.

Três agentes e uma base de regras para cada transportadora

A disputa é encaminhada a um de três agentes especializados:

• Invoice Matching Agent localiza o registro do embarque ao qual a fatura se refere e aponta o que não bate.
• Pricing Variance Agent compara o preço cobrado com o contratado e decide se a diferença se justifica.
• Accessorial Validation Agent verifica se as taxas adicionais são confirmadas por eventos reais de entrega: se houve plataforma elevatória, se o endereço era residencial.

Cada agente tem uma instrução (papel, limites de decisão, formato de resposta), um conjunto de ações no SpeedShip e acesso a uma base de conhecimento. A base reúne as regras tarifárias, as definições de taxas, o procedimento de disputa e os limites de desvio aceitáveis de cada transportadora. Antes de decidir, o agente busca os documentos daquela transportadora específica. Por isso, os mesmos três agentes atendem todas as mais de 40 transportadoras conectadas, sem código separado para cada uma.

Do ponto de vista de engenharia, as decisões são bem pensadas. A empresa montou a orquestração por conta própria, em servidores Amazon EC2 com escalonamento automático, e usa o Bedrock apenas para chamar os modelos por meio de uma API única. A lógica de roteamento fica com a equipe, e é possível usar bibliotecas abertas para agentes. Os agentes acessam o SpeedShip pelas mesmas APIs que os analistas, e por isso enxergam as mesmas tarifas contratuais, os mesmos dados do embarque e as mesmas confirmações de entrega. Depois da decisão, o sistema escreve uma nota clara: o que encontrou e o que fez. Em disputas que envolvem dinheiro, essa explicabilidade é indispensável.

O humano não saiu do processo. No início, um funcionário confirmava cada recomendação na interface habitual. Quando a precisão passou de 99%, a confirmação em lote virou o modo principal. As rejeições são registradas, e a equipe usa esses registros para ajustar instruções e bases de conhecimento. As métricas nos dashboards são: taxa de automação por transportadora, erros por tipo de disputa, tempo de resolução e frequência de substituição da decisão pelo humano.

Os números e o que vale conferir neles

Resultados declarados em seis meses:

• Os agentes resolvem cerca de 10 000 disputas por semana, aproximadamente metade do fluxo. Menos de 1% de erros.
• As disputas em aberto caíram de $15 milhões (junho de 2025) para $4 milhões.
• O prazo para transformar um pedido em dinheiro diminuiu 4 semanas.
• Economia superior a $1 milhão por ano, retorno declarado de 60 vezes no primeiro ano e entrada única de $10 milhões no fluxo de caixa.

O texto é um post no blog da própria AWS, e os números nele não fecham por completo. A taxa de automação aparece como "cerca de 50%" e como "mais de 40%". O ganho de $10 milhões é descrito tanto como uma liberação única de caixa quanto como o volume semanal de faturas processadas mais rápido. A queda de $15 milhões para $4 milhões equivale, na prática, a 73%, e não exatamente a 75%. O modelo usado e o custo das chamadas não são informados, embora a economia do projeto dependa sobretudo deles. Como "erro", ao que parece, conta apenas o que o revisor rejeitou; os erros que ele deixou passar na confirmação em lote não entram nesse número.

Mesmo assim, o esquema parece transferível para a logística e para qualquer empresa com grande fluxo de faturas. Comece pelo tipo de disputa mais frequente e comprove a precisão nele. Guarde as regras dos fornecedores como documentos para busca, sem embuti-las no código. Dê ao agente acesso às mesmas APIs que as pessoas usam e mantenha a confirmação humana até que as métricas mostrem precisão estável. A empresa já está levando a abordagem para outras etapas do ciclo "do pedido ao pagamento".