Согласование платежей: маршрут заявки, лимиты и решения согласующих

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

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

Где начинается и заканчивается согласование платежа

В переписке словом «платёж» часто называют и просьбу оплатить счёт, и решение руководителя, и банковскую операцию. Для автоматизации это разные объекты и статусы:

1. Заявка на платёж фиксирует намерение: что, кому, сколько и к какому сроку предполагается оплатить.
2. Проверка устанавливает, заполнены ли обязательные поля, приложено ли основание, совпадают ли значения с источниками и подходит ли заявка под заданный регламент.
3. Разрешение фиксирует решение уполномоченного человека по определённой версии заявки: одобрить, отклонить или вернуть на уточнение.
4. Платёжный реестр группирует разрешённые заявки для дальнейшей работы. Попадание в проект реестра не доказывает оплату.
5. Банковское исполнение происходит отдельно. Его подтверждают статус и идентификатор из системы, которая хранит фактические сведения об операции.

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

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

Какие поля и подтверждения нужны в заявке

Минимальный набор полей зависит от внутреннего регламента, но для описанного маршрута нужны:

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

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

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

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

Как задать маршрут, лимиты и замещение

Маршрут строят из решений, а не из списка должностей. Для каждого шага указывают предмет проверки, условие запуска, допустимые ответы и следующее действие.

Рассмотрим синтетический регламент для учебного примера:

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

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

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

На время отсутствия согласующего подходят два заранее выбранных состояния:

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

Нельзя назначать заместителя задним числом только ради прохождения конкретной заявки. В журнале следует сохранить, кто принял решение, в какой роли и на каком основании получил задачу.

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

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

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

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

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

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

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

Учебный пример изменения суммы после согласования

Ниже приведён синтетический пример, а не результат клиента Switch On AI и не проверка реальной финансовой системы.

Инициатор создаёт заявку поставщику на 90 000 ₽ в валюте RUB. Финансовый согласующий одобряет версию v1. Затем инициатор меняет сумму на 120 000 ₽ и повторно нажимает «Отправить». Остальные поля остаются без изменений.

Разница составляет 120 000 − 90 000 = 30 000 ₽. Относительное увеличение: 30 000 / 90 000 × 100% = 33,33% с округлением до двух знаков. Но пересогласование требуется не из-за самого процента. Новая сумма пересекает установленный в учебном регламенте порог 100 000 ₽ и запускает другой состав решений.

Маршрут версий

Пока v2 не прошла новый маршрут, исполнение по ней запрещено внутренним правилом примера. Одобрение v1 не переносится автоматически: согласующий принимал решение по другой сумме и другому набору условий.

Журнал версий

Обязательную сводку можно сформулировать так:

Главный вывод примера: решение принадлежит версии, а не заявке вообще. Журнал сохраняет прежнее согласование как факт истории, но новая версия получает собственный маршрут.

Как связать разрешение с бюджетом и реестром

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

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

Продолжим синтетический пример. Бюджет на октябрь — 250 000 ₽. Фактически исполнено 80 000 ₽, ещё 40 000 ₽ запланировано по другим заявкам. Доступный плановый остаток перед учётом v2:

250 000 − 80 000 − 40 000 = 130 000 ₽.

Если после всех решений v2 на 120 000 ₽ включат в план, расчётный остаток составит:

130 000 − 120 000 = 10 000 ₽.

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

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

Такая интеграция не работает с банковскими ключами и не распоряжается деньгами. Работа с 1С в эту услугу не входит. Правила бухгалтерского и финансового учёта задаёт и проверяет специалист заказчика.

Как принять автоматизацию согласований

До разработки запишите сценарии приёмки как пары «входное условие — ожидаемое поведение». Следующие пункты — проект проверок, а не заявление о выполненном тесте:

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

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

Описание подхода и границ полномочий есть на странице разработки AI-агентов. Общий маршрут документов разобран отдельно в материале об автоматизации согласования документов; здесь предметом остаётся исходящая заявка на платёж и связь её версии с разрешением.

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