Автоматизация обработки документов: где достаточно OCR, а где нужен ИИ

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

На презентации этот процесс часто сокращают до одного шага: «Загрузим PDF в нейросеть — она всё распознает».

И вот здесь начинается проблема.

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

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

OCR решает только часть задачи

OCR — оптическое распознавание текста. Сервис получает изображение или PDF и возвращает машиночитаемый текст, его расположение на странице и, в зависимости от модели, структуру таблиц или стандартных полей.

Например, Yandex Vision OCR предлагает отдельные модели для обычного текста, многоколоночных страниц, таблиц, рукописного текста и некоторых шаблонных документов. При этом в документации прямо перечислены ограничения: хуже распознаются художественные шрифты, вертикальный текст, отдельные виды анкет и слишком крупные надписи.[1]

После OCR система может получить примерно такой набор:

{
  "text": "ООО Поставщик...",
  "date": "08.07.2026",
  "amount": "125 430,00",
  "positions": []
}

Но она ещё не знает:

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

OCR читает страницу. Бизнес-процесс начинается после чтения.

Из каких этапов состоит обработка документа

Для устойчивой автоматизации полезно разделить маршрут документа на отдельные операции.

1. Получение и сохранение оригинала

Документы приходят по почте, через форму на сайте, ЭДО, Telegram, личный кабинет или общую папку.

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

2. Определение типа документа

Счёт, акт, УПД, заявка, паспорт изделия и коммерческое предложение требуют разных полей и разных маршрутов.

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

3. Распознавание текста и структуры

На этом этапе работает OCR. Он извлекает текст, таблицы, координаты блоков и стандартные поля.

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

4. Извлечение рабочих полей

Из всего текста нужно получить структуру, понятную учётной системе:

• тип документа;
• номер и дату;
• ИНН и наименование контрагента;
• позиции;
• количество и цену;
• сумму и НДС;
• номер заказа или договора.

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

5. Проверка бизнес-правил

Это детерминированный этап. Модель здесь не должна принимать решение «по смыслу».

Система может проверить:

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

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

6. Передача сомнительных случаев человеку

Не все документы должны проходить автоматически.

Проверка нужна, если:

• отсутствует обязательное поле;
• разные методы извлечения дали разные значения;
• контрагент не найден;
• сумма не сходится;
• документ относится к неизвестному типу;
• качество скана низкое;
• действие трудно отменить.

В промышленной архитектуре Ricoh и AWS OCR, классификация и извлечение данных дополнены правилами, оценкой уверенности и очередью ручной проверки. Поля ниже установленного порога отправляются оператору, который сверяет их с оригиналом.[2]

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

7. Запись в систему и журналирование

Только после проверки workflow создаёт документ в 1С, ERP, CRM или внутреннем сервисе.

При этом нужно фиксировать:

• исходный файл;
• распознанные значения;
• результаты проверок;
• исправления сотрудника;
• статус интеграции;
• повторные попытки;
• окончательное действие.

Если 1С временно недоступна, документ не должен исчезнуть или создаться второй раз после повторного запуска. Нужны очередь, контролируемые повторы и защита от дублей.

Именно это отличает рабочую автоматизацию от демонстрации распознавания.

Когда достаточно OCR и правил

ИИ нужен не для каждого документа.

OCR и обычного workflow обычно достаточно, когда:

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

Представим, что поставщики присылают счета одного формата. Номер, дата, ИНН и итоговая сумма находятся в известных местах. После распознавания система проверяет реквизиты, ищет контрагента и заказ, а затем подготавливает запись в 1С.

Здесь языковая модель добавит стоимость и ещё одну точку отказа, но почти не добавит пользы.

Для стандартной бухгалтерской первички сначала стоит проверить возможности готового сервиса. «1С:Распознавание первичных документов» поддерживает счета, накладные, акты, счета-фактуры, УПД, УКД и чеки. Официальный процесс состоит из загрузки, распознавания, проверки результата и создания документа в базе.[3]

Если задача укладывается в этот сценарий, отдельную ИИ-систему строить рано.

Где ИИ действительно полезен

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

Разная вёрстка

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

Смешанные пакеты

В одном PDF могут находиться счёт, акт, приложение и сопроводительное письмо. Сначала нужно разделить пакет, затем определить тип каждой части.

Свободный текст

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

Контекстная классификация

Документ нужно направить в конкретный отдел не по одному реквизиту, а по совокупности содержания.

Изменяющиеся формы

Если шаблоны регулярно меняются, постоянная перенастройка правил может стоить дороже ограниченного ИИ-этапа.

Но даже в этих случаях модель не должна управлять всем маршрутом. Рациональная схема выглядит так:

источник → сохранение оригинала → классификация → OCR → извлечение полей → проверки → ручная очередь → 1С или ERP → журнал

ИИ работает внутри конвейера, а не вместо него.

