Три ШІ-агенти розібрали завали в рахунках перевізників

Звідки бралися завали: три типи розбіжностей

У перевезенні збірних вантажів (LTL), за даними AWS, приблизно 14% рахунків не проходять стандартну тристоронню звірку: замовлення на закупівлю, підтвердження отримання і рахунок перевізника. Кожен такий рахунок іде на ручний розбір. У Worldwide Express (входить до ShipStation Global; понад 75 перевізників, понад 130 тис. клієнтів) розбіжності ділились на три типи:

• Невідповідність позицій: кількість або код послуги не збігається із записом про відвантаження.
• Цінова розбіжність: перевізник виставив тариф, відмінний від договірного.
• Неочікувані додаткові збори: за гідроборт, доставку на приватну адресу чи перезважування, яких не було в початковому розрахунку.

Ручний процес мав п'ять кроків: визначити тип розбіжності, знайти причину в записах постачальника, написати перевізнику чи складу, чекати відповіді, провести рішення в системі. Цим займалась зовнішня команда, яка розбирала випадки по одному. За словами компанії, щомісяця в неврегульованих розбіжностях стояло $15 млн вільного грошового потоку.

З чого складається кожен агент

Кожен із трьох агентів закриває свій тип розбіжності й має три складники: інструкцію (роль, межі рішення, формат відповіді), набір дій у транспортній системі SpeedShip і доступ до бази знань перевізника. Агенти працюють через ті самі API, що й аналітики, тобто бачать те саме: договірні тарифи, дані відвантаження, підтвердження доставки. У базі знань для кожного перевізника зберігаються тарифні правила, визначення зборів, порядок оскарження і допустимі пороги відхилень. Тому одні й ті самі три агенти обслуговують усіх перевізників без окремого коду під кожного.

Структуру інструкції можна взяти як шаблон для власного пілоту:

Роль: перевіряєш додаткові збори в рахунку перевізника. Межі: підтверджуєш збір лише якщо він є в правилах цього перевізника і підтверджений подіями доставки; інакше повертаєш людині. Формат: тип розбіжності, знайдене, рекомендована дія, пояснення простою мовою.

Після закриття розбіжності система пише коротку нотатку простою мовою: що знайдено і яку дію виконано. У джерелі це прямо пов'язано з вимогою, щоб кожне автоматичне рішення в спорах за рахунками можна було пояснити.

Людина в контурі і як знижували помилки

На старті кожну рекомендацію затверджував рецензент у звичному інтерфейсі SpeedShip: за даними джерела, без цього фінансова команда не прийняла б систему. Коли точність перевищила 99%, типовим режимом стало пакетне затвердження, тобто людина вже не переглядає кожне рішення окремо.

Команда відстежувала частку автоматизації за перевізниками, частку помилок за типами розбіжностей, час розгляду й частоту, з якою людина скасовує рішення агента. Кожну відхилену рекомендацію логували, а інструкції й бази знань доопрацьовували за історією відмов. Перш ніж переходити на пакетне затвердження у себе, варто мати ці самі показники.

Межі прийому і що перевірити в цифрах

• Підхід працює там, де правила контрагента задокументовані. Без тарифів, визначень зборів і порогів агенту нема на що спертися.
• Порада з джерела: почати з найповторюванішого типу розбіжності, довести точність, потім розширювати.
• Результати, за даними компанії: ~10 тис. розбіжностей на тиждень (близько 50%), помилок менше 1%, залишок розбіжностей зменшився з $15 млн (червень 2025) до $4 млн за пів року. $10 млн вивільненого грошового потоку — разовий ефект, а не щорічний. Окремо компанія називає понад $1 млн економії на рік, 60-кратну окупність у перший рік і прискорення надходження грошей на чотири тижні.
• Віцепрезидент з FinOps у цитаті говорить про автоматизацію «понад 40%» щотижневих розбіжностей, а в розділі результатів стоїть близько 50%. Поточна частка залежить від того, як її рахувати.

Матеріал опубліковано в блозі AWS, тобто це опис кейсу самим постачальником. Вартості впровадження в ньому немає, тому окупність (60x) перевірити неможливо.