Коротко: Business Central дає фактичний рух грошей із коробки, прогноз на 30–90 днів — після налаштування, а корисним прогноз стає тоді, коли в нього додані зобов'язання, яких в ERP немає: зарплата, податки, кредити. Без них картина буде впевнено оптимістичною.
Три рівні
| Рівень | Що показує | Що потрібно |
|---|---|---|
| 1. Факт | Що вже сталося з грошима | Налаштований банк і каса |
| 2. Прогноз | Що станеться за 30–90 днів | Плюс зовнішні зобов'язання |
| 3. Сценарії | Що буде, якщо клієнт не заплатить | Плюс дисципліна оновлення |
Більшість компаній зупиняється на першому рівні й називає це cash flow. Формально правильно, практично марно: факт відповідає на питання «що було», а керувати треба тим, що буде.
Рівень 1: факт
Рух грошей за період у розрізі статей — це те, що система будує на основі проведених банківських і касових документів. Умови дві.
Банківські виписки завантажуються, а не вводяться руками. Ручне введення означає затримку в кілька днів, і фактичний звіт завжди відстає. Механіка — банківська виписка й автоматична звірка.
Платежі застосовані до документів. Незастосований платіж потрапить у рух грошей, але не зменшить дебіторку — і два звіти розійдуться. Про це — управління платежами.
Розрізи задаються розмірностями: за напрямами, проєктами, юрособами. Тут же вирішується, чи потрібен вам прямий метод (за статтями надходжень і виплат) чи непрямий (від прибутку через зміни в оборотних активах). Для оперативного управління зазвичай потрібен прямий.
Рівень 2: прогноз
Прогноз збирається з чотирьох джерел, три з яких є в системі.
- Дебіторка з очікуваними датами. Відкриті рахунки плюс строки за умовами оплати.
- Кредиторка до сплати. Те саме з боку постачальників.
- Відкриті замовлення. Те, що буде відвантажено й оплачено в горизонті прогнозу.
- Зобов'язання поза системою. Ось цього немає — і саме через це прогноз найчастіше не працює.
Горизонт: 30 днів для оперативних рішень, 90 — для планування. Далі точність падає настільки, що прогноз перетворюється на побажання.
Чого немає в системі
Найважливіший розділ. Прогноз, побудований лише з даних ERP, буде оптимістичним — і помітите ви це в найгірший момент.
Що треба додати вручну або окремим механізмом:
- Зарплата й податки на неї — якщо облік зарплати ведеться поза системою.
- Податкові платежі за графіком.
- Кредити й лізинг — тіло й відсотки.
- Оренда й регулярні платежі, які не оформлюються замовленнями.
- Дивіденди й виплати власникам, якщо вони планові.
- Інвестиційні витрати — обладнання, ремонт.
Практично це робиться так: складається перелік регулярних зобов'язань із сумами й датами, і він вноситься в прогноз як окремий шар. Роботи — кілька годин один раз плюс оновлення при змінах. Без цього кроку решта налаштування не має сенсу.
Прогноз за поведінкою, а не за договором
Друга річ, яка відрізняє робочий прогноз від формального.
За замовчуванням надходження прогнозуються за строками з умов оплати: у клієнта 14 днів — значить, гроші прийдуть на 14-й. Якщо клієнт стабільно платить на 35-й, прогноз буде неправильним щомісяця й в один бік.
Рішення — рахувати фактичну затримку по кожному клієнту з історії застосованих платежів і використовувати її замість договірної. Це не автоматична функція, але дані для розрахунку в системі є. Той самий підхід описаний у матеріалі про аналіз дебіторки.
Різниця на практиці велика: прогноз за договорами показує рівний потік, прогноз за поведінкою — реальні провали, до яких можна підготуватися.
Рівень 3: сценарії
Коли прогноз працює, з'являється сенс питати «а що, якщо».
- Що буде, якщо три найбільші клієнти затримають оплату на два тижні?
- Що буде, якщо ми заплатимо постачальнику достроково заради знижки?
- Скільки ми можемо вилучити з обороту без розриву?
- Витримаємо велике замовлення з відстрочкою 60 днів?
Останнє запитання — найпрактичніше. Велике замовлення з довгою відстрочкою виглядає як успіх продажів і може бути причиною касового розриву: товар відвантажили, постачальнику заплатили, гроші прийдуть через два місяці. Механіка цієї пастки — касовий розрив при зростанні.
Хто веде прогноз
Технічно налаштувати прогноз нескладно. Складно домовитися, хто його підтримує — і без цієї відповіді він застаріває за два тижні.
Робочий розподіл: фінансист відповідає за модель і зовнішні зобов'язання, продажі дають очікувані надходження за великими угодами, закупівлі — планові виплати понад поріг. Кожен оновлює свою частину, а не «фінансовий відділ збирає з усіх», бо збирання перетворюється на щотижневе полювання за даними.
Друга умова — прогноз має бути в одному місці. Варіант, коли фінансист веде свою версію, а керівник продажів свою, гірший за відсутність прогнозу: замість рішень ви отримуєте суперечку про те, чия таблиця правильна.
І третє: домовтеся, що вважається великою угодою, яку треба вносити окремо. Без порогу в прогноз потрапляє або все, або нічого.
Останнє: прогноз має бути видимий не лише як цифра, а як графік залишку на рахунках по днях. Таблиця з надходженнями й виплатами показує рух, але провал видно тільки на кривій — і саме момент, коли лінія опускається нижче нуля, і є те, заради чого прогноз будують.
Помилки при побудові
Прогноз без зовнішніх зобов'язань. Найчастіша й найдорожча. Картина виглядає спокійною до дня виплати зарплати.
Прогноз за договірними строками. Дає рівний потік там, де насправді провали.
Занадто довгий горизонт. Прогноз на пів року в оперативному управлінні створює ілюзію контролю. Для оперативки — 30 днів, для планування — 90.
Ніхто не оновлює. Прогноз — живий документ. Якщо його переглядають раз на місяць, до середини місяця він уже неправильний. Робоча частота — щотижня.
Прогноз бачить тільки фінансист. Рішення про відстрочку клієнту ухвалює продажник, і він має бачити, як воно впливає на потік. Що з цього має доходити до керівництва — у статті Business Central для CEO.
Часті запитання
Чи є в Business Central готовий звіт про рух грошей?
Фактичний рух за статтями будується на основі проведених банківських і касових документів після налаштування статей і розмірностей. Прогноз потребує додаткової роботи — насамперед внесення зобов'язань, яких в ERP немає.
Чому прогноз завжди оптимістичніший за реальність?
Дві причини: у ньому немає зарплати, податків і кредитів, якщо вони ведуться поза системою, і надходження прогнозуються за договірними строками замість фактичної поведінки клієнтів.
На який горизонт будувати?
30 днів для оперативних рішень, 90 для планування. Далі точність падає настільки, що прогноз стає побажанням і створює ілюзію контролю.
Як часто оновлювати?
Щотижня. Прогноз, який переглядають раз на місяць, до середини місяця вже неправильний, і рішення на його основі ухвалювати не варто.
Хто має бачити прогноз?
Не тільки фінансова служба. Рішення про відстрочку клієнту ухвалює продажник, і він має бачити наслідки для потоку — інакше умови даються без розуміння ціни.