Стендфирст: обновлено в 2026 году, я переписал статью с упором на практическую схему OCR плюс NLP, контроль ошибок и передачу данных в учетную систему.

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

В этой версии я убрал устаревший акцент на «магическое распознавание» и разложил процесс так, как его стоит проектировать в реальной компании. Скан сам по себе редко бывает идеальным. У поставщика может быть бледная печать, у курьера снимок под углом, у архива файл на 150 dpi, а у бухгалтерии несколько форматов счетов от одного контрагента. Если пропустить эти детали, ИИ будет выглядеть умно на демо и ошибаться на потоке.

Что именно должен сделать ИИ с документом

Задача звучит просто: прочитать документ и занести сумму, дату, номер и контрагента в учетную систему. На практике это цепочка из 7 этапов.

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

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

Финальный шаг, запись в учетную систему. Чаще всего это REST API, обменный файл, очередь задач или промежуточный реестр, который бухгалтер подтверждает перед загрузкой. Полностью автоматическая запись подходит не всем. Если ошибка в 1 поле может привести к неверному платежу, я обычно закладываю режим «человек подтверждает спорные документы».

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

OCR не равен пониманию документа

OCR отвечает за распознавание символов. Он может прочитать «1 250 000,00», но сам по себе не всегда поймет, это сумма к оплате, сумма с НДС, остаток долга или лимит по договору. В счетах часто есть 5–10 числовых полей: цена за единицу, количество, сумма по строке, НДС, итог, предоплата, скидка. Если забирать первое крупное число, ошибок будет много.

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

Условный пример: если в компанию приходит 2 000 счетов в месяц от 300 поставщиков, ручной ввод 5 полей по каждому документу превращается в 10 000 операций копирования. Даже при скорости 45 секунд на документ это около 25 часов чистого ввода, без учета поиска файла, исправлений и согласований.

Качество входного изображения сильно влияет на результат. Для бумажных сканов рабочим минимумом обычно считают 300 dpi. Черно-белые копии с сильной компрессией хуже передают мелкие реквизиты, особенно ИНН, номера договоров и печати. Фото со смартфона требует коррекции перспективы: обрезки краев, выравнивания, удаления тени. Если этого нет, модель может перепутать «8» и «3», «0» и «О», «1» и «I».

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

Я бы не начинал с интеграции в учетную систему. Сначала нужно собрать эталонную выборку. Обычно берут 100–300 документов разных типов: счета от частых поставщиков, редкие формы, плохие сканы, многостраничные PDF, документы с печатями поверх текста. Для каждого файла вручную размечают нужные поля.

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

После разметки можно тестировать извлечение. Хороший формат ответа, строго структурированный JSON с фиксированными ключами. Например: дата в формате ГГГГ-ММ-ДД, сумма в копейках или с двумя десятичными знаками, ИНН строкой, контрагент в исходном написании плюс нормализованное название. Такой ответ проще проверять автоматически.

При работе с языковыми моделями помогает жесткий промпт: «верни только JSON», «если поле не найдено, верни null», «не вычисляй значение, если оно отсутствует в документе», «укажи фрагмент текста, из которого взято поле». Последний пункт особенно полезен для аудита. Когда оператор видит источник значения, он быстрее подтверждает документ.

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

Проверка ошибок: где автоматизация чаще всего ломается

Самые частые ошибки я делю на 5 групп.

Первая, неверное поле суммы. Модель берет «Итого без НДС» вместо «Всего к оплате». Лечится арифметической проверкой и приоритетом терминов. Если есть «Всего к оплате», оно важнее строки «Итого по товарам».

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

Третья, неверная дата. На документе может быть дата договора, дата счета и дата оплаты. Поле нужно задавать явно: «дата документа», а не «любая дата».

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

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

Гипотетический пример: компания из сферы логистики, ~200 сотрудников, обрабатывает 1 500 закрывающих документов в месяц. Если система автоматически отправляет на проверку только 12% документов с низкой уверенностью, оператор смотрит 180 файлов вместо всего потока. Остальные проходят по правилам, но с журналом источников и контрольных проверок.

Классификация, нейросети и проверка подлинности

В сложных потоках одной OCR-системы мало. Классификаторы на основе сверточных сетей хорошо работают с визуальными признаками: где расположены таблицы, печати, подписи, логотипы, блоки реквизитов. Архитектуры семейства Transformer помогают с контекстом: они видят, что число рядом со словами «в том числе НДС» отличается по смыслу от числа рядом с «к оплате».

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

Здесь полезна простая шкала уверенности. Например, поле «сумма» найдено с высокой уверенностью, потому что совпали OCR, ключевые слова и арифметика. Поле «контрагент» найдено со средней уверенностью, потому что название распознано, но ИНН поврежден. Поле «дата» найдено с низкой уверенностью, потому что в документе 3 даты и нет явного маркера. Такой разбор помогает не спорить с моделью, а проектировать маршрут документа.

Как связать извлечение с учетной системой

Интеграция начинается с карты полей. Учетная система редко принимает «как написано в документе». Ей нужны справочники: контрагент должен совпасть с карточкой, договор с внутренним номером, статья расходов с планом счетов, валюта с кодом, подразделение с организационной структурой.

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

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

Условный пример: в потоке из 10 000 документов пакетная загрузка по 500 записей снижает риск остановки процесса. Если одна пачка не прошла из-за ошибки в справочнике, остальные 9 500 документов можно продолжить обрабатывать, а проблемные 500 отправить на исправление.

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

Какие метрики качества смотреть

Точность OCR по символам сама по себе мало что говорит бизнесу. Можно распознать 98% символов и ошибиться в единственной цифре суммы. Для финансовых документов лучше считать точность по полям.

Я бы смотрел 6 метрик: доля документов, где все обязательные поля извлечены верно; точность суммы; точность даты; точность контрагента по ИНН; доля дублей, найденных до загрузки; доля документов, отправленных на ручную проверку. Отдельно считают время обработки: от загрузки файла до статуса «готов к учету».

Для пилота достаточно 200–500 документов, если они покрывают основные форматы. Для промышленного запуска выборку расширяют: новые поставщики, сезонные документы, сканы из архива, фотографии, многостраничные вложения. Не гонитесь за 100% автопроводкой. В бухгалтерских процессах выгоднее надежно автоматизировать 70–85% типового потока, а рискованные 15–30% направить человеку с уже заполненной карточкой.

Для примера: если оператор раньше тратил 2 минуты на документ, а после извлечения проверяет заполненную карточку за 25 секунд, экономия возникает даже без полной автономности. На 3 000 документах в месяц это разница между 100 часами ручного ввода и примерно 21 часом проверки.

Как подготовить команду и промпты

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

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

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

Чек-лист запуска пилота

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

Соберите выборку. Включите хорошие PDF, плохие сканы, фотографии, документы на 1–5 страниц, старые формы и файлы от частых контрагентов. Разметьте поля вручную. Это скучная часть, но без нее невозможно понять, улучшилась система или просто красиво отвечает.

Сделайте первый контур без автозагрузки в учет. Пусть система извлекает данные в таблицу или тестовый реестр. Сравните результат с ручной разметкой. Исправьте промпты, правила валидации и карту полей. Только после этого подключайте учетную систему.

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

Заключение: что изменилось в обновленной версии

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

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