Распознавание документов с помощью ИИ: счета, накладные и акты без ручного ввода

Короткий ответ: ИИ читает скан или PDF счёта, накладной, УПД или акта, определяет тип документа и раскладывает данные по полям — контрагент, ИНН, номер, дата, строки товаров, суммы и НДС. Программа сверяет суммы и реквизиты, сотрудник подтверждает черновик, и только потом запись уходит в 1С или другую систему. Ручной ввод сменяется проверкой. Цена — из тарифов прайса: ИИ-решение от 72 000 ₽ и от 3 дней, связка с учётной системой от 32 000 ₽ и от 2 дней; подробности — на странице внедрения ИИ.

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

Чем ИИ-распознавание отличается от обычного OCR?

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

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

Языковая модель на шаблоны не опирается: она читает документ так, как его прочитал бы бухгалтер, — по смыслу подписей «ИНН/КПП продавца», «Всего к оплате», «Основание». Цена этого — вероятностный результат. Модель может уверенно вернуть неверную цифру, поэтому в рабочей схеме у неё всегда есть два страховочных слоя: арифметические проверки программой и подтверждение человеком.

• OCR с шаблонами подходит, когда форм мало, они стабильны и важна предсказуемость.
• ИИ-извлечение подходит, когда форм много, они меняются, а документы приходят сканами и фото из разных источников.
• Ни то, ни другое не нужно, если документы уже электронные и структурированные — об этом ниже.

Документ и источник	Как распознаётся	Где чаще ошибки	Что делать
PDF, выгруженный из учётной программы поставщика	Уверенно: текст уже внутри файла, его не нужно «видеть»	Редко; иногда путается порядок колонок в таблице товаров	Сверять итог строк с итогом документа
Скан с принтера 300 dpi, ровный лист	Хорошо, если печать и подпись не закрывают цифры	Суммы под печатью, мелкий шрифт в табличной части	Подсветить поля с низкой уверенностью
Фото с телефона на столе	Средне: перекос, тени, блики	Цифры 3/8, 1/7, пропущенные строки на сгибе	Требовать фото на ровной поверхности, проверять каждую сумму
Многостраничная накладная с сотнями строк	Медленнее, ошибки накапливаются	Строки на стыке страниц, переносы наименований	Сверять число строк и итог по каждой странице
Рукописные пометки, исправления от руки	Плохо и непредсказуемо	Любые поля, где цифру исправили ручкой	Отправлять человеку целиком
Электронный УПД из ЭДО (XML)	Распознавать не нужно: данные уже структурированы	—	Загружать напрямую, без ИИ

Какие документы распознаются хорошо, а какие плохо?

Уверенно читаются PDF, выгруженные из учётной программы поставщика, и ровные сканы: цифры в них чёткие. Хуже — фото с телефона, длинные многостраничные накладные и всё, что исправлено от руки. Электронный УПД из ЭДО распознавать вообще не нужно.

Про ЭДО стоит сказать отдельно, потому что на нём многие переплачивают. Формат электронного счёта-фактуры и УПД утверждён приказом ФНС России от 19.12.2023 № ЕД-7-26/970@: в таком файле каждый реквизит уже лежит в своём поле. Если половина ваших поставщиков работает через оператора ЭДО, их документы загружаются в учёт обычным обменом, без модели. ИИ нужен для второй половины — тех, кто присылает бумагу, скан или PDF на почту.

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

Поле	Что извлекаем	Как проверяем программой	Когда стоп и к человеку
ИНН и КПП продавца и покупателя	Цифры без пробелов	Длина 10 или 12 знаков, контрольные цифры ИНН, поиск контрагента в справочнике	Контрагент не найден или ИНН не прошёл проверку
Номер и дата документа	Как напечатано, дата в одном формате	Дата не в будущем и не старше периода, номер не повторяет уже загруженный	Возможный дубль документа
Табличная часть	Наименование, количество, единица, цена, сумма, ставка НДС	Количество × цена = сумма строки с допуском на округление	Расхождение больше копеек
Итоги	Сумма без НДС, НДС, всего к оплате	Сумма строк = итог; НДС пересчитывается по ставке из документа	Итоги не сходятся
Банковские реквизиты	БИК, расчётный и корреспондентский счёт	Длина БИК и счетов, контрольный ключ счёта вместе с БИК, сравнение с карточкой контрагента	Реквизиты отличаются от прежних платежей
Основание	Номер договора или заказа	Поиск договора у этого контрагента в учёте	Договор не найден