Microsoft использует похожее разделение в своём наборе автоматизации документов: Power Automate управляет процессом, AI Builder извлекает сведения, пользователь вручную просматривает спорные документы, а отдельное хранилище отвечает за очередь и данные.[4]

Готовый сервис или собственная система

Выбор зависит не от модности технологии, а от границ процесса.

Ситуация	Рациональный вариант
Стандартная первичка поступает в 1С	Сначала проверить готовый сервис 1С
Один стабильный шаблон	OCR, правила и простая интеграция
Несколько известных шаблонов	OCR плюс набор конфигураций
Много поставщиков с разной вёрсткой	OCR и модель для извлечения полей
В одном файле несколько документов	Классификация и разделение пакета
Данные уходят в несколько систем	Собственный управляемый workflow
Есть нестандартные правила согласования	Собственная логика и очередь проверки
Документы содержат критичные данные	Ограниченные доступы и обязательное подтверждение

Собственная система имеет смысл, когда готовое решение не поддерживает нужные документы, каналы, проверки или интеграции.

Во всех остальных случаях разработка «своего ИИ для документов» рискует стать дорогим способом повторить существующую функцию.

Как ограничить первый пилот

Формулировка «автоматизировать документы компании» слишком широкая.

Для пилота лучше выбрать:

• один тип документа;
• один канал поступления;
• одну целевую систему;
• ограниченный набор полей;
• понятную очередь ручной проверки.

Например: входящие счета от поставщиков, которые приходят на отдельный адрес и должны подготавливаться для ввода в 1С.

До запуска нужно собрать реальные примеры:

• хорошие сканы;
• фотографии под углом;
• многостраничные файлы;
• документы с печатями поверх текста;
• разные варианты таблиц;
• отсутствующие поля;
• исправления от руки;
• дубли;
• документы неизвестного типа.

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

Что измерять

Общая «точность распознавания» мало говорит о качестве процесса.

Ошибка в названии товара и ошибка в сумме платежа имеют разную цену. Поэтому метрики лучше разделить.

Качество данных

• правильность каждого критичного поля;
• полнота извлечения;
• количество исправлений;
• доля документов, которые нельзя обработать.

Работа процесса

• время от получения до готовой записи;
• доля документов, прошедших без ручного исправления;
• размер очереди проверки;
• количество возвратов;
• количество дублей.

Эксплуатация

• стоимость обработки одного документа;
• задержка OCR и модели;
• ошибки интеграций;
• повторные попытки;
• причины передачи человеку.

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

Главная метрика — не автономность. Главная метрика — корректно завершённый бизнес-процесс.

Типичные ошибки

Отправлять весь PDF напрямую в модель

Такой вариант подходит для прототипа, но плохо контролируется на больших, многостраничных и смешанных документах. Разделение на OCR, классификацию и извлечение упрощает проверку ошибок. В кейсе Ricoh OCR использовался в том числе для обработки больших документов, которые неудобно передавать модели целиком как изображения.[2]

Автоматически доверять уверенности модели

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

Записывать данные без бизнес-проверок

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

Начинать сразу со всех документов

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

Считать человека временным недостатком

Очередь проверки — нормальный компонент архитектуры. Со временем часть случаев можно автоматизировать, но нестандартные и рискованные документы всё равно должны иметь понятный путь к сотруднику.

С чего начать

Возьмите один реальный документ и проследите его путь:

1. Откуда он приходит?
2. Кто определяет его тип?
3. Какие сведения переносит сотрудник?
4. С чем он их сверяет?
5. Какие ошибки встречаются?
6. Как принимается решение о дальнейшей обработке?
7. Что произойдёт при неправильном значении?
8. В какую систему записывается результат?

После такого разбора станет видно, где достаточно OCR, где нужны правила, где оправдан ИИ, а где решение должен подтвердить человек.

Общий принцип выбора между обычной автоматизацией и вероятностным ИИ подробнее разобран в статье «Автоматизация с помощью ИИ: какие процессы ему поручать, а какие — правилам».

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

Частые вопросы

Чем OCR отличается от ИИ для документов?

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

Можно ли автоматически вводить документы в 1С?

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

Когда нужен человек?

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

Нужна ли языковая модель для первичных документов?

Не всегда. Для стандартных счетов, актов, накладных и УПД сначала стоит проверить готовые функции 1С и OCR-сервисов. Модель полезна при нестандартной вёрстке, смешанных пакетах и свободном тексте.

Как оценивать качество распознавания?

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

Источники

1. Yandex Vision OCR: описание сервиса и ограничения — документация, известные проблемы.
2. How Ricoh built a scalable intelligent document processing solution on AWS — AWS и Ricoh, 4 марта 2026 года.
3. «1С:Распознавание первичных документов» — официальный портал 1С.
4. Набор инструментов для автоматизации документооборота — Microsoft Learn, обновлено 14 января 2026 года.
5. Accelerate intelligent document processing with generative AI on AWS — AWS, 22 августа 2025 года, обновление март 2026 года.