Согласование платежей — это управленческий процесс, в котором организация проверяет основание расхода, бюджетный источник, полномочия, реквизиты и срок, а затем разрешает, отклоняет или возвращает платёж на уточнение. Результатом является не банковская операция, а документированное решение: можно ли включить расход в платёжную очередь и на каких условиях.
Главная причина путаницы — одним словом «платёж» называют разные объекты. Подразделение формирует потребность, поставщик выставляет счёт, финансовая служба проверяет статью и лимит, казначейство готовит платёжный документ, банк исполняет поручение, а учётная система фиксирует факт. Если эти объекты не связаны, согласующий видит сумму без контекста, а после оплаты трудно восстановить основание решения.
Разрешение на расход не заменяет бухгалтерский контроль, формирование платёжного поручения и исполнение банком. Оно связывает эти этапы с бизнес-основанием и полномочиями.
Что именно проходит согласование
Маршрут лучше строить вокруг заявки на оплату — карточки, которая объединяет потребность, документы и решение. Счёт может быть одним из приложений, но не всегда является достаточным основанием: могут потребоваться договор, акт, заказ, график платежей, бюджетная строка или решение уполномоченного органа.
| Объект | На какой вопрос отвечает | Кто обычно отвечает | Результат проверки |
|---|---|---|---|
| Потребность / заявка | зачем и в связи с чем нужен расход | инициатор и владелец бюджета | обоснование, проект, статья, срок |
| Договор и первичный документ | возникло ли обязательство и выполнены ли условия | владелец договора, бухгалтерия, юрист по необходимости | комплектность и допустимость оплаты |
| Лимит и платёжный календарь | есть ли источник и когда расход допустим | финансовая служба и казначейство | дата, очередь или решение об исключении |
| Платёжные реквизиты | кому и куда будут перечислены деньги | казначейство / бухгалтерия | подтверждённый получатель и счёт |
| Факт оплаты | что действительно исполнено | банк и учётная система | дата, сумма, статус, идентификатор операции |
Такое разделение не означает пять независимых форм. В едином досье сведения вводятся один раз и дополняются по мере прохождения процесса. Важно сохранять источник каждого значения: кто указал сумму, откуда получены реквизиты и какая версия документа была проверена.
Граница с соседними финансовыми процессами
Контроль бюджетных лимитов отвечает, можно ли принять новую заявку или обязательство в рамках утверждённой базы. Контроль исполнения бюджета сопоставляет план, обязательства, факт и прогноз. Согласование платежа находится между этими контурами: перед конкретной оплатой нужно подтвердить основание, полномочия и место в календаре.
Процесс Procure-to-Pay шире: он начинается с потребности в закупке и заканчивается оплатой поставщику. Согласование платежей может обслуживать не только закупки, но и налоги, возвраты, командировочные расходы, внутригрупповые расчёты и другие виды выплат. Поэтому универсальный маршрут должен учитывать тип расхода, а не копировать закупочный процесс целиком.
Как построить маршрут без универсальной галочки
Каждой роли нужна собственная проверка. Инициатор подтверждает деловую потребность и документы. Владелец бюджета отвечает за приоритет. Финансовая служба проверяет статью и доступный источник. Казначейство — реквизиты, платёжный календарь и техническую готовность. Руководитель подключается, когда сумма или исключение входят в его полномочия.
Статус «согласовано» должен обозначать конкретное решение конкретной роли. Возврат сохраняет причину, адресата и новую контрольную дату, поэтому заявку не приходится собирать заново из переписки.
- Регистрация. Инициатор выбирает тип расхода, получателя, сумму, срок и основание; обязательные поля зависят от сценария.
- Проверка комплектности. Система или контрольная роль подтверждает наличие договора, счёта, акта и других требуемых документов.
- Финансовый контроль. Заявка связывается со статьёй, центром ответственности, проектом и доступным лимитом.
- Проверка реквизитов. Новые или изменённые реквизиты проходят отдельное подтверждение; источник изменения сохраняется.
- Маршрут полномочий. Состав согласующих определяется суммой, типом расхода, организацией и наличием исключения.
- Платёжная очередь. Казначейство назначает дату с учётом приоритета и ликвидности.
- Исполнение и сверка. Статус из банка или учётной системы связывается с заявкой; частичная или отклонённая оплата остаётся видимым исключением.
Свяжите решение, документы и платёжный факт
На базе Comindware Platform можно настроить карточку заявки, маршруты по сумме и типу расхода, задачи согласующим, контроль сроков и обмен с учётной системой. Финансовая методика, полномочия и банковские правила остаются ответственностью организации.
Какие проверки нельзя сводить в один этап
- Деловое основание — расход нужен для заявленной цели и относится к конкретному владельцу.
- Документальное основание — обязательство подтверждено актуальным комплектом документов.
- Бюджетная допустимость — статья, лимит и период выбраны корректно.
- Полномочия — решение принимает роль с правом согласовать такую сумму и тип операции.
- Реквизиты — получатель и банковские данные проверены независимо от инициатора изменения.
- Календарь — дата оплаты учитывает приоритет, договорный срок и доступную ликвидность.
Параллельное согласование ускоряет независимые проверки, но не всегда допустимо. Например, руководитель может оценивать приоритет одновременно с проверкой документов, а казначейство не должно ставить заявку в окончательный реестр до подтверждения финансового источника.
Исключения, которые требуют отдельного решения
Рутинные заявки проходят по правилам. Управленческое внимание нужно там, где правило не выполнено: превышен лимит, не хватает документа, изменились реквизиты, запрошен срочный платёж или один счёт оплачивается частями. Такие случаи полезно выводить в отдельную очередь, а не искать среди сотен строк.
Для исключения фиксируют владельца, основание, срок и следующий шаг. Сам факт ручного вмешательства не является проблемой; проблема — исключение без документированного решения.
| Сигнал | Риск | Какое решение требуется |
|---|---|---|
| сумма выше доступного лимита | необеспеченный расход | перенос, перераспределение или отказ уполномоченной роли |
| изменены реквизиты | ошибочный или мошеннический перевод | независимое подтверждение источника и получателя |
| нет закрывающего документа | оплата до выполнения условия | возврат либо зафиксированное исключение по правилам договора |
| срочность вне календаря | вытеснение более приоритетных платежей | решение владельца ликвидности и корректировка очереди |
| частичная оплата | неверный остаток обязательства | разбиение суммы и сохранение связи с исходным документом |
Интеграция с учётной системой
В публичном материале Comindware о событийной оркестрации описан сценарий, в котором согласование и утверждение платежей выполняются в BPM-платформе, а данные утверждённых заявок передаются в 1С. Информация о фактической оплате возвращается обратно и связывается с бюджетными строками.
Этот пример показывает правильное разделение ответственности: маршрут управляет решением и исключениями, учётная система ведёт финансовый факт, а интеграция не требует ручного переноса статусов. При проектировании нужно заранее определить владельца каждого поля, идентификатор связи, обработку повторной отправки и действие при недоступности внешней системы.
Показатели процесса
Количество согласованных заявок мало говорит о качестве управления. Полезнее видеть время по этапам, долю возвратов, причины исключений, возраст заявок в очереди, платежи с изменёнными реквизитами и расхождения между разрешённой и фактической суммой.
- медианное и предельное время согласования по типу расхода;
- доля возвратов из-за неполных документов и неверной статьи;
- возраст необработанных исключений;
- число срочных платежей вне календаря и их основания;
- доля заявок, для которых факт оплаты не получен или не сопоставлен;
- повторные изменения реквизитов одного контрагента.
Чек-лист готовности к автоматизации
- определены типы выплат и обязательные документы для каждого типа;
- разделены заявка, счёт, разрешение, платёжный документ и факт;
- матрица полномочий зависит от суммы, организации и вида расхода;
- понятны правила параллельных проверок и обязательная последовательность;
- новые реквизиты проходят независимое подтверждение;
- возврат содержит причину, адресата и срок повторной подачи;
- частичные оплаты и отмены не теряют связь с исходной заявкой;
- для интеграции определены владельцы данных и обработка ошибок;
- контроль строится по причинам задержек и исключениям, а не только по количеству заявок.
Проверьте маршрут на реальном наборе платежей
На демонстрации можно разобрать ваши типы заявок, матрицу полномочий, возвраты, платёжный календарь и обмен с учётной системой — без попытки заменить бухгалтерию или банк процессной платформой.
Частые вопросы
Что такое согласование платежей?
Это процесс проверки основания расхода, документов, бюджета, полномочий, реквизитов и срока до включения заявки в платёжную очередь.
Чем заявка на оплату отличается от счёта?
Счёт выставляет контрагент и он содержит данные к оплате. Заявка — внутренний управленческий объект, который связывает счёт с потребностью, договором, бюджетом, согласованиями и фактом.
Кто должен согласовывать платёж?
Состав ролей зависит от типа и суммы расхода. Обычно участвуют инициатор, владелец бюджета, финансовый контролёр, казначейство и руководитель в пределах установленной матрицы полномочий.
Можно ли согласовывать этапы параллельно?
Да, если проверки независимы. Окончательное включение в платёжный реестр должно ждать всех обязательных решений и устранения блокирующих замечаний.
Как контролировать срочные платежи?
Срочность оформляют как исключение с причиной, уполномоченным решением и влиянием на очередь. Она не должна просто отключать остальные проверки.
Нужно ли хранить факт оплаты в BPM-системе?
Бухгалтерский факт остаётся в учётной системе, но его статус и идентификатор полезно передавать в карточку заявки для сквозного контроля и расследования расхождений.
Какие ошибки встречаются чаще всего?
Одна универсальная галочка, согласование суммы без основания, ручное копирование реквизитов, потеря причины возврата, отсутствие контроля частичной оплаты и неподтверждённые срочные исключения.
