УПД распознан. На экране красиво подсвечены номер, дата, поставщик и итоговая сумма. Я всё равно не стал бы проводить документ.
Перед записью в 1С нужно ответить хотя бы на несколько контрольных вопросов: найден ли тот же контрагент в справочнике, сходятся ли суммы по строкам с итогом, корректно ли определён НДС, не загружался ли этот документ раньше, что делать с неизвестной номенклатурой. Распознавание УПД в 1С имеет смысл автоматизировать только вместе с проверкой реквизитов и явным статусом перед созданием учётного документа.
Автоматизация первички начинается не с OCR, а с последовательности статусов, где каждое критичное поле либо подтверждено, либо явно отправлено в исключение.
Первый статус — документ принят, а не готов к проведению
Файл может прийти из почты, папки обмена, ЭДО или загрузки пользователя. На входе я бы сохранил оригинал, канал, время, идентификатор партии и checksum. Это позволяет потом восстановить источник и отличать технический повтор от нового документа.
Затем определяется тип: УПД, счёт-фактура, счёт, акт или другой первичный документ. Ошибка классификации опаснее ошибки одного поля, потому что дальше применяется неверная схема извлечения и проверки.
1С:Распознавание первичных документов как раз строит процесс вокруг загрузки, распознавания и ввода документов в программы 1С. Но для собственного контура важно сохранить явные промежуточные статусы, а не считать любой распознанный файл готовым.
Проверяемые источники: 1С — 1С:Распознавание первичных документов · 1С — Распознавание и автоматический ввод первичных документов
Контрагент подтверждается справочником, а не похожим названием
На странице может быть написано сокращённое название, бренд или старое наименование. Для учётной записи важнее идентификаторы: ИНН, КПП и другие реквизиты, которые позволяют однозначно связать документ с карточкой контрагента.
Если найден один уверенный match, поле получает подтверждённый статус. Если найдено несколько кандидатов или реквизит новый, документ идёт в review. Автоматически создавать нового контрагента по одному скану я бы не стал без отдельной политики.
Полезно хранить не только найденный ID 1С, но и исходное значение документа. Тогда после изменения справочника можно понять, почему система сделала именно такое сопоставление.
Проверяемые источники: 1С — 1С:Распознавание первичных документов · Google Cloud — Document AI overview
Номер, дата и реквизиты требуют нормализации с сохранением оригинала
Дата может быть распознана в нескольких форматах. Номер содержит символы, пробелы или префиксы. Я бы нормализовал значение для поиска и записи, но исходную строку оставлял рядом как доказательство.
Критичный принцип — не исправлять документ молча. Если система решила, что `01.08.26` — это 1 августа 2026 года, правило преобразования должно быть воспроизводимым. Неоднозначный формат отправляется человеку.
Такая педантичность кажется избыточной только до первого спора о том, почему в учёте появилась конкретная дата.
Проверяемые источники: Google Cloud — Document AI overview · Microsoft — Document Processing Models — Document Intelligence
Сумма и НДС проверяются арифметикой, а не confidence модели
Если в документе есть позиции, итог можно сверить с суммой строк с учётом правил округления и налогов. Это сильнее общего confidence: арифметика либо сходится в заданном допуске, либо нет.
Отдельно проверяются ставка и сумма НДС, валюта, количество и цена. При расхождении я бы показывал сотруднику конкретную строку и итоговый контроль. Общей красной метки на весь документ недостаточно.
Document AI и специализированные модели умеют извлекать таблицы и сущности. Но учётный процесс должен самостоятельно определить, какие связи и контрольные суммы являются обязательными до записи.
Проверяемые источники: Google Cloud — Document AI overview · Microsoft — Document Processing Models — Document Intelligence
Номенклатура — отдельная задача сопоставления
Поставщик пишет своё название позиции, а в 1С используется внутренний справочник. Даже идеальное распознавание строки не даёт нужный ID номенклатуры.
Я бы использовал последовательность: артикул или код поставщика, известная таблица соответствий, характеристики, затем только более гибкий поиск по названию. Если совпадение не доказано, создаётся кандидат для ручного выбора и после подтверждения сохраняется новое соответствие.
Главное — не разрешать модели тихо выбирать похожую позицию ради высокого straight-through rate. Ошибка в номенклатуре потом дорого исправляется в учёте и аналитике.
Проверяемые источники: 1С — 1С:Распознавание первичных документов
Проведение разрешается только после набора обязательных статусов
Я бы формализовал Definition of Done: тип документа подтверждён, контрагент найден, ключевые реквизиты проверены, суммы сходятся, дубль исключён, позиции сопоставлены или одобрены, права на создание документа проверены.
Если хотя бы один обязательный статус отсутствует, результат остаётся черновиком или попадает в очередь исключений. Сотрудник видит конкретную причину, исправляет только сомнительное место, после чего проверки запускаются повторно.
Это разделяет распознавание и проведение. Первое может быть вероятностным. Второе должно опираться на подтверждённое состояние.
Проверяемые источники: 1С — 1С:Распознавание первичных документов · 1С — Распознавание и автоматический ввод первичных документов
Каждое исправление сотрудника должно улучшать следующий документ
Ручная проверка полезна не только для текущего УПД. Если сотрудник подтвердил новое соответствие поставщика или номенклатуры, решение стоит сохранить как отдельное правило с источником и датой.
Я бы различал одноразовое исправление OCR и устойчивое mapping-решение. Первое относится к конкретному файлу. Второе может применяться к будущим документам этого контрагента после проверки.
Так очередь исключений должна со временем сокращаться. Если один и тот же реквизит исправляют вручную каждый день, система не учится на подтверждённых правилах процесса.
Проверяемые источники: 1С — 1С:Распознавание первичных документов · 1С — Распознавание и автоматический ввод первичных документов
Контрольные вопросы перед внедрением
Можно ли автоматически загружать УПД в 1С?
Да, если процесс включает не только распознавание, но и проверку критичных реквизитов, сопоставление справочников, контроль дублей и понятный статус перед записью. Не каждый распознанный документ должен проводиться автоматически.
Какие поля УПД нужно проверять особенно внимательно?
Набор зависит от учётного процесса, но обычно критичны стороны документа, номер и дата, суммы, НДС, позиции и реквизиты, от которых зависит проведение. Для каждого поля нужен источник и правило проверки.
Что делать, если AI не уверен в одном поле?
Показать сотруднику именно это поле вместе с фрагментом исходника и причиной сомнения. После подтверждения сохранить решение и повторить зависимые проверки.
Документ готов не тогда, когда OCR закончил работу. Он готов, когда критичные реквизиты имеют подтверждённый статус, исключения разобраны, а система может объяснить происхождение каждого значения, которое собирается записать в 1С.
Для соседних проверок пригодятся для «распознавание УПД в 1С»: Как передавать данные из PDF в 1С с подтверждением сотрудника · Как AI сравнивает договор, счёт и акт между собой · Что делать, если AI неправильно распознал документ.