Платежный календарь: приоритизация оплат и прогноз остатка

Что такое платежный календарь и какую проблему он решает

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

Главная проблема, которую он решает, - отсутствие понятной очереди оплат. Когда заявок много, а денег ограниченно, легко оплатить «кто громче попросил», забыть про обязательные платежи или не увидеть, что через три дня счет уйдет в минус.

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

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

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

Какой формат выбрать: горизонт, детализация, валюта

Формат платежного календаря должен отвечать на один вопрос: сможете ли вы за 2-3 минуты понять, хватит ли денег на ближайшие оплаты и что переносить, если денег не хватает.

Горизонт: день, неделя или месяц

Если у компании много платежей и остаток меняется каждый день, берите дневной горизонт минимум на 2-4 недели вперед. Так кассовый разрыв становится виден заранее, а не в день оплаты.

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

Детализация: что обязательно

Чтобы календарь не превратился в «табличку для галочки», в каждой строке должны быть: контрагент и сумма, договор или счет (основание), дата плановой оплаты и возможность сдвига, статья платежа (налоги, зарплата, аренда, поставщики), а также статус (заявка, согласовано, в оплате, оплачено).

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

Валюта: одна или несколько

Чтобы не запутаться, заведите «рабочую» валюту (часто KZT) и храните рядом исходную валюту платежа. Пересчет делайте по фиксированному правилу: например, курс на дату планирования или курс банка на дату платежа. Главное - одно правило для всех, иначе прогноз остатка будет постоянно «прыгать».

Факт оплат и связь с банком

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

Какие данные нужны на входе и откуда их брать

Календарь работает ровно настолько хорошо, насколько точны входные данные.

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

Дальше - ожидаемые поступления: продажи, авансы, возвраты от поставщиков, возмещение НДС, проценты, разовые поступления. Самая частая ошибка - брать поступления «как в бюджете». Для календаря включайте только то, что привязано к конкретной дате и подтверждено (счет, договор, письмо, график оплат, история по клиенту).

Вторая половина картины - плановые платежи. Важны суммы, даты и основания: закупки, зарплата, налоги, аренда, лизинг и кредиты, сервисные контракты, командировки. Например, у производственной компании вроде GSE.kz закупки комплектующих и логистика часто имеют жесткие даты: сдвиг платежа может остановить поставку. Поэтому у каждой заявки должно быть понятное «почему платим именно сейчас».

Чтобы данные не расползались по чатам и таблицам, заранее закрепите источники. Остатки - интернет-банк, бухгалтерия, казначейство (ежедневная сверка). Поступления - CRM и реестр счетов, договоры, подтверждения от клиентов. Платежи - заявки подразделений, графики по налогам и кредитам, кадровый план по зарплате. Плюс ограничения: лимиты по счетам, требования банка, даты закрытия периода, внутренние запреты.

Ограничения лучше занести отдельным блоком. Тогда календарь показывает не только «хотим оплатить», но и «можем оплатить сегодня».

Как собирать заявки на оплату без хаоса

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

Сделайте одну форму заявки и договоритесь, что другие каналы не считаются заявкой. Форма может быть в таблице, учетной системе или сервис-деске - важно, чтобы шаблон был один.

Минимальный набор полей обычно такой: сумма и валюта, желаемая дата оплаты, основание (счет, акт, счет-фактура) и номер договора, статья/назначение платежа, инициатор и подразделение.

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

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

Срочные заявки неизбежны, но им тоже нужна дисциплина. Введите признак «срочно» и обязательное поле «почему срочно» (1-2 фразы). Полезно заранее определить, какие причины считаются допустимыми.

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

Логика приоритизации заявок на оплату

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

Удобно заранее договориться о четырех группах и закрепить их в регламенте:

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

Внутри группы сначала смотрят на прямые потери (штрафы, пени), затем на риск остановки процессов, дальше на репутационные риски (особенно при работе с крупными заказчиками и госконтрактами). Скидки за раннюю оплату - уже после этого.

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

Чтобы решения не терялись, фиксируйте изменения прямо в заявке: кто и когда поменял дату или сумму, причина переноса (код и комментарий), новая дата и условие возврата в очередь (например, «после поступления оплаты от клиента»), кто согласовал. Так календарь становится управляемой очередью, а не «таблицей на сегодня».

Как считать прогноз остатка денежных средств

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

Формула на каждый день: стартовый остаток + поступления - платежи = прогноз остатка. Важно считать цепочку по дням, а не один итог на конец недели.

Чтобы прогноз не превращался в фантазию, разделяйте план и факт. Удобно держать «ожидали» и «получилось» рядом, плюс отклонение и причину (клиент перенес оплату, банк задержал зачисление, поставщик изменил дату). Так накапливается статистика, и прогноз становится точнее.

Частичные оплаты и платежи по этапам лучше вести отдельными строками. Например, счет на 10 млн можно разнести на три платежа: аванс 30% в понедельник, промежуточный 40% в среду, финальный 30% после акта. Тогда один крупный платеж не «роняет» прогноз, а переносить проще конкретный этап.

По валюте держитесь простых правил: базовая валюта календаря (часто тенге), пересчет по заранее закрепленному курсу. Рядом храните сумму в валюте и небольшой «запас на курс» в процентах, если курс скачет. Тогда видно, что при росте курса на 3%-5% понадобится больше тенге, и можно заранее сдвинуть некритичные оплаты.

Кассовые разрывы: ранние сигналы и варианты действий

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

Ранние сигналы и пороги

