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

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

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

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

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

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

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

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

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

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

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

Как работают стартовые файлы (прочтите это перед вводом данных)​

Листы. Книга (cash-flow-forecast-13-week-ru.xlsx, v1.1.0) содержит шесть листов в следующем порядке:

• Forecast — ваш рабочий план: 13 датированных недель, допущения, поступления, выплаты, чистый/исходящий остаток денежных средств. Редактируйте его так часто, как захотите.
• Baseline — снимок только со значениями строк 2–29 листа Forecast, помеченный версией в B31 и датой на момент в B32. Он не содержит формул, поэтому ничто из того, что вы делаете в других местах, не может его изменить.
• Actuals — банковские поступления, которые фактически прошли за каждую закрытую неделю, введённые вами: статус в строке 3 (complete или partial), суммы по категориям в тех же строках, что и в Forecast, и необязательный остаток по выписке в строке 30.
• Variance — только формулы: Факт − Базовый план для каждой категории и итога, сопоставленные по дате начала недели, плюс легенда с пояснением каждого слова статуса. Он никогда не читает лист Forecast.
• Vendor Mapping — сопоставление реестр→категория с правилом подсчёта денежных средств банк/карта для каждого источника.
• Notes — механика, еженедельный обзор, переключатели сценариев и версия, дублированные из генератора, чтобы файл объяснял себя в автономном режиме.

Все четыре сетки недель имеют одну и ту же структуру: недели W1–W13 — это столбцы B–N, строка 2 содержит дату начала каждой недели, входящий остаток — строка 10, поступления — строки 12–14 (итог 15), выплаты — строки 17–26 (итог 27), чистый остаток — строка 28 и исходящий — строка 29. Так что B12 — это поступления от клиентов за W1 на каждом из них.

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

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

Что вы вводите, а что вычисляется. На листе Forecast синие ячейки — это ручные вводы, а всё остальное — формула (Actuals работает так же со своими вводами, описанными в разделах Зафиксируйте базовый план и еженедельный обзор ниже):

• Вводы: входящий остаток B5 (85 000), переключатели B6/B7 (1,0), нижний порог B8 (40 000), три базовые суммы категорий поступлений, десять базовых сумм категорий выплат и даты начала недель на листе Forecast.
• Формулы (показаны для столбца 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, модуль записи openpyxl 3.1.5; --verify повторно открывает файл и проверяет, что каждая итоговая ячейка содержит реальную формулу).

Образец против ваших данных. Три вещи поставляются предзаполненными, и все три — это разобранный пример, а не ваш бизнес:

• синие ячейки на листе Forecast (текущий план образцовой компании);
• снимок на листе Baseline, версия B1 на 2026-09-11 — план таким, каким он был до закрытия первых двух недель;
• записи W1–W2 на листе Actuals (столбцы B–C), которые являются банковскими поступлениями в образцовом реестре (sample.bean, выше). W3–W13 оставлены пустыми.

Поскольку образцовые Baseline и Actuals различаются, лист Variance открывается на реальном сравнении: W1 закрывается на +500 лучше плана, а W2 на +300 (см. Анализ отклонений ниже). Перед своим первым обзором замените все три: введите свой план на Forecast, очистите образцовые записи Actuals и зафиксируйте свой собственный Baseline поверх B1 (шаги ниже). Два переключателя (B6 масштабирует все поступления от клиентов, B7 масштабирует все предоплаты) — единственное, что должно оставаться обобщённым, для проигрывания сценариев.

Переходите с v1.0.0? Структура листа Forecast не изменилась, поэтому вы можете осознанно перенести свой план: в вашем старом файле скопируйте только входные диапазоны — B2:N2 (даты), B5:B8, B12:N14 и B17:N26 — и вставьте их как значения по тем же адресам в лист Forecast нового файла, никогда не поверх строк с формулами. v1.0.0 не сохраняла базовый план, поэтому любая прошедшая неделя, перезаписанная вами фактическими данными, не имеет восстановимого плана: введите банковские поступления этих недель на лист Actuals и начните свой первый Baseline с сегодняшнего Forecast.

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

Ваш лист прогноза должен быть структурирован со следующими строками, чтобы охватить все движения денежных средств. Как устроена книга: строки ниже находятся на листе Forecast (13 датированных недель с Входящим остатком, тремя категориями поступлений, десятью категориями выплат, Чистым и Исходящим остатком), а Baseline, Actuals и Variance повторяют их строка за строкой; Vendor Mapping сопоставляет источники реестра с этими категориями, включая правило исключения двойного счёта банк/карта, а Notes объясняет механику в автономном режиме. На листе Forecast поступления группируются как Поступления от клиентов, Новые бронирования/предоплаты и Прочие притоки; выплаты группируются как Зарплата, Подрядчики, Облако/Хостинг, ПО/SaaS, Маркетинг, Аренда, Юридические и бухгалтерские услуги, Налоги и сборы, Обслуживание долга и Разовые платежи; итоги разворачиваются Входящий → Итого поступления → Итого выплаты → Чистый → Исходящий.

• Входящий остаток денежных средств (должен совпадать с Исходящим остатком предыдущей недели)

• Поступления (приток денежных средств)

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

• Выплаты (отток денежных средств)

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

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

• Исходящий остаток денежных средств (= Входящий остаток + Чистый денежный поток)

Разобранный 13-недельный пример (USD)​

Таблица ниже — это лист Forecast книги для образцовой компании, неделя за неделей — текущий план, перепрогнозированный после закрытия W1 и W2, поэтому эти два столбца теперь содержат то, что фактически сделал банк. W1 и W2 — это фактические данные реестра — они равны итогам, которые yarn check:cash-flow-actuals выводит из sample.bean (поступления 12 200 / 13 200, выплаты 9 700 / 17 200, закрытие 87 500 / 83 500). W3–W13 — это допущения книги из образцовых баз генератора (не проведены в реестре). План, к которому компания обязалась заранее, хранится отдельно на листе Baseline и отличается от этих столбцов W1–W2; Анализ отклонений ниже сравнивает их. Валюта — целые USD; Закрытие = Входящий + Поступления − Выплаты каждую неделю.

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

Логика скользящего прогноза проста и мощна — и в загрузке она уже прописана как формулы на листе 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).

Те же строки существуют на листе Actuals как простые итоги (B15 = SUM(B12:B14), B27 = SUM(B17:B26), B28 = B15-B27, B29 = B10+B28, C10 = B29), при этом фактический входящий остаток недели вводится один раз в Actuals!B10. У листа Actuals нет переключателей, и он никогда не ссылается на другой лист.

Зафиксируйте базовый план (один раз на горизонт)​

Сделайте это, когда ваш Forecast содержит план, относительно которого вы хотите измеряться — до закрытия первой недели.

1. Скопируйте план как значения. Выделите Forecast!B2:N29 и скопируйте. Выделите Baseline!B2 и вставьте только значения — Excel: Специальная вставка → Значения; LibreOffice: Специальная вставка → Только значения; Numbers: Правка → Вставить результаты формул. Обычная вставка перенесла бы живые формулы, и «базовый план» молча следовал бы за каждым последующим изменением.
2. Пометьте его. Введите версию (например, B1) в Baseline!B31 и сегодняшнюю дату в Baseline!B32. Обе находятся под вставленным блоком, поэтому более поздняя фиксация никогда их не перезапишет.
3. Выровняйте недели. Скопируйте Baseline!B2:N2 и вставьте значения в Actuals!B2, чтобы оба листа называли одни и те же 13 дат начала недель, и введите банковский остаток, с которого вы начинаете, в Actuals!B10.

С этого момента ввод фактических данных, редактирование Forecast или переключение переключателя пересчитывает Forecast и Variance и оставляет Baseline точно таким, каким он был зафиксирован.

Ваш еженедельный обзор в понедельник (по этой книге)​

1. Зафиксируйте неделю на листе Actuals — никогда на Forecast. В столбце, дата в строке 2 которого — это только что закрывшийся понедельник, введите банковские поступления недели по категориям в строках 12–14 и 17–26 (сопоставление ниже). Введите 0 там, где денежные средства не двигались: пустая ячейка означает «ещё не введено», а не ноль. Поместите закрывающий остаток банковской выписки в строку 30; строка 31 тогда должна показывать 0. Всё остальное — ошибка сопоставления — обычно учтённый расход по карте или сохранённый перевод — а не ошибка банка.
2. Проверьте, что неделя полная. Введите complete в строке 3, как только каждая строка категории содержит число, или partial, пока неделя ещё открыта (раскрывающийся список предлагает оба варианта). Variance сравнивает неделю только тогда, когда она complete, каждая категория введена и дата Actuals равна дате Baseline в том же столбце.
3. Прочитайте Variance. Строка 3 называет состояние каждой недели; только compared недели показывают числа, а любое другое состояние показывает n/a, никогда 0, поэтому невведённая неделя не может сойти за «по плану». Знаки — это Факт − Базовый план (столбец O повторяет их): поступления, чистый и исходящий положительные = больше денежных средств, чем планировалось; выплаты положительные = больше расходов, чем планировалось. Строка 29 кумулятивная — она включает каждую более раннюю неделю — и существует только пока все недели до неё compared. Строки 32–35 выражают итоги как долю от базового плана (n/a, когда базовый план равен нулю).
4. Переоцените будущее на Forecast. Обновите синие ячейки для следующих 2–4 недель самой свежей информацией (недавно отправленные счета, предстоящие платежи поставщикам, подтверждённые даты выплаты зарплаты). Чтобы сохранить полный 13-недельный обзор вперёд, прокрутите окно Forecast: сдвиньте его синие вводы, включая даты в строке 2, на один столбец влево (старая Неделя 2 становится Неделей 1), затем очистите столбец N и присвойте ему дату новой Недели 13. Формулы переноса вперёд переустанавливаются автоматически; Baseline, Actuals и Variance не затрагиваются.

Прокрутите горизонт обзора (намеренный шаг, а не еженедельный)​

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

1. Архивируйте. Сохраните копию книги (например, cash-flow-forecast-B1.xlsx). Она хранит старый базовый план, его фактические данные и их отклонение вместе; рабочий файл истории не ведёт.
2. Очистите фактические вводы. На листе Actuals очистите строки 3, 12–14, 17–26 и 30 в столбцах B–N, а также B10. Оставьте C10:N10, строки 15 и 27–29 и строку 31 в покое — они формулы.
3. Зафиксируйте новый базовый план из сегодняшнего Forecast со следующей версией (B2) и сегодняшней датой, затем выровняйте даты Actuals и входящий остаток точно так, как в разделе Зафиксируйте базовый план выше.

Никогда не вставляйте и не удаляйте столбцы недель. Если вы заново фиксируете базовый план, но забываете переустановить даты Actuals, каждая затронутая неделя показывает date mismatch вместо сравнения недели с планом другой недели.

Сопоставление из Beancount в ваш прогноз​

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

• Кредитные карты: покупка по карте проводится по Liabilities:CreditCard:* и не двигает банковские денежные средства, поэтому она не учитывается при списании. Денежные средства уходят один раз, при расчёте (платёж банк→карта). Учёт списания плюс расчёта считает один и тот же расход дважды. В образцовом реестре W1 содержит 420,00 USD расходов по Amex на SaaS (только обязательство, игнорируется) рядом с расчётом по августовской выписке на 600,00 USD (учитывается). Наивный итог «банковские оттоки + расходы по карте» для W1 составляет 10 120,00 USD — ровно на 420,00 завышен; книга считает 9 700,00.
• Внутренние переводы: перевод Checking↔Savings имеет две противоположные банковские ноги, поэтому в этой области он сводится к нулю и исключается из обоих — и поступлений, и выплат. Образцовые переводы в 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; арендодатель → Аренда; юридическая фирма → Юридические/Бухгалтерские; налоговый орган → Налоги и сборы; автоплатёж по кредиту → Обслуживание долга.

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

Отрывок из Beancount, который питает W1​

Каждая проводка ниже также существует в поставляемом sample.bean. Сохранённый отдельно, этот отрывок проходит uvx --from beancount bean-check и даёт поступления W1 таблицы (12 200), выплаты (9 700) и закрытие (87 500), как только вы примените область банковских денежных средств выше (исключите перевод Checking↔Savings с обеих сторон; считайте расчёт по Amex, а не списания обязательства).

option "title" "Cash forecast sample — W1 excerpt"
option "operating_currency" "USD"
 
2026-09-13 open Assets:Bank:Checking USD
2026-09-13 open Assets:Bank:Savings USD
2026-09-13 open Liabilities:CreditCard:Amex USD
2026-09-13 open Liabilities:Loan USD
2026-09-13 open Equity:Opening-Balances USD
2026-09-13 open Income:Sales USD
2026-09-13 open Income:Interest USD
2026-09-13 open Expenses:Contractors USD
2026-09-13 open Expenses:Cloud USD
2026-09-13 open Expenses:Software USD
2026-09-13 open Expenses:Marketing USD
2026-09-13 open Expenses:Rent USD
2026-09-13 open Expenses:Interest USD
 
2026-09-13 * "Opening balances"
  Assets:Bank:Checking            80000.00 USD
  Assets:Bank:Savings              5000.00 USD
  Liabilities:CreditCard:Amex      -600.00 USD
  Liabilities:Loan               -20000.00 USD
  Equity:Opening-Balances        -64400.00 USD
 
2026-09-14 * "Stripe" "Customer receipts W1"
  Assets:Bank:Checking            12000.00 USD
  Income:Sales                   -12000.00 USD
 
2026-09-15 * "Contractor" "Contractors W1"
  Expenses:Contractors              1500.00 USD
  Assets:Bank:Checking             -1500.00 USD
 
2026-09-15 * "AWS" "Cloud hosting W1"
  Expenses:Cloud                    2200.00 USD
  Assets:Bank:Checking             -2200.00 USD
 
2026-09-16 * "Bank" "Checking -> Savings sweep"
  Assets:Bank:Savings               3000.00 USD
  Assets:Bank:Checking             -3000.00 USD
 
2026-09-17 * "SaaS vendor" "Amex SaaS charges"
  Expenses:Software                  250.00 USD
  Liabilities:CreditCard:Amex       -250.00 USD
 
2026-09-17 * "SaaS vendor" "Amex SaaS charges"
  Expenses:Software                  170.00 USD
  Liabilities:CreditCard:Amex       -170.00 USD
 
2026-09-18 * "Amex" "August statement settlement"
  Liabilities:CreditCard:Amex        600.00 USD
  Assets:Bank:Checking              -600.00 USD
 
2026-09-19 * "Landlord" "Rent W1"
  Expenses:Rent                     3500.00 USD
  Assets:Bank:Checking             -3500.00 USD
 
2026-09-19 * "Agency" "Marketing W1"
  Expenses:Marketing                1000.00 USD
  Assets:Bank:Checking             -1000.00 USD
 
2026-09-19 * "Bank" "Interest W1"
  Assets:Bank:Checking               200.00 USD
  Income:Interest                   -200.00 USD
 
2026-09-19 * "Lender" "Loan autopay W1"
  Liabilities:Loan                   800.00 USD
  Expenses:Interest                  100.00 USD
  Assets:Bank:Checking              -900.00 USD

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

Входящие банковские денежные средства — 85 000,00 (Checking 80 000 + Savings 5 000 на 2026-09-13) — значение в Actuals!B10. Банковские ноги реестра за W1, после исключения пары переводов в 3 000,00, идут в столбец B листа Actuals; каждая не указанная категория вводится как 0, а строка 3 устанавливается в complete:

Перенос вперёд в 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 книги на листе Actuals (и на перепрогнозированном листе Forecast). Остатки по выпискам 87 500 и 83 500 находятся в Actuals!B30:C30, поэтому строка 31 читает 0 для обеих недель: это ваше доказательство, что сопоставление работает. Что недели сделали против плана — отдельный вопрос, на который отвечает раздел Variance ниже.

Воспроизведите это (проверено 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 реестра доказывают исходящий остаток каждой недели), запросы экспорта ниже и независимый перенос вперёд на 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";

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

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

1. Соберите фактические данные (15 мин): Экспортируйте проводки недели по Assets:Bank:* (запустите запросы выше или скачайте транзакции из своих банковских счетов — списания по карте остаются в стороне; считается только платёж по расчёту) и введите их на лист Actuals. Убедитесь, что Исходящий остаток недели на листе Actuals точно совпадает с вашим фактическим совокупным банковским балансом (Checking + Savings) — строка 31 читает 0. Эта сверка не подлежит обсуждению.
2. Проверьте дебиторскую задолженность (10 мин): Перечислите все неоплаченные счета и распределите их по неделям, в которые вы ожидаете оплату. Будьте консервативны и применяйте реалистичные задержки сбора, основанные на прошлых результатах.
3. Проверьте кредиторскую задолженность и зарплату (10 мин): Распределите сроки оплаты всех известных предстоящих счетов. Заполните заранее даты и суммы выплаты зарплаты на весь квартал. Отложите некритичные выплаты на пятницы, чтобы сохранить возможность манёвра с денежными средствами в течение недели.
4. Встреча по отклонениям (10 мин): Откройте лист Variance и пройдитесь по столбцу compared недели: какие категории сдвинулись, в каком направлении и что это сделало с кумулятивным исходящим остатком. Отметьте причины любых существенных различий и решите, нужно ли скорректировать ваши правила прогнозирования на будущее.

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

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

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

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

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

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

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

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

Простой набор категорий (для 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 — дополнительная проводка не нужна.

Обучение и избегание ошибок​

Анализ отклонений (сделайте обучение накапливающимся)​

Книга ведёт учёт отклонений за вас: Отклонение = Факт − Базовый план, по категории и по итогу, для каждой недели, чьи фактические данные complete и датированы так же, как базовый план. Ваша работа — объяснить числа. При обзоре помечайте причины крупных различий: задержка сбора, сдвиг объёма, незапланированная покупка у поставщика, смещение сроков. Если один и тот же тип отклонения повторяется, измените основное правило вашей модели. Например, если сборы постоянно запаздывают на неделю, измените допущение о задержке сбора по умолчанию с 21 дня на 28 дней.

Разобранное сравнение (поставляемый образец). Базовый план B1 был зафиксирован 2026-09-11 при входящем остатке 85 000; фактические данные — это банковские денежные средства образцового реестра. Знаки соответствуют листу Variance: поступления, чистый и исходящий положительные = больше денежных средств, чем планировалось, расходы положительные = больше потрачено, чем планировалось.

Читая это так, как это излагает лист Variance:

• W1, +500. Поступления от клиентов пришли на 200 выше запланированных 11 800 (Variance!B12 = +200), а AWS выставил счёт на 2 200 против запланированных 2 500 (Variance!B19 = −300: меньше расходов, благоприятно). 85 000 + 12 200 − 9 700 = 87 500 факт против 85 000 + 12 000 − 10 000 = 87 000 план.
• W2, +300. Поступления пришли точно по плану, но счёт за SaaS, оплачиваемый банком, составил 600 против запланированных 400 (Variance!C20 = +200: больше расходов, неблагоприятно). Чистый за неделю −200, поэтому кумулятивное преимущество исходящего остатка сокращается с +500 до +300 (Variance!C29): 87 500 + 13 200 − 17 200 = 83 500 против 87 000 + 13 200 − 17 000 = 83 200.
• W3 и далее, not observed. Ничего не введено, поэтому каждая ячейка показывает n/a — а не утешительный 0.
• В процентах (строки 32–33): поступления W1 +1,67% и расходы −3,00%; поступления W2 0,00% и расходы +1,18%.

Из этого вытекают два вывода: оценка AWS завышена, а строка SaaS, оплачиваемого банком, была запланирована на 200 слишком низко. Оба — исправления допущений Forecast; базовый план B1 остаётся как есть, чтобы в следующем квартале вы всё ещё могли видеть, насколько далёк был первоначальный план.

Распространённые ошибки (избегайте их)​

• Перезапись плана: Ввод фактических данных поверх ячеек Forecast (или повторная вставка Baseline каждую неделю) уничтожает план, относительно которого вы должны были измеряться. Фактические данные идут на лист Actuals; базовый план меняется только когда вы намеренно прокручиваете горизонт.
• Смешивание начисления и денежных средств: Этот прогноз — только для денежных средств. Признанная выручка, амортизация и другие концепции начисления относятся к вашему основному реестру, а не сюда.
• Забывание о неравномерных годовых расходах: Годовые страховые взносы, крупные продления SaaS и квартальные налоговые платежи могут стать огромными сюрпризами. Запланируйте их в своём прогнозе, как только узнаете о них.
• Игнорирование денежных средств по налогу с продаж: Даже если это транзитное обязательство, денежные средства находятся на вашем банковском счёте до перечисления. Моделируйте и приток, и отток.
• Отсутствие сверки: Если Исходящий остаток недели на листе Actuals не совпадает с вашим фактическим совокупным банковским балансом (Checking + Savings; остатки по картам исключены), у вас ошибка сопоставления — обычно учтённый расход по карте или сохранённый перевод. Вы должны это исправить, прежде чем сможете доверять прогнозу.
• Отсутствие чёткого ответственного: Назначьте одного человека ответственным за обновление прогноза каждую неделю. Назначьте заместителя на время отпусков.

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

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

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

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