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

Что считать заявкой, согласованием и оплатой

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

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

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

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

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

Кто отвечает за счёт и какие данные нужны

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

Для маршрута стоит отдельно определить:

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

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

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

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

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

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

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

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

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

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

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

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

Как подтвердить платёж и сверить остаток

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

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

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

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

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

Как проверить готовую программу на своём маршруте

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

Помимо «Майснаб», в сохранённой 13 октября 2026 года версии описания iSpace перечислены настройка маршрутов согласования, реестр плановых платежей, привязка заявки к договору и другим первичным документам, права доступа и просмотр истории изменений. Эти описания помогают составить вопросы поставщику. Они не подтверждают, что любой из продуктов подходит конкретной компании или уже решает все перечисленные выше исключения.

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

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

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

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

Когда обсуждать интеграцию и что передать исполнителю

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

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

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

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

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

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

Источники