OCR и NLP для сканов: сумма, дата, контрагент в 2026

Практическая инструкция по построению конвейера, который читает сканы, находит реквизиты, проверяет ошибки и передаёт данные в учётную систему без ручного ввода.

Обновлено: 2 июля 2026.

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

В статье разберу схему OCR + NLP для финансовых и первичных документов: как подготовить изображение, распознать текст, выделить сущности, проверить их правилами и записать результат в учётную систему. Принцип подходит для счетов, актов, накладных, УПД, кассовых чеков и договорных приложений. Если вы только начинаете внедрять ИИ в операционные процессы, полезно сначала разобраться, как выбирать рабочие сценарии для нейросетей, потому что извлечение реквизитов почти всегда упирается в регламенты, а не только в качество модели.

Из чего состоит связка OCR + NLP

OCR превращает изображение в текст и координаты слов на странице. NLP разбирает этот текст: ищет дату, сумму, название контрагента, ИНН, номер документа и другие сущности. В связке они решают разные задачи. OCR отвечает на вопрос «что написано и где это находится», NLP отвечает на вопрос «что из этого является нужным реквизитом».

Для бухгалтерских документов я закладываю минимум пять этапов:

1. Приём файла: PDF, JPG, PNG или TIFF.
2. Предобработка изображения: выравнивание, очистка шума, повышение контраста.
3. OCR: распознавание текста, строк, таблиц и координат.
4. NLP: извлечение сущностей и нормализация форматов.
5. Валидация и запись: проверка реквизитов, журнал ошибок, передача в учётную систему.

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

Шаг 1. Подготовьте сканы до распознавания

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

Я бы заложил такие правила приёма файла:

• размер страницы не меньше 1000 пикселей по короткой стороне для обычного А4;
• автоповорот по направлению строк;
• удаление пустых страниц, если OCR вернул меньше 20–30 символов;
• сохранение исходного файла без изменений;
• отдельное хранение обработанной версии, которую видела модель.

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

Для многостраничных PDF нужно заранее решить, где искать реквизиты. В счётах сумма и контрагент чаще находятся на первой странице. В договорах сумма может появиться в приложении, а дата, на титульном листе. Поэтому в настройках конвейера полезно хранить тип документа: «счёт», «акт», «УПД», «договор», «чек». Тип влияет на правила извлечения.

Шаг 2. Получите не просто текст, а текст с координатами

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

Практическая схема хранения результата OCR выглядит так:

• текст слова;
• координаты прямоугольника на странице;
• номер страницы;
• уверенность распознавания;
• принадлежность к строке или таблице;
• исходный фрагмент изображения для спорных зон.

Уверенность нужна для маршрутизации. Если сумма распознана с уверенностью 0,99, а ИНН с 0,62, конвейер может автоматически записать сумму и отправить ИНН на дополнительную проверку. Без этого все поля выглядят одинаково убедительно, хотя одно извлечено из чистого PDF, а другое из размытой печати.

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

Шаг 3. Извлеките дату, сумму и контрагента через NLP

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

Сумма. Ищем числа рядом со словами «итого», «к оплате», «всего», «сумма», «стоимость». Нормализуем пробелы, запятые и точки. Значение «1 245 300,50» должно стать числом 1245300.50, а исходная строка остаётся в журнале. Если в документе есть НДС, полезно хранить несколько полей: сумма без НДС, НДС, сумма с НДС.

Дата. Ищем форматы 12.03.2026, 12 марта 2026 г., 2026-03-12. Для короткого года «26» лучше задавать правило: 00–79 трактовать как 2000–2079, 80–99 как 1980–1999, если бизнес-процесс допускает старые документы. В учётных документах это снижает риск получить 1926 год из строки «12.03.26».

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

Для примера: документ содержит строки «Поставщик: ООО «Вектор»», «ИНН 7701234567» и «Итого к оплате 86 420,00 руб.». Конвейер должен вернуть не красивый пересказ, а структуру: тип контрагента, название, ИНН, сумма, валюта, дата, номер страницы, координаты и уверенность по каждому полю.

Шаг 4. Нормализуйте данные до записи

Извлечённые сущности редко готовы к записи без обработки. Дату нужно привести к ISO-формату, сумму к десятичному числу, контрагента к записи в справочнике. Отдельно храните исходное значение. Это помогает при разборе ошибок: бухгалтер видит, что модель прочитала «8 620,00» как «86 20,00», а не просто получила неверное число.

Минимальный JSON для передачи дальше может выглядеть так:

{
  «document_type»: «invoice»,
  «date»: «2026-03-12»,
  «amount_total»: 86420.00,
  «currency»: «RUB»,
  «counterparty_name»: «ООО «Вектор»»,
  «counterparty_inn»: «7701234567»,
  «confidence»: {
    «date»: 0.97,
    «amount_total»: 0.99,
    «counterparty_inn»: 0.94
  }
}

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

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

Шаг 5. Проверьте ошибки до автоматической записи

Автозапись без участия человека безопасна только для документов, которые проходят набор проверок. Я не советую делать одно общее условие «уверенность выше 0,9». Поля имеют разный риск. Ошибка в сумме на 100 рублей и ошибка в контрагенте с таким же названием, но другим ИНН, дают разные последствия.

Рабочий набор проверок:

• дата документа не позже текущей даты, если процесс не допускает будущие документы;
• сумма больше 0 и меньше установленного лимита для типа документа;
• валюта входит в разрешённый список;
• ИНН проходит проверку контрольного числа;
• КПП имеет 9 цифр, если контрагент юрлицо;
• контрагент найден в справочнике или попадает в очередь создания;
• сумма с НДС согласуется с суммой без НДС и ставкой;
• дубль документа не найден по связке контрагент, дата, номер и сумма.

Условный пример: для актов до 100 000 рублей можно разрешить автозапись при уверенности суммы и даты выше 0,95, совпадении ИНН со справочником и отсутствии дубля. Для документов выше лимита система создаёт карточку, но просит человека подтвердить сумму и контрагента. Это уже не полностью автоматический сценарий, зато риск контролируется.

Ошибки лучше делить на классы. Технические, файл не читается или OCR вернул пустой текст. Логические, сумма с НДС не сходится. Справочные, контрагент не найден. Политика обработки для них разная: повторное распознавание, ручная проверка или задача на обновление справочника.

Шаг 6. Запишите результат в учётную систему

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

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

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

Где нейросеть действительно помогает

Языковые модели особенно полезны там, где документ не укладывается в один шаблон. Они понимают, что «к оплате», «итого», «всего с налогом» и «сумма документа» могут указывать на одно поле, но не всегда. Они помогают отличать дату договора от даты отгрузки по словам рядом. Они могут вернуть объяснение, почему выбрали именно эту сумму.

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

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

Как понять, что процесс готов к запуску без человека

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

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

Если бы я запускал такой процесс у себя, я начал бы с одного класса документов, например счетов от регулярных поставщиков. Там проще настроить справочник, лимиты и проверку дублей. После стабильного журнала ошибок добавил бы акты, затем УПД, потом более свободные документы. Автоматизация первички хорошо растёт слоями. Когда каждый слой измерим, команда перестаёт спорить «доверяем ли мы ИИ» и начинает обсуждать конкретные правила допуска к автозаписи.