Как нейросети читают сканы и заносят данные в учёт
Обновлено 25 июня 2026: я переписал материал под текущий цикл IDP, добавил этапы проверки, нормализации и передачи данных в учётную систему.
Автоматическое чтение сканов давно вышло за рамки простого распознавания букв. В рабочем процессе участвуют OCR, классификация документов, извлечение полей, проверка арифметики, поиск дублей и передача результата в учёт. Если убрать один из этих этапов, бухгалтерия получает не автоматизацию, а новый источник ошибок.
Я обычно смотрю на такую задачу как на конвейер. На входе лежит скан счёта, акта, накладной или чека. На выходе должна появиться структурированная запись: контрагент, ИНН, номер документа, дата, сумма без НДС, сумма НДС, итог, валюта, статус проверки и ссылка на исходный файл. Между этими точками происходит несколько операций, и каждая влияет на точность.
Что изменилось в обновлённой версии статьи
Ранняя версия подобных разборов часто сводила всё к OCR: программа «читает» картинку и превращает её в текст. В 2026 году такой взгляд слишком узкий. В реальных проектах распознавание текста даёт только сырьё. Дальше система должна понять, где в документе поставщик, где покупатель, какие строки относятся к табличной части, а какие к печати, подписи или банковским реквизитам.
Я обновил структуру по полному циклу IDP, то есть интеллектуальной обработки документов. В фокусе теперь не один алгоритм, а связка из 7 шагов: приём файла, улучшение изображения, OCR, разметка структуры, извлечение полей, валидация, экспорт в учёт. Такой подход лучше описывает практику: один счёт на 1 страницу и акт на 18 страниц требуют разных проверок, хотя оба начинаются со скана.
Если вы только выстраиваете работу с нейросетями в команде, полезно сначала отделить повторяемые операции от творческих задач. Я подробно разбирал этот принцип в статье про внедрение нейросетей в рабочие процессы, а здесь применю его к документам и бухгалтерским данным.
Из чего состоит конвейер чтения сканов
Типовой поток выглядит так:
- Файл попадает в систему из почты, папки обмена, веб-формы или сканера.
- Изображение очищается: поворот, шум, контраст, обрезка пустых полей.
- OCR извлекает текстовые блоки и координаты слов на странице.
- Модель определяет тип документа: счёт, акт, УПД, накладная, чек, договор.
- Из текста и координат извлекаются поля: дата, сумма, контрагент, ИНН, номер.
- Правила и модели проверяют результат: формат даты, совпадение итогов, дубли.
- Подтверждённые данные отправляются в учётную систему или очередь на ручную проверку.
На практике главная ценность появляется на шагах 5–7. OCR может распознать «1 240 000,00», но не всегда понимает, это итог по документу, сумма предоплаты или значение в строке таблицы. Извлечение поля требует контекста: рядом могут быть слова «Итого», «Всего к оплате», «Сумма с НДС», «Аванс». Для бухгалтерского контура это разные сущности.
Как OCR превращает изображение в текст
OCR работает с пикселями, а не с документами в привычном человеческом смысле. Сначала изображение переводится в более удобный вид: выравнивается перекос, усиливается контраст, удаляются серые тени от сканера. Даже поворот на 2–3 градуса может ухудшить распознавание табличных строк, особенно когда шрифт мелкий, 7–9 пунктов.
Затем движок ищет текстовые области. В хорошем результате у каждого слова есть координаты: страница, левый верхний угол, ширина, высота, уверенность распознавания. Эти координаты нужны для восстановления структуры. Например, если «Дата» стоит слева, а «15.06.2026» справа на одной линии, система связывает их как пару «метка — значение».
Типичные ошибки OCR:
| Фрагмент на скане | Возможная ошибка | Почему это опасно |
|---|---|---|
| «0» и «О» | замена цифры на букву | ломается ИНН или номер счёта |
| «1» и «I» | неверный символ | ошибка в номере документа |
| «8» и «В» | смешение кириллицы и цифр | неверное название контрагента |
| «1 000,00» | потеря пробела или запятой | сумма меняется на порядок |
| таблица на 2 страницах | строки склеены | итог не сходится с позициями |
Поэтому OCR без последующей проверки нельзя считать готовой автоматизацией. Он даёт кандидатов, а не финальный бухгалтерский факт.
Как извлекаются сумма, дата и контрагент
Для даты система ищет несколько признаков: формат «дд.мм.гггг», соседние слова «от», «дата», «составлен», положение в шапке документа. В счёте дата часто находится рядом с номером, в акте может быть в заголовке или перед подписями, в договоре встречается в первом абзаце и в реквизитах. Простое регулярное выражение найдёт все даты, но не выберет главную.
С суммой сложнее. В одном документе могут быть сумма без налога, налог, итог, задолженность, аванс, скидка и округление. Хорошая схема извлечения строит набор кандидатов и присваивает каждому вес. Сильные признаки: слова «всего к оплате», «итого с НДС», положение в нижней части таблицы, совпадение с суммой прописью, соответствие арифметике строк.
Контрагент определяется через реквизиты и контекст. Название рядом с ИНН поставщика надёжнее, чем первое юридическое лицо в тексте, потому что в документе часто указаны две стороны. Для российских первичных документов полезны ИНН, КПП, расчётный счёт, БИК, адрес. Если ИНН состоит из 10 или 12 цифр и проходит контрольную проверку, уверенность растёт.
Условный пример: в счёте на 3 страницы система нашла 6 дат, 4 суммы с копейками и 2 организации в реквизитах. Датой документа выбран фрагмент рядом с «Счёт № 184 от», итоговой суммой стала строка «Всего к оплате», контрагентом поставщика выбрана организация, возле которой стоит ИНН продавца. Это не магия, а набор проверок по тексту, координатам и смыслу.
Проверка ошибок: где автоматика должна тормозить
Полностью доверять первому ответу нельзя. Я закладываю минимум четыре уровня контроля.
Первый уровень, форматный. Дата должна быть реальной: «31.02.2026» уходит в ошибку. ИНН проверяется по длине и контрольным цифрам. Сумма приводится к единому виду: пробелы удаляются, запятая переводится в десятичный разделитель, валюта отделяется от числа.
Второй уровень, арифметический. Если в таблице есть строки «количество × цена», система сверяет суммы строк и итог. Допуск задаётся правилами, например 1 копейка на округление. Если итог отличается на 37 рублей, документ нельзя отправлять в учёт без проверки человеком.
Третий уровень, контекстный. Если документ классифицирован как акт, но в нём нет исполнителя, заказчика, периода или подписей, уверенность снижается. Если файл похож на чек, но поле «контрагент» извлечено из рекламного слогана внизу страницы, запись отправляется на ручной просмотр.
Четвёртый уровень, сверка с уже известными данными. Система ищет дубли по номеру, дате, ИНН и сумме. Для дубликата полезно сравнивать не один признак, а комбинацию. Счёт № 15 может повторяться у разных поставщиков, а вот связка «ИНН + номер + дата + сумма» гораздо точнее.
Обновление раздела про модели и инструменты
Раньше для такой задачи часто хватало связки «OCR плюс правила». Сейчас к ней добавляют языковые модели и модели анализа макета. Их задача не заменить проверки, а разобрать неоднозначные места: понять, какая из найденных сумм является итоговой, отличить покупателя от поставщика, восстановить таблицу после плохого скана.
Современные ИИ-модели хорошо помогают там, где документ плохо подчиняется жёсткому шаблону. У одного поставщика итоговая сумма называется «Всего», у другого «Итого к перечислению», у третьего «Сумма платежа». Правило на 20 вариантов быстро разрастается. Модель может использовать контекст вокруг поля и вернуть структурированный ответ: «дата документа», «номер», «поставщик», «покупатель», «итоговая сумма».
При этом для бухгалтерского процесса нужен не красивый ответ, а проверяемый результат. Я предпочитаю хранить вместе с каждым полем источник: страницу, координаты, исходный текст и уверенность. Тогда оператор видит не просто «1240000,00», а фрагмент скана, из которого взята сумма. Это резко упрощает разбор спорных документов.
Если команда учится формулировать запросы к языковым моделям для извлечения данных, пригодится материал про промптинг для точных ответов нейросетей. В документах особенно важны ограничения: вернуть только JSON, не додумывать отсутствующие поля, помечать сомнительные значения как «требует проверки».
Как данные попадают в учётную систему
После проверки запись нужно передать дальше. Обычно используют один из трёх способов: API, обмен файлами или промежуточную таблицу для оператора. API подходит для зрелого процесса: система отправляет поля напрямую, получает идентификатор созданного документа и сохраняет статус. Обмен файлами проще внедрить, если учётная система уже принимает XML, CSV или другой регламентированный формат. Таблица удобна на пилоте, когда правила ещё меняются каждую неделю.
Я не советую начинать с полной автозагрузки без очереди контроля. Безопаснее разделить документы на три группы:
| Группа | Признак | Действие |
|---|---|---|
| Высокая уверенность | все проверки пройдены, сумма сходится | отправить в учёт |
| Средняя уверенность | одно поле сомнительно | показать оператору |
| Низкая уверенность | плохой скан, не найден ИНН, сумма не сходится | вернуть на ручную обработку |
Гипотетический пример: компания из сферы оптовой торговли, ~80 сотрудников, получает 1 500 входящих документов в месяц. Если 60% документов проходят автоматическую проверку, оператор вручную смотрит уже не 1 500 файлов, а около 600. Это пример для иллюстрации расчёта нагрузки, а не обещание результата: фактическая доля зависит от качества сканов, типов документов и дисциплины поставщиков.
Какие поля нужны для контроля качества
Для каждого извлечённого значения я бы сохранял технический след. Минимальный набор: имя поля, значение, исходный текст, страница, координаты, уверенность OCR, уверенность извлечения, результат проверки, причина ошибки. Без этого невозможно понять, почему система ошиблась.
Пример структуры записи:
{
«document_type»: «счет»,
«number»: «184»,
«date»: «2026-06-15»,
«supplier_inn»: «7700000000»,
«total_amount»: «1240000.00»,
«currency»: «RUB»,
«validation_status»: «needs_review»,
«reason»: «итог не совпал с суммой строк»
}
В рабочем проекте я добавил бы ещё ссылку на исходный файл и массив координат для каждого поля. Тогда бухгалтер кликает на сумму и сразу видит нужное место на скане. Это экономит минуты на каждом спорном документе, особенно когда акт состоит из нескольких страниц.
Где нейросети помогают, а где лучше оставить правила
Нейросети сильны в понимании контекста, классификации и разборе нестандартных формулировок. Правила сильны в проверках, где есть строгая математика: контрольные цифры ИНН, формат даты, сумма строк, валюта, допустимый диапазон значений. Лучший результат обычно даёт гибрид.
Для генерации черновиков инструкций, шаблонов проверок и описаний полей можно использовать языковые модели. Подходы к таким текстовым задачам я разбирал в статье про нейросеть для генерации текста и проверку результата. Но финальное правило для суммы или ИНН должно быть исполняемым и тестируемым, иначе его трудно контролировать.
Я бы не поручал модели «просто занести всё правильно». Формулировка должна быть жёстче: извлеки поля по схеме, верни пустое значение, если поля нет, укажи фрагмент-источник, не исправляй документ за пользователя. Такой режим снижает риск выдуманных данных.
Практический чек-лист запуска
Начните с набора документов за 1–2 месяца. Разделите их по типам: счета, акты, УПД, чеки, накладные. Для каждого типа выберите 20–50 примеров разного качества: нормальные PDF, кривые сканы, фото с телефона, многостраничные файлы, документы с печатями и рукописными пометками.
Дальше составьте словарь полей. Не пишите «вытащить всё». Для учёта обычно нужны 10–20 полей, среди них номер, дата, стороны, ИНН, сумма, налог, валюта, договор, назначение, период. Для каждого поля задайте тип, обязательность и проверку. Например, «дата документа: обязательна, формат ISO, не позже текущей даты более чем на 5 рабочих дней без предупреждения».
Затем настройте очередь ручной проверки. Оператор должен видеть исходный скан, подсвеченный фрагмент, предложенное значение и причину сомнения. Кнопки нужны простые: подтвердить, исправить, отклонить, отправить на повторное распознавание. Исправления стоит сохранять как обучающие примеры для улучшения правил и подсказок.
Финальный этап, мониторинг. Считайте долю документов по статусам, частые причины ошибок, среднее время ручной проверки, поля с наибольшим числом исправлений. Если 70% ошибок приходится на дату договора, менять нужно не весь конвейер, а конкретное правило или подсказку для этого поля.
Финальный вывод к обновлению
Обновлённый подход к чтению сканов строится вокруг проверяемого конвейера. OCR распознаёт текст, модели помогают понять структуру и смысл, правила ловят арифметические и форматные ошибки, а учётная система получает только те данные, которые прошли контроль.
Хорошая автоматизация не обещает мгновенно убрать человека из процесса. Она убирает ручной ввод там, где данные уверенно распознаны, и оставляет бухгалтеру спорные случаи: плохой скан, конфликт сумм, неясный контрагент, дубль. Именно такая схема выдерживает поток документов и не превращает ускорение в бухгалтерский риск.