директор и машина · финансы · запись № 007 · 16 июня 2026 · Давид Герштейн

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

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Финансовый директор рассчитал прибыль за период и распределил её между сотрудниками. В том же месяце выяснилось: денег на рекламу нет. Коллеге пришлось вносить личные средства, чтобы кампании не остановились. Разбор показал: платёжный календарь должен был показать кассовый разрыв за месяц-два до того, как он случился. Резервного фонда не было вообще.

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

Что такое платёжный календарь и чем он не является

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

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

В другой компании — производстве на заказ с отделом из 8 менеджеров и оборотом около 12 млн ₽/мес — средние ежемесячные расходы превышали выручку. Дефицит кассы по итогам месяца — около 1,2 млн ₽, то есть порядка десятой части месячной выручки. Этого не хватало даже на зарплаты. Цифра считается заранее, простым вычитанием обязательств из ожидаемых поступлений. Без календаря её видят в день, когда нужно платить.

На диаграмме — соотношение выручки, расходов и дефицита кассы за месяц (легендированные суммы).

Механика: что → чем → куда за 4 шага

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

1. Что берём. Два списка: обязательства (счета к оплате, зарплата, аренда, налоги — с датой и суммой) и ожидаемые поступления (сделки с датой оплаты по договору и вероятностью, что деньги придут вовремя). Источник — CRM (Bitrix24, amoCRM) и банковская выписка.
2. Чем считаем. Скрипт или модель раз в сутки сводит оба списка по неделям и считает разрыв: поступления минус обязательства. Для чистой агрегации без интерпретации хватает дешёвой модели — это не аналитика, а арифметика по структурированным данным.
3. Куда попадает результат. В таблицу (Google Sheets) с условной раскраской: неделя в минусе — красная. Копия результата — в Telegram-чат финансиста и собственника, без дополнительных кликов.
4. Кто и когда смотрит. Фиксированное время раз в неделю, не по требованию. В одной компании время финансового планирования специально перенесли с утра на 13:00 четверга — чтобы данные успевали собраться полностью до разговора, а не в процессе него.

ИИ-связка: прогноз разрыва без ручного сведения таблиц

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

Схема конвейера: Bitrix24-вебхук выгружает сделки со статусом оплаты и датой → Google Apps Script раз в сутки в 07:00 кладёт их в лист «receipts», а счета к оплате — в лист «obligations» → скрипт вызывает API дешёвой модели с промптом ниже → ответ пишется в лист «calendar» → строки с риском подсвечиваются условным форматированием → копия сводки уходит в Telegram-бота ответственному.

Модель — дешёвая (класса gpt-4o-mini или аналог). Задача не требует рассуждений — это агрегация чисел по датам и сравнение с порогом. Дорогая модель здесь не даёт точности выше, только увеличивает счёт.

Ты — финансовый аналитик. На входе JSON с двумя массивами:
"obligations" (обязательства: дата, сумма, статья) и
"receipts" (ожидаемые поступления: дата, сумма, вероятность оплаты от 0 до 1, источник).

Задача:
1. Сгруппируй обе таблицы по неделям (понедельник-воскресенье).
2. Для каждой недели посчитай сумму обязательств и сумму поступлений
   (поступления умножь на вероятность).
3. Посчитай разрыв = поступления - обязательства для каждой недели.
4. Если разрыв отрицательный — пометь неделю risk: true и укажи дефицит.
5. Не давай советов и рекомендаций. Только цифры и метки риска.

Верни строго JSON без пояснений в формате:
{"weeks":[{"week_start":"YYYY-MM-DD","obligations":0,"receipts":0,"gap":0,"risk":false}]}

Входные данные:
{"obligations":[{"date":"2026-06-03","sum":420000,"item":"аренда+зарплата"}],
"receipts":[{"date":"2026-06-05","sum":500000,"probability":0.7,"source":"сделка №118"}]}

Пример ответа модели на модельных (иллюстративных) данных:

{"weeks":[
  {"week_start":"2026-06-01","obligations":420000,"receipts":350000,"gap":-70000,"risk":true},
  {"week_start":"2026-06-08","obligations":310000,"receipts":355000,"gap":45000,"risk":false}
]}

Так это выглядит в самом листе «calendar», куда скрипт кладёт ответ модели:

Второй шаг конвейера — короткое уведомление человеку, а не сырой JSON. Для этого второй, тоже дешёвый, вызов модели превращает результат в текст для Telegram:

Ты — ассистент финансиста. На входе JSON с неделями и полем risk.
Составь короткое сообщение для Telegram (не длиннее 3 строк):
для каждой недели с risk: true укажи дату начала недели и сумму дефицита.
Если рисковых недель нет — напиши одну строку "Разрывов на 4 недели вперёд не найдено".
Тон нейтральный, без оценочных слов.

Входные данные: {"weeks":[{"week_start":"2026-06-01","gap":-70000,"risk":true}]}

Пример ответа: «Неделя с 01.06: дефицит ≈17% от суммы обязательств. Проверьте перенос платежей или поступление по сделке №118.»

Инженерная обвязка. Всё крутится на бесплатном тарифе Google Apps Script (триггер по расписанию) плюс API дешёвой модели. Если вебхук Bitrix24 не ответил или структура данных не совпала с ожидаемой — скрипт не падает молча, а пишет строку ошибки в отдельную ячейку листа «log» и дублирует её в тот же Telegram-чат. Перезапуск ручной: кнопка в кастомном меню Sheets «Пересчитать календарь» вызывает тот же скрипт вне расписания. Никакого отдельного сервера не требуется — это тот же принцип, что описан в разборе про сдвиг дат в Битрикс24: если источник данных врёт (сделки «мигрируют» на 18-36 часов при синхронизации), календарь унаследует эту ошибку, поэтому сверка версий обязательна на входе, а не после.

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

Учёт платежей: обоснование суммы важнее самой суммы

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

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

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

Строка «остаток после авансов» — самая важная. Именно её обычно не считают, пока не наступает день зарплаты.

Длинный цикл: почему календарь нужен тем более, чем дольше ждать оплаты

Чем длиннее разрыв между расходом и поступлением денег, тем раньше нужен прогноз, а не факт. В одной услуге норматив прохождения от первого обращения до результата — около 5 месяцев (10 дней на рекомендации, 10 рабочих дней на анкету клиента, неделя на отправку, 5 рабочих дней на финальный этап, плюс запись, которая варьируется по локации от 1 до 2 месяцев). Всё это время компания несёт расходы, а платёж приходит в конце.

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

Именно на длинном цикле резерв не создавали — и в апреле упёрлись в лимит, оказавшийся на порядок меньше нужного. После этого договорились откладывать 30% от прибыли на резервы. Решение правильное, но с опозданием: оно принято уже после того, как образовался долг перед поставщиком услуг на 800 000 ₽ — около 7% месячного оборота, — а не до.

Резервы: прибыль на бумаге не равна деньгам в кассе

«Мы не можем распределить всю премию, давайте подождём» — фраза, которая должна звучать до распределения, а не после того, как выяснится нехватка на маркетинг. В одном случае компания потратила из резерва 900 000 ₽ — около четверти годового резерва в 3,6 млн ₽ — на маркетинговую кампанию, и встал вопрос учёта: считать это текущими затратами или инвестицией. Ответ зависит от результата: окупилось продажами — показываем расход с доходом; убыток — списываем на резервы, не включая в месячные показатели. Это разграничение имеет смысл только тогда, когда резерв вообще существует.

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

Дебиторка и возвраты как часть календаря

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

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

Такая же дыра — с реферальными вознаграждениями: партнёры задерживали информацию о выплатах до момента, когда клиент сам просил возврат денег. Решение заняло около 20 минут работы — настроить автоматическое уведомление в боте о закрытии проекта реферала, чтобы вознаграждение выплачивалось вовремя, а не по напоминанию. Маленькая правка того же типа, что и вебхук выше: не новая система, а закрытие дыры в существующей.

Кто должен видеть календарь

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

Та же логика — в контроле начислений. В одной компании возник спор: начислять бонус в момент подписания договора с клиентом или дожидаться платежа. Решили платить по факту получения денег, а не по факту обещания. Это тоже часть платёжного календаря — он должен быть завязан на реальное движение денег, а не на промежуточные события в CRM, которые могут не подтвердиться.

Экономика: что это стоит и что даёт

Внедрение считается в часах, не в новой системе. Настройка связки «вебхук CRM → Google Sheets → API модели → Telegram» занимает у толкового исполнителя 8-12 часов (оценка): подключить выгрузку, написать два промпта, настроить условное форматирование и уведомление об ошибке. Дороже всего — не код, а согласование, откуда именно брать «обязательства» и «поступления», чтобы обе стороны совпадали по смыслу.

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

Формула для своего случая: часы ручной сверки в неделю × ставка часа × число недель в месяце = стоимость ручного труда в месяц. Оценка эффекта именно этого шага — без смешения с организационными решениями вроде «откладывать 30% в резерв» (это отдельная мера, её эффект в статье не считаем): если финансист тратит на ручной сбор и сверку данных для календаря около 6 часов в неделю (оценка), при 4 неделях в месяце это ≈24 часа трудозатрат в месяц — при ставке ~1 000 ₽/час это ≈24 000 ₽/мес ручного труда (оценка). Автоматическая выгрузка и агрегация снимает большую часть рутины — вручную остаётся только проверка аномалий, оценочно 30% времени, то есть ≈1,8 часа в неделю вместо 6. Экономия — около 70% времени на этой позиции, то есть ≈16 800 ₽/мес (оценка), не считая эффекта от более раннего обнаружения разрыва.

Окупаемость: настройка в 8-12 часов при той же ставке ~1 000 ₽/час — это разовое вложение около 8 000-12 000 ₽ (оценка), которое окупается сэкономленным временем меньше чем за месяц (оценка). Дальше это уже чистая экономия времени, а не разовый эффект.

На диаграмме — часы ручной сверки данных в неделю до и после автоматизации (оценка).

Отдельно — цена самого разрыва, если его не увидеть заранее. При расходах, превышающих выручку, ежемесячный дефицит около 1,2 млн ₽ (≈10% выручки) — это не разовая, а системная проблема. Без прогноза она решается экстренными кредитами «на всякий случай» каждый месяц, а не одним резервом, рассчитанным за 4 недели вперёд.

С чего начать в понедельник

• Выгрузить из CRM и банка все обязательства на 4 недели вперёд — с точной датой и суммой, без усреднения по статьям.
• Собрать ожидаемые поступления с вероятностью оплаты, а не просто сумму сделки из карточки.
• Свести оба списка в одну таблицу по неделям и посчитать разрыв вручную хотя бы один раз, прежде чем автоматизировать.
• Назначить фиксированное время пересчёта раз в неделю — и не пересчитывать календарь по требованию «нужно оплатить за полчаса».
• Завести резерв отдельной строкой, которую нельзя тронуть без обоснования суммой и датой.
• Настроить хотя бы одно автоматическое уведомление о риске — бот, скрипт, письмо — чтобы разрыв не узнавали в день зарплаты.

Частые вопросы

Чем платёжный календарь отличается от отчёта о движении денежных средств?

ДДС показывает, что уже произошло. Платёжный календарь — что произойдёт: конкретные даты, суммы, обязательства на 4-8 недель вперёд, с учётом цикла поступлений.

Как понять, что кассовый разрыв уже наступает?

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

Можно ли вести платёжный календарь в Excel без ИИ и CRM?

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

#деньги #аналитика и отчётность #автоматизация