Летний спад без кассового разрыва: как использовать план-фактный анализ в 1С
15 июля компании нужно перечислить зарплату, налоги и оплату поставщику. К этой дате должен поступить крупный платёж от клиента, но клиент переносит оплату на конец месяца. Июль по бюджету всё ещё выглядит прибыльным: ожидаемая выручка превышает расходы. Денег в середине месяца всё равно не хватает.
Летом такой сценарий встречается чаще. Продажи замедляются, сроки оплаты растягиваются, а постоянные расходы сохраняют прежний график. Если прогноз не обновляется вместе с датами поступлений, руководитель обнаруживает дефицит уже в день обязательного платежа.
Почему прибыльный месяц всё равно заканчивается нехваткой денег
Компания входит в лето с расходами сильного сезона, но уже без его поступлений. Зарплата, аренда, налоги и договоры с поставщиками привязаны к конкретным датам. Выручка зависит от продаж и того, когда клиент действительно переведёт деньги.
Из-за этого месячный бюджет может сходиться, а одна из недель — уходить в минус. Допустим, на 1 июля на счетах есть 700 тысяч рублей. До 10 июля ожидается оплата клиента на 900 тысяч, а к 15 июля нужно провести обязательные платежи на 1,3 млн. По плану после них останется 300 тысяч. Если клиент переносит расчёт на 25 июля, прогнозный остаток на середину месяца становится отрицательным: не хватает 600 тысяч рублей.
После позднего поступления итог июля может оказаться положительным. Проблема возникает раньше — в день, когда компания обязана заплатить больше, чем есть на счетах.
Новая дата оплаты должна сразу менять прогноз и список платежей, которые можно провести без привлечения заёмных денег.
Что сравнивать в 1С перед низким сезоном
Руководителю нужен короткий набор показателей:
• фактический остаток на счетах и в кассе;
• ожидаемые поступления с суммами и актуальными датами;
• обязательные и переносимые платежи;
• отклонения по сумме и сроку;
• минимальный прогнозный остаток;
• обязательства, на которые этого остатка не хватает.
По принятой в компании методике БДР может показывать прибыль по итогам июля, даже если часть оплат поступит позже. В БДДС перенос клиентского платежа на 25 июля сразу меняет положение дел на 15-е число. Платёжный календарь соединяет остаток, сроки поступлений и заявки на расходы — так становится видно, какое сочетание дат ведёт к дефициту.
При небольшом числе платежей достаточно актуального БДДС, платёжного календаря и своевременных заявок. Отдельный модуль бюджетирования нужен, когда планы собираются по нескольким подразделениям или бюджетам. Интеграция с CRM становится оправданной, если ожидаемые оплаты и статусы сделок хранятся вне 1С.
Что изменили в ТМТМ
Переход от учёта совершённых операций к прогнозу по дням показан в опубликованном кейсе Международной ассоциации «Транскаспийский международный транспортный маршрут». Проект проходил в ноябре–декабре 2020 года.
До внедрения платёжный календарь вели в Excel, заявки на оплату согласовывали на бумаге, а в «1С:Бухгалтерии для Казахстана» отражали уже состоявшиеся поступления и расходы. Поэтому финансовая служба не видела план, факт и будущий остаток в одной системе.
В компании внедрили «БИТ.Финанс Стандарт» и настроили БДР, БДДС и платёжный календарь с разбивкой по дням. Система собирала фактические данные, контролировала лимиты и проводила заявки по заданным маршрутам согласования. Бюджеты были детализированы по 300 статьям оборотов, для анализа загрузили фактические данные начиная с 2017 года.
В описании проекта заявлено, что после внедрения в Ассоциации исключили кассовые разрывы и ситуации, когда платёж был запланирован на день с недостаточным остатком. Автоматизация согласования, по оценке участников проекта, сэкономила 30% времени. Финансовая служба получила возможность увидеть отклонение и сразу перейти к документам, из которых оно сложилось.
Три отклонения, которые нельзя оставлять до конца месяца
Поступление сдвинулось. Сделка закрыта, счёт выставлен, но клиент изменил дату оплаты. В прогнозе нужно обновить срок поступления, а не оставлять деньги в прежней неделе только потому, что продажа уже включена в план.
Расход пришёл раньше или вырос. Поставщик запросил предоплату, закупочная цена изменилась, рекламный бюджет израсходован быстрее. Одно и то же превышение может быть безобидным в конце месяца и критичным перед зарплатой.
В прогноз попали заявки, которые ещё не стали оплатами. В сервисном бизнесе обращение, запись, визит и поступление денег происходят в разные моменты. Если финансовый план учитывает все заявки из рекламы как будущую выручку, ожидаемая сумма оказывается завышенной ещё до начала месяца.
В материале о «сквозной аналитике бьюти-сферы» мы разбирали, почему для оценки продаж нужно считать стоимость реального визита, а не клика или заявки. В финансовый прогноз ожидаемое поступление стоит включать тогда, когда у него появляется обоснованная сумма и дата оплаты.
Компания заранее определяет, какие изменения требуют пересчёта: перенос крупного поступления, превышение лимита или снижение остатка ниже установленного резерва. Сотрудники обновляют даты и суммы, а руководитель решает, какие платежи можно перенести и где потребуется дополнительное финансирование.
Как пересобрать платежи до того, как остаток уйдёт в минус
Отрицательный прогнозный остаток на конкретную дату даёт финансовой службе ясную задачу. В зависимости от причины дефицита компания может:
• ускорить получение клиентских оплат;
• договориться с поставщиками об отсрочке;
• перенести необязательные закупки или рекламные расходы;
• заранее оценить кредитную линию, стоимость финансирования и срок погашения.
Но сам отчёт бесполезен, если сроки поступлений не обновляются, а заявки на расходы появляются только в день оплаты. Особенно заметен этот разрыв там, где запись проходит через сайт или приложение, работа с клиентом — через CRM, а деньги отражаются в 1С. Без обмена между системами финансовый план может учитывать отменённую запись или не видеть полученную предоплату.
В статье о «цифровой экосистеме wellness-бизнеса» показано, как сайт, приложение, CRM и 1С связывают путь от записи до оплаты. Для план-фактного анализа такая схема ценна своевременным обновлением исходных данных. При этом интеграция не заменяет дисциплину: переносы, отмены и будущие обязательства всё равно нужно фиксировать.
Когда достаточно БДДС и платёжного календаря. Такой вариант подходит компании с одним юридическим лицом, небольшим числом расчётных счетов и простым согласованием платежей.
Когда нужна интеграция. Она оправдана при нескольких филиалах, разных каналах продаж, абонементах, предоплатах и разрыве между CRM и учётной системой.
Перед низким сезоном стоит найти в прогнозе ближайшую дату, на которую денег не хватает для обязательных платежей. Тогда у руководителя остаётся время изменить график выплат, ускорить поступление или подготовить финансирование, а не искать деньги в день зарплаты.
