ИИ-проверка счетов поставщиков: от расхождения до учётной записи.

Внешний опыт · источник проверен 06.11.2026

Что известно о результате Fugro — и чего из него не следует.

В опубликованном кейсе Rossum для Fugro поставщик сообщает о снижении среднего времени обработки счёта с двух минут до 35 секунд и автоматизации 70% счетов. В описании указан поток около 300 000 счетов в год. Это результаты названного внешнего внедрения, опубликованные его поставщиком. Они не являются результатами BORNLI, независимой экспертизой или обещанием эффекта для небольшого пилота; период сравнения на странице не указан.

Полезный вопрос для своего проекта — где именно уходит время. Если сотрудник быстро переносит реквизиты, но долго выясняет причину расхождения, новое распознавание само по себе не устранит задержку. Ниже показываем собственную демонстрацию этого узкого участка.

Модельный сценарий · концепция BORNLI

Один счёт, исходное письмо и понятная причина проверки.

Для статьи мы собрали демонстрационный кабинет проверки счетов. Документы, поставщики и события в нём условные; реальная 1С не подключена. Сценарий начинается со счёта INV-2048: поставщик указал 24 монтажных комплекта по 450 ₽, всего 10 800 ₽. В связанной приёмке RCV-018 отмечено 20 комплектов. Налоговый расчёт и оплата находятся вне этого примера.

В очереди контролёр видит не только статус «Проверить», но и причину: «24 в счёте / 20 принято». В карточке сохраняются исходное письмо, вложение, заказ, приёмка и ответственный. Так сотрудник начинает с конкретного вопроса, а не открывает все файлы подряд.

Для пилота предложим заранее определить признаки повторного документа. Одного похожего имени файла недостаточно: нужно согласовать проверку поставщика, номера, даты, суммы и версии. Совпадение становится поводом для проверки, а не основанием незаметно удалить входящий файл.

Обработка и сопоставление

Число распознано верно. Счёт всё равно требует решения.

Слева в концепте показан исходный документ, справа — извлечённые значения и сравнение с заказом и приёмкой. В счёте действительно написано 24. Ошибки распознавания здесь нет: расходятся документы. AI не должен молча заменить 24 на 20, чтобы получить удобный результат.

У каждой проверки должен быть свой исход. Если не найден заказ — попросить связать документ. Если не определена единица измерения — показать возможное соответствие сотруднику. Если количество отличается от приёмки — оставить передачу заблокированной до решения. Для каждой строки нужно сохранить, откуда взято значение и что изменил проверяющий.

Этот процесс связан со складом, но решает другую задачу: склад фиксирует фактическую приёмку, финансовая команда решает, можно ли передать счёт дальше. Если сам факт приёмки ещё не ведётся последовательно, сначала стоит разобрать складские операции и обмен с учётом. Нельзя компенсировать отсутствующий источник уверенным ответом модели.

Решение сотрудника

Исправленный документ — новая версия, а не затёртая старая.

В нашем сценарии контролёр запрашивает корректировку. Поставщик присылает версию 2 того же счёта: 20 комплектов по 450 ₽, всего 9 000 ₽. Исходная версия остаётся в истории. Это выбранное развитие модельного примера, а не правило для любого расхождения: в реальной ситуации причина может быть в неполной приёмке или другом документе.

Контролёр сравнивает версии, проверяет основание и подтверждает именно v2. До этого новый файл остаётся на проверке. Если после подтверждения снова меняются количество, сумма или источник, предлагаем требовать нового решения: прежняя подпись не должна автоматически разрешать передачу изменённых данных.

В демонстрации кнопка подтверждения требует отметку о проверке и заполненное основание. Решение «Поставщик прислал исправленный счёт» связывается с конкретной версией. Проверка счёта в этом пилоте не означает разрешения на оплату: права на платёж и соответствующий процесс оцениваются отдельно.

Передача и восстановление

Ответ потерялся. Отправлять ещё один счёт рано.

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

Предлагаем сохранять ключ операции, связанную версию и результат обмена. В демонстрации ключ inv-2048-v2 позволяет проверить, не создана ли запись ранее. Поиск возвращает условную DEMO-081, поэтому повторный документ не появляется. Это имитация обмена, а не доказанная интеграция с вашей 1С.

До реализации нужно проверить, умеет ли принимающая система искать результат по согласованному идентификатору и предотвращать дубли. Если нет, автоматическую повторную отправку после неопределённого ответа следует остановить и передать разбор сотруднику. Наличие API само по себе не подтверждает безопасность повтора.

Польза и измерение

Сначала проверяем исход операции. Затем считаем эффект.

Итог демонстрации ограничен одной операцией: сохранены обе версии INV-2048, контролёр подтвердил v2 на 9 000 ₽, после проверки потерянного ответа найдена одна модельная запись DEMO-081. Эти числа описывают условные документы. Они не показывают экономию, выручку или успешное внедрение у клиента BORNLI.

Для оценки пилота предлагаем обработать одинаковый обезличенный набор документов вручную и через новый процесс. Отдельно учесть нормальные документы, расхождения и сбои. Начинать измерение нужно до автоматизации, иначе сравнивать будет не с чем.

В протоколе нашего концепта стоит «Измерение не начато». Экономию пока не заявляем. В будущий расчёт нужно включить стоимость сервисов, проверку исключений и сопровождение: сокращение времени ввода ещё не равно снижению всех расходов.

Границы пилота

Один тип документа, одна принимающая система, проверяемые исключения.

Первый объём удобнее ограничить одним потоком счетов и понятным способом передачи. Автоматическую оплату, смену реквизитов поставщика, налоговые решения и работу с несколькими юридическими лицами не следует незаметно включать в тот же пилот: это отдельные правила, права и проверки.

1. Опишите вход. Откуда приходят документы, какие типы и форматы нужно разобрать.
2. Назовите учётную систему. Конфигурация, версия, способ обмена и наличие тестовой среды.
3. Дайте правила проверки. Как связываются счёт, заказ и приёмка; кто решает спорные случаи.
4. Подготовьте обезличенные примеры. Обычный счёт, дубль, новая версия, неясная единица и расхождение количества.
5. Согласуйте приёмку. Какие ошибки блокируют передачу, как проверяется повтор и кто отвечает за восстановление.

По этим материалам можно спроектировать демонстрацию и оценить конкретный объём. Стоимость и срок AI-проекта не выводятся из цены типового мобильного приложения. Опишите процесс проверки счетов в форме BORNLI — для первого обсуждения достаточно задачи и названия системы, без реальных счетов и банковских реквизитов.