Прогноз денежных средств: метод скользящего прогноза на 13 недель

Это руководство даёт простой метод уровня CFO для управления ликвидностью компании. Построив скользящий 13-недельный прогноз денежных средств, вы будете видеть запас денег понедельно, осознанно управлять поступлениями и платежами и исключите финансовые сюрпризы. Система построена для основателей — а эта страница сразу даёт и модель: рабочую книгу с формулами и примерами данных плюс пример Beancount-ledger за первые две недели (загрузки — ниже).

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

Почему 13 недель?​

13-недельный прогноз — золотой стандарт управления операционной ликвидностью по нескольким ключевым причинам:

• Краткосрочный контроль: он покрывает примерно один деловой квартал и даёт ясную картину ближайшей ликвидности. Горизонта хватает на 2–3 зарплатных цикла, налоговые платежи и типичные сроки оплаты поставщикам, но он достаточно короткий, чтобы оставаться высокоточным и исполнимым.
• Взгляд через поступления и выплаты: прогноз использует «прямой метод» — только движение денежных средств. Речь не о начислении или рентабельности, а о том, что реально придёт на ваш банковский счёт или уйдёт с него, — поэтому прогноз напрямую привязан к банковскому остатку.
• Скользящий, а не статичный: это не разовый бюджет. Каждую неделю вы вычёркиваете прошедшую неделю, добавляете в конец новую (неделю 13) и обновляете допущения. Так горизонт остаётся постоянным, а прогнозирование становится динамической еженедельной дисциплиной.

Что вы построите​

1. Одна таблица: сердце — лист на 13 колонок (недели с 1-й по 13-ю) с чёткими блоками: начальный остаток, поступления, выплаты, чистый денежный поток и конечный остаток.
2. Маппинг категорий: простая система, привязывающая проводки из вашего ledger к категориям прогноза (например, все поступления от Stripe относятся на «Поступления от клиентов»; выплаты Gusto — на «Заработная плата»). Вкладка Vendor Mapping в книге уже содержит этот маппинг — включая банковско-карточное правило против двойного счёта, — начните с неё, а не изобретайте свою.
3. Еженедельный ритм: повторяемый процесс обновления прогноза, отслеживания отклонений (прогноз против факта) и набор заранее заданных триггеров на действия при достижении денежных порогов.

Скачайте стартовые файлы​

Не начинайте с пустого листа: к руководству приложены книга с формулами и примерами данных плюс ledger-пример за первые две недели.

• Рабочая книга прогноза на 13 недель (XLSX, v1.0.0) — cash-flow-forecast-13-week-ru.xlsx. Редактируемые допущения, связанные формулами недели и вкладка маппинга поставщиков; замените синие примерные ячейки своими числами.
• Пример ledger и факты (Beancount-ledger, .bean) — sample.bean. Сбалансированный пример ledger с проработанными банковскими фактами W1–W2, совпадающими с первыми двумя неделями книги.

Как устроены стартовые файлы (прочтите, прежде чем вводить)​

Листы. В книге (cash-flow-forecast-13-week-ru.xlsx, v1.0.0) три листа:

• Forecast — 13 датированных недель, допущения, поступления, выплаты, чистый/конечный остаток.
• Vendor Mapping — маппинг ledger→категории с банковско-карточным правилом учёта денег по каждому источнику.
• Notes — механика, сценарные переключатели и версия, перенесённые из генератора, чтобы файл объяснял себя офлайн.

Базис времени. Недели начинаются с понедельника, W1 стартует 2026-09-14, W13 — 2026-12-07 (строка 2 в Forecast; при переносе модели поменяйте эти даты — все формулы относительны недель, так что цепочка сохранится). Проводка относится к неделе, содержащей её дату, с понедельника по воскресенье.

Единицы. Везде целые USD (формат #,##0). Пример — seed-SaaS с начальным остатком 85,000, зарплатой, чередующейся 0 / 11,000 по неделям, ежемесячной арендой и автоплатежом по кредиту 900 в неделю.

Что вводите вы, а что считает. Синие ячейки — ручной ввод; всё остальное — формулы:

• Ввод: начальный остаток B5 (85,000), переключатели B6/B7 (1.0), пол B8 (40,000), базы поступлений в строках 12–14, базы выплат в строках 17–26 и даты недель в строке 2.
• Формулы (показаны для колонки B, недели 1 — каждая следующая неделя сдвигает букву колонки): начальный остаток B10 = $B$5 (недели 2–13 вместо этого подхватывают прошлую неделю, например C10 = B29); итого поступлений B15 = B12*$B$6+B13*$B$7+B14; итого выплат B27 = SUM(B17:B26); чистый поток B28 = B15-B27; конечный остаток B29 = B10+B28.
• Пересчёт стоит на автомате, а файл выставляет fullCalcOnLoad, так что Excel, LibreOffice и Numbers пересчитывают всё при каждом открытии (кэшированных значений формул файл не хранит). Поменяйте одну синюю ячейку — сдвинутся все 13 недель: например, переключатель сборов B6 на 1.2 поднимет поступления W1 с 12,200 до 14,600, а конечный остаток W1 — с 87,500 до 89,900.
• Чистый файл в любой момент пересоздаётся командой yarn generate:cash-flow-forecast (генератор: scripts/generate-cash-flow-forecast.py, writer openpyxl 3.1.5; --verify переоткрывает файл и проверяет, что каждая итоговая ячейка — настоящая формула).

Примерные и ваши данные. Каждая синяя ячейка содержит примерные числа — это разобранный пример, а не ваша компания. Заменяйте их своими неделю за неделей; только два переключателя (B6 масштабирует все поступления от клиентов, B7 — все предоплаты) специально общие, для сценарных игр. Факты W1–W2 примерного ledger по построению равны примеру прогноза W1–W2 книги, так что отклонение прогноза от факта там нулевое: это вид правильно сошедшейся сверки, а не утверждение про ваши книги.

Структура (нужные строки)​

Лист прогноза стоит построить из следующих строк, чтобы покрыть все движения денег. Это карта листа Forecast в скачанном файле (строки поступлений 12–14, строки выплат 17–26, итоги в строках 10/15/27–29) — читайте её как карту, а не как вторую спецификацию.

• Начальный остаток денежных средств (должен совпадать с конечным остатком прошлой недели)

• ПОСТУПЛЕНИЯ (приток денег)

  • Поступления от клиентов: деньги, которые вы ожидаете собрать по выставленным счетам (дебиторка).
  • Новые бронирования/предоплаты: предоплаты, которые вы ожидаете от новых сделок внутри 13-недельного окна.
  • Прочие поступления: все остальные притоки — возвраты налогов, проценты, гранты.

• ВЫПЛАТЫ (отток денег) — 10 строк в книге (строки 17–26):

  • Заработная плата: полная денежная стоимость, включая нетто-зарплаты и все налоги работодателя на ФОТ.
  • Подрядчики: выплаты не-сотрудникам.
  • Облако/хостинг (COGS): ключевая инфраструктура вроде AWS, GCP и т. п.
  • ПО/SaaS: все подписки на софт.
  • Маркетинг: рекламные траты, гонорары агентств и прочие расходы на бренд.
  • Аренда/офис: стоимость физического офиса.
  • Юридические/бухгалтерские: гонорары профессиональных подрядчиков.
  • Налоги и сборы: перечисления НДС и прочие платежи государству.
  • Обслуживание долга: тело и проценты по всем кредитам.
  • Разовое: комковатые редкие платежи вроде годовых страховок, депозитов или железа/капзатрат (ноутбуки, техника) — всё, чему нет строки выше, идёт сюда.

• Чистый денежный поток (= итого поступлений − итого выплат)

• Остаток денежных средств (= начальный остаток + чистый поток)

Скользящая механика (как построено в книге)​

Логика скользящего прогноза проста и сильна — а в скачанном файле она уже разведена формулами на листе Forecast (строки в скобках):

• Начальный остаток (Неделя 1) = допущение начального остатка — ячейка B10 = $B$5.
• Начальный остаток (Неделя n) = Остаток (Неделя n−1) — например C10 = B29 (строка 10, недели 2–13).
• Итого поступлений (Неделя n) = Поступления от клиентов × переключатель сборов + Предоплаты × переключатель бронирований + Прочее — например B15 = B12*$B$6+B13*$B$7+B14 (строка 15).
• Итого выплат (Неделя n) = SUM 10 строк категорий выше — например B27 = SUM(B17:B26) (строка 27).
• Чистый поток (Неделя n) = Итого поступлений − Итого выплат — например B28 = B15-B27 (строка 28).
• Остаток (Неделя n) = Начальный остаток + Чистый поток — например B29 = B10+B28 (строка 29).

Ваше еженедельное утро понедельника (по этой книге):

1. Сдвиньте окно: сдвиньте весь прогноз на неделю вперёд — подвиньте синие вводы каждой недели на колонку влево (старая неделя 2 становится новой неделей 1), очистите последнюю колонку и датируйте её в строке 2 как новую неделю 13. Формулы переноса (C10 = B29, …) перепривяжутся сами; точечно проверьте, что начальный остаток новой недели 1 равен остатку прошлой недели.
2. Обновите фактами: перезапишите синие прогнозные ячейки прошлой недели фактическими банковскими движениями недели по маппингу ниже (запросить, разложить, вставить — руками). Затем убедитесь, что ячейка остатка недели в точности равна вашему реальному суммарному банковскому остатку (Assets:Bank:Checking + Assets:Bank:Savings): не сошлось — неверен маппинг, а не банк.
3. Переоцените будущее: обновите синие ячейки ближайших 2–4 недель свежей информацией (новые счета, грядущие платежи поставщикам, подтверждённые даты зарплат).

Маппинг Beancount на ваш прогноз​

Объём банковских денег (правило против двойного счёта). Недельные факты — это проводки по Assets:Bank:* и только — объём, закрывающий сразу обе ловушки:

• Кредитные карты: покупка по карте проводится на Liabilities:CreditCard:* и банковских денег не двигает, поэтому в момент покупки не считается. Деньги уходят из банка один раз — при погашении (платеж банк→карта). Кто считает покупку плюс погашение, считает один расход дважды. В примере ledger W1 содержит покупки SaaS по Amex на 420.00 USD (только обязательство, игнорируется) рядом с погашением августовского счёта на 600.00 USD (считается). Наивный итог «оттоки банка + покупки по картам» для W1 — 10,120.00 USD, ровно на 420.00 больше; книга считает 9,700.00.
• Внутренние переводы: перевод между расчётным и накопительным счетами имеет два встречных банковских плеча, внутри этого объёма схлопывается в ноль и исключается из обоих, поступлений и выплат. Примерные переводы 3,000.00 USD (W1) и 1,500.00 USD (W2) иначе раздули бы обе стороны на эти суммы.
• Следствие: маппьте банковские плечи, а не плечи доходов/расходов. Тело кредита — не расход, но есть банковский отток (примерные автоплатежи 900.00 USD = 800 тело + 100 проценты, все посчитаны в обслуживании долга); покупка по карте есть расход, но ещё не банковский отток.

Разбивка поступлений/выплат. Из выгруженных банковских плеч: положительные плечи — поступления, отрицательные — выплаты, плечи переводов исключены. Маппинг категорий (как во вкладке Vendor Mapping): выплаты Stripe/PayPal → Поступления от клиентов; входящие переводы новых клиентов → Новые бронирования / Предоплаты; проценты/гранты → Прочие поступления; Gusto/ADP → Заработная плата; AWS/GCP → Облако/Хостинг; SaaS с оплатой из банка → ПО/SaaS; арендодатель → Аренда; юрфирма → Юридические/Бухгалтерские; налоговая → Налоги и сборы; автоплатёж по кредиту → Обслуживание долга.

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

Разобранная неделя: W1 целиком (2026-09-14 – 2026-09-20)​

Начальные банковские деньги — 85,000.00 (расчётный 80,000 + накопительный 5,000 на 2026-09-13). Банковские плечи W1 из ledger, после исключения пары перевода 3,000.00:

Перенос в W2. C10 = B29, значит W2 открывается с 87,500.00. Её банковские плечи дают поступления 8,000 (Stripe) + 5,000 (предоплата) + 200 (проценты) = 13,200.00 и выплаты 11,000 (зарплата Gusto) + 1,500 + 2,200 + 600 (SaaS из банка) + 1,000 + 900 = 17,200.00; чистый −4,000.00, остаток 83,500.00 — в точности колонка W2 книги. Отклонение прогноза от факта за эти две недели по построению нулевое; это ваше доказательство, что маппинг работает, — с W3 применяйте так же по одной неделе за раз.

Воспроизведение (проверено 2026-09-09, Beancount 3.2.3 + beanquery 0.2.0)​

uvx --from beancount bean-check public/downloads/cash-flow-forecast/sample.bean
yarn check:cash-flow-actuals

Проверяльщик запускает bean-check (балансовые ассёрты balance самого ledger доказывают остаток каждой недели), экспортные запросы ниже и независимый Python-перенос — и ассёртит, что все три сходятся: W1 12,200.00 / 9,700.00 / 87,500.00, W2 13,200.00 / 17,200.00 / 83,500.00:

SELECT date, narration, account, position
FROM date >= 2026-09-14 AND date <= 2026-09-20
WHERE account ~ "^Assets:Bank" ORDER BY date;
 
SELECT sum(position) AS net
FROM date >= 2026-09-14 AND date <= 2026-09-20
WHERE account ~ "^Assets:Bank";
 
SELECT sum(position) AS bank_cash
FROM close ON 2026-09-21 WHERE account ~ "^Assets:Bank";

(Для W2 сдвиньте даты на 7 дней, закрытие на 2026-09-28.) Одно ограничение BQL, которое стоит знать: эта версия beanquery не умеет фильтровать проводки по знаку, поэтому разбивка поступлений/выплат применяется к выгруженным строкам — положительные банковские плечи в поступления, отрицательные в выплаты, пары переводов исключены, — ровно как делает проверяльщик.

Ритм обновления (30–45 минут в неделю)​

1. Забрать факты (15 мин): выгрузите проводки недели по Assets:Bank:* (запустите запросы выше либо скачайте выписки банковских счетов — покупки по картам остаются за бортом; считается только платёж погашения). Убедитесь, что «остаток» прошлой недели в точности равен вашему реальному суммарному остатку в банках (расчётный + накопительный). Эта сверка не обсуждается.
2. Проверить дебиторку (10 мин): перечислите все открытые счета и разложите их по неделям ожидаемой оплаты. Будьте консервативны и закладывайте реалистичные задержки сборов из вашего опыта.
3. Проверить кредиторку и зарплаты (10 мин): разложите все известные грядущие счета по срокам. Даты и суммы зарплат на весь квартал внесите заранее. Некритичные выплаты ставьте на пятницу, чтобы сохранять денежную опциональность внутри недели.
4. Встреча по отклонениям (10 мин): коротко сравните прогноз прошлой недели с фактом. Запишите причины существенных расхождений и решите, надо ли менять правила прогноза.

Точность и решения​

Эмпирические правила точности​

• Недели 1–2: цельтесь в отклонение ±5–10%. Эти даты и суммы должны быть высоконадёжными.
• Недели 3–6: ожидайте отклонение ±10–20%. Здесь смесь известных счетов и оценок по паттернам.
• Недели 7–13: эта часть прогноза — направляющая. Её двигают воронка продаж и постоянные расходы.

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

Триггеры и действия (задайте заранее)​

Прогноз без плана бесполезен. Заранее определите действия на конкретные пороги.

• Минимальный денежный пол: правило может звучать, например, так: «держим деньги всегда ≥ 1,5× ближайшей полной зарплаты». Покажет прогноз просадку ниже — сразу запускайте заранее оговорённый план: спринт по сборам плюс стоп всех дискреционных трат.
• Ограждение запаса: например: «если остаток в неделе 13 означает меньше X месяцев бёрна — запускаем план финансирования». Это может быть term sheet, скидка клиентам за предоплату или выбор кредитной линии.
• Правило крупных трат: например: «любая отдельная не-зарплатная выплата свыше 5% текущих денег — за две недели на согласование, с запасным планом».

Шаблон и сценарии​

Простой набор категорий (для seed-SaaS)​

• Поступления: Поступления от клиентов, Прочие поступления (проценты, возвраты, гранты)
• Выплаты: Заработная плата (нетто + налоги работодателя), Подрядчики, Облако/Хостинг (COGS), ПО/SaaS (OpEx), Маркетинг (платный/бренд), Аренда/Офис, Юридические/Бухгалтерские, Налоги и сборы, Обслуживание долга, Разовые / Годовые
• Расчётные: Чистый денежный поток, Остаток денежных средств

Шаблон (в скачанном файле уже построен; скопируйте для пустой сборки)​

Таблица ниже — форма листа Forecast: те же строки, те же формулы — для пересборки на пустом листе. В скачанном файле в строке 2 уже стоят даты начал недель (W1 2026-09-14 по W13 2026-12-07), и каждый итог связан; заморозьте ниже строки 3 и правее колонки A (B4 в файле), чтобы повторить.

Сценарные переключатели (держите лёгкими)​

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

• Переключатель сборов B6: [1.0] (поставьте 1.2, чтобы смоделировать сборы медленнее на 20%, — итог поступлений каждой недели пересчитается через COL15 = COL12*$B$6+COL13*$B$7+COL14)
• Переключатель бронирований B7: [1.0] (поставьте 0.8, чтобы смоделировать недобор бронирований на 20%)

Это настоящие ячейки допущений на листе Forecast — никакой дополнительной разводки не нужно.

Учимся и избегаем ошибок​

Отслеживание отклонений (пусть обучение копится)​

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

Частые ловушки (избегайте их)​

• Смешение начислений и денег: этот прогноз — только про деньги. Выручка по отгрузке, амортизация и прочие начисленческие понятия живут в главном ledger, а не здесь.
• Забытые комковатые годовые даты: годовые страховки, крупные продления SaaS и квартальные налоги могут стать огромными сюрпризами. Ставьте их в прогноз, как только узнали.
• Игнорирование денег НДС: пусть это и проходящее обязательство — деньги до перечисления лежат на вашем банковском счёте. Моделируйте и приток, и отток.
• Несверка: не сошёлся остаток прогноза с реальным суммарным остатком в банках (расчётный + накопительный; карточные остатки исключены) — у вас ошибка маппинга, чаще всего посчитанная покупка по карте или оставленный перевод. Чините до того, как доверять прогнозу.
• Нет владельца: назначьте одного человека ответственным за еженедельное обновление прогноза. Назначьте заместителя на отпуска.

Быстрые связки Beancount​

• План счетов: держите денежные корзины чистыми (например, Assets:Bank:Checking, Assets:Bank:Savings, Liabilities:CreditCard:Amex). Недельные факты — только плечи Assets:Bank:*: счёт карты существует, чтобы у погашений было откуда взяться, а не как второй источник оттоков.
• Не сверяйтесь с P&L: отчёт о прибылях Fava — начисленческий: покупки по картам он проводит в момент покупки, а тело кредита игнорирует, — поэтому он по построению расходится с этим денежным прогнозом. Денежная сверка — это экспорт bean-query + перенос выше (yarn check:cash-flow-actuals), который обязан сходиться к остатку каждую неделю.
• Документы: по крупным разовым позициям прикладывайте PDF счёта в папку documents/ вашего Beancount и ссылайтесь на него в колонке примечаний прогноза.

Пак для борда/инвесторов (один слайд)​

1. График: простая линия остатка по всем 13 неделям. Добавьте горизонтальную линию минимального денежного пола.
2. Таблица: маленькая таблица остатков W1–W13 плюс список топ-5 крупнейших ожидаемых притоков и оттоков квартала.
3. Заметки: несколько пунктов о ключевых допущениях, изменившихся с прошлого обновления, и о сработанных или ожидаемых триггерах.