Согласование заявок на оплату: как AI-агент помогает держать расходы под контролем

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

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

Что проверить до передачи заявки на согласование

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

В описании подсистемы казначейства «1С:ERP» указаны заявки на расходование денежных средств, платёжный календарь и контроль лимитов. Это функции учётной системы. Готовый AI-агент в описании не заявлен. Перед интеграцией проверьте конфигурацию своей базы, права пользователей и способы обмена данными. Итоговый статус заявки должен оставаться в системе, где компания ведёт согласование.

Для карточки заявки нужны:

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

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

Что поручить AI-агенту

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

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

Лимиты, пороги и полномочия задаёт компания в своей системе или регламенте. Агент может предложить маршрут по этим правилам. Право одобрить расход, изменить банковские реквизиты и отправить платёж ему не передают. Microsoft описывает процесс согласования в Power Automate: система направляет запрос человеку и фиксирует его ответ. В рассматриваемом сценарии AI помогает подготовить запрос к такому решению.

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

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

Возьмите 30-50 недавних заявок одного типа. Это объём выборки для разбора процесса, а не норматив для всех компаний. Включите заявки, которые возвращали на исправление. Запишите, кто инициировал расход, где возникла задержка, сколько раз меняли документы и какое правило согласования применяли. Отдельно отметьте решения, принятые устно: их трудно восстановить при проверке платежа.

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

Кейс 1С об электронном документообороте в ОТЛК описывает согласование договоров и финансовых документов по настроенным маршрутам, а также обмен с системой финансового учёта. Это чужой проект документооборота. Он показывает, что маршруты согласования можно закрепить в системе; результат ОТЛК нельзя использовать как прогноз для заявок вашей компании. Источник не подтверждает наличие AI-агента в этом кейсе.

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

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

Как разбирать исключения до согласования

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

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

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

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

Как передавать заявку между сотрудниками

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

Владелец бюджета проверяет необходимость расхода и его место в плане подразделения. Ему нужны сумма, доступный лимит, связанные обязательства и объяснение срока. Агент собирает эти сведения, но решение сотрудник фиксирует сам. При отказе он указывает причину, а при запросе уточнения - конкретный вопрос. Так заявка не зависает между статусами «на согласовании» и «возвращена».

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

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

Интеграция с 1С и другими системами

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

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

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

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

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

После описания маршрута согласования и разграничения прав агента можно разместить на облачном сервере Timeweb Cloud. Он сможет по расписанию проверять новые заявки, готовить карточки и отправлять напоминания. Перед запуском ограничьте доступ к финансовым документам, настройте мониторинг заданий и журнал ошибок и назначьте сотрудника, который проверяет сбои. Если сервер или связь с 1С недоступны, сотрудники продолжают согласование по ручному маршруту. Решение об оплате принимает уполномоченный человек.

Пилот: один тип расхода и проверяемый результат

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

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

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

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

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

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

Источники

• 1С:ERP - подсистема «Казначейство»
• 1С - кейс электронного документооборота ОТЛК
• Microsoft Learn - процесс согласования в Power Automate

Если хочешь внедрить ИИ агентов в свой бизнес, но не знаешь с чего начать, пиши мне в телеграм t.me/berdoff, я проведу бесплатную консультацию, поделюсь своим опытом