ИИ для первичных документов: распознавание и загрузка в 1С

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

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

Где теряется время при обработке первички?

Прежде чем автоматизировать, стоит посчитать, на что уходят часы. Обычно не на ввод цифр — на всё вокруг него. Хронометраж на выборке из 20–30 документов разных типов показывает примерно такую структуру работы бухгалтера или оператора:

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

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

Отдельно о масштабе: по опросу VK WorkSpace и Hi-Tech Mail среди более 1000 представителей малого и среднего бизнеса в августе–сентябре 2026 года, главным препятствием для внедрения ИИ 38% назвали отсутствие понятной пользы, и только 4% — стоимость (CNews, 23 сентября 2026). Таблица выше — способ сделать пользу понятной: посчитать часы по этапам и цену ошибок по своим данным, прежде чем обсуждать инструменты.

Чем отличаются OCR, ЭДО, правила и агент?

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

Типовая схема — все четыре вместе: ЭДО закрывает часть потока структурированными данными; OCR превращает остальное в текст и поля; правила проверяют всё, что проверяется однозначно; агент разбирает то, что осталось, и объясняет человеку, почему документ попал в исключения. У 1С есть собственный сервис для первого и части третьего слоя — «1С:Распознавание первичных документов» распознаёт сканы и фотографии счетов, накладных ТОРГ-12, актов, счетов-фактур, УПД, УКД и кассовых чеков, сопоставляет поставщиков, покупателей, товары и услуги с объектами базы и после проверки пользователем создаёт документы в учётной базе (портал 1С:ИТС, «1С:Распознавание первичных документов»). Это важно знать до того, как заказывать разработку: если ваш поток — типовые документы по почте и сканы, и объём умеренный, этого слоя может хватить, и об этом ниже в разделе про готовые сервисы.

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

Как собирать входящие документы?

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

Источники и правила приёма:

• Почта. Отдельный адрес для документов, на который поставщики отправляют первичку; агент читает письма, извлекает вложения, определяет по тексту письма и имени файла, что это и от кого, и ставит в очередь. Письма с общего ящика сотрудников — только по правилу пересылки, иначе половина потока останется в личной почте.
• ЭДО. Документы оператора ЭДО приходят структурированными и подписанными; их не нужно распознавать, но нужно поставить в ту же очередь с пометкой «ЭДО», чтобы контроль закрывающих и сопоставление с заказами шли по единому списку.
• Сканы и фото. Кладовщик фотографирует накладную при приёмке, водитель — акт; файл уходит в очередь через бота в мессенджере или через папку. Качество таких файлов — отдельный риск, и об этом в разделе про извлечение.
• Личные кабинеты и порталы. Маркетплейсы, транспортные компании, операторы связи выкладывают акты и отчёты в кабинете; их забирают по API или по расписанию. Отчёты площадок — отдельная история со своей сверкой; здесь важно, что акты об услугах площадок — тоже первичка, и в очередь они должны попадать.
• Бумага. Остаётся у части поставщиков; сканируется на входе и дальше идёт как скан.

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

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

Карта движения документа — артефакт, который стоит нарисовать до разработки:

1. Поступление — из источника в очередь с метаданными.
2. Классификация — тип документа, контрагент, предполагаемый договор или заказ.
3. Извлечение — реквизиты и строки, с оценкой уверенности по каждому полю.
4. Проверка правилами — обязательные реквизиты, арифметика, дубли, точные соответствия.
5. Сопоставление — контрагент, договор, номенклатура; неточные совпадения — с объяснением.
6. Решение — автоматически в 1С как записанный документ, либо в очередь исключений с основанием.
7. Подтверждение человеком — проведение, правка или отклонение.
8. Контроль — документ закрывает ожидание по оплате или заказу; незакрытые ожидания — в список на запрос поставщику.

Как извлекать реквизиты и строки?

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

Реквизиты шапки. Перечень того, что нужно извлечь, задаёт закон: обязательные реквизиты первичного учётного документа — наименование документа, дата составления, наименование составившего его экономического субъекта, содержание факта хозяйственной жизни, величина натурального и денежного измерения с единицами, должности ответственных лиц и их подписи с расшифровкой (Федеральный закон № 402-ФЗ, статья 9, актуальная редакция). Для работы в учёте к ним добавляются ИНН и КПП сторон, номер документа, номер и дата договора или счёта, суммы с НДС и без, ставка НДС, а для счетов-фактур и УПД — реквизиты, предусмотренные налоговым законодательством. Что именно обязательно для каждого вида документа в вашей ситуации, подтверждает бухгалтер; задача системы — извлечь эти поля и показать, какие из них не найдены.

