Короткий ответ: Content AI берут, когда распознавание должно стать рабочим местом бухгалтера и настраиваться без программиста, а Smart Engines — когда распознавание должно стать частью вашей собственной системы и работать без интерфейса вообще. Это не два конкурента с разной галочкой в таблице, а два разных предмета покупки, и половина неудачных выборов происходит именно здесь: компания покупает движок, а ждёт продукт.
Оба решения российские, оба живут на вашем сервере, оба закрывают одну и ту же боль — ручной ввод первички. ABBYY ушла из России в 2022 году, её линейку продолжил Content AI: ContentReader PDF вместо FineReader, ContentCapture вместо FlexiCapture. Smart Engines шёл своим путём и изначально проектировался как движок распознавания, который встраивают в чужие системы. К сентябрю 2026 года это два основных варианта, между которыми выбирает средняя компания, плюс отраслевые решения вроде 1С:Распознавания первичных документов и Directum, если вы и так живёте внутри этих контуров.
Мы не продаём ни то, ни другое — мы подключаемся к тому, что выбрал заказчик, поэтому дальше идёт разбор без вендорской стороны. Ниже: чем эти решения различаются по существу, как замерить точность на своих документах до оплаты, где на самом деле живёт экономия, во что обходится год эксплуатации на потоке 50 000 документов и в чём обе системы одинаково бессильны.
Кто есть кто: продукт с интерфейсом против движка под встраивание
Различие проще всего увидеть в вопросе «кто заведёт новый тип документа». У вас появился поставщик со своей формой акта — кто настроит извлечение полей? В продуктовой модели это делает аналитик или администратор в интерфейсе: разметил поля на образце, проверил на десятке документов, выпустил в работу. В движковой модели это делает разработчик: правила извлечения живут в коде и конфигурации вашей системы, а не в отдельном приложении.
Отсюда растёт вся остальная разница — в сроке запуска, в том, кто дежурит при сбое, и в том, чью зарплату вы платите за поддержку. Таблица ниже описывает устройство, а не функции: перечень поддерживаемых полей у обоих вендоров меняется от релиза к релизу, и его надо смотреть на сайте вендора на дату сделки, а не в статье.
| Признак | Content AI | Smart Engines |
|---|---|---|
| Происхождение | Российский преемник ABBYY: ContentReader PDF вместо FineReader, ContentCapture вместо FlexiCapture | Российский разработчик движков распознавания, продукт с самого начала делался под встраивание |
| Что вы покупаете | Готовый продукт: рабочее место оператора плюс серверный поток обработки | Движок и SDK, который надо встроить в свою систему |
| Кто заводит новый тип документа | Аналитик или администратор в интерфейсе | Разработчик, кодом и конфигурацией |
| Кто чинит ошибку в проде | Администратор системы, часто ключевой пользователь из бухгалтерии | Ваш разработчик или интегратор |
| Где выполняется распознавание | Свой сервер или рабочее место сотрудника | Свой сервер, вплоть до полностью офлайнового контура |
| Порог входа | Ниже: можно начать пилот без разработчика | Выше: без разработчика проект не стартует |
| Что получается на выходе | Готовый процесс обработки с очередью проверки | Структурированный ответ, который вы сами кладёте в учётную систему |
Сравнение в две колонки. Левая — «Продукт»: иконка приложения, под ней подписи «рабочее место оператора», «новый тип документа заводит аналитик», «чинит администратор», «порог входа ниже». Правая — «Движок»: иконка библиотеки-кубика внутри большего контура «ваша система», подписи «встраивается по SDK», «новый тип документа заводит разработчик», «чинит ваш интегратор», «работает без интерфейса». Внизу общая подпись: «Разный предмет покупки, а не разные галочки». Чертёжный стиль, подписи по-русски.
Что именно они читают и где кончается их зона ответственности
Оба решения покрывают стандартный набор бухгалтерской первички: УПД и УКД, счета-фактуры, акты выполненных работ, ТОРГ-12 и ТОРГ-13, КС-2 и КС-3, банковские выписки и платёжные поручения, ГТД. Это тот перечень, вокруг которого построен российский рынок распознавания, и на нём обе платформы работают на типовых формах из коробки. Различия начинаются там, где документ перестаёт быть типовым, — и это ровно та часть потока, которая съедает время бухгалтерии.
| Тип документа | Обычно читается штатно | Что приходится настраивать под себя |
|---|---|---|
| УПД, УКД, счета-фактуры | Да: форма унифицирована | Табличную часть при нестандартной вёрстке и переносах строк на следующий лист |
| ТОРГ-12, ТОРГ-13 | Да | Сопоставление номенклатуры поставщика с вашим справочником — это уже не распознавание |
| КС-2, КС-3 | Да, при типовой форме | Расшифровки и приложения, которые каждый подрядчик верстает по-своему |
| Банковские выписки, платёжки | Да | Разноску по статьям и договорам — задача учётной системы, а не движка |
| Счета поставщиков | Частично: формы произвольные | Каждого крупного поставщика отдельно, если он верстает счёт по-своему |
| Акты сверки, договоры | Текст — да, структура — нет | Извлечение условий: сроки, суммы, штрафы. Это отдельный класс задач |
Отсюда практическое правило: считать надо не «сколько типов документов поддерживается», а какую долю вашего реального потока составляют нетиповые формы. У оптовика с двадцатью постоянными поставщиками нетиповых счетов может быть 15 %, у строительной компании с сотней подрядчиков и их приложениями к КС-2 — все 60 %. Мы разбирали покрытие рынка по типам документов отдельно в статье какой сервис какие документы берёт; там перечень шире, здесь важнее сама методика оценки.
Самая частая недооценка сметы: движок отдал сумму, дату, ИНН и строки таблицы — а дальше их надо сопоставить с вашим контрагентом, вашим договором и вашей номенклатурой. Эта часть не входит ни в одну лицензию и делается на вашей стороне. В проектах она регулярно оказывается дороже самого распознавания, потому что зависит от того, в каком состоянии ваши справочники. Похожая логика описана в материале про сверку документов с контрагентами.
Как замерить точность на своей выборке из 200 сканов
Единственный способ сравнить два движка честно — прогнать через оба одну и ту же выборку своих документов и посчитать одну метрику: долю документов, прошедших без единой правки человеком. Не точность по символам, не точность по полям, а сквозной показатель, который прямо переводится в часы бухгалтера. Замер занимает 15–20 часов работы инженера, то есть около 60 000 ₽ по ставке 3 000 ₽/час, и это самая окупаемая строка всего проекта.
- 1Соберите 200 сканов, а не 20 красивых
Пропорция должна повторять ваш реальный поток. Рабочая раскладка: 40 УПД, 40 счетов-фактур, 30 актов, 30 ТОРГ-12, 20 банковских выписок, 20 КС-2 и КС-3 и обязательно 20 заведомо плохих — фото с телефона под углом, печать поверх суммы, скан с полосой от сканера, второй экземпляр через копирку.
- 2Зафиксируйте эталон руками
По каждому документу выпишите те поля, которые реально попадают в учётную систему: номер, дата, контрагент, ИНН, сумма, НДС, строки таблицы. Эталон делает человек, который потом будет пользоваться системой, — иначе спор о том, что считать ошибкой, начнётся уже после покупки.
- 3Прогоните выборку через оба движка в одинаковых условиях
Одинаковое разрешение сканов, одинаковый набор настроенных шаблонов, одинаковое время на настройку — например, по 8 часов на платформу. Разное время подготовки делает сравнение бессмысленным.
- 4Считайте документы, а не символы
Документ считается пройденным, только если ни одно из значимых полей не потребовало правки. Одна исправленная цифра в сумме — документ в минусе целиком, потому что бухгалтер всё равно его открыл.
- 5Разложите ошибки по причинам
Плохой исходник, незнакомая форма, сложная табличная часть, рукописная пометка. Это важнее итогового процента: первую причину чинит регламент сканирования и стоит ноль рублей, вторую — настройка шаблона, третью — доработка, четвёртую не чинит никто.
- 6Пересчитайте результат в часы и рубли
Доля без правки × ваш месячный поток × время правки одного документа × 700 ₽ за час. Именно эта цифра, а не процент из презентации, идёт в расчёт окупаемости.
Почему нельзя верить проценту из презентации, видно из простой арифметики. Вендор честно показывает точность по полю — скажем, 98 %. Но документ проходит без правки, только если правильно прочитаны все его поля. При 12 полях вероятность этого равна 0,98 в двенадцатой степени, то есть 78 %. Никто не соврал, просто метрики разные.
| Точность по одному полю | Документ из 8 полей | Документ из 12 полей | Документ из 20 полей |
|---|---|---|---|
| 99 % | 92 % без правки | 89 % без правки | 82 % без правки |
| 98 % | 85 % без правки | 78 % без правки | 67 % без правки |
| 95 % | 66 % без правки | 54 % без правки | 36 % без правки |
Сгруппированная столбчатая диаграмма. По горизонтали три группы: «8 полей», «12 полей», «20 полей». В каждой группе три столбца — точность по полю 99 %, 98 %, 95 %. Значения: 92, 89, 82 для 99 %; 85, 78, 67 для 98 %; 66, 54, 36 для 95 %. Ось Y — «доля документов без правки, %». Столбец «98 % при 12 полях = 78 %» выделен и подписан. Внизу пометка: «вендор меряет поле, вы платите за документ».
Порог уверенности и очередь проверки: здесь и живёт экономия
Ни один движок не читает всё безошибочно, и правильно спроектированная система на это и не рассчитывает. Она делит поток надвое: документы, где движок уверен, идут в учётную систему сами, остальные попадают в очередь ручной проверки, где человек видит скан и подставленные значения рядом и правит только спорные поля. Экономия проекта складывается не из процента распознавания, а из того, насколько дёшево обходится этот остаток.
Число от 0 до 1, ниже которого распознанное значение не принимается автоматически, а уходит человеку. Поднимая порог, вы уменьшаете число ошибок, проскочивших в учёт, и увеличиваете очередь проверки; опуская — наоборот. Настраивается по полям: сумма и ИНН заслуживают более высокого порога, чем адрес доставки.
В модельной конфигурации на 72 % документов система срабатывает начисто, 28 % уходят в очередь. Оператор тратит на документ из очереди 2,5 минуты вместо шести на ввод с нуля, плюс 5 % автоматически прошедших документов проходят выборочный контроль по минуте. На потоке 4 200 документов в месяц это 49 часов очереди и 3 часа выборочного контроля — 52 часа против 420 часов ручного ввода. Механику остатка ошибок мы подробно разбирали в статье про реальную точность распознавания, и она одинакова для обеих платформ.
Схема потока слева направо, 6 блоков со стрелками. «Скан или фото» → «Движок распознавания» → ромб «Порог уверенности». От ромба две ветки: вверх «Автоматически, 72 % — 3 024 документа» → «Учётная система»; вниз «Очередь проверки, 28 % — 1 176 документов, 2,5 минуты каждый» → та же «Учётная система». Отдельная тонкая стрелка от верхней ветки вниз: «выборочный контроль 5 %». Внизу подпись: «52 часа в месяц вместо 420». Подписи по-русски, чертёжная манера.
Счёт на 50 000 документов в год
Модельная компания: оптовик, 4 200 первичных документов в месяц, примерно 50 000 в год. Сейчас их вводят руками, шесть минут на документ, полная стоимость часа рядового сотрудника — 700 ₽. Цены вендоров даны порядком величин по состоянию на сентябрь 2026 года; конкретный прайс зависит от объёма, числа рабочих мест и способа лицензирования, и его надо запрашивать под свой поток.
Разброс лицензий здесь шире, чем разброс работ, и это нормально: движковая поставка обычно считается от объёма распознаваний, продуктовая — от числа рабочих мест и серверных ядер. Поэтому при одном и том же потоке дешевле может оказаться и то и другое, в зависимости от того, сколько у вас операторов. Правило простое: если операторов трое, а документов много — считайте объёмную модель; если операторов пятнадцать, а документов на каждого немного, — посмотрите на модель по рабочим местам. Общая структура расходов на распознавание разобрана в материале сколько стоит распознавание документов.
Двухосевой график за 12 месяцев. Серая штриховая горизонталь — разовое вложение 680 000 ₽. Синяя область — накопленная чистая экономия при 187 600 ₽/мес (нижняя граница) и голубая — при 217 600 ₽/мес (верхняя). Обе линии пересекают штриховую на четвёртом месяце, точка подписана «окупаемость, 4-й месяц». Ось X — месяцы, ось Y — рубли. Внизу пометка: «поток 4 200 документов в месяц».
В чём обе одинаково слабы
Это самая полезная часть сравнения, и её нет ни в одной вендорской таблице. Пять вещей не умеет ни Content AI, ни Smart Engines, и если ваша боль в этом списке — выбор между ними ничего не изменит.
- Не улучшают исходник. Фото под углом с бликом от лампы, печать поверх суммы, третий экземпляр через копирку — брак остаётся браком. Регламент сканирования (200–300 dpi, документ целиком, без наклона) поднимает долю чистого прохода сильнее, чем смена движка, и стоит ноль рублей.
- Не знают ваших справочников. Движок вернёт строку «Кабель ВВГнг 3х2,5, м» — а какой это код в вашей номенклатуре, он не знает. Сопоставление контрагентов, договоров и позиций делается на вашей стороне и часто стоит дороже самого распознавания.
- Не отвечают за последствия ошибки. Если НДС принят к вычету по неверной сумме, объясняться будете вы, а не вендор. Поэтому порог уверенности по денежным полям задирают выше, а выборочный контроль оставляют навсегда, а не «на период опытной эксплуатации».
- Меряют не то, за что вы платите. Обе платформы показывают точность по символам или по полям. Ваша метрика — доля документов без правки; её никто, кроме вас, не посчитает, потому что она зависит от числа значимых полей именно в ваших документах.
- Не устраняют причину. Распознавание — это компенсация того, что контрагент прислал картинку вместо структурированного документа. Если он готов работать через ЭДО, данные придут полями и распознавать будет нечего. Как устроен этот путь, мы разбирали в сравнении операторов ЭДО.
Цена ошибки: сколько стоит уйти с одного движка на другой
Между платформами переносятся сами документы и результаты обработки — они лежат у вас. Не переносится главное: правила извлечения. Шаблон, размеченный в одном продукте, во втором не открывается ни в каком виде, и вся работа по формам делается заново. Поэтому цена неправильного выбора почти равна цене первого внедрения.
Из этого следует единственное архитектурное решение, которое стоит принять до выбора вендора: распознавание должно быть сменяемым узлом, а не вросшим в процесс. Практически это значит, что ваша система обращается к движку через собственный внутренний контракт — «отдать файл, получить набор полей», — а не разбросана вызовами конкретного SDK по десятку мест. Прослойка добавляет к интеграции 40 000–60 000 ₽, то есть около трети от 180 000 ₽ этой строки, и превращает будущий переезд из проекта на 690 000 ₽ в замену одного адаптера. Та же логика работает и при выборе RPA-платформы, и при выборе модели: сменяемым должен быть любой узел, который вы не контролируете.
Когда не нужно ни то ни другое
Есть четыре ситуации, в которых мы сами советуем не покупать распознавание вообще — ни продуктовое, ни движковое.
- Поток меньше 300 документов в месяц. Ручной ввод в этом объёме стоит 300 × 6 мин = 30 часов, или 21 000 ₽ в месяц. Поддержка и лицензии даже минимальной конфигурации — 40 000–70 000 ₽ в месяц. Арифметика закрывает вопрос без обсуждения функций.
- Контрагенты готовы перейти на ЭДО. Если 80 % потока приходит от двадцати постоянных поставщиков, договориться о структурированном обмене дешевле и надёжнее, чем распознавать их бумагу годами. Распознавание останется для хвоста из разовых поставщиков.
- Справочники в беспорядке. Дубли контрагентов, номенклатура в свободной форме, договоры без номеров — распознанные поля не с чем сопоставлять, и вы получите быстро заполненные, но бесполезные документы. Сначала порядок в данных, потом движок.
- Процесс не описан. Если непонятно, кто принимает документ, кто утверждает расхождение и в какой момент он попадает в учёт, автоматизация зафиксирует хаос в коде. Разобрать процесс на бумаге стоит дешевле любой лицензии — как это делается, показано в материале про обработку первички без ручного ввода.
И последнее. Всё, что написано выше про состав линеек и модели лицензирования, верно по состоянию на сентябрь 2026 года — рынок распознавания в России перестраивается с 2022 года и продолжает двигаться. Устойчива только методика: своя выборка из 200 сканов, метрика «документов без правки», расчёт остатка ошибок в часах и сменяемый узел распознавания в архитектуре. Она переживёт и смену вендора, и смену вашего мнения о нём.
Движок покупают на год, метрику выбирают на всю жизнь системы. Ошибиться во второй дороже.
