Счёт с отсрочкой: почему согласование платежей ломается именно здесь

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

Как обычно выглядит согласование платежей

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

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

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

Счёт с отсрочкой висит в подвешенном состоянии. Формально он согласован, значит, процесс по нему завершён. Фактически по нему ничего не сделано. В отчёте он выглядит закрытым, в реальности — нет.

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

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

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

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

Решение, к которому мы пришли на проектах, выглядит так. В процессе появляется отдельный статус — «отсрочка». Туда попадает всё, у чего желаемая дата платежа больше, чем сегодня.

Если дата платежа сегодня или завтра — счёт сразу идёт в статус «оплатить», минуя отсрочку. Если позже — уходит в отсрочку и там спокойно лежит. При этом сразу создаётся задание бухгалтеру: завести счёт в платёжный календарь. То есть ожидание фиксируется не в чьей-то голове, а в системе.

За день до желаемой даты счёт автоматически переезжает в статус «оплатить счёт», и на ответственного падает задача на оплату. Никто ничего не вспоминает — система напоминает сама, ровно тогда, когда это нужно.

Механика вроде бы элементарная. Но именно она превращает согласование платежей из красивой схемы в работающий процесс.

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

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

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

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

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

Второе — исчезает категория «забыли оплатить». Это звучит смешно, пока не посчитаешь, во сколько такие забывания обходятся: пени, испорченные отношения с поставщиком, остановка поставки в сезон.

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

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

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

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

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

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

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

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

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

Мы занимаемся автоматизацией внутренних процессов на Битрикс24 — lidkom.ru.