Worldwide Express отдала спорные счета ИИ-агентам и сократила долг на 75%

Worldwide Express, американский брокер грузоперевозок с оборотом около $5 млрд в год, 130 000 клиентами и 75 перевозчиками сборных грузов (LTL, когда в фуре едут партии сразу нескольких заказчиков), отдала разбор спорных счетов ИИ-агентам. Проблема была приземлённой. Около 14% счетов от перевозчиков не проходят «трёхстороннюю сверку»: счёт должен совпасть с заказом и с актом приёмки груза. Каждый такой счёт превращается в спор, а пока спор не закрыт, деньги стоят. У компании в таких «исключениях» висело около $15 млн свободного денежного потока. С помощью AWS и интегратора LTM она построила мультиагентную систему на Amazon Bedrock, встроенную в её систему управления перевозками SpeedShip. Через полгода объём незакрытых споров упал до $4 млн.

Почему счета перевозчиков не сходятся

Споры делятся на три типа:

• Расхождения по строкам. Количество или код услуги в счёте не совпадает с записью о перевозке.
• Ценовые отклонения. Перевозчик выставил ставку, отличную от договорной.
• Неожиданные дополнительные сборы. Подъёмный борт, доставка на жилой адрес, пересчёт веса. В первоначальной смете этих сборов не было.

Прежде каждый случай шёл по пяти шагам: определить тип, найти причину в записях поставщика, написать перевозчику или на склад, ждать ответа, внести решение в систему. Работу вёл аутсорсинговый отдел, дело за делом, с телефонными звонками. У каждого перевозчика свои тарифы и свой порядок споров, так что отдел финансовых операций (FinOps) тонул в рутине.

Классическая роботизация процессов (RPA) здесь не годится: она хороша для жёстких сценариев. А тут нужно прочитать политику перевозчика, сопоставить сбор с фактом доставки и решить, законен ли он при данной сумме. Это работа с текстом и контекстом, поэтому выбрали агентов на языковых моделях.

Три агента и база правил по каждому перевозчику

Спор попадает к одному из трёх специализированных агентов:

• Invoice Matching Agent находит запись о перевозке, к которой относится счёт, и отмечает, что не сходится.
• Pricing Variance Agent сравнивает выставленную цену с договорной и решает, оправдана ли разница.
• Accessorial Validation Agent проверяет, подтверждаются ли дополнительные сборы реальными событиями доставки: был ли подъёмный борт, был ли жилой адрес.

У каждого агента есть инструкция (роль, границы решений, формат ответа), набор действий в SpeedShip и доступ к базе знаний. В базе лежат тарифные правила, определения сборов, порядок споров и допустимые пороги отклонений каждого перевозчика. Перед решением агент подтягивает документы именно этого перевозчика. Поэтому те же три агента работают со всеми 40+ подключёнными перевозчиками, и отдельного кода под каждого не пишут.

С инженерной стороны решения аккуратные. Оркестрацию компания собрала сама на серверах Amazon EC2 с автомасштабированием, а Bedrock использует только для вызова моделей через единый API. Логика маршрутизации остаётся у команды, и можно брать открытые библиотеки для агентов. Агенты ходят в SpeedShip через те же API, что и аналитики, так что видят те же договорные ставки, данные перевозки и подтверждения доставки. После решения система пишет понятную заметку: что нашли и что сделали. Для споров о деньгах такая объяснимость обязательна.

Человека не убрали. Сначала сотрудник подтверждал каждую рекомендацию в привычном интерфейсе. Когда точность превысила 99%, основным режимом стало массовое подтверждение. Отказы логируются, и команда по ним правит инструкции и базы знаний. Метрики на дашбордах: доля автоматизации по перевозчикам, ошибки по типам споров, время решения, частота переопределений человеком.

Цифры и что в них стоит перепроверить

Заявленные результаты за шесть месяцев:

• Агенты закрывают около 10 000 споров в неделю, это примерно половина потока. Ошибок меньше 1%.
• Незакрытые споры упали с $15 млн (июнь 2025) до $4 млн.
• Срок превращения заказа в деньги сократился на 4 недели.
• Экономия — свыше $1 млн в год, заявленная окупаемость в первый год — 60-кратная, единоразовый приток денежного потока — $10 млн.

Это пост в блоге самого AWS, и числа в нём не вполне стыкуются. Доля автоматизации указана как «около 50%» и как «более 40%». Прирост в $10 млн назван и единоразовым освобождением денег, и еженедельным объёмом счетов, обработанных быстрее. Падение с $15 млн до $4 млн на деле составляет 73%, а не ровно 75%. Не названы модель под капотом и стоимость вызовов, хотя экономику проекта в основном определяет именно она. «Ошибкой» считается, видимо, то, что отвергнул проверяющий, а ошибки, которые он пропустил при массовом подтверждении, этой цифрой не охвачены.

Тем не менее схема для логистики и любых компаний с потоком счётов выглядит переносимой. Начните с самого частого типа спора и докажите точность на нём. Храните правила контрагентов как документы для поиска, не вшивайте в код. Пускайте агента в те же API, что и людей, оставьте человеку подтверждение, пока метрики не покажут стабильную точность. Компания уже переносит подход на другие части цикла «от заказа до оплаты».