ИИ в документообороте полезен там, где бухгалтерия каждый день переносит одни и те же реквизиты из PDF, сканов и фотографий в учётную систему.

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

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

Где начинается автоматизация: входящий документ

В бухгалтерском потоке документ редко приходит в идеальном виде. Это может быть PDF из почты, фотография акта с телефона, скан с перекосом на 4–7 градусов, многостраничный договор со счётом на последней странице или архив из 30 файлов. На первом этапе система приводит этот поток к нормальному виду.

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

Для примера: если в папку попали 500 PDF за день, из них часть текстовые, а часть сканы, система сначала отделяет документы с уже встроенным текстовым слоем от картинок. Текстовый PDF можно разобрать быстрее, потому что не нужен полный OCR. Скан и фото идут через распознавание изображения.

Связанный навык, который экономит много времени в таких проектах, это умение формулировать задачу для ИИ без лишних общих слов. Я подробно разбирал это в статье про нейросеть для генерации текста и проверку результата, и тот же принцип работает здесь: чем точнее задан формат результата, тем меньше ручной правки.

Как система находит сумму, дату и контрагента

После подготовки изображения начинается распознавание. Условно процесс делится на два слоя: чтение символов и понимание структуры документа. OCR отвечает за буквы и цифры. Модель анализа документа отвечает за вопрос «что это за поле».

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

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

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

Поле Как извлекается Частая ошибка Как проверять
Сумма По подписи, формату числа, позиции в документе Берётся сумма строки вместо итога Сравнить итог, НДС и сумму к оплате
Дата По соседству с номером документа и типом формы Подставляется дата договора Задать приоритет дат для каждого типа документа
Контрагент По ИНН, КПП, счёту, названию Выбран поставщик вместо покупателя Проверить роль стороны в документе
НДС По строкам таблицы и итоговому блоку Ставка 20% принята за сумму Сверить ставку, базу и итог
Номер документа По метке рядом с реквизитом Номер договора принят за номер счёта Учитывать тип документа и расположение

Почему одного OCR недостаточно

OCR может прочитать текст, но он не понимает бухгалтерский смысл. Если на странице есть строка «Договор № 18 от 12.03.2025» и строка «Счёт № 18 от 14.03.2025», простой парсер легко возьмёт первое совпадение. Для бизнеса это ошибка: документ уйдёт в учёт с неверной датой.

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

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

Проверка ошибок: арифметика, справочники и риск-сигналы

Автоматизация без валидации превращается в быстрый способ размножать ошибки. Я обычно делю проверки на четыре уровня.

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

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

Третий уровень, справочный. Контрагент сверяется с внутренним справочником. Если ИНН найден, но название отличается из-за сокращения «Общество с ограниченной ответственностью» и «ООО», это не ошибка. Если ИНН совпал, а расчётный счёт новый, документ можно отправить на отдельное подтверждение. В интеграциях с внешними реестрами часто проверяют действительность реквизитов и статус организации, но конкретный набор проверок зависит от юридических и технических требований компании.

Четвёртый уровень, поведенческий. Система сравнивает документ с историей: привычный поставщик, обычный диапазон сумм, типовые статьи затрат, частота повторов. Условный пример: компания из сферы оптовой торговли, ~150 сотрудников, обычно получает счета от одного перевозчика в диапазоне 80–120 тысяч рублей, а новый счёт от того же ИНН пришёл на 310 тысяч рублей. Такой документ не нужно блокировать автоматически, но его стоит отправить ответственному сотруднику до записи в учёт.

Как данные попадают в учётную систему

Когда поля извлечены и проверены, система формирует структурированный объект. Обычно это JSON или другой внутренний формат: тип документа, номер, дата, контрагент, сумма, валюта, НДС, строки табличной части, ссылки на исходный файл, уровень уверенности по каждому полю.

Дальше данные передаются в учётную систему через API, файловый обмен, очередь задач или промежуточный модуль. В больших контурах часто используют очереди, потому что документы приходят пачками. Если 2 000 сканов загрузились после выходных, обработка не должна обрушить учётную систему. Очередь дозирует нагрузку, повторяет неудачные операции и сохраняет статус каждого документа.

Типичный статусный маршрут выглядит так: «получен», «распознан», «прошёл проверки», «требует уточнения», «записан», «ошибка интеграции». Последний статус особенно нужен. Без него бухгалтер видит только пропавший документ, а не причину: недоступен API, не найден контрагент, закрыт период, не хватает обязательного поля.

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

Где человек всё ещё нужен

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

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

Для примера: в потоке из 1 000 документов разумно проектировать не «100% автозаписи», а маршрут, где типовые 700–850 документов проходят без ввода руками, а остальные уходят в понятную очередь исключений. Это не универсальная норма, а рабочий ориентир для проектирования нагрузки.

Как оценивать точность без самообмана

Процент распознавания сам по себе мало что говорит. Если система верно нашла 98% номеров документов, но ошиблась в 5% сумм, бизнес всё равно получит финансовый риск. Поэтому метрики нужно считать по полям и по стоимости ошибки.

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

Для настройки качества нужен тестовый набор. Лучше собрать документы за несколько месяцев: разные поставщики, хорошие PDF, плохие сканы, акты, счета, УПД, документы с НДС и без НДС. На малой выборке из 20 файлов легко получить красивую цифру, которая развалится в первый же месяц эксплуатации.

Безопасность и контроль доступа

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

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

Как бы я запускал такой проект

Я начал бы не с выбора модели, а с карты документов. Сколько типов первички приходит за месяц, какие поля обязательны, где больше всего ручного ввода, какие ошибки дороже всего. После этого выбрал бы один поток: например счета от постоянных поставщиков за последние 3–6 месяцев. На нём можно собрать тестовый набор, описать правила проверки и увидеть реальную долю исключений.

Дальше я бы развёл два контура. Первый, автоматическая запись для документов с высокой уверенностью и пройденными проверками. Второй, очередь уточнений с причиной остановки: «не найден ИНН», «расхождение итога», «новый банковский счёт», «низкое качество скана». Бухгалтеру не нужно гадать, что случилось. Он должен открыть карточку и сразу понять, какое поле требует решения.

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