Табличная часть. Строки с наименованием, количеством, единицей, ценой, суммой, ставкой и суммой НДС. Здесь ошибки распознавания чаще всего: переносы строк, объединённые ячейки, длинные наименования, рукописные правки. Поэтому строки извлекаются вместе с контрольными суммами и сразу проверяются арифметикой: количество × цена = сумма по строке, сумма строк = итог, НДС по ставке = сумма НДС. Если арифметика не сходится, документ не идёт дальше без человека — независимо от «уверенности» распознавания.

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

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

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

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

Ситуация: документы приходят из почты, ЭДО, мессенджеров и сканами, вводятся руками, и каждый месяц кто-то ищет недостающие акты. Что разберём: типы документов, число в месяц, источники, конфигурацию 1С и кто вводит сейчас. Результат: карта движения документа для вашего потока и честный ответ, какой слой нужен — ЭДО, готовый сервис распознавания, правила или агент. Действие: спроектировать пилот обработки первички.

Как обнаруживать дубли?

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

Проверка на дубль идёт в несколько уровней, от строгого к мягкому:

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

Нормализация перед сравнением. Номера документов приводятся к единому виду — убираются символы «№», пробелы, ведущие нули; даты — к одному формату; суммы — сравниваются с допуском в копейки. Без нормализации «Счёт № 0125 от 01.03» и «125 от 1 марта» окажутся разными документами.

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

Как сопоставлять номенклатуру и контрагентов?

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

Контрагенты. Ключ — ИНН, уточнение — КПП. Сопоставление по наименованию недопустимо: «ООО Ромашка» и «Ромашка, ООО» — одна компания, а «ИП Иванов И.И.» и «ИП Иванов И.С.» — разные. Правила:

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

Договоры и заказы. Если в документе указан номер договора или счёта — точное сопоставление. Если нет — поиск по контрагенту и сумме среди открытых заказов поставщику и неоплаченных или оплаченных счетов, с предложением и объяснением: «поступление на 48 300 ₽ от этого контрагента, открыт заказ № 77 на 48 300 ₽ от такого-то числа». Подтверждает человек.

Номенклатура. Самая трудная часть. Уровни сопоставления:

1. По артикулу или штрихкоду поставщика, если он есть в документе и в карточке номенклатуры.
2. По таблице соответствий «наименование поставщика → ваша номенклатура», которая накапливается с каждым подтверждением: однажды сопоставленное «Болт М8 оцинк. DIN 933» в следующий раз сопоставляется автоматически.
3. По семантическому сходству — здесь работает языковая модель: она предлагает наиболее вероятную позицию и объясняет, почему, но предложение подтверждает человек.
4. Нет соответствия — в исключения с основанием «новая номенклатура»; создание позиции только после подтверждения.

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

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

Что разрешать только после подтверждения?

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

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

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

Доступы агента к 1С строятся по тому же принципу минимально необходимого: чтение контрагентов, номенклатуры, договоров, заказов поставщикам и документов поступления за период; запись документов поступления и актов в непроведённом виде; запись в журнал. Прав на проведение, на изменение проведённых документов и на платёжные документы у агента на старте нет. Как устроены роли «читает / пишет / предлагает / запрещено» по системам, уровни автономности, условия остановки пилота и что должно быть в договоре с исполнителем — разобрано в статье как внедрить ИИ-агента в бизнес: пилот, тесты, безопасность.

Персональные данные. Первичка содержит ФИО подписантов, данные ИП, иногда паспортные данные в договорах. Если распознавание или языковая модель работают у внешнего провайдера, документы уходят ему — и это обработка персональных данных со всеми требованиями закона: условия обработки, обязанности оператора, ограничения трансграничной передачи (Федеральный закон № 152-ФЗ, актуальная редакция). Какие именно требования возникают у вас и допустим ли выбранный провайдер — определяет юрист; задача проектирования — знать маршрут каждого документа и зафиксировать его в договоре с исполнителем. Размещение агента на вашем сервере не отменяет вопроса: запросы к модели всё равно уходят её провайдеру, если модель не развёрнута у вас.

Как контролировать недостающие закрывающие?

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

Логика контроля:

1. Источник ожиданий — оплаты и заказы. Каждая исходящая оплата поставщику и каждый заказ поставщику создают ожидание закрывающего документа: по авансу — поступление или акт, по постоплате — проверку, что документ уже есть.
2. Закрытие ожидания — поступивший документ. Когда накладная или акт от того же контрагента на ту же или близкую сумму попадает в очередь и подтверждается, ожидание закрывается. Привязка — по номеру счёта в назначении платежа, по заказу, по сумме и дате с допуском.
3. Список незакрытых — по сроку. Ожидания, не закрытые через согласованное число дней после оплаты или после даты поставки, попадают в список с данными: контрагент, сумма, дата оплаты, что ожидается, кому писали и когда.
4. Запрос поставщику. По списку формируются письма с перечнем документов, которые нужны, и реквизитами оплат; на старте их отправляет человек, после пилота типовые запросы можно отправлять автоматически по согласованному шаблону и расписанию.
5. Контроль ответов. Пришедший документ закрывает ожидание; повторный запрос — через согласованный интервал; эскалация — ответственному, если документ не пришёл к закрытию периода.

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

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

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

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

Качество измеряется до запуска, на пилоте и в эксплуатации — одинаковыми метриками, чтобы цифры можно было сравнивать. «Точность распознавания 98%» без указания, что именно и на каких документах измерялось, — не метрика, а рекламная фраза.

Что считать:

Контрольная выборка. До пилота отбираются 100–300 документов прошлых периодов разных типов и поставщиков, по которым правильные значения известны — они уже введены в 1С и проверены. Система прогоняется на них, и метрики считаются по сравнению с базой. Это и есть тест на исторических данных, без которого ни одно обещание исполнителя не проверяемо.

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

Экономика. Метрики сходятся в одну модель: часы, которые перестали тратить на ввод и поиск, плюс предотвращённые ошибки с их ценой, против стоимости разработки, сопровождения, инфраструктуры и часов на разбор исключений. Как считать эту модель — что считать экономией, почему высвобождённые часы не равны зарплате и при каких объёмах проект не окупается — разобрано в статье сколько стоит ИИ-агент для бизнеса и когда он окупается. На условиях Like Sites документооборот — процесс каталога со стартовой ценой 350 000 ₽, поддержкой 35 000 ₽ в месяц и инфраструктурой 5 000–15 000 ₽ в месяц по факту, с оплатой 50% на старте и 50% после приёмки по метрикам, неделей черновиков и передачей кода и документации клиенту (страница «ИИ-агенты для бизнеса», условия на 31 октября 2026 года). Это условия одного исполнителя, не рыночная цена; метрики выше — способ понять, стоит ли ваш поток таких денег.

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

Когда достаточно готового сервиса?

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

• Большая часть поставщиков в ЭДО. Если документы приходят структурированными и подписанными, распознавать нечего; остаётся сопоставление с заказами и контроль закрывающих — а это часто закрывается настройками учётной системы и дисциплиной.
• Поток умеренный и документы типовые. Счета, накладные, акты, УПД от постоянных поставщиков по почте и сканами — задача готовых сервисов распознавания, в том числе встроенного в 1С, который сопоставляет контрагентов и номенклатуру с базой и создаёт документы после проверки пользователем (портал 1С:ИТС, «1С:Распознавание первичных документов»). Если его точности на вашей выборке хватает, разработка избыточна.
• Нет порядка в справочниках. Два контрагента с одним ИНН, номенклатура с дублями, договоры без номеров — агент будет ошибаться на этих данных. Сначала справочники, потом автоматизация.
• Нет ответственного за очередь исключений. Если некому разбирать вероятные дубли, новых контрагентов и неточные сопоставления, очередь растёт, и документы не доходят до учёта. Автоматизация без владельца хуже ручного ввода.
• Задача на самом деле — не ввод. Если время уходит на согласование документов внутри компании, на споры с поставщиками по суммам или на закрытие периода, распознавание эту проблему не решит. Хронометраж из первого раздела показывает, где именно теряется время.
• Объём мал. Десятки документов в месяц вводятся руками быстрее, чем настраивается и проверяется любая автоматизация; регулярные расходы на сопровождение и инфраструктуру не окупятся.

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

Ситуация: у вас сотни документов в месяц из разных источников, ручной ввод и ежемесячный поиск недостающих актов, и неясно, хватит ли готового сервиса или нужен агент. Что разберём: типы документов, число в месяц, источники — почта, ЭДО, сканы, — конфигурацию 1С и кто вводит сейчас. Результат: ответ, какой слой нужен и какой нет, с метриками на вашей выборке; если нужен агент — состав пилота с порогами и критериями приёмки. Действие: спроектировать пилот обработки первички.