Заранее задайте два порога: минимальный резерв (на обязательные платежи и непредвиденные расходы) и тревожный уровень (когда уже нужно вмешиваться). Например, резерв - 5 млн, тревожный уровень - 2 млн. Если на среду прогноз показывает 1,6 млн, это не «плохой день», а точка, где надо менять план оплат.

Полезно держать три сценария: стандартный (по плану), стресс (ключевые поступления сдвинулись на 3-7 дней), оптимистичный (часть денег приходит раньше).

Пример: во вторник ждете поступление 4 млн, а в среду нужно оплатить поставщику 6 млн. В стресс-сценарии поступление переносится на пятницу, и разрыв возникает именно в среду.

Что делать, если разрыв уже на горизонте

Выбирайте действия по скорости и «цене» решения. Чаще всего помогает перенос платежа (частично или полностью) на дату после поступления, дробление оплаты на 2-3 транша, рассрочка, пересборка приоритетов. Кредитная линия или овердрафт тоже могут быть мостом, но только под понятный срок закрытия.

Главное - фиксировать решение в календаре сразу, чтобы команда видела обновленный план.

Сценарии согласования и контрольные точки

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

Роли и что проверяет каждая

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

Уровни согласования: по сумме и по типу

Лучше задать два набора правил. Первый - по сумме (до X, от X до Y, выше Y). Второй - по типу платежа: налоги и зарплата идут по ускоренной ветке, а авансы поставщикам и разовые закупки могут требовать дополнительных проверок (договор, лимит, приемка).

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

Исключения (срочно, вне лимита, без договора) оформляйте одинаково: причина срочности и крайний срок, источник покрытия (что переносим или какой резерв используем), риск, кто утверждает, и план закрытия «хвостов» по документам.

Пример на простой неделе: как календарь помогает принять решение

Допустим, в понедельник на расчетном счете 12 млн тг. В календаре стоит поступление от клиента 15 млн тг в среду, но во вторник клиент сообщает: оплата задержится на 5 дней.

Плановые оплаты на неделе:

• Понедельник: налоги 4 млн тг (переносить нельзя)
• Вторник: аренда 2 млн тг (штраф за просрочку)
• Четверг: поставщик 10 млн тг (комплектующие, критично для производства)
• Пятница: зарплата 8 млн тг (переносить нельзя)

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

Решение фиксируют прямо в календаре: что оплачиваем, что переносим, что дробим, и кто это утвердил. Например, поставщику платим 5 млн тг в четверг, остаток 5 млн тг переносим на следующий вторник; неприоритетные заявки (командировки, мебель, маркетинг) сдвигаем на следующую неделю; руководителей проектов предупреждаем о риске задержки поставки.

После решения прогноз остатка по дням выглядит так:

Календарь показывает разрыв заранее (в пятницу минус 7 млн тг). Значит, еще в начале недели можно согласовать действия: ускорить дебиторку, привлечь краткосрочный лимит, перенести часть оплат или заранее договориться с поставщиком.

Частые ошибки и ловушки при внедрении

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

Частые ошибки:

• Смешивают план и факт в одной колонке. В итоге непонятно, на какой день вы реально рассчитываете деньги.
• Не задают правила для срочных платежей. Когда каждый день «очень срочно», приоритизация превращается в ручные исключения.
• Включают в прогноз обещания без подтверждений. Для сомнительных поступлений нужен отдельный статус или учет только части суммы.
• Нет одного ответственного и регулярного ритма. Если календарь обновляют «когда вспомнят», обсуждают устаревшие цифры.
• Нет связи со статусами согласования. Без статусов (черновик, на согласовании, согласовано, оплачено) непонятно, что вообще можно платить.

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

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

Короткий чек-лист: быстрые проверки перед оплатой

Каждый день начните с факта: обновите остаток по счетам и отметьте, что реально оплачено и что реально поступило. Затем проверьте критичные платежи на ближайшие 1-3 дня и убедитесь, что даты и суммы не изменились.

Перед тем как нажать «оплатить», пройдите пять пунктов:

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

Раз в неделю сверяйте ожидаемые поступления: что подтверждено, что под вопросом, где нужна работа с дебиторкой. После этого пересоберите прогноз и заранее утвердите лимиты на неделю.

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

Следующие шаги: как внедрить и поддерживать процесс

Начните с короткого пилота на 2-4 недели. Возьмите один контур и минимальный набор статей: налоги, зарплата, ключевые поставщики, аренда, кредиты. Цель - каждый день получать актуальные заявки и видеть прогноз остатка хотя бы на 2-3 недели вперед.

Чтобы процесс не рассыпался, закрепите понятные роли и ритм: владелец календаря (обычно казначейство) собирает заявки, ведет прогноз и фиксирует переносы; инициаторы (закупки, бухгалтерия, проекты) подают заявки по шаблону и вовремя обновляют даты; утверждающий (финансовый директор/руководитель) принимает решения по приоритетам и лимитам. Договоритесь об окне для новых заявок до фиксированного времени и коротком ежедневном согласовании на 10-15 минут. Любая правка даты или суммы должна сопровождаться причиной.

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

Когда пилот стабилизируется, оцените ИТ-основу. Если календарь упирается в скорость, права доступа и надежность данных, стоит переходить на более устойчивую инфраструктуру для финансовых систем: рабочие станции и серверы, а также интеграции с учетными системами, чтобы заявки, выписки и план-факт сходились без ручной правки. В Казахстане такие задачи часто закрывают через GSE как производителя и системного интегратора (сайт gse.kz).