Какие поля извлекать и как проверять суммы и ИНН?

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

Это главная идея всей схемы: модель не проверяет сама себя. Её ответ проверяет обычный код по правилам, которые не зависят от того, насколько уверенно модель «прочитала» документ.

• Арифметика. Количество × цена = сумма строки; сумма строк = итог без НДС; итог без НДС + НДС = всего к оплате. Если хотя бы одно равенство не сходится, ошибка почти наверняка в распознавании, а не в документе.
• Контрольные цифры. У ИНН организации 10 цифр, у ИП и физического лица — 12, и последние цифры вычисляются по формуле из остальных. Случайная ошибка в одной цифре обычно ломает контрольную сумму и ловится сразу.
• Справочники. ИНН ищем в карточках контрагентов, номер договора — у этого контрагента, единицы измерения — в вашем справочнике. Новый контрагент — повод для человека посмотреть внимательнее.
• Дубли. Тот же поставщик, номер и дата уже загружены — система не создаёт второй документ, а показывает первый.
• Изменившиеся реквизиты. Если в счёте расчётный счёт не совпадает с тем, на который вы платили раньше, это стоп-сигнал: так выглядит и смена банка, и мошеннический счёт.

Сопоставление строк товаров с вашей номенклатурой — отдельная задача. У поставщика «Саморез 4,2×19 ПШ оц.», у вас — «Саморез по металлу 4,2х19». ИИ предлагает соответствие, человек подтверждает его один раз, и дальше пара запоминается. Через месяц работы большинство строк от постоянных поставщиков сопоставляется по сохранённым парам, а не заново.

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

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

Подтверждение не означает «перепечатать всё заново». Хороший экран проверки устроен так, чтобы на один документ уходили секунды, а не минуты:

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

Так устроен и наш продукт «Реестр» для договорной документации строительства. По данным кейса — около 35 секунд на распознавание одного документа и 9 типов документов в одной цепочке связей; ИИ извлекает реквизиты, сотрудник проверяет, а каждое изменение в базе проходит подтверждение, пишется в журнал и может быть откачено. Как он работает с договорами, КС-2, КС-3 и платёжками, мы подробно разбирали в статье о документах ПТО.

Как данные попадают в 1С?

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

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

1. Тип документа в 1С. Счёт поставщика, поступление товаров, поступление услуг — у каждого свой набор обязательных полей. Его фиксируем в ТЗ.
2. Правила по номенклатуре. Что делать со строкой, которой нет в справочнике: создать новую позицию, поставить в очередь человеку или записать одной строкой «услуги».
3. Склад, статья затрат, подразделение. На скане этого нет — значения берутся из правил: по контрагенту, по договору или по выбору сотрудника на экране проверки.
4. Скан в учёте. Исходный файл прикладываем к документу, чтобы при проверке не искать бумагу.

Если учёт ведётся не в 1С, схема та же: CRM, складская программа или таблица получают данные через API. Связка до двух систем входит в тариф интеграций; доработка самой конфигурации 1С на её стороне в этот тариф не входит и оценивается отдельно.

Как измерить точность до запуска?

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

Порядок замера, который мы предлагаем заказчику на брифе:

1. Выборка. 50–100 документов за обычный месяц: разные поставщики, сканы и фото, длинные и короткие, удачные и неудачные. Не выбирайте самые чистые — тогда цифра будет красивой и бесполезной.
2. Эталон. Сотрудник заполняет правильные значения полей в таблице. Это скучная работа, но без неё замер не имеет смысла.
3. Прогон. Документы проходят через систему, результат сравнивается с эталоном построчно.
4. Разбор по полям. ИНН, итог и дата могут читаться почти всегда верно, а сопоставление номенклатуры — заметно хуже. Отсюда решение: какие поля сотрудник может принимать взглядом, а какие сверяет всегда.
5. Разбор по источникам. Часто выясняется, что почти все ошибки дают два-три поставщика с неудобной формой или фото с телефона. Иногда проще договориться с ними о PDF или ЭДО, чем усложнять систему.

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

Когда распознавание вам не нужно и какие ошибки встречаются?

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

• Десятки документов в месяц. Если ввод занимает час в неделю, разработка и сопровождение не стоят этого часа. Посчитайте объём до разговора о модели.
• Поставщики на ЭДО. Электронные документы загружаются обменом; модель там лишняя.
• Готовые возможности учётной системы. Проверьте, что уже умеет ваша программа и ваш оператор ЭДО: если штатной загрузки хватает, начните с неё — это дешевле.
• Ошибка: автоматическое проведение. «Пусть само проводится, если уверенность высокая» — так однажды проходит счёт с чужим расчётным счётом.
• Ошибка: замер на чистых примерах. Пилот на десяти идеальных PDF даёт цифру, которая не повторится на реальном потоке.
• Ошибка: нет журнала. Без записи «кто подтвердил, что исправил, с какого скана» невозможно разобраться в спорной проводке.
• Ошибка: забыть про персональные данные. В актах и накладных бывают ФИО и паспортные данные водителей и доверенных лиц. Где работает модель — в российском облаке, на вашем сервере или в зарубежном сервисе, — решаем до разработки; разбор — в статье о 152-ФЗ и облачном ИИ.

Из чего складывается стоимость?

Из двух тарифов прайса и расходов на модель. ИИ-решение для распознавания и проверки — от 72 000 ₽ и от 3 дней, связка до двух систем, например почты и 1С, — от 32 000 ₽ и от 2 дней. Работу модели вы оплачиваете её поставщику по факту, со своего аккаунта: в тариф эти расходы не входят.

Что двигает цену вверх от базовой:

• Число типов документов. Счёт и УПД — одна история; добавить акты, доверенности и договоры — уже другая.
• Источники. Одна почта — просто; почта, бот для фото со склада и папка на диске — больше работы.
• Сопоставление номенклатуры. Если строки нужно разносить по вашим позициям, а не одной суммой, это отдельный блок работы.
• Экран проверки. Простая очередь документов или полноценный кабинет с ролями, журналом и откатом. Система уровня «Реестра» с цепочками связей и финансами делается по тарифу «Веб-приложение / SaaS» — от 160 000 ₽ и от 10 дней.
• Сопровождение. Новые формы поставщиков появляются постоянно; поддержка и развитие — от 7 900 ₽ в месяц.

Работаем по договору: оплата 50/50, приёмка — 5 рабочих дней, до 2 раундов правок, гарантия — 30 календарных дней с даты акта. Итоговую цену и срок называем после брифа и замера на ваших образцах и фиксируем в договоре до старта.

С чего начать?

С подсчёта и выборки. Запишите, сколько документов в месяц вводится вручную, от скольких поставщиков, какая доля приходит через ЭДО и сколько минут уходит на один документ. Затем соберите 20–30 типичных образцов — с этого начинается разговор о составе работ.

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

Короткие ответы на частые вопросы

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

OCR превращает картинку в текст, но не понимает, где в нём номер счёта, а где сумма к оплате. ИИ поверх распознанного текста определяет тип документа и раскладывает данные по полям, даже если каждый поставщик рисует счёт по-своему.

Нужно ли распознавать электронные УПД из ЭДО?

Нет. Электронный УПД приходит в формате, утверждённом ФНС, и данные в нём уже разложены по полям. Его загружают в учёт напрямую; распознавание нужно для бумаги, сканов, фото и PDF.

Может ли ИИ сам провести документ в 1С?

В наших схемах — нет. ИИ создаёт черновик с заполненными полями, а сотрудник сравнивает его со сканом и проводит. Записи, связанные с деньгами, подтверждает человек.

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

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

Сколько стоит распознавание документов под ключ?

Цена собирается из тарифов прайса: ИИ-решение — от 72 000 ₽ и от 3 дней, связка с 1С или другой системой — от 32 000 ₽ и от 2 дней. Работу языковой модели вы оплачиваете её поставщику по факту, со своего аккаунта. Итог называем после брифа и фиксируем в договоре до старта.

Услуги и кейсы по теме: внедрение ИИ под ключ · интеграция с 1С и CRM от 32 000 ₽ · кейс «Реестр» · цены и сроки