Dlaczego 13-tygodniowa prognoza gotówki ciągle chybia

Wyobraź sobie poniedziałek w szóstym tygodniu kwartału. Trzynastotygodniowa prognoza gotówki, która w pierwszym tygodniu poszła do banku, mówiła, że debet osiągnie szczyt mniej więcej w połowie limitu. Teraz zmierza prosto do limitu, a nic spektakularnego się nie wydarzyło: żaden klient nie upadł, żadne duże zamówienie nie przepadło. Trzech średnich klientów zapłaciło dwanaście dni po terminie, dostawca przesunął swój cykl przelewów, a płatność VAT wypadła w tym samym tygodniu co wynagrodzenia. O każdej z tych rzeczy ktoś w firmie wiedział. Żadnej nie było w prognozie.

Prognoza 13-tygodniowa to jedyna prognoza, którą bank naprawdę czyta — a w wielu firmach średniej wielkości to najsłabiej zamodelowana liczba w całym dziale finansowym. Zwykle jest arkuszem przesuwanym ręcznie w każdy piątek i zasilanym eksportem rozrachunków z ERP.

Prawdziwa przyczyna: termin płatności to jeszcze nie gotówka

ERP wie, kiedy faktura jest wymagalna. Nie wie, kiedy zostanie zapłacona. Mimo to niemal każdy model 13-tygodniowy zaczyna od terminów, bo to właśnie eksportuje raport wiekowania należności, a potem poprawia wynik procentowym „poślizgiem”, który ktoś ustawił dwa lata temu.

Gotówka płynie jednak według zachowań. Klient z 30-dniowym terminem, który osiem ostatnich faktur zapłacił w 44. dniu, zapłaci w 44. dniu i tym razem — niezależnie od tego, co mówi księga. Twoje własne wypływy idą za kalendarzem przelewów i nawykami osoby, która je zleca, a nie za terminami na fakturach dostawców. Prognoza myli się więc w sposób uporządkowany i przewidywalny. To dobra wiadomość: uporządkowany błąd da się zamodelować.

Gdzie pękają prognozy 13-tygodniowe

Wpływy liczone z terminów, a nie z historii. Raport wiekowania zakłada, że wszyscy płacą na czas, a poślizg — że wszyscy spóźniają się tak samo. Jedno i drugie jest fałszywe dla konkretnego klienta, a błąd skupia się właśnie u tych klientów, którzy są na tyle duzi, żeby miało to znaczenie.

Jeden poślizg dla całej księgi. Płaski procent opóźnienia ukrywa przesunięcie, które się liczy: jednego dużego klienta, który w ciągu kwartału przechodzi z 35. na 50. dzień. Uśredniony z resztą portfela dryf jest niewidoczny aż do tygodnia, w którym uderza.

Wypływy według terminów na fakturach. Większość firm płaci cyklami — co tydzień, co dwa tygodnie, czasem doraźnie, gdy gotówki brakuje. Prognozowanie zobowiązań po terminach przesuwa gotówkę między tygodniami, a dla banku rozkład na tygodnie jest sednem sprawy.

Pozycje o stałych terminach poza modelem. Wynagrodzenia, składki ZUS, VAT i zaliczki na CIT mają ustawowe terminy i często są wpisywane ręcznie. Ręcznie wpisane wiersze dezaktualizują się jako pierwsze, gdy zmieni się stawka albo liczba etatów.

Brak pamięci własnego błędu. Większość zespołów nadpisuje zeszłotygodniową prognozę bieżącą. Bez przechowywania każdej wersji nikt nie powie, czy model jest systematycznie zbyt optymistyczny — ani w których tygodniach.

Co robić zamiast tego

Zacznij od tych samych danych z ERP, tylko użytych inaczej.

• Prognozuj wpływy per klient na podstawie zachowań płatniczych. Dla każdego istotnego klienta policz liczbę dni do zapłaty z ostatnich faktur — medianę i rozrzut, nie tylko średnią — i ustaw każdą otwartą fakturę na dniu, który podpowiada historia. Klienci bez historii dostają termin plus ostrożny domyślny poślizg.
• Obserwuj dryf, nie tylko poziom. Klient, któremu liczba dni do zapłaty rośnie z faktury na fakturę, sam w sobie jest wczesnym ostrzeżeniem — zwykle na długo przed pierwszym telefonem z windykacji. To zachowanie pętli pierwszego rzędu opisane w tekście o zamknięciu ciągłym: odchylenie wychodzi na wierzch w dniu, w którym się pojawia, a nie na koniec kwartału.
• Układaj wypływy według własnego kalendarza przelewów. Modeluj, kiedy faktycznie płacisz, a nie kiedy jesteś winien. Gdy cykl przelewów się przesunie, prognoza przesuwa się razem z nim.
• Zamień pozycje o stałych terminach w reguły, a nie komórki. Wynagrodzenia z systemu kadrowo-płacowego, podatki i składki z ich podstaw, każda pozycja w swoim ustawowym terminie.
• Przechowuj każdą wersję i ją rozliczaj. Zapisuj prognozę z każdego tygodnia. Trzynaście tygodni później porównaj ją z rzeczywistością, tydzień po tygodniu. Kształt błędu — kierunek, wielkość, tygodnie, w których się skupia — pokaże, gdzie model jest obciążony.

Nic z tego nie wymaga dużego modelu. Wymaga dostępu do odczytu do należności, zobowiązań, wyciągów bankowych i płac oraz dyscypliny w przechowywaniu historii. AI zarabia na siebie w tej części, którą ludzie pomijają: co noc od nowa szacuje zachowania płatnicze setek klientów i prostym językiem mówi, które trzy zmiany poruszyły prognozą od piątku. Pomaga też sygnał z zewnątrz. Klient, którego własny rynek ma kłopoty — jak w tekście o OSINT dla CFO — zwykle zaczyna płacić później, zanim ktokolwiek wyjaśni Ci dlaczego.

Test na ten tydzień

Potrzebujesz jednego eksportu: zapłacone faktury z ostatnich dwunastu miesięcy, z datą wystawienia, terminem płatności i datą zapłaty.

1. Dla dwudziestu największych klientów według wpływów policz medianę liczby dni między terminem a zapłatą.
2. Policz, ilu z nich ma medianę spóźnienia powyżej pięciu dni, i zanotuj największą.
3. Weź prognozę wysłaną sześć tygodni temu i znajdź wpływy, których spodziewała się od tych samych klientów. Porównaj je z tym, co faktycznie wpłynęło w każdym kolejnym tygodniu.

Jeśli spóźniający się klienci tłumaczą większość różnicy, Twoja prognoza nie ma pecha — jest zbudowana na złej dacie. To decyzja modelowa i da się ją naprawić. Podejmowanie jej od nowa co noc, na Twoim sprzęcie, zanim zapyta bank, to praca, do której budujemy ObserBI.