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

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

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

Что изменилось в обновлённой версии

В старых материалах по OCR часто делали акцент на самом факте распознавания текста. В 2026 году этого мало. Для бухгалтерии, закупок, логистики и документооборота ценность появляется там, где система уверенно отвечает на три вопроса: какая сумма, какая дата, кто контрагент. Остальное вторично, если процесс заточен под первичную автоматизацию ввода.

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

Из чего состоит конвейер OCR + NLP

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

Предобработка отвечает за поворот страницы, удаление шума, повышение контраста, разделение многостраничных файлов. Для сканов документов рабочее разрешение обычно держат в районе 300 dpi. При 150 dpi мелкие цифры в суммах и ИНН чаще слипаются, при 600 dpi файл становится тяжелее, но точность не всегда растёт пропорционально. Если документ приходит как фото с телефона, добавляется коррекция перспективы: лист на столе почти никогда не лежит идеально ровно.

OCR превращает изображение в текст и координаты фрагментов. Координаты нужны не для красоты. Они помогают понять, что число «12 480,00» находится рядом с подписью «Итого», а не в строке табличной части. Для счетов и актов полезно сохранять страницу, блок, строку и прямоугольник каждого найденного токена. Тогда спорное поле можно подсветить проверяющему прямо на скане.

NLP-слой извлекает сущности: сумму, дату, контрагента, номер документа, валюту, ИНН, КПП, ставку НДС. Для задачи из брифа минимальный набор состоит из трёх полей, но в реальной проверке их лучше расширить до 6–8. Например, контрагента легче подтвердить, если рядом есть ИНН. Дату легче проверить, если известен тип документа. Сумму безопаснее заносить, если отдельно выделены «без НДС», «НДС» и «с НДС».

Почему сумма ошибается чаще, чем кажется

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

Я обычно закладываю отдельные правила для денежных полей. Во-первых, нормализую разделители: «1 250,50», «1250.50» и «1.250,50» в разных источниках выглядят похоже, но парсятся по-разному. Во-вторых, храню валюту отдельным полем, а не частью строки. В-третьих, проверяю арифметику: если есть сумма без налога и налог, их сумма должна совпадать с итогом с учётом копеек. Допуск в 1 копейку нужен из-за округлений, особенно когда налог считается по строкам.

Условный пример: в документе «Счёт № 104» система видит три числа, 8 000,00, 1 600,00 и 9 600,00, а рядом встречаются подписи «Сумма», «НДС 20%» и «Всего к оплате». Верный кандидат на занесение в поле «итоговая сумма» здесь 9 600,00, но только после проверки, что 8 000,00 + 1 600,00 = 9 600,00.

Как извлекать дату документа, а не любую дату на странице

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

Хорошая схема начинается с классификации типа документа. Для счёта ищем паттерны рядом с «от», «дата счёта», номером и заголовком. Для акта важны фразы «составили настоящий акт» и область рядом с названием документа. Для накладной проверяем шапку и реквизиты отгрузки. При этом формат даты нужно приводить к одному виду, например ГГГГ-ММ-ДД, чтобы учётная система не гадала между 03.04.2026 и 04.03.2026.

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

Контрагент: почему одного названия мало

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

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

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

Проверка ошибок: пороги уверенности и ручная очередь

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

Я разделяю три уровня статуса. «Автопринято» получает документ, где OCR дал читаемый текст, NLP нашёл все обязательные поля, справочник подтвердил контрагента, арифметика суммы сошлась, дата попала в допустимый период. «На проверку» уходят документы с низкой уверенностью, несколькими кандидатами на одно поле или расхождением между суммой цифрами и прописью. «Отклонено» получают файлы не того типа, пустые сканы, повреждённые PDF и документы без обязательных реквизитов.

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

Модельный кейс: компания из сферы логистики, ~200 сотрудников, обрабатывает 12 000 входящих актов в месяц и ставит автопроведение только для документов, где 5 обязательных проверок прошли без конфликта. При таком подходе даже 70% автопринятых документов дают заметную экономию, потому что ручная команда смотрит 3 600 спорных файлов вместо всей очереди.

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

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

Я не советую сразу включать автопроведение в первый день. Сначала режим «только черновик»: система заполняет карточку, человек подтверждает. Затем «автосохранение без проведения»: документ попадает в учёт, но не влияет на регистры до проверки. Лишь после статистики по ошибкам можно включать автопроведение для узких классов документов, например для актов от проверенных контрагентов с одним типом услуги.

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

Обновление раздела про модели и инструменты

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

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

В SoftChat можно работать с диалогами, системными промптами и шаблонами запросов, а ответы отображаются с разметкой Markdown, включая таблицы и блоки кода. В чате поддерживаются вложения изображений и документов, если выбранная модель умеет работать с таким типом входа. Это удобно для разбора спорных примеров, подготовки промптов проверки и описания правил, но сам контур OCR, интеграции с учётом и автопроведение нужно проектировать как отдельную систему.

Практическая схема внедрения за 6 этапов

Первый этап, собрать выборку. Для старта хватает 200–500 документов одного типа, если формат относительно стабильный. Если типов много, выборку делят: счета отдельно, акты отдельно, накладные отдельно. Смешивать всё в одну кучу рано, потому что ошибки будут непонятными.

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

Третий этап, настроить OCR и хранение координат. Не выбрасывайте промежуточный текст. Он нужен для отладки. Если модель извлекла неверную дату, вы должны видеть, был ли текст распознан неверно или ошибка появилась уже на NLP-слое.

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

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

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

Где автоматизация окупается быстрее

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

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

Для примера: если оператор тратит 2 минуты на ввод одного документа, поток в 1 000 документов занимает около 33 часов чистого ввода без учёта переключений, поиска файлов и исправлений. Автоматическое заполнение трёх полей не убирает всю работу, но сокращает самый монотонный участок и переносит внимание человека на исключения.

Риски, о которых вспоминают слишком поздно

Первый риск, ложная уверенность. Красивый текстовый ответ модели не равен проверенному учётному полю. Нужны ссылки на источник внутри документа и машинные проверки.

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

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

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

Выводы после обновления

OCR + NLP для документов работает хорошо, когда система строится как конвейер с проверками, а не как магическая кнопка распознавания. Скан нужно подготовить, текст распознать с координатами, поля извлечь по контексту, значения проверить арифметикой и справочниками, спорные случаи отправить человеку. Только после этого данные можно безопасно передавать в учётную систему.

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