Прогнозиране на паричните потоци: Методът на 13-седмичната подвижна прогноза

Това ръководство предоставя прост метод на ниво финансов директор за управление на ликвидността на вашата компания. Изграждайки 13-седмична подвижна прогноза за паричните потоци, можете да видите своя cash runway по седмици, стратегически да насочвате събиранията и плащанията и да елиминирате финансовите изненади. Това е система, създадена за основатели — и тази страница предоставя самия модел: работна книга с формули и примерни данни, плюс примерния регистър в Beancount зад първите ѝ две седмици (вижте файловете за изтегляне по-долу).

Две неща, които това ръководство не е: прогнозата представлява прогнозни оценки за бъдещето, които вие въвеждате, докато счетоводните фактически данни са банкови движения, вече осчетоводени във вашия регистър — затова работната книга ги държи отделно. Замразявате копие на плана си като датирана базова линия (Baseline), въвеждате банковите парични средства за всяка приключена седмица на отделен лист Actuals, и четете разликата на лист Variance; планът, с който сравнявате, никога не се презаписва. Тук нищо не се синхронизира автоматично: работната книга няма макроси или външни връзки и нито една стъпка не извлича данни от вашата банка или Beancount самостоятелно.

Защо 13 седмици?​

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

• Краткосрочен контрол: Обхваща приблизително едно бизнес тримесечие, давайки ви ясен поглед върху непосредствената ви ликвидност. Този хоризонт е достатъчно дълъг, за да включи 2–3 цикъла на заплати, данъчни плащания и типични условия за плащане към доставчици, но достатъчно кратък, за да остане високо точен и приложим.
• Изглед на постъпления и плащания: Прогнозата използва „директния метод“, фокусирайки се изцяло върху паричните постъпления и плащания. Това не е за начисляване или рентабилност; това е за това какво действително ще влезе или излезе от банковата ви сметка, гарантирайки, че прогнозата се свързва директно с банковия ви баланс.
• Подвижна, не статична: Това не е еднократен бюджет. Всяка седмица премахвате изминалата седмица, добавяте нова седмица в края (седмица 13) и актуализирате предположенията си. Това поддържа прогнозния хоризонт постоянен, превръщайки прогнозирането в динамична, седмична дисциплина.

Какво ще изградите​

1. Една прогнозна решетка: Ядрото на системата е един лист с 13 колони (Седмица 1 до Седмица 13) и ясно дефинирани секции: Начални парични средства, Постъпления, Плащания, Нетни парични средства и Крайни парични средства. Три придружаващи листа със същите редове запазват замразена базова линия (Baseline) на този план, фактическите данни (Actuals), записани от вашата банка, и отклоненията (Variance) между тях.
2. Картиране на категории: Проста система за съпоставяне на транзакции от вашия регистър към прогнозните категории (напр. всички плащания от Stripe се съпоставят на „Постъпления от клиенти“; плащанията от Gusto се съпоставят на „Заплати“). Разделът Vendor Mapping в работната книга вече кодира тази карта, включително правилото за недвойно отчитане на банка/карта — започнете от него, вместо да измисляте свое.
3. Седмичен ритъм: Повтарящ се процес за записване на фактическите данни, преглед на отклоненията спрямо базовата линия, към която сте се ангажирали, преоценка на предстоящите седмици и набор от предварително дефинирани тригери за действие при достигане на финансови прагове.

Изтеглете началните файлове​

Пропуснете настройката на празна страница: това ръководство предоставя работна книга с формули и примерни данни, плюс примерния регистър зад първите ѝ две седмици.

• Работна книга за 13-седмична прогноза (XLSX, v1.1.0) — cash-flow-forecast-13-week-bg.xlsx. Редактируеми предположения, формулно-свързани седмици, моментна снимка само със стойности на Baseline, лист Actuals, лист Variance само с формули и раздел за карта на доставчици. Всяко примерно число е от разработения пример — заменете го със своите (вижте Примерни спрямо вашите данни по-долу).
• Примерен регистър и фактически данни (Beancount регистър, .bean) — sample.bean. Балансиран примерен регистър, чиито банкови парични средства за W1–W2 са точно това, което листът Actuals на работната книга съдържа за първите си две седмици.

Как работят началните файлове (прочетете това преди да пишете)​

Листове. Работната книга (cash-flow-forecast-13-week-bg.xlsx, v1.1.0) има шест листа, в този ред:

• Forecast — вашият активен план: 13-те датирани седмици, предположения, постъпления, плащания, нетни/крайни парични средства. Редактирайте го колкото често искате.
• Baseline — моментна снимка само със стойности на редове 2–29 от Forecast, обозначена с версия в B31 и дата на състоянието в B32. Не съдържа формули, така че нищо, което правите другаде, не може да го промени.
• Actuals — банковите парични средства, които всяка приключена седмица действително е преместила, въведени от вас: статус в ред 3 (complete или partial), суми по категории в същите редове като Forecast и незадължителен баланс по извлечение в ред 30.
• Variance — само формули: Actual − Baseline за всяка категория и общо, съпоставени по дата на начало на седмицата, плюс легенда, обясняваща всяка дума за статус. Никога не чете 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/Инструменти: Всичките ви софтуерни абонаменти.
  • Маркетинг: Разходи за реклама, такси на агенции и други разходи, свързани с бранда.
  • Наем/Офис: Разходи за физически офис.
  • Правни и счетоводни: Такси за професионални услуги.
  • Данъци и такси: Плащания на данък върху продажбите и други плащания към държавата.
  • Обслужване на дълг: Както главница, така и лихва по всякакви заеми.
  • Еднократни: Непостоянни, редки плащания като годишни застрахователни премии, депозити за сигурност или хардуер/capex (лаптопи, оборудване) — всичко без собствен ред по-горе попада тук.

• Нетен паричен поток (= Общо постъпления − Общо плащания)

• Краен паричен баланс (= Начални парични средства + Нетен паричен поток)

Разработен 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: Paste Special → Values; LibreOffice: Paste Special → Values Only; Numbers: Edit → Paste Formula Results. Обикновеното поставяне би пренесло живи формули и „базовата линия“ би следвала безшумно всяка следваща редакция.
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, така че невъведена седмица не може да мине за „по план“. Знаците са Actual − Baseline (колона 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.
• Вътрешни прехвърляния: прехвърляне Разплащателна↔Спестовна има два противоположни банкови крака, така че се нетува до нула в рамките на този обхват и се изключва от както постъпленията, така и плащанията. Примерните прехвърляния от 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), след като приложите горния обхват на банковите парични средства (изключете прехвърлянето Разплащателна↔Спестовна от двете страни; отчитайте уреждането на 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 (Разплащателна 80,000 + Спестовна 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 съвпадат напълно с действителния ви комбиниран банков баланс (Разплащателна + Спестовна) — ред 31 показва 0. Това съгласуване е задължително.
2. Прегледайте вземанията (10 мин): Избройте всички неизплатени фактури и ги разпределете в седмицата, в която очаквате плащане. Бъдете консервативни и прилагайте реалистични закъснения при събирането въз основа на миналата ефективност.
3. Прегледайте задълженията и заплатите (10 мин): Разпределете падежите за всички известни предстоящи сметки. Предварително попълнете датите и сумите на заплатите за цялото тримесечие. Отложете некритичните плащания за петък, за да запазите опционалност на паричните средства през седмицата.
4. Среща за отклоненията (10 мин): Отворете листа Variance и прегледайте колоната compared за седмицата: кои категории са се променили, в каква посока и какво е направило това с кумулативните крайни парични средства. Отбележете причините за значителните разлики и решете дали трябва да коригирате правилата си за прогнозиране занапред.

Точност и вземане на решения​

Емпирични правила за точността​

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

Кодове за увереност: За да направите прогнозата по-лесна за четене, маркирайте всеки прогнозен ред с код за увереност: Ангажирано (напр. заплати, наем), Вероятно (напр. фактури към добри клиенти) или Потенциално (напр. нови сделки от воронката).

Тригери и действия (решете ги предварително)​

Прогнозата е безполезна без план. Дефинирайте предварително действията си за достигане на определени прагове.

• Минимален праг на паричните средства: Например, вашето правило може да бъде „Трябва да поддържаме парични средства ≥ 1.5× следващата пълна сума за заплати по всяко време.“ Ако прогнозата показва, че ще нарушите този праг, незабавно изпълнявате предварително договорен план, като например спринт за събиране и спиране на всички дискреционни разходи.
• Предпазна граница на cash runway: Например, „Ако Крайните парични средства в Седмица 13 предполагат по-малко от X месеца изгаряне, ще задействаме плана си за финансиране.“ Това може да включва търсене на term sheet, предлагане на клиентите отстъпка за предплащане на приходи или изтегляне на кредитна линия.
• Правило за големи изходящи потоци: Например, „Всяко отделно плащане извън заплати, по-голямо от 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 — не е нужно допълнително свързване.

Учене и избягване на грешки​

Преглед на отклоненията (направете ученето натрупващо се)​

Работната книга прави счетоводството на отклоненията вместо вас: Variance = Actual − Baseline, по категория и по обща сума, за всяка седмица, чиито Actuals са complete и датирани като Baseline. Вашата задача е да обясните числата. При прегледа маркирайте причините за големите разлики: забавяне при събирането, отклонение в обхвата, непланирана покупка от доставчик, промяна във времето. Ако същият тип отклонение се повтаря, променете основното правило на модела си. Например, ако събирането постоянно закъснява с една седмица, променете предположението си за закъснение при събиране по подразбиране от 21 дни на 28 дни.

Разработено сравнение (предоставеният пример). Базовата линия B1 беше прихваната на 2026-09-11 от начални 85,000; Actuals са банковите парични средства от примерния регистър. Знаците следват листа 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 — Baseline B1 остава както е, така че следващото тримесечие все още можете да видите колко далеч беше първоначалният план.

Чести капани (избягвайте ги)​

• Презаписване на плана: Въвеждането на фактически данни върху клетките на Forecast (или повторното поставяне на Baseline всяка седмица) унищожава плана, спрямо който е трябвало да бъдете измервани. Фактическите данни отиват в Actuals; Baseline се променя само когато умишлено преместите хоризонта.
• Смесване на начисляване и парични средства: Тази прогноза е само за парични средства. Признат приход, амортизация и други начисляващи концепции принадлежат във вашия основен регистър, не тук.
• Забравяне на непостоянните годишни разходи: Годишните застрахователни премии, големите подновявания на SaaS и тримесечните данъчни плащания могат да бъдат огромни изненади. Планирайте ги в прогнозата си веднага щом научите за тях.
• Игнориране на паричните средства от данък върху продажбите: Дори ако е задължение за препращане, паричните средства са в банковата ви сметка, докато не ги внесете. Моделирайте както входящия, така и изходящия поток.
• Липса на съгласуване: Ако Крайните парични средства за седмицата в Actuals не съвпадат с действителния ви комбиниран банков баланс (Разплащателна + Спестовна; салдата по карти се изключват), имате грешка в картата — обикновено отчетено плащане по карта или запазено прехвърляне. Трябва да я поправите, преди да можете да се доверите на прогнозата.
• Липса на ясен отговорник: Възложете на един човек отговорността да актуализира прогнозата всяка отделна седмица. Определете заместник за отпуски.

Бързи връзки с 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. Бележки: Няколко точки за ключови предположения, които са се променили след последната актуализация, и всички тригери, които сте задействали или очаквате да задействате.