Автоматизация проверки первичной документации: от штучного кейса клиента до запуска SaaS
Бывает, что работа над конкретной задачей клиента подсвечивает проблему, общую для всего рынка. В этой статье мы расскажем, как автоматизировали проверку 25 000 документов в месяц и почему решили превратить это решение в самостоятельный сервис после того, как заказчик поставил проект на паузу.
Исходные данные и задача
Процесс одного из наших клиентов завязан на обработку более чем 5 000 комплектов документов в месяц. В каждом комплекте — 4–5 документов (акты, накладные, счета, договоры). Итого — до 25 000 единиц первичной документации ежемесячно.
До автоматизации всё проверялось вручную. Десять сотрудников отдела документооборота вычитывали каждый лист, проверяя:
- Комплектность (все ли документы на месте).
- Наличие подписей и печатей.
- Корректность реквизитов и отсутствие расхождений между документами в связке.
- Указан неверный представитель принимающей стороны.
Проверять их вручную было экономически неэффективно - сотрудники вычитывали каждый документ.
Если комплект не соответствовал требованиям, его возвращали на переоформление.
В среднем фиксировалось около 150 возвратов в месяц — это примерно 3% комплектов.
У части заказчиков действовали собственные требования к оформлению, которые необходимо учитывать при проверке.
Проблема
Руководство понимало, что текущая модель — это операционный риск и источник неэффективности.
Ресурсная нагрузка:
- 10 сотрудников полностью заняты ручной проверкой;
- высокая стоимость процесса за счёт ФОТ;
- масштабирование только через увеличение штата;
- монотонная работа и выгорание;
- отсутствие дифференциации задач по квалификации;
- зависимость от доступности каждого сотрудника.
Человеческий фактор и проблемы ручного подхода:
3% комплектов с ошибками — это только выявленные случаи.
Пропущенные ошибки означают:
- риск штрафов при налоговой проверке;
- риск задержки признания выручки и поступления денежных средств.
В пиковые периоды возникали задержки обработки, что влияло на скорость получения денег.
Решение, которое мы разработали
Мы спроектировали систему автоматизированной AI-проверки первичной документации как первый уровень контроля перед финальной верификацией человеком.
Архитектура предполагала:
- проверку каждого документа в составе комплекта;
- формирование протокола с конкретными замечаниями;
- передачу сотруднику списка проблем для решения.
Система должна была:
- распознавать текст и идентифицировать контрагента;
- находить требования заполнения в базе знаний;
- проверять комплектность;
- валидировать обязательные реквизиты в соответствии с Федеральный закон № 402-ФЗ (ст. 9);
- проверять наличие подписей и, при необходимости, печатей;
- сверять реквизиты между документами комплекта;
- формировать структурированный протокол.
Если система не уверена — документ маркируется как требующий ручной проверки.
Пилот и промежуточные результаты
Мы реализовали пилот и протестировали архитектуру на реальных документах.
На этапе пилота сотрудники параллельно продолжали ручную проверку — чтобы валидировать результаты системы.
Через несколько недель:
- точность по обязательным реквизитам и комплектности достигла 99,8%;
- система выявляла на 3–5% больше ошибок, чем фиксировалось при полностью ручной проверке;
- удалось формализовать проверку — она перестала быть личной ответственностью сотрудника.
Технологически гипотеза подтвердилась.
Проект не перешёл в масштабное внедрение
На этом этапе клиент принял решение временно приостановить проект из-за внутренних реорганизаций и смены приоритетов. Это не было связано с качеством решения или результатами пилота — скорее с управленческим контекстом и изменением фокуса внутри бизнеса.
Однако технические результаты были слишком убедительными, чтобы оставить разработку «в столе».
Для нас это стало важной точкой.
Мы увидели, что:
- проблема типовая и системная;
- архитектура работает;
- эффект измерим;
- зависимость от одного корпоративного внедрения — ограничивает скорость развития продукта.
Что произошло дальше
Мы увидели, что логика, заложенная в проект, универсальна. Мы очистили решение от специфики конкретного заказчика и переработали его в независимый сервис DokFlow.
Мы переработали архитектуру:
- вынесли логику проверки в универсальный конфигурируемый слой;
- стандартизировали протоколы;
- доработали масштабируемость и отказоустойчивость;
- отделили продуктовый контур от конкретной ИТ-инфраструктуры клиента.
Теперь это не кастомная разработка под одну компанию, а сервис, который можно подключить к 1С, Битрикс или любой другой системе.
Как устроено под капотом
Решение реализовано как последовательный поток обработки документов.
1. Получение пакета документов
Согласование с разработчиками 1С механизма пакетной отправки документов и получение статуса обработки. Используем REST: один POST-запрос с типом multipart/form-data, содержащий массив PDF-файлов.На сервере развернут FLASK и асинхронная обработка в фоновых задачах (workers) Celery.
2. Подготовка к распознаванию
Для устойчивого результата при анализе используется двойная обработка: исходный PDF и изображения страниц (PNG). Это повышает точность распознавания подписей и печатей.
Прототип собрали на n8n, но для большей гибкости и масштабируемости продуктовый контур выполнили на Python + OpenAI.
3. Формализованный чек-лист
Логика проверки задается конфигурационно:
- список обязательных документов;
- требования к подписям и печатям;
- перечень реквизитов и правила соответствия договору.
Проверка перестаёт быть «в голове сотрудника».
4. AI-анализ
Каждый документ анализируется автоматически:
- распознаются номера, даты, ИНН;
- фиксируется наличие подписи и печати;
- выявляются типовые несоответствия.
Ответ валидируется и агрегируется по комплекту.
Для финальной обработки в prompt добавили жесткое ограничение по возвращаемому ответу в JSON-формате.
5. Протокол и маршрутизация
На выходе формируется структурированный отчет и JSON для обработки на стороне 1С:
- статус по каждому документу;
- перечень замечаний и классификация критичности;
- общий вывод.
Если комплект корректен — он проходит дальше автоматически. Если есть ошибки — сотрудник получает уже конкретный список нарушений.
SaaS
В результате получился самостоятельный сервис — Dokflow.
Для тестов мы сделали веб-интерфейс, в котором можно загрузить комплект документов и увидеть, как система разбирает его, извлекает реквизиты и формирует протокол замечаний — ещё до интеграции в ИТ-контур компании.
Для промышленного использования подключение происходит через API: вся логика проверки, маршрутизация и формирование структурированных ответов и протоколов уже работают под капотом, встраиваются в текущие процессы через интеграции с системами клиента.
Итог
Этот проект не завершился классическим корпоративным внедрением.
Мы проверили продуктовую гипотезу и подтвердили ее практикой.
Мы убедились, что:
Качество и скорость
- Автоматизированная проверка позволяет находить больше ошибок и формализовать процесс контроля.
Экономика
- Даже без сокращения штата бизнес получает ускорение оборота средств и снижение налоговых рисков.
Сегодня DokFlow это самостоятельный сервис, выросший из реальной задачи бизнеса, а не из абстрактной идеи «давайте внедрим AI».
Выводы
Переход от проектной работы к продукту позволил нам взглянуть на автоматизацию документооборота шире. Сегодня сервис помогает решать три ключевые задачи:
- Снижение рисков: Полный контроль 100% входящего потока документов.
- Скорость: Ускорение обработки сделок и оборачиваемости средств.
- Эффективность: Освобождение квалифицированных сотрудников от механической сверки данных.
Мы продолжаем развивать систему, дообучая модели на новых типах документов и усложняя логику проверок.
Если вы сталкиваетесь с похожими объемами документации, то мы готовы подробнее рассказать о работе сервиса или показать, как он справится с вашими тестовыми образцами.