Обновлено: июнь 2026. Я переработал материал под практический сценарий: от качества скана и распознавания текста до проверки ошибок и передачи полей в учётную систему.

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

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

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

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

Для бухгалтерских документов я обычно делю пайплайн на 7 шагов: приём файла, предобработка изображения, OCR, классификация документа, извлечение полей, валидация, запись в учётную систему. Если пропустить классификацию, модель может искать сумму оплаты в акте так же, как в счёте. Если не валидировать результат, сумма 100 000,00 может стать 10 000,00 из-за пропущенного нуля или плохого распознавания разделителя.

Факты, которые стоит держать в голове при проектировании: для уверенного OCR сканы обычно готовят в 300 dpi, серые или цветные изображения дают больше информации, чем пережатый чёрно-белый файл, перекос страницы даже на 3–5 градусов ухудшает распознавание таблиц. PDF с текстовым слоем обрабатывается быстрее скана, потому что текст уже есть внутри файла. А фотографии с телефона почти всегда требуют выравнивания, удаления теней и поиска границ листа.

Базовая архитектура: от файла до записи в учёте

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

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

NLP-слой получает уже не картинку, а набор текстовых блоков. На этом этапе решаются 4 задачи: определить тип документа, найти кандидатов на поля, выбрать правильное значение, вернуть структурированный результат. Минимальный JSON для бухгалтерского контура обычно содержит тип документа, номер, дату, контрагента, ИНН или налоговый номер, сумму без налога, сумму налога, сумму итого, валюту и степень уверенности по каждому полю.

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

Как OCR ищет текст, а NLP превращает его в поля

OCR отвечает на вопрос: «Что написано на странице?» NLP отвечает на другой вопрос: «Что из написанного нужно занести в поле?» Эта разница критична.

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

С суммой похожая история. В документе бывают цена за единицу, сумма по строке, НДС, итог, предоплата, задолженность. Я предпочитаю хранить всех кандидатов, а не только выбранное значение. Например, кандидат 118 000,00 рядом с «Итого к оплате» получает высокий балл, кандидат 18 000,00 рядом с «НДС» получает другой тип, а 100 000,00 рядом с «Без НДС» попадает в отдельное поле. Затем арифметическая проверка сверяет: 100 000,00 + 18 000,00 = 118 000,00.

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

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

Проверки, без которых автозаполнение опасно

Я разделяю проверки на синтаксические, арифметические, справочные и процессные.

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

Арифметические проверки сверяют взаимосвязанные поля. Если сумма без налога 24 500,00, налог 4 410,00, итог 28 910,00, расхождение в 0,01 допустимо из-за округления, а расхождение в 410,00 требует ручной проверки. Для документов с таблицами полезно пересчитать строки: количество × цена, сумма строк, налог, итог.

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

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

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

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

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

Условный пример: компания из сферы оптовой торговли, ~80 сотрудников, обрабатывает 1 200 входящих документов в месяц и вводит 12 полей на документ. Даже если ручной ввод одного поля занимает 6 секунд, получается около 24 часов чистого набора в месяц без учёта сверки и исправлений. Автоматизация не убирает человека полностью, но переводит его из режима печатания в режим контроля исключений.

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

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

Где помогают языковые модели

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

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

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

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

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

Метрики качества: что измерять до запуска

Для суммы, даты и контрагента мало измерять общую точность. Нужны отдельные метрики по каждому полю. Сумма может извлекаться с точностью 98%, а дата с 85%, потому что в документах много похожих дат. Контрагент может быть найден правильно по ИНН, но название будет отличаться пробелами, кавычками и организационно-правовой формой.

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

Модельный кейс: на тестовой выборке из 500 сканов система нашла сумму в 492 документах, но 9 раз выбрала сумму налога вместо суммы к оплате. Формально поле найдено в 98,4% документов, но бизнес-качество ниже, потому что ошибка относится к критическому классу. После добавления правила «приоритет фраз рядом с итогом к оплате» и арифметической сверки такие случаи обычно уходят в ручную очередь, а не в автозапись.

Ещё одна полезная метрика, процент прямой автоматизации. Это доля документов, которые прошли все проверки без участия оператора. На старте нормальна низкая доля, например 30–50% для разнородных сканов. Гонка за 95% в первый месяц часто приводит к скрытым ошибкам. Лучше честная очередь исключений, чем красивый отчёт и ручное исправление в закрытом периоде.

Типовые ошибки при внедрении

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

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

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

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

Пошаговый план запуска

Начните с инвентаризации документов. Разделите поток на типы, источники, объём в месяц, количество страниц, качество сканов, обязательные поля. Для пилота выберите один тип и 5–10 полей. Сумма, дата и контрагент подходят хорошо, потому что по ним легко считать ошибки и бизнес-эффект.

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

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

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

Пятый шаг, заведите цикл улучшения. Раз в неделю смотрите 20–50 ошибок из очереди проверки, группируйте причины, добавляйте правила, обновляйте промпты, расширяйте тестовый набор. Если ошибка повторилась 10 раз за неделю, это кандидат на автоматическое правило. Если ошибка единичная и риск высокая сумма, лучше оставить ручной контроль.

Заключение: обновлённый взгляд на OCR и NLP

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

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