С какой проблемы начать
В небольшой компании счёт приходит в почту, договор лежит в общей папке, а акт подписывается в другой системе. Сотрудник сравнивает их глазами под конец дня и легко пропускает смену расчётного счёта, лишнюю строку услуги или другой период. Задача ИИ здесь узкая: подготовить список несовпадений между конкретными версиями документов. Модель не должна решать, можно ли платить, и тем более нажимать кнопку отправки. Заранее назначьте владельца договора и бухгалтера, который окончательно сверит основание, сумму и реквизиты. Без такого распределения даже аккуратная автоматизация ускорит передачу ошибки дальше.
Подготовьте комплект, а не один файл
Для первого пилота возьмите пять закрытых случаев из архива и удалите персональные данные, не нужные для проверки. На каждый случай соберите договор с приложениями, заказ или спецификацию, счёт и акт, если он уже есть. Укажите номер редакции каждого документа. Если приложение упомянуто, но отсутствует, модель должна остановиться и назвать нехватку, а не восстановить типовые условия по памяти. Проверьте OCR сканов: цифра 8 похожа на 3, а знак валюты иногда пропадает. До запуска попросите человека подтвердить, что комплект относится к одной сделке и одному периоду.
Задайте таблицу сравнения
В запросе перечислите поля: поставщик и юридическое лицо, договор и дата, период услуги, наименование, количество, единица измерения, цена без и с налогом, итог, банковские реквизиты и валюта. Для каждого поля требуйте цитату, страницу либо номер строки из каждого документа и статус: совпадает, отличается, не найдено. Запретите модели самостоятельно менять документы и придумывать недостающий реквизит. Отдельной колонкой пусть пишет вопрос сотруднику. Такая таблица полезнее ответа «всё выглядит нормально», потому что её можно открыть рядом с первичными файлами и проверить по пунктам.
Определите опасные расхождения
Не все отличия одинаковы. Сдвиг пробела в названии услуги и новые банковские реквизиты требуют разных реакций. Составьте три уровня: техническое оформление, вопрос владельцу заказа и стоп перед оплатой. К последнему обычно относятся другой получатель, сумма сверх утверждённого лимита и услуга вне подписанной спецификации. Но конкретные пороги утверждает компания, а не модель. Если поставщик прислал письмо о смене реквизитов, проверяйте его по независимому известному каналу связи. Нельзя считать письмо доказательством лишь потому, что оно приложено к счёту.
Пример одного прохода
Предположим, в договоре указаны 20 часов поддержки по фиксированной цене, а в счёте стоят 24 часа и новая строка «срочная обработка». Модель должна вывести обе цитаты, посчитать разницу, отметить отсутствующее дополнительное соглашение и предложить вопрос владельцу договора. Неправильный результат — уверенное объяснение, что перерасход «вероятно согласован устно». После проверки специалист либо находит подписанный документ, либо запрашивает корректировку. Не заставляйте бухгалтерию выяснять коммерческие условия без владельца процесса: это организационный сбой, который ИИ не устранит.
Права и конфиденциальность
Счёт содержит реквизиты и иногда данные физических лиц. Перед выбором инструмента уточните, где хранятся загруженные файлы, кто видит историю и можно ли удалить материал. Для пилота используйте изолированную папку и учётную запись только с чтением. Не подключайте рабочую платёжную систему к экспериментальному агенту. Храните журнал: какие версии загружены, что отметила модель и кто подтвердил итог. По той же логике полезна проверка ответов на нашем сайте: машинный вывод должен иметь конкретный источник, а не просто уверенный тон.
Как измерить пользу
Сравните десять обычных проверок без ИИ и десять с ним. Считайте не только минуты на составление таблицы, но и время исправления ложных тревог. Главная метрика — сколько существенных несовпадений было найдено и сколько пропущено. Для контроля заранее внесите в несколько учебных копий известные ошибки: неправильный период, другую валюту, пропущенное приложение, смену получателя. Если модель пропускает критический случай, пилот не готов к масштабированию даже при большом выигрыше по времени. Обобщать результат на всех поставщиков после одной аккуратной папки нельзя.
Решение и следующий шаг
Заканчивайте не фразой «счёт одобрен ИИ», а подписанным человеком чек-листом: комплектность, сверка полей, объяснение расхождений, подтверждение реквизитов и разрешение на платёж. Сохраните минимальный набор тестовых случаев для повторной проверки после обновления модели. Если сегодня нужен только порядок в файлах, начните с материала о первом процессе внедрения, а не с интеграции агента. Автоматизировать стоит устойчивый маршрут, где понятно, кто отвечает за остановку, исправление и окончательное решение.
Проверка после смены поставщика
Когда у компании меняется поставщик или способ оплаты, повторно протестируйте маршрут на новом комплекте документов. Старые правила сопоставления реквизитов могут принять непривычный формат за ошибку либо, наоборот, пропустить новый риск. Разберите с бухгалтером три случая: корректная смена юридического лица с подписанным соглашением, письмо без подтверждения и счёт с похожим названием компании. Запишите, какой документ нужен для разрешения каждого случая. Модель может подсветить отличие, но не должна утверждать подлинность письма или банковского счёта. Перед первой реальной оплатой новый маршрут проходит независимую ручную проверку.
Почему полезна выборочная ручная перепроверка
После запуска не ограничивайтесь просмотром только тех счетов, которые модель отметила как подозрительные. Выбирайте случайную долю документов со статусом «совпадает»: именно там могут скрываться тихие пропуски. Бухгалтер отмечает, нашёл ли он несовпадение, какой документ был решающим и изменилась ли сумма к оплате. Раз в месяц пересматривайте этот журнал вместе с владельцем закупок. Если доля пропусков растёт после смены шаблона поставщика или сканера, верните все счета этого потока на ручную проверку до настройки маршрута. Это не наказание модели, а нормальный предохранитель процесса с реальными деньгами.