Как ИИ читает сканы документов и заносит данные
Обновлено: июнь 2026. Разбираю рабочую схему: от скана счёта или акта до записи в учётной системе без ручного набора суммы, даты и контрагента.
Эту статью я обновил как практическую инструкцию, а не обзор «магии ИИ». В старых материалах про распознавание документов часто всё сводилось к OCR: загрузили скан, получили текст, дальше бухгалтер сам исправляет поля. Сейчас рабочий контур шире. Нужны предобработка изображения, извлечение сущностей, проверка реквизитов, контроль уверенности, очередь на ручную верификацию и безопасная передача в учётную систему через API или файл обмена.
Я бы не начинал такой проект с выбора модели. Сначала надо описать документы: счёт, акт, накладная, УПД, платёжное поручение, договор. У каждого типа есть свои поля, свои ошибки и свои правила проверки. Сумма может встречаться три раза, дата документа отличается от даты оплаты, контрагент пишется полным и кратким названием, а ИНН иногда попадает в подвал рядом с банковскими реквизитами.
Что изменилось в обновлённой версии
Я перестроил материал вокруг полного конвейера обработки. Добавил этапы, которые обычно всплывают уже после пилота: контроль качества скана, нормализацию дат и сумм, проверку ИНН и КПП, статусы уверенности, ручную очередь спорных документов, экспорт в учётную систему. Устаревшую идею «OCR решает всё» заменил на связку OCR, языковой модели, правил валидации и интеграционного слоя.
Ещё одно изменение касается роли промптов. Для разовых задач достаточно попросить нейросеть извлечь сумму, дату и контрагента из текста. Для учётного процесса нужен стабильный формат ответа, например JSON с фиксированными ключами: document_type, document_date, counterparty_name, inn, total_amount, vat_amount, currency, confidence. Если команда только проектирует такой сценарий, полезно сначала отработать структуру запросов и проверки в диалоге. О базовых принципах формулировки заданий я отдельно писал в статье про правильные запросы к нейросетям.
Общая схема: 7 этапов вместо одного распознавания
Автоматическое чтение сканов лучше рассматривать как цепочку из 7 шагов.
- Приём документа: загрузка PDF, фото или скана, присвоение идентификатора, сохранение исходника.
- Предобработка: поворот, обрезка полей, выравнивание перспективы, повышение контраста, удаление шума.
- OCR: получение текстового слоя и координат слов на странице.
- Классификация: определение типа документа, например счёт, акт, УПД или накладная.
- Извлечение полей: сумма, дата, номер, контрагент, ИНН, НДС, валюта.
- Валидация: арифметика, формат дат, контроль ИНН, сверка суммы с НДС, проверка дублей.
- Передача в учёт: запись через REST API, обменный файл, очередь интеграции или ручное подтверждение.
Если оставить только третий пункт, бухгалтерия получит текстовую простыню. Если собрать все 7 этапов, система сможет сама подготовить карточку документа и отправить её дальше, а человеку оставить 5-15% спорных случаев. Такой диапазон я беру как практическую оценку для смешанных архивов, где встречаются сканы с печатями, фото со смартфона и PDF из почты.
Шаг 1. Приём документа и паспорт качества
На входе надо сохранить не один файл, а набор признаков: источник, тип файла, число страниц, размер, разрешение, цветность, дата загрузки, автор загрузки, хеш документа. Хеш помогает ловить дубли. Для PDF из почты это особенно полезно: один и тот же счёт могут переслать бухгалтер, менеджер и поставщик.
Минимальный паспорт качества я делаю таким:
| Признак | Хорошее значение | Что делать при проблеме |
|---|---|---|
| Разрешение | 200-300 dpi | просить новый скан или повышать резкость |
| Наклон страницы | до 2 градусов | автоповорот и повторный OCR |
| Доля тёмного фона | ниже 15% | очистка фона |
| Читаемость мелкого текста | от 8 pt | ручная проверка реквизитов |
| Число страниц | совпадает с ожидаемым типом | отправить в очередь разбора |
Для примера: если в пачке 1 000 документов 120 фото сделаны под углом, выгоднее автоматически выпрямить их до OCR, чем потом править суммы и ИНН вручную. Сумма «18 500,00» легко превращается в «13 500,00», если край таблицы размыт или цифра 8 склеилась с печатью.
Шаг 2. Предобработка изображения
Предобработка нужна даже при хороших сканах. Алгоритм обычно делает 5 операций: ищет границы листа, поворачивает страницу, убирает серый фон, повышает контраст, делит многостраничный PDF на страницы. Для фото добавляется исправление перспективы, потому что лист часто снят под углом 10-20 градусов.
Есть простое правило: если документ можно улучшить до OCR, надо улучшать до OCR. Я видел слишком много проектов, где пытались «допросить» модель после плохого распознавания. Это дороже и менее стабильно. Нейросеть может догадаться, что «ООО Ромашка» похоже на контрагента, но она не должна угадывать ИНН по размытой строке.
Шаг 3. OCR: текст плюс координаты, а не просто текст
OCR возвращает не только слова. Для финансовых документов нужны координаты: где именно слово найдено на странице, в какой строке, рядом с какими подписями и цифрами. Сумма около фразы «Итого к оплате» весит больше, чем сумма в таблице товаров. Дата рядом с «Дата документа» важнее даты в банковских реквизитах.
Хороший результат OCR для одной страницы выглядит так: текст, блоки, строки, слова, координаты, уверенность по каждому слову. Если слово распознано с уверенностью 0,62, его нельзя молча отправлять в учёт. Его надо либо перепроверить моделью по изображению, либо подсветить оператору.
Для документов с таблицами особенно полезна разметка строк. В УПД и накладных одна строка товара может содержать 8-12 колонок: наименование, единица измерения, количество, цена, сумма без налога, ставка налога, сумма налога, итог. Если таблица «поехала», общая сумма ещё может быть верной, но позиции станут мусором.
Шаг 4. Классификация документа
Перед извлечением полей система определяет тип документа. Это можно делать по заголовкам, шаблонам и текстовым признакам. Счёт часто содержит «Счёт на оплату», акт содержит «Акт выполненных работ», УПД содержит номер формы и строку про статус документа.
Классификация нужна по двум причинам. Первая, разные поля. У счёта есть дата оплаты или срок, у акта есть период оказания услуг, у накладной есть грузоотправитель и грузополучатель. Вторая, разные проверки. Для УПД полезно сравнить итоговую сумму с суммой строк, а для платёжного поручения проверить БИК, расчётный счёт и назначение платежа.
Условный пример: если система обрабатывает 5 типов документов и для каждого задано 12 обязательных полей, получится 60 проверяемых признаков, но оператор увидит только те поля, которые относятся к текущему типу. Это снижает шум в интерфейсе и уменьшает число случайных правок.
Шаг 5. Извлечение суммы, даты и контрагента
Извлечение полей лучше делать гибридно. Регулярные выражения хорошо находят ИНН, КПП, БИК, номера счетов и даты. Языковая модель помогает понять контекст: какая из пяти дат является датой документа, какая сумма является итоговой, кто продавец, кто покупатель.
Для суммы я задаю приоритеты:
- поле рядом с «Итого», «Всего к оплате», «Сумма документа»;
- сумма прописью, если она есть;
- итог таблицы;
- сумма с НДС и сумма без НДС;
- сумма в назначении платежа или комментарии, если других признаков нет.
Для даты схема похожая. Дата рядом с номером документа получает высокий приоритет. Дата в шапке письма или штамп входящего документа не должна попадать в поле document_date. Формат надо нормализовать сразу: 2026-06-26, а не «26 июня 2026 г.» или «26.06.26». Тогда учётная система не будет спорить с локалью и масками ввода.
Контрагент сложнее суммы. В документе могут быть продавец, покупатель, грузоотправитель, банк, подписант и организация-получатель. Поэтому я советую извлекать не одно поле counterparty, а роли: seller, buyer, payer, shipper, consignee. Потом бизнес-правило выбирает нужную роль для конкретного процесса.
Если вы выстраиваете похожие сценарии для текстов и документов, пригодится подход из материала про нейросеть для генерации текста и проверку результата: сначала получить черновик, затем прогнать его через чек-лист качества. Для документов этот чек-лист превращается в валидатор полей.
Шаг 6. Проверка ошибок: правила, арифметика, справочники
Без валидации автоматический ввод опасен. Система должна доказать, что поле похоже на правду. Проверки делятся на 4 группы.
Первая группа, формат. ИНН юридического лица содержит 10 цифр, ИНН физического лица содержит 12 цифр, КПП содержит 9 цифр. Дата должна существовать в календаре: «31.02.2026» нельзя пропускать. Сумма должна быть числом с двумя знаками после запятой, если учётная система требует такой формат.
Вторая группа, арифметика. Если сумма без налога равна 100 000,00, ставка НДС 20%, то сумма налога должна быть 20 000,00, а итог 120 000,00. Допуск в 1 копейку иногда нужен из-за округления строк, но допуск в 15 рублей уже требует проверки.
Третья группа, связи между полями. Номер расчётного счёта должен соответствовать банку по БИК, контрагент должен совпадать со справочником, валюта документа должна совпадать с валютой договора или заказа. Если справочник содержит «Ромашка, ООО», а в документе написано «ООО Ромашка», это не ошибка, но нужен нормализатор названий.
Четвёртая группа, антидубли. Дубль можно искать по сочетанию ИНН контрагента, номера документа, даты и суммы. Один признак даёт много ложных совпадений. Четыре признака дают гораздо более чистый сигнал.
Гипотетический пример: документ «Счёт № 145» на 48 000,00 рублей пришёл дважды, один раз в PDF и один раз как фото. Если совпали ИНН, номер, дата и сумма, система ставит статус «возможный дубль» и не создаёт вторую запись без подтверждения.
Шаг 7. Передача в учётную систему
После проверки данные попадают в учётную систему. Технически есть 3 распространённых способа: REST API, файл обмена, очередь сообщений. API удобен для почти мгновенной записи и обратного статуса. Файл обмена проще согласовать в компаниях, где интеграции жёстко регламентированы. Очередь сообщений полезна при больших объёмах, когда обработка идёт пачками.
Передавать надо не только поля документа. Нужны исходный файл, ссылка на распознанный текст, статус проверки, уверенность по полям, список предупреждений и история правок. Если оператор исправил ИНН, это событие надо сохранить. Потом на таких правках обучают правила нормализации и улучшают подсказки.
Минимальный объект для передачи может выглядеть так:
{
"document_type": "invoice",
"document_number": "145",
"document_date": "2026-06-26",
"counterparty_name": "ООО Ромашка",
"inn": "7700000000",
"total_amount": 48000.00,
"currency": "RUB",
"confidence": 0.91,
"warnings": ["possible_duplicate"]
}
Тут точность важнее красоты. Лучше вернуть пустое поле и предупреждение, чем придумать недостающую дату. Для учёта выдуманное значение хуже ошибки распознавания, потому что оно выглядит правдоподобно.
Где нужны нейросети, а где достаточно правил
Не весь процесс надо отдавать модели. Правила быстрее, дешевле и предсказуемее там, где есть строгий формат. ИНН, КПП, даты, суммы, ставки налога, номера счетов хорошо проверяются алгоритмически. Нейросеть полезна там, где нужен смысл: определить, какая организация является контрагентом, понять назначение платежа, разобрать нестандартный акт, сопоставить «итого к оплате» с общей суммой.
Я обычно делю поля на 3 категории:
| Поле | Чем извлекать | Как проверять |
|---|---|---|
| ИНН, КПП, БИК | OCR плюс шаблоны | длина, контрольные правила, справочник |
| Дата и номер | OCR плюс контекст | формат, диапазон дат, связь с дублями |
| Контрагент | языковая модель плюс справочник | нормализация названия, ИНН, роль в документе |
| Сумма и НДС | таблицы, OCR, модель | арифметика, ставка, итоговые строки |
| Тип документа | классификатор | набор обязательных полей |
Такой гибрид проще сопровождать. Если изменилась форма документа, можно обновить правило или промпт для одного типа, а не переписывать весь конвейер.
Как настроить контроль уверенности
Каждому полю нужен статус. Я использую 4 уровня: «принято автоматически», «нужна проверка», «ошибка», «не найдено». Для автоматического принятия обычно требуется высокая уверенность OCR, совпадение с правилами и отсутствие конфликтов между источниками.
Пример для иллюстрации: сумма 120 000,00 найдена рядом с «Итого к оплате», сумма прописью совпала, НДС сошёлся до 1 копейки, OCR дал уверенность 0,96. Такое поле можно принять автоматически. Если сумма найдена только в таблице, OCR дал 0,71, а строка закрыта печатью, документ должен уйти оператору.
Порог нельзя выбрать один раз навсегда. На пилоте я советую начать жёстко: принимать автоматически только поля с уверенностью от 0,90 и полным набором проверок. Через 2-4 недели накопится статистика ошибок, и пороги можно разделить по типам документов. Счета из электронных PDF часто проходят легче, фото актов со смартфона требуют ручной очереди чаще.
Как запустить пилот за 4 недели
Пилот не должен начинаться со всего архива. Возьмите один тип документа и один маршрут, например входящие счета поставщиков. Дальше двигайтесь короткими итерациями.
Неделя 1: собрать 200-500 документов без персональных лишних файлов, разметить обязательные поля, описать статусы и причины ошибок. Для ручной разметки 200 документов обычно нужны часы, а не минуты, поэтому лучше заранее договориться, кто принимает спорные значения.
Неделя 2: настроить OCR, предобработку, классификацию и первичное извлечение. На этом этапе полезно хранить все версии результата: исходный текст, найденные поля, координаты, предупреждения.
Неделя 3: добавить проверки, справочники, антидубли, очередь оператора. Если нет очереди, люди начнут править данные прямо в учётной системе, и команда потеряет обратную связь по качеству распознавания.
Неделя 4: подключить тестовый контур учётной системы, проверить статусы обмена, замерить долю автоматического принятия, долю ручных правок и типы ошибок. Не гонитесь за 100% автоматизацией. Для документов с разным качеством сканов реалистичнее постепенно снижать ручной труд, сохраняя контроль спорных случаев.
Если задача шире и затрагивает рабочие процессы, полезно заранее описать роли, SLA и правила внедрения. Я разбирал этот управленческий слой в статье про внедрение нейросетей в рабочие процессы.
Типичные ошибки внедрения
Первая ошибка, принимать распознанный текст как истину. OCR ошибается на печатях, тонких шрифтах, плохих фото, сканах с низким контрастом. Для денег и реквизитов нужна проверка.
Вторая ошибка, отправлять в учёт все поля без статусов. Через месяц никто не поймёт, какие записи были приняты автоматически, какие исправлял оператор, какие пришли из интеграции.
Третья ошибка, смешивать документы разных типов в одном промпте и одном наборе правил. Счёт и акт похожи только снаружи. Для учётной системы это разные объекты с разными обязательными полями.
Четвёртая ошибка, не хранить исходник рядом с результатом. При споре с поставщиком или внутренней проверке надо открыть документ, увидеть координаты распознавания и понять, почему система выбрала именно это значение.
Пятая ошибка, пытаться заменить бухгалтерскую экспертизу угадыванием модели. ИИ хорошо ускоряет ввод и первичную проверку, но правила учёта, договорные условия и ответственность за проводки остаются в процессе.
Роль SoftChat в подготовке такого проекта
SoftChat уместен на этапе проектирования и проверки текстовых сценариев: можно вести диалог с нейросетью, сохранять историю обсуждения по организации, использовать шаблоны запросов для повторяемых задач и прикладывать документы к сообщениям там, где выбранная модель поддерживает работу с такими вложениями. Это не заменяет интеграционный модуль учётной системы и не превращает чат в бухгалтерский робот. Зато через диалог удобно быстро собрать список полей, описать JSON-формат, подготовить чек-лист валидации и сравнить варианты промпта для извлечения данных.
Я бы использовал чат как черновую лабораторию: сначала описать 10-15 реальных форм документов, затем попросить модель предложить поля, проверки и спорные случаи, потом уже отдавать техническое задание разработчикам интеграции. Такой подход экономит время аналитика, потому что вместо пустого листа команда получает структурированный черновик.
Итог обновления
Обновлённая схема обработки документов строится не вокруг одного OCR, а вокруг контролируемого конвейера. Скан надо подготовить, текст распознать, поля извлечь с учётом контекста, суммы и реквизиты проверить, спорные документы отправить оператору, подтверждённые данные передать в учётную систему.
Главный критерий качества, это не красивая демонстрация на одном счёте. Нужны метрики по пачке документов: сколько полей принято автоматически, сколько исправлено вручную, какие ошибки повторяются, сколько дублей остановлено до записи в учёт. Тогда ИИ перестаёт быть экспериментом и становится понятным инструментом снижения ручного ввода.