Dlaczego raporty finansowe w SaaS różnią się między źródłami?
Otwierasz zestawienie faktur, księgę główną i panel płatności. Wszystkie pokazują dane za ten sam miesiąc, ale kwoty się nie zgadzają. Pierwszy odruch: gdzieś jest błąd. Tyle że rozbieżność nie musi oznaczać, że któryś z raportów jest niepoprawny.
Jedno źródło może ujmować transakcję według daty wykonania usługi, drugie według daty płatności, a trzecie według wpływu środków. Zanim zlecisz poprawkę, trzeba więc ustalić, czy raporty stosują inne zasady, czy dane rzeczywiście rozjechały się między systemami.
W tym artykule pokażę, jak rozróżnić te dwa przypadki, znaleźć źródło rozbieżności i naprawić problem tak, żeby nie wracał w kolejnych raportach.
W skrócie
|
Zestawienie faktur, panel płatności i księga mogą poprawnie pokazywać różne kwoty
Wystawienie faktury, płatność i wpływ środków na konto nie muszą nastąpić tego samego dnia. Dlatego raporty mogą pokazywać różne wartości i nadal poprawnie opisywać rzeczywistość.
Załóżmy, że faktura dotyczy usługi wykonanej w sierpniu. Klient płaci za nią we wrześniu, a bank potwierdza wpływ następnego dnia. Jedna transakcja ma więc co najmniej trzy istotne daty: wykonania usługi, rejestracji płatności i wpływu środków na konto.
Raport sprzedaży może przypisać kwotę do sierpnia. Panel operatora płatności pokaże ją we wrześniu. Wyciąg bankowy uwzględni środki dzień później.
Nie musisz więc szukać jednej kwoty za sierpień we wszystkich trzech raportach. Musisz umieć powiedzieć, dlaczego ta sama faktura jest w raporcie sprzedaży w sierpniu, a w panelu płatności we wrześniu. Tak samo nie ocenisz budżetu IT po jednej metryce: liczy się, co ta liczba oznacza i z czym ją zestawiasz.
Zanim zlecisz poprawkę, sprawdź, czy nie porównujesz sprzedaży z sierpnia z płatnościami z września.
Ustal, czy raporty używają tych samych definicji i dat
Zanim założysz, że dane są błędne, ustal, jaki okres obejmuje każdy raport, według której daty ujmuje transakcję i jak traktuje późniejsze zmiany.
Załóżmy, że fakturę z 1 sierpnia ktoś anuluje 10 września, a potem znowu wygeneruje raport za sierpień. Jaką kwotę powinien on wtedy pokazać?
Moduł faktur może pominąć tę fakturę, bo 10 września została anulowana. Księga główna, czyli General Ledger (GL), może nadal ją uwzględniać zgodnie ze stanem na 31 sierpnia (w tamtym momencie należność przecież istniała). Oba raporty mogą być w takim wypadku “poprawne”, choć pokazują inne wartości.
W tym przykładzie jeden raport bierze stan po anulowaniu, drugi stan przed. U was mogą rozjechać się inne zestawienia, z tej samej przyczyny albo z zupełnie innej. Skoro liczby już się nie zgadzają, musisz wiedzieć dlaczego, zanim zlecisz ewentualną poprawkę.
Anulowanie faktury nie zawsze znaczy to samo
Sposób anulowania dokumentu bezpośrednio wpływa na wynik raportu. System może oznaczyć fakturę jako nieważną albo utworzyć osobny dokument korygujący.
W pierwszym wariancie faktura może zniknąć z bieżącego zestawienia. W drugim pozostaje w historii, a dokument korygujący zmienia jej wartość. Raport za okres między fakturą a korektą pokaże więc inną kwotę niż raport po korekcie.
To, czy system pomija anulowaną fakturę, czy uwzględnia ją wraz z dokumentem korygującym, zmienia skład raportu i jego wynik.
Ta sama transakcja może mieć różną datę w różnych raportach
Strefa czasowa też wpływa na to, do którego dnia raport przypisze transakcję. Jeden moduł może brać datę według UTC, a drugi według lokalnego czasu klienta.
Transakcja wykonana blisko północy może wtedy zostać przypisana do różnych dni w różnych modułach. Jeśli transakcja przypada na granicę miesiąca, może też wpłynąć na wynik za dany miesiąc. To może być błąd implementacji, ale może też wynikać ze świadomie przyjętej reguły. Problem zaczyna się wtedy, gdy nikt nie potrafi tej reguły wyjaśnić.
Jeśli definicje są spójne, a liczby nadal się różnią, trzeba przejść do drugiej grupy przyczyn.
Sprawdź, czy dane nie rozjechały się między modułami
Zgodne definicje nie gwarantują zgodnych danych. Dana operacja mogła powieść się tylko w części systemu.
Załóżmy, że anulowanie faktury powiodło się w module faktur. Moduł księgowy odrzucił jednak zmianę, ponieważ poprzedni miesiąc został już zamknięty. Użytkownik widzi anulowany dokument, ale kwota z faktury nadal pozostaje w księdze.
Kilka kroków miało złożyć się na jedną zmianę, ale system wykonał tylko część z nich. Jeśli błąd nie został poprawnie obsłużony albo komunikat został zignorowany, problem może pozostać niewidoczny. To tzw. silent failure.
Taki problem jest trudniejszy do wykrycia i obsługi w systemach, które przetwarzają zdarzenia w tle lub dzielą proces między wiele usług. Nie oznacza to jednak, że mikroserwisy z definicji psują dane. Ryzyko wynika z niewłaściwej obsługi sytuacji, w której tylko część operacji kończy się powodzeniem.
System może próbować wycofać kroki, które zdążył wykonać. Ale cofnięcie również może się nie udać. Im więcej etapów ma operacja, tym więcej możliwych stanów pośrednich może powstać.
W poprzedniej sekcji problemem była różna interpretacja poprawnych danych. Tutaj dwa moduły opisują sprzeczne stany. To niespójność danych, której koszty widać z opóźnieniem. Żeby rozstrzygnąć, z którym przypadkiem masz do czynienia, musisz znaleźć konkretną transakcję.
Zawężaj analizę od miesiąca do pojedynczej transakcji
Nie próbuj wyjaśniać całego raportu naraz. Znajdź najmniejszy zakres danych, dla którego źródła nadal pokazują różne wyniki.
Porównanie samych sum potwierdzi, że problem istnieje. Nie wyjaśni jednak jego mechanizmu. Tutaj trzeba zejść poziom niżej:
- Porównaj te same źródła i ten sam okres. Zestaw panel płatności, moduł faktur i moduł księgowy.
- Sprawdź wzorzec w czasie. Zobacz, czy podobna różnica powtarza się w kolejnych miesiącach.
- Zawężaj zakres. Przejdź od miesiąca do tygodnia, dnia i konkretnej transakcji.
- Odtwórz przebieg zdarzenia. Porównaj daty, statusy i kolejne kroki we wszystkich modułach.
- Rozstrzygnij przyczynę. Ustal, czy widzisz różne definicje, czy faktyczną niespójność danych.
Powtarzalna różnica bywa szczególnie pomocna. Jeśli ta różnica co miesiąc odpowiada stawce VAT, warto sprawdzić, czy podatek nie jest pomijany w jednym źródle albo naliczany podwójnie w innym.
Wahanie od 7,5% do 9% nie wyklucza wspólnej przyczyny. Błąd może dotyczyć tylko dokumentów korygujących, cofniętych płatności albo wybranego typu transakcji. Procent zmienia się wtedy wraz z udziałem tych zdarzeń w danym miesiącu.
Dopiero pojedyncza faktura pozwala prześledzić, dlaczego moduł A i moduł B pokazują różne wyniki. Czasem znajdziesz błąd. Innym razem dane są poprawne, a rozbieżność wynika z tego, że zespół źle rozumiał, jak każdy raport ma ujmować transakcję.
Gdzie pomaga AI? AI może przygotować zapytania SQL na podstawie schematu i pomóc porównać wyniki. Nie zna jednak definicji biznesowej, jeśli nie ma jej w swoim kontekście. Bezpieczniej, gdy AI zaproponuje zapytanie, człowiek je sprawdzi, a do dalszej analizy przez AI trafią tylko zanonimizowane wyniki. Swobodny dostęp AI do środowiska produkcyjnego stwarza ryzyko dla poufności danych i wydajności systemu.
Napraw definicję, system i dane historyczne
Zmiana jednego rekordu może zamknąć ticket, ale nie usuwa przyczyny. Trwała naprawa musi objąć to, jak każdy raport ma ujmować transakcję, zachowanie systemu i dane historyczne.
Jeżeli zespół poprawi datę jednego dokumentu korygującego, to klient znów zobaczy oczekiwaną kwotę. Ale system się nie zmieni, a wcześniejsze dane zostaną bez zmian.
Dlatego naprawa powinna obejmować trzy warstwy:
- Definicja. Uzgodnić z biznesem, działem finansowym i zespołem technicznym, jak każdy raport ma ujmować transakcję i co mają oznaczać prezentowane w nim dane.
- System. Poprawić kod i obsługę błędów tak, żeby ta sama niespójność nie powstała ponownie.
- Historia. Zdecydować, czy przeliczyć stare dane, oznaczyć zmianę metodologii, czy wyznaczyć moment, od którego ma obowiązywać nowa reguła.
To, jak każdy raport ma ujmować transakcję (definicja), nie może być znane wyłącznie osobom, które obsłużyły incydent. Ma być dostępne dla użytkowników, działu finansowego, zespołu technicznego i narzędzi wspierających analizę.
Za pół roku osób, które wprowadziły poprawkę, może już nie być w projekcie. Jeśli tylko one wiedzą, jak raport ma ujmować transakcję, bus factor spada do jednej osoby. Nowa osoba musi móc ustalić, dlaczego raport przed 1 września działa inaczej niż raport po tej dacie.
Właśnie tutaj powstaje dług danych. Składają się na niego nie tylko błędne rekordy, ale też brak dokumentacji wyjaśniającej znaczenie poprawnych danych. Bez tej wiedzy za kilka miesięcy zespół znów będzie zmuszony naprawiać ten sam problem.
Oceń, czy rozjazd raportów jest objawem większego problemu
Powracające różnice mogą oznaczać, że problem wykracza poza jeden raport, szczególnie gdy zespół nie potrafi wyjaśnić definicji raportów, błędy znikają bez śladu, a poprawki nie obejmują danych historycznych.
W takiej sytuacji CFO lub CEO nie musi od razu zamawiać dużego audytu. Może zacząć od samodzielnej diagnozy stanu projektu IT. Pozwala ona sprawdzić, czy sprzeczne raporty są odosobnionym problemem danych, czy elementem szerszej utraty kontroli nad produktem.
Jeżeli diagnoza pokaże brak spójnego obrazu stanu, odpowiedzialności i procesu, punktowe poprawki mogą nie wystarczyć. Wtedy potrzebne bywa wsparcie zagrożonego projektu technologicznego, które porządkuje sposób pracy, zarządzanie ryzykiem i realizację zobowiązań.
Podsumowanie
Różne raporty finansowe nie muszą świadczyć o błędzie. Mogą ujmować transakcję według innej daty, odtwarzać stan z innego momentu albo inaczej traktować korekty. Jeśli każdy raport ma ujmować transakcję według tych samych zasad, szukaj operacji, która powiodła się tylko w części systemu.
Kolejność ma znaczenie: ustal, jak każdy raport ma ujmować transakcję (definicja), znajdź transakcję, odtwórz jej przebieg, a potem napraw system i dane historyczne. Wiarygodny raport nie musi pokazywać tej samej liczby co każdy inny. Musi jasno wskazywać, na jakie pytanie odpowiada, na jakich danych opiera wynik i dlaczego można mu zaufać.
