ИИ-обработка сканов: OCR, проверка и учёт в 2026

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

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

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

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

В старых материалах по теме обработка сканов часто сводилась к простой формуле: OCR распознал текст, программа записала данные. Такой подход устарел. Для реального учёта мало получить строку «Итого 125 430,00». Нужно понять, где сумма к оплате, где сумма без налога, где НДС, какая дата относится к документу, а какая к договору или оплате.

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

Практическая разница видна на простом счёте. На странице могут быть номер счёта, дата составления, срок оплаты, реквизиты продавца, реквизиты покупателя, несколько строк товаров, ставка НДС 20%, итог без налога и итог с налогом. Если система извлекла 12 полей из 14, но перепутала получателя и плательщика, документ нельзя отправлять в учёт без проверки.

Шаг 1. Загрузка скана и подготовка изображения

Качество входного файла задаёт потолок точности. Для бумажных документов обычно хватает 300 dpi: это даёт читаемые символы в мелких реквизитах, печатях и табличных строках. При 150 dpi система чаще путает «8» и «3», теряет запятые в суммах и плохо видит тонкие линии таблиц. Для мобильных фото критичны три вещи: отсутствие сильной перспективы, ровное освещение и полный лист в кадре.

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

Распространённый набор входных форматов: PDF, JPEG, PNG, TIFF. PDF бывает двух типов. Первый уже содержит текстовый слой, тогда извлечение идёт быстрее. Второй состоит из картинок, тогда нужен полноценный OCR. Отдельная сложность, сканы с печатями поверх текста, бледные копии после факса и документы, где табличная часть занимает 70–80% страницы.

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

Шаг 2. OCR превращает изображение в текст

OCR распознаёт символы и возвращает текст вместе с координатами. Координаты нужны не меньше, чем сами буквы. Если строка «125 430,00» находится рядом с подписью «Итого к оплате», это один смысл. Если она стоит в колонке «Цена за единицу», смысл другой.

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

OCR особенно часто ошибается в похожих символах: «О» и «0», «З» и «3», «1» и «I». В реквизитах это болезненно. Один неверный символ в ИНН или номере счёта меняет смысл записи. Поэтому после распознавания начинается второй слой проверки, уже не визуальный, а смысловой.

Шаг 3. NLP находит сумму, дату и контрагента

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

Пример для иллюстрации: в счёте есть строки «Дата оплаты: 14.06.2026», «Счёт № 77 от 10.06.2026» и «Договор от 02.03.2025». Система должна выбрать 10.06.2026 как дату документа, а не срок оплаты и не дату договора. Для этого она смотрит на соседние слова, расположение поля и тип документа.

Для суммы применяется похожая логика. В документе могут быть «Сумма без НДС», «НДС», «Всего к оплате», «Предоплата», «Остаток». Автоматическая запись должна брать именно итог к оплате или тот показатель, который нужен вашему учёту. Если бизнес-правило говорит записывать сумму с НДС, система не должна выбирать базу без налога.

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

Шаг 4. Проверка ошибок до записи в учёт

Автоматизация без валидации опасна. Я обычно делю проверки на 4 группы.

Форматные проверки отсекают очевидное. ИНН юридического лица содержит 10 цифр, ИНН физического лица, 12 цифр. Дата должна быть календарной. Сумма не должна быть отрицательной, если это обычный счёт на оплату.

Арифметика полезна даже при хорошем OCR. Если строки дают 125 000,00, НДС равен 25 000,00, а итог распознан как 150 900,00, документ нужно остановить. Причина может быть в распознавании, скидке, округлении или нестандартной форме, но автоматическая запись здесь преждевременна.

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

Процессная проверка защищает от дублей. Типовой ключ для поиска дубля: ИНН поставщика, номер документа, дата и сумма. Иногда номер пишут по-разному, например «Счёт 77», «№77» и «77/06». Поэтому жёсткого сравнения строк мало, лучше нормализовать номер и сравнивать несколько признаков одновременно.

Шаг 5. Очередь ручной верификации

Полная автоматизация звучит красиво, но в учёте чаще нужен режим «автоматически, если уверенность высокая; человеку, если есть риск». Это снижает нагрузку без потери контроля. Документы можно делить на три группы.

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

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

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

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

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

Когда поля подтверждены, система формирует структурированную запись. Обычно это JSON, XML, CSV или прямой вызов API. Минимальный набор для счёта: тип документа, номер, дата, контрагент, ИНН, сумма без НДС, НДС, сумма с НДС, валюта, ссылка на файл, статус проверки и идентификатор оператора, если была ручная правка.

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

Условный пример: компания из сферы логистики, ~200 сотрудников, обрабатывает 12 000 входящих документов в месяц и вводит обязательный порог уверенности 0,95 для суммы, даты и ИНН. Всё, что ниже порога, уходит оператору. Такая схема не обещает ноль ручной работы, зато отделяет рутинные документы от спорных и даёт понятный аудит.

Аудит нужен с первого дня. Для каждого поля храните исходный фрагмент, координаты на странице, предложенное значение, исправленное значение, время обработки и причину правки. Через 2–3 месяца эти данные покажут, какие шаблоны документов чаще ломаются и где нужно дообучать правила или менять маршрутизацию.

Где здесь место языковых моделей и SoftChat

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

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

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

Практический чек-лист внедрения

1. Выберите 1 тип документа и 5–10 обязательных полей.
2. Зафиксируйте требования к скану: 300 dpi для бумажных копий, полный лист, без сильных бликов.
3. Настройте извлечение текста с координатами, а не только строковым результатом.
4. Опишите сущности: дата документа, номер, ИНН, контрагент, сумма, НДС, валюта.
5. Добавьте форматные и арифметические проверки.
6. Настройте пороги уверенности: например, отдельный порог для суммы, ИНН и даты.
7. Сделайте очередь исключений с понятными причинами.
8. Сохраняйте историю правок по каждому полю.
9. Передавайте в учёт только подтверждённые данные.
10. Раз в месяц анализируйте ошибки и обновляйте правила.

Хороший ориентир для первой версии: не процент полной автоматизации, а снижение ручного набора на повторяемых документах. Если оператор вместо 20 полей проверяет 2–3 спорных, экономия уже заметна. Но качество нельзя оценивать по среднему числу распознанных символов. Для учёта важнее точность критичных полей: сумма, дата, контрагент и номер документа.

Типичные ошибки в проектах IDP

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

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

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

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

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

Итог обновления

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

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