Суть задачи

Три документа отвечают на разные вопросы

Заказ показывает, что компания собиралась купить. Накладная фиксирует то, что поставщик передал по документам. Счёт содержит требование оплатить конкретные позиции и суммы. Когда все три файла лежат рядом, кажется, что достаточно попросить нейросеть «сверить поставку». Но в каждом документе могут быть свои коды, сокращения названий, упаковки и версии цен. Поставщик мог заменить позицию по согласованию, привезти часть заказа или выставить счёт раньше приёмки. Задача ИИ — не подтвердить оплату, а выделить расхождения, приложить точные строки и составить вопросы ответственным людям. Решение об акцепте остаётся у сотрудника, который знает договор и фактическую приёмку.

Исходные данные

Подготовьте пример, в котором возможна ошибка

Для пилота достаточно десяти строк из одного заказа. Возьмите исходный заказ с датой и номером, накладную, счёт и документ с согласованными заменами, если он есть. Сохраните копии в защищённой рабочей папке. Уберите банковские реквизиты и персональные контакты, если они не нужны для сверки; не загружайте чувствительные документы в сервис без проверки договора обработки данных. Каждому файлу дайте понятное имя и номер версии. Если документ сфотографирован, сначала проверьте читаемость: ошибка распознавания цифры «8» как «3» создаст ложное расхождение, которое затем будет казаться математическим. Исходные изображения оставьте нетронутыми.

Рабочий маршрут

Превратите документы в строки одного формата

Попросите модель извлечь из каждого документа идентификатор позиции, наименование, единицу, количество, цену за единицу, общую сумму и ссылку на страницу или строку. Поле, которого нет, должно остаться пустым; запрещайте системе подставлять значение из соседней позиции. Для упаковок добавьте отдельный коэффициент: коробка из двенадцати штук не равна одной штуке, хотя название товара совпадает. Проверьте первые и последние две строки вручную. После этого сопоставляйте позиции по коду, а название используйте как дополнительную проверку. Если коды различаются, не позволяйте модели окончательно «склеить» строки только по сходству слов.

Проверка

Сверьте четыре типа расхождений

Первое — количество: заказали двадцать, в накладной восемнадцать. Второе — цена: цена за единицу изменилась, хотя количество совпало. Третье — состав: новая позиция присутствует в счёте, но отсутствует в заказе и акте согласования. Четвёртое — арифметика и налог: произведение количества на цену не даёт указанной суммы либо налог рассчитан по иному основанию. Для каждого флага нужен не общий красный значок, а пара конкретных значений и источник. Если сумма выглядит странно из-за скидки на весь заказ, это не доказательство ошибки. Модель должна отметить возможное объяснение и оставить его на проверку, а не выбирать удобную версию.

Практический пример

Пример: похожие строки с разной упаковкой

Компания заказала сорок ламп поштучно. В накладной стоят четыре коробки по десять, а в счёте — сорок единиц. На первый взгляд документы расходятся в десять раз. После явного перевода единиц количество совпадает. Но проверка не окончена: маркировка модели, цветовая температура и цена за штуку должны соответствовать заказу. Если одна коробка содержит другую модель, суммарное количество всё ещё равно сорока, а поставка неверна. Здесь ИИ полезен как помощник в нормализации полей, но человеку нужно сверить маркировку с принятыми коробками и сделать отметку в системе учёта.

Риски

Не включайте автоматическую оплату в пилот

Даже точное извлечение строк не даёт модели полномочия отправлять деньги. Настройте только отчёт: «совпало», «требует проверки», «не хватает документа». Для сомнительных строк добавьте кнопку перехода к исходной странице, имя ответственного и статус решения. Если накладная подписана, но товары ещё не пересчитаны физически, отчёт обязан показывать эту неопределённость. Согласование поставки и финансовое разрешение — разные роли. При большом потоке можно измерить, какие классы расхождений модель находит стабильно, и только затем думать об автоматизации дальнейшего шага.

После запуска

Как измерить пользу без красивых отчётов

Возьмите двадцать закрытых поставок, в которых бухгалтер уже отметил реальные исправления. Запустите новый маршрут без подсказки, где ошибки. Считайте долю пропущенных расхождений, число ложных тревог и время до принятого решения, включая ручную проверку. Цена токенов редко главная: дорогие минуты возникают, когда сотрудник ищет несуществующую ошибку без ссылки на строку. Сопоставьте результат с прежним ручным процессом. Если система хорошо ловит арифметику, но путает упаковки, оставьте узкое применение вместо заявления «сверка закупок автоматизирована». Тему контроля исходных сумм продолжает наш <a href="/materialy/smeta-remonta-ofisa-ii-proverka-20261025-b1">разбор сметы ремонта</a>.

Внедрение

Вывод и вопросы

Хорошая сверка оставляет понятную таблицу расхождений, а не вердикт от чат-бота. Документы должны быть доступны для повторной проверки, преобразования единиц — явными, а оплата — только после подтверждения уполномоченным человеком. Можно ли сравнивать сканы? Да, после отдельной проверки распознавания. Что делать с согласованной заменой? Приложить подтверждение и связать её с исходной строкой. Можно ли принимать решение по совпадению общей суммы? Нет, неверный состав может дать ту же сумму. Когда пилот успешен? Когда он сокращает полный цикл сверки без роста пропусков и ложных тревог. Дополнительный принцип назначения владельца процесса описан в <a href="/materialy/pervyi-process">материале о первом внедрении</a>.

← Все материалы