Прогнозування грошових потоків: метод 13-тижневого ковзного прогнозу

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

Цей посібник не є двома речами: прогноз — це перспективні оцінки, які ви вводите вручну, тоді як бухгалтерські факти — це банківські операції, вже проведені у вашому реєстрі — щопонеділкова процедура, описана нижче, вручну переносить останні в перші. Тут нічого не синхронізується автоматично: у робочому зошиті немає макросів або зовнішніх з'єднань, і жоден крок не отримує дані з вашого банку чи Beancount самостійно.

Чому 13 тижнів?​

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

• Короткостроковий контроль: Він охоплює приблизно один бізнес-квартал, даючи вам чітке уявлення про вашу поточну ліквідність. Цей горизонт достатньо довгий, щоб включити 2–3 цикли виплати зарплати, податкові платежі та типові умови оплати постачальникам, але достатньо короткий, щоб залишатися високоточним і практичним.
• Погляд на надходження та виплати: Прогноз використовує «прямий метод», зосереджуючись виключно на надходженні та вибутті грошей. Це не про нарахування або прибутковість; це про те, що фактично надійде на ваш банківський рахунок або піде з нього, що гарантує прямий зв'язок прогнозу з вашим банківським залишком.
• Ковзний, а не статичний: Це не разовий бюджет. Щотижня ви відкидаєте минулий тиждень, додаєте новий тиждень у кінець (тиждень 13) і оновлюєте свої припущення. Це підтримує постійний горизонт планування, перетворюючи прогнозування на динамічну щотижневу дисципліну.

Що ви побудуєте​

1. Єдина електронна таблиця: Основою системи є один аркуш із 13 стовпцями (Тиждень 1 — Тиждень 13) і чітко визначеними розділами: Початкова готівка, Надходження, Виплати, Чистий грошовий потік та Кінцева готівка.
2. Відображення категорій: Проста система для зіставлення операцій із вашого реєстру з категоріями прогнозу (наприклад, усі платежі від Stripe відображаються як «Надходження від клієнтів»; платежі Gusto — як «Зарплата»). Вкладка Відповідність постачальників у робочому зошиті вже містить цю карту, включаючи правило запобігання подвійному обліку банк/картка — почніть із неї, а не вигадуйте власну.
3. Щотижневий ритм: Повторюваний процес оновлення прогнозу, відстеження відхилень (прогноз проти факту) та набір заздалегідь визначених тригерів для дій при досягненні фінансових порогів.

Завантажте стартові файли​

Уникайте налаштування з чистого аркуша: цей посібник надає робочий зошит із формулами та зразковими даними, а також зразок реєстру, що стоїть за його першими двома тижнями.

• Робочий зошит 13-тижневого прогнозу (XLSX, v1.0.0) — cash-flow-forecast-13-week-uk.xlsx. Редаговані припущення, пов'язані формулами тижні та вкладка відповідності постачальників; замініть сині комірки зразка власними цифрами.
• Зразок реєстру та фактичних даних (реєстр Beancount, .bean) — sample.bean. Збалансований приклад реєстру з опрацьованими банківськими фактами W1–W2, що відповідають першим двом тижням робочого зошита.

Як працюють стартові файли (прочитайте це перед введенням даних)​

Аркуші. Робочий зошит (cash-flow-forecast-13-week-uk.xlsx, v1.0.0) має три аркуші:

• Прогноз — 13 датованих тижнів, припущення, надходження, виплати, чистий/кінцевий залишок готівки.
• Відповідність постачальників — карта «реєстр→категорія» з правилом обліку готівки банк/картка для кожного джерела.
• Примітки — механіка, перемикачі сценаріїв та версія, продубльовані з генератора, щоб файл пояснював себе автономно.

Часова база. Тижні починаються з понеділка, W1 починається 2026-09-14 до W13, що починається 2026-12-07 (рядок 2 аркуша Прогноз; відредагуйте ці дати, коли адаптуєте модель — кожна формула прив'язана до тижня, тому ланцюжок збережеться). Операція належить до тижня, що містить дату проведення, з понеділка по неділю.

Одиниці. Суцільні USD (формат числа #,##0). Зразкова компанія — це SaaS на початковій стадії, що відкривається з 85,000, щотижнева зарплата чергується 0 / 11,000, щомісячна оренда та автоплатіж за кредитом 900/тиждень.

Що ви вводите проти що обчислюється. Сині комірки — це ручні введення; все інше — формули:

• Введення: початковий залишок B5 (85,000), перемикачі B6/B7 (1.0), мінімальний поріг B8 (40,000), три базові категорії надходжень, десять базових категорій виплат і дати початку тижнів на аркуші Прогноз.
• Формули (показані для стовпця 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 повторно відкриває файл і перевіряє, що кожна комірка підсумків містить справжню формулу).

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

Структура (потрібні рядки)​

Ваш аркуш прогнозу має бути структурований із наведеними нижче рядками, щоб охопити всі рухи грошових коштів. Як організовано робочий зошит: три аркуші — Прогноз (13 датованих тижнів із Початковою готівкою, трьома категоріями надходжень, десятьма категоріями виплат, Чистим та Кінцевим залишком), Відповідність постачальників (джерело реєстру → категорія прогнозу, включаючи правило запобігання подвійному обліку банк/картка), та Примітки (механіка та версія, щоб файл пояснював себе автономно). На аркуші Прогноз надходження групуються як Надходження від клієнтів, Нові бронювання/Передоплати та Інші надходження; виплати групуються як Зарплата, Підрядники, Хмарні послуги/Хостинг, Програмне забезпечення/SaaS, Маркетинг, Оренда, Юридичні та бухгалтерські послуги, Податки та збори, Обслуговування боргу та Одноразові; підсумки перетікають Початкова → Загальні надходження → Загальні виплати → Чистий → Кінцева.

• Початковий залишок готівки (має дорівнювати Кінцевому залишку готівки попереднього тижня)

• Надходження (прихід грошей)

  • Надходження від клієнтів: Готівка, яку ви очікуєте отримати за наявними рахунками-фактурами (дебіторська заборгованість).
  • Нові бронювання/Передоплати: Авансові платежі, які ви очікуєте від нових угод, що закриються протягом 13-тижневого вікна.
  • Інші надходження: Будь-яка інша готівка, що надходить, як-от податкові відшкодування, процентний дохід або грантове фінансування.

• Виплати (вибуття грошей)

  • Зарплата: Повна вартість у готівці, включаючи чисту виплату працівникам та всі податки на зарплату з боку роботодавця.
  • Підрядники та фрилансери: Платежі не-працівникам.
  • Хмарні послуги/Хостинг (COGS): Основні інфраструктурні витрати, як-от AWS, GCP тощо.
  • SaaS/Інструменти: Усі ваші підписки на програмне забезпечення.
  • Маркетинг: Витрати на рекламу, гонорари агентств та інші витрати, пов'язані з брендом.
  • Оренда/Офіс: Фізичні офісні витрати.
  • Юридичні та бухгалтерські послуги: Гонорари професійних послуг.
  • Податки та збори: Перерахування податку з продажів та інші державні платежі.
  • Обслуговування боргу: Основна сума та відсотки за будь-якими кредитами.
  • Одноразові: Нерегулярні, рідкісні платежі, як-от щорічні страхові внески, гарантійні депозити або обладнання/капітальні витрати (ноутбуки, устаткування) — будь-що без власного рядка вище потрапляє сюди.

• Чистий грошовий потік (= Загальні надходження − Загальні виплати)

• Кінцевий залишок готівки (= Початкова готівка + Чистий грошовий потік)

Опрацьований 13-тижневий зразок (USD)​

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

Механіка ковзання (як реалізовано в робочому зошиті)​

Логіка ковзного прогнозу проста та потужна — і в завантаженні вона вже реалізована як формули на аркуші Прогноз (рядки в дужках):

• Початкова готівка (Тиждень 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), очистіть останній стовпець і поставте дату нового Тижня 13 у рядку 2. Формули перенесення (C10 = B29, …) переорієнтуються автоматично; вибірково перевірте, що Початкова нового Тижня 1 дорівнює Кінцевій минулого тижня.
2. Оновіть фактичними даними: Перезапишіть сині комірки прогнозу минулого тижня фактичними банківськими операціями тижня згідно з відповідністю нижче (запит, розділення, вставка — вручну). Потім підтвердьте, що комірка Кінцевої готівки тижня дорівнює вашому фактичному сукупному банківському залишку (Assets:Bank:Checking + Assets:Bank:Savings): якщо ні, то помилка у відповідності, а не в банку.
3. Переоцініть майбутнє: Оновіть сині комірки для наступних 2–4 тижнів найсвіжішою інформацією, яку маєте (щойно надіслані рахунки-фактури, майбутні платежі постачальникам, підтверджені дати зарплати).

Відображення з 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) інакше завищили б обидві сторони на ці суми.
• Наслідок: відображайте банківські ноги, а не ноги Income/Expense. Основна сума кредиту не є витратою, але є банківським вибуттям (автоплатежі зразка на 900.00 USD = 800 основна + 100 відсотки, усі враховуються як Обслуговування боргу); покупка за карткою є витратою, але ще не банківським вибуттям.

Розподіл надходжень/виплат. З експортованих банківських ніг: позитивні ноги — надходження, негативні ноги — виплати, ноги переказів виключені. Карта категорій (така сама, як на вкладці Відповідність постачальників): виплати 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). Банківські ноги W1 із реєстру після виключення пари переказів на 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 реєстру доводять кінцеву готівку кожного тижня), зазначені нижче експортні запити та незалежне перенесення на 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:* (виконайте запити вище або завантажте операції зі своїх банківських рахунків — карткові списання не враховуються; лише платіж за розрахунок). Підтвердьте, що ваша «Кінцева готівка» за минулий тиждень точно збігається з фактичним сукупним банківським залишком (Checking + Savings). Ця звірка є обов'язковою.
2. Перегляньте дебіторську заборгованість (10 хв): Складіть список усіх неоплачених рахунків-фактур і розподіліть їх по тижнях, коли очікуєте оплату. Будьте консервативними та застосовуйте реалістичні затримки збору на основі минулих показників.
3. Перегляньте кредиторську заборгованість та зарплату (10 хв): Розподіліть дати оплати всіх відомих майбутніх рахунків. Попередньо заповніть дати та суми зарплати на весь квартал. Плануйте некритичні виплати на п'ятницю, щоб зберегти гнучкість із готівкою протягом тижня.
4. Зустріч щодо відхилень (10 хв): Коротко порівняйте прогноз минулого тижня з фактичними результатами. Зафіксуйте причини будь-яких значних розбіжностей і вирішіть, чи потрібно скоригувати правила прогнозування надалі.

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

Правила точності​

• Тижні 1–2: Цільтеся на похибку ±5–10%. Ці дати та суми мають бути високо визначеними.
• Тижні 3–6: Очікуйте похибку ±10–20%. Цей період буде сумішшю відомих рахунків та оцінок на основі закономірностей.
• Тижні 7–13: Ця частина прогнозу напрямна. Вона визначається вашим конвеєром продажів та поточними витратами.

Коди впевненості: Щоб полегшити читання прогнозу, позначте кожен рядок прогнозу кодом впевненості: Підтверджено (напр., зарплата, оренда), Ймовірно (напр., рахунки-фактури надійним клієнтам) або Потенціал (напр., нові угоди з конвеєра).

Тригери та дії (визначте їх заздалегідь)​

Прогноз марний без плану. Заздалегідь визначте свої дії для досягнення певних порогів.

• Мінімальний поріг готівки: Наприклад, ваше правило може бути: «Ми повинні підтримувати готівку ≥ 1.5× наступної повної суми зарплати в будь-який час». Якщо прогноз показує порушення цього порогу, ви негайно виконуєте попередньо узгоджений план, як-от інтенсивний збір платежів і пауза на всі дискреційні витрати.
• Запобіжник грошового запасу: Наприклад, «Якщо Кінцева готівка на Тижні 13 означає менше ніж X місяців витрат, ми запускаємо наш план фінансування». Це може включати пошук умов угоди, пропозицію клієнтам знижки за передоплату доходу або використання кредитної лінії.
• Правило великих виплат: Наприклад, «Будь-яка одноразова виплата, відмінна від зарплати, що перевищує 5% поточного залишку готівки, має бути схвалена за два тижні наперед і мати запасний план».

Шаблон та сценарії​

Простий набір категорій (для SaaS на початковій стадії)​

• Надходження: Надходження від клієнтів, Інші надходження (відсотки, відшкодування, гранти)
• Виплати: Зарплата (чиста + податки роботодавця), Підрядники, Хмарні послуги/Хостинг (COGS), Програмне забезпечення/SaaS (OpEx), Маркетинг (Платний/Бренд), Оренда/Офіс, Юридичні/бухгалтерські, Податки та збори, Обслуговування боргу, Одноразові / Щорічні
• Розрахункові: Чистий грошовий потік, Кінцева готівка

Шаблон (вже вбудований у завантаження; скопіюйте це, щоб відтворити порожній)​

Таблиця нижче — це форма аркуша Прогноз — ті самі рядки, ті самі формули — для відтворення на порожньому аркуші. У завантаженні рядок 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%)

Це фактичні комірки припущень на аркуші Прогноз — додаткове налаштування не потрібне.

Навчання та уникнення помилок​

Відстеження відхилень (змусьте навчання накопичуватися)​

У тижні, що щойно завершився, додайте два стовпці: «Прогноз минулого тижня» та «Факт». Розрахуйте відхилення. Під час перегляду позначте причини значних розбіжностей: затримка збору, зсув обсягу, незапланована покупка у постачальника, зміна термінів. Якщо той самий тип відхилення повторюється, змініть базове правило вашої моделі. Наприклад, якщо збори постійно запізнюються на тиждень, змініть припущення за замовчуванням про затримку збору з 21 дня на 28 днів.

Поширені пастки (уникайте цих)​

• Змішування нарахування та готівки: Цей прогноз лише для готівки. Визнаний дохід, амортизація та інші концепції нарахування належать до вашого основного реєстру, а не сюди.
• Забування про великі щорічні витрати: Щорічні страхові внески, великі поновлення SaaS та квартальні податкові платежі можуть бути величезними несподіванками. Плануйте їх у своєму прогнозі, щойно дізнаєтеся про них.
• Ігнорування готівки податку з продажів: Навіть якщо це транзитне зобов'язання, готівка перебуває на вашому банківському рахунку, доки ви її не перерахуєте. Моделюйте і надходження, і вибуття.
• Відсутність звірки: Якщо Кінцева готівка вашого прогнозу не збігається з фактичним сукупним банківським залишком (Checking + Savings; залишки карток виключені), у вас помилка відповідності — зазвичай враховане карткове списання або збережений переказ. Ви повинні виправити це, перш ніж довіряти прогнозу.
• Відсутність чіткого відповідального: Призначте одну особу, відповідальну за оновлення прогнозу щотижня. Визначте заступника на час відпусток.

Швидкі інтеграції з Beancount​

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

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

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