От распознавания документа до проверенного черновика: где нужны правила, а где решение сотрудника

Автор: VOSHOD

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

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

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

Определите, какой результат вы покупаете

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

Такое ограничение позволяет заранее ответить на вопросы:

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

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

Схема обработки одного документа

Предлагаемая последовательность:

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

Рассмотрим учебный пример. Пришёл счёт на десять единиц товара по 2 000 рублей. В нём указана итоговая сумма 20 000 рублей, а в согласованном заказе десять единиц по 1 900 рублей. Для простоты примера налоги, доставка и дополнительные начисления отсутствуют.

Извлечение может быть совершенно правильным: десять, 2 000, 20 000. Арифметика также сходится. Но цена отличается от заказа. Поэтому результатом должна стать отметка о расхождении и передача ответственному, а не автоматическое признание документа согласованным.

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

Что поручать модели

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

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

Если поле отсутствует или читается неоднозначно, система должна это обозначить. Заполнение «по смыслу» опасно, особенно для номера договора, валюты и реквизитов. Предположение и подтверждённое значение должны иметь разные статусы.

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

Что проверять обычными правилами

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

Например:

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

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

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

Дубли бывают разными

Один файл может прийти повторно без изменений. Тогда помогает контрольная сумма файла. Но тот же документ могут заново отсканировать, переименовать или прислать в другом формате. Побайтовое сравнение уже не даст совпадения.

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

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

Что происходит, если учётная система не ответила

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

Один из способов безопасного повторения называется идемпотентностью: повтор одной операции с тем же идентификатором не должен создавать дополнительный результат. AWS Builders’ Library объясняет этот принцип через идентификатор запроса и обработку повторов на стороне сервиса.

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

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

Очередь исключений должна быть рабочим инструментом

Статус «ошибка обработки» слишком общий. Сотруднику полезнее видеть причину и следующее действие:

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

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

Как принимать такую систему

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

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

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

Материал подготовлен VOSHOD. Сайт проекта · Telegram-бот.

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

Как поручить ИИ разбор счетов и актов, сохранив контроль над деньгами