Распознавание документов: как работает OCR и что он реально экономит

Распознавание текста — только четвёртый шаг из шести, и остальные пять решают, будет ли работать четвёртый.

Не каждый поток окупается. Работает произведение трёх величин — объём, однотипность и цена ошибки.

Входящая первичка. Счета, накладные, УПД, акты. Объём большой, формы похожие, ошибка стоит денег и споров с налоговой. Самый частый и самый окупаемый случай.

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

Документы клиента на онбординге. Паспорт, СНИЛС, свидетельство. Объём зависит от притока, ошибка дорогая, требования к хранению отдельные.

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

Акты приёмки и путевые листы. Приходят с полей фотографиями, качество плохое, зато поля простые и их мало.

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

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

Через оператора электронного документооборота УПД приходит машиночитаемым файлом формата 5.03 — этот формат обязателен с 1 апреля 2025 года. Никакого извлечения полей там не требуется, данные уже разложены по тегам.

В 2026 году регулирование подталкивает в ту же сторону. Приказ ФНС от 20.01.2025 № ЕД-7-26/28@ с 1 января отменил форматы ТОРГ-12 и документа о передаче результатов работ, оставив УПД, неформализованный документ с электронной подписью и бумагу. А письмо ФНС от 29.09.2023 № Д-5-26/56@ прямо запрещает инспекциям требовать бумажные и сканированные копии формализованных документов, созданных электронно.

Практический вывод для проекта. Сначала считаем, какая доля потока идёт через оператора, какую можно забрать по API у крупных поставщиков и какую выгрузить из личного кабинета. Распознавание достаётся остатку — бумаге, сканам, фотографиям и мелким контрагентам без электронного обмена. Как устроен сам обмен документами, разобрано отдельно в материале про системы документооборота.

Это самый дешёвый способ уменьшить проект. Перевести часть контрагентов на электронный обмен — работа переговорная, и разработки она не требует.

Вендоры обещают точность 99% и почти никогда не говорят, по чему считали. Разница огромная, и её видно на арифметике.

Посимвольная точность. Доля верно распознанных знаков. Именно её обычно и называют, потому что она самая красивая.

Точность по полю. Доля полей, распознанных целиком верно. Поле из двадцати цифр при посимвольной точности 99% верно в 0,99²⁰ ≈ 82% случаев. При 99,9% — уже в 98%. Расчётный счёт — как раз двадцать цифр.

Точность по документу. Доля документов, где верны все нужные поля. Шесть полей с точностью 95% каждое дают верный документ в 0,95⁶ ≈ 74% случаев.

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

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

Straight-through processing — доля документов, которые прошли конвейер и уехали в учёт без прикосновения человека. Это главная величина экономики, и считать проект надо в ней.

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

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

Время на документ сокращают пять вещей.

• Подсветка поля на образе. Оператор видит, откуда система взяла значение, и не ищет его глазами по скану.
• Только сомнительные поля. На проверку выносится то, в чём система не уверена или что не прошло проверку. Уверенные поля показываются, но не требуют внимания.
• Клавиатура вместо мыши. Переход по полям, подтверждение и переход к следующему документу делаются с клавиатуры.
• Подстановка из справочника. Контрагента, договор и номенклатуру оператор выбирает подсказкой и не набирает заново.
• Возврат в поток. Исправление оператора попадает в обучающую выборку, иначе одна и та же ошибка повторяется месяцами.

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

Плохой экран верификации съедает всю выгоду от хорошей модели. Мы видели процессы, где оператор открывал скан в одном окне, карточку в другом и сверял их глазами — при формально высокой точности распознавания.

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

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

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

Распознать документ и провести его в учёте — две разные задачи, и вторая обычно больше.

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

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

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

Технику обмена с учётной системой здесь не раскрываем — она разобрана в материале про интеграцию с 1С. Для проекта важно одно требование: документ не должен потеряться и не должен уехать дважды.

Распознавание документов клиента поднимает вопрос, который обычно обсуждают последним. Скан паспорта — это персональные данные, и обычно их собирают с запасом. Для проверки клиента хватает нескольких полей, а компания сохраняет образ целиком.

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

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

Цена небрежности выросла в мае 2025 года, когда вступил в силу 420-ФЗ. Массовая утечка персональных данных стоит до 15 млн ₽, повторная — от 1 до 3% годовой выручки. Архив сканов паспортов «на всякий случай» превратился из удобства в риск с ценником.

Два факта, которые стоит знать до проекта.

Скан — это электронный образ, а не электронный оригинал. Если инспекция запросила подлинник бумажного документа, представить вместо него скан-образ нельзя: такая позиция закреплена письмом ФНС от 17.05.2016 № АС-4-15/8657@. Значит бумагу после распознавания всё равно увозят в архив.

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

Полезно сравнить две внешние цифры. Сырое облачное распознавание страницы у Yandex Vision OCR стоит 0,13 ₽. Готовый сервис «1С:Распознавание первичных документов» стоит от 6 ₽ за страницу на пакете в сто страниц до 3 ₽ на пакете в миллион, а первые 250 страниц дают бесплатно.

Разница в двадцать с лишним раз — это и есть цена конвейера. Классификация, извлечение полей, проверки, экран оператора и проводка стоят ровно столько. Когда обсуждают «стоимость OCR», обычно имеют в виду первую цифру, а покупают вторую.

Своя разработка окупается там, где ни один из двух вариантов не закрывает поток. По нашим работам: сервисы на своих моделях — от 1,8 млн ₽, заказная разработка под процесс — от 1,7 млн ₽, отдельная интеграция с учётной системой, оператором обмена или хранилищем — от 150 тыс. до 1,5 млн ₽, аудит существующего решения — от 200 до 600 тыс. ₽. Точную цифру считаем по вашему потоку и типам документов: оценка проекта бесплатная.

Порядок бюджета можно прикинуть заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.

Точность принимают по символам. В договоре стоит 99%, на боевом потоке верных документов две трети, и спорить не о чем: методику не зафиксировали.

Экран верификации рисуют последним. Модель отличная, оператор тратит на документ полторы минуты, экономии нет.

Проверок нет. Система уверенно ставит ИНН покупателя в поле поставщика, документ уезжает в учёт, ошибку находит бухгалтер через месяц.

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

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

Первое — собрать сто документов из боевого потока. Архив ровных сканов для этого не годится. Фотографии, штампы, длинные таблицы и повреждённые экземпляры должны попасть в выборку в тех же пропорциях, в каких они приходят на самом деле.

Второе — выписать поля, которые нужны для проводки, и отметить критичные. Обычно их пять-семь, и именно по ним замеряют точность. Заодно выяснится, что часть полей никому не нужна.

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