Прогноз грошового потоку

Фінансова команда витрачає час щотижня на перезбирання прогнозу кеш-флоу: вивантаження проводок, зведення в Excel, перерахунок під «що якщо».

Автоматизація знімає цю рутину і переводить прогноз із режиму «знімок раз на місяць» у режим «актуальна картина щодня».

AI-агент бере дані з бухгалтерської системи та сховища даних / BI, будує прогноз на 30/60/90 днів і супроводжує його текстовим поясненням. Фінансовий менеджер не отримує голу таблицю — він отримує короткий звіт із поясненням, що змінилося і чому.

Що робить автоматизація

1. Підтягує фактичні дані з бухгалтерії (надходження, платежі, зобов'язання) та зі сховища даних (контрактні графіки, періодичні підписки, прогноз продажів).
2. Категоризує рухи: операційні надходження, податки, ФОТ, оренда, разові платежі.
3. Будує прогноз на три горизонти: 30, 60 і 90 днів.
4. Формує три сценарії: базовий (за фактом і підтвердженими зобов'язаннями), оптимістичний (з урахуванням конвеєру продажів), песимістичний (із затримкою ключових надходжень).
5. Порівнює з попередньою версією прогнозу: що змінилося, які нові ризики з'явилися, який тренд по грошовій позиції.
6. Готує текстовий виклад — коротке пояснення цифр у форматі, зрозумілому власнику без фінансової освіти.
7. Доставляє звіт за розкладом (наприклад, вранці щопонеділка) або на запит — в email, Slack або Notion.

Чого автоматизація не робить

• Не замінює скарбника і фінансового директора. Рішення про платежі, переговори з банком, залучення фінансування залишаються за людиною.
• Не передбачає виручку, якої немає в системі. Якщо конвеєр продажів ведеться в голові менеджера, а не в CRM — прогноз буде неповним.
• Не править дані у джерелі. Якщо бухгалтерія не закрита або проводки затримані — прогноз відобразить це, але не виправить.

Під капотом — зв'язка з коннекторів до джерел, ETL-шару для нормалізації даних, прогнозної моделі та LLM для генерації текстового коментаря. Реалізація — код на замовлення на Python: готові SaaS-рішення рідко покривають специфіку роботи з рахунками, контрагентами та графіком податків конкретної компанії.

Архітектурний потік

Сирі дані надходять з двох категорій джерел. Бухгалтерія (1С, QuickBooks, Xero, NetSuite — що використовується) дає фактичні залишки, проводки, контрагентів, відкриті рахунки. Сховище даних / BI (BigQuery, Snowflake, Metabase) дає продуктові метрики, контрактні графіки, розширений конвеєр продажів. Якщо сховища немає, AI-агент працює напряму з CRM і таблицями.

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

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

Кроки впровадження

1. Аудит джерел. Описати, де лежать фактичні дані (бухгалтерія), де планові (CRM, контракти), які категорії витрат потрібно відстежувати.
2. Маппінг рахунків. Звести план рахунків та категорії CRM до єдиної таксономії для прогнозу (операційка, ФОТ, податки, інвестиції, разове).
3. Підключення коннекторів. API бухгалтерії та сховища даних / BI; якщо API обмежений — вивантаження через регулярне вивантаження.
4. Збірка прогнозної моделі. Базова логіка — повторювані + заплановані + сценарні корективи. Без ML на першій ітерації, щоб результат був пояснюваним.
5. Налаштування сценаріїв. Параметри для оптимістичного та песимістичного сценаріїв узгоджуються з CFO: % затримки надходжень, % зірваної воронки продажів, прискорені платежі.
6. Підключення LLM-шару для текстового викладу. Промпт з контекстом компанії, останній прогноз, зміни. Тон та формат коментаря узгоджуються на кількох ітераціях.
7. Канал доставки. Email з PDF, Slack-повідомлення, Notion-сторінка, дашборд у BI — вибирається за тим, як команда вже працює з фінансовою звітністю.
8. Запуск у тіньовому режимі на 2-4 тижні. AI-агент будує прогноз паралельно з ручною версією, розбіжності розбираються та калібруються.

Компоненти

Оркестрація — low-code платформа або код в Airflow / cron, залежно від того, що вже використовується в команді. Для SMB частіше рушій робочих процесів: візуальний робочий процес простіше підтримувати без виділеного DevOps.

Впровадження потребує доступу до джерел даних і невеликої підготовчої роботи з боку фінансової команди.

Доступи та дані

• Доступ до бухгалтерської системи (1С, QuickBooks, Xero, NetSuite або інша) — краще API, у крайньому разі вивантаження.
• Доступ до сховища даних / BI або до джерел, на основі яких будується конвеєр продажів (CRM, білінг, таблиці контрактів).
• План рахунків і таксономія рухів в актуальному вигляді.
• Інформація про повторювані зобов'язання: оренда, підписки, ФОТ, податки.

Готовність команди

• CFO або фінансовий менеджер, який погоджує таксономію та параметри сценаріїв. Це не одноразове завдання — на першій ітерації потрібно 4-6 робочих сесій.
• Готовність працювати в тіньовому режимі 2-4 тижні: ручний прогноз і AI-прогноз паралельно для калібрування.
• Доступ до людини, яка розуміє структуру даних у джерелах (бухгалтер, власник BI).

Терміни

Базове впровадження займає 6-10 тижнів:

1. Аудит джерел і маппінг — 2 тижні.
2. Збірка моделі та інтеграцій — 3-4 тижні.
3. Тіньовий період і калібрування — 2-4 тижні.

Терміни зростають, якщо дані в джерелах розрізнені або якщо потрібні нестандартні сценарії (мульти-валютний прогноз, факторинг, робота з авансами від великих клієнтів).