Aging należności — jak liczyć przedziały 30/60/90 i dlaczego liczby mogą się różnić od Optimy

Trzy daty w Optimie — tylko jedna jest właściwa dla aging

Każdy dokument w Optimie ma kilka dat: datę wystawienia faktury, datę sprzedaży lub datę księgowania oraz termin płatności. Dla aging należności liczy się wyłącznie termin płatności. Nie data wystawienia.

Aging mówi, ile dni minęło od momentu, w którym płatność powinna już być. Jeśli faktura ma termin 60-dniowy i jest wystawiona 1 marca, to aging zaczyna się liczyć dopiero 1 maja — nie od razu. Użycie daty wystawienia zamiast terminu płatności zawyża aging dla faktur z długim terminem i zaniża dla faktur z krótkim terminem (np. 7-dniowym). Optima w swoim raporcie aging używa terminu płatności. System BI powinien robić to samo.

Standardowe przedziały aging

Najpopularniejszy podział wygląda tak:

• Current (bieżące) — niezapłacone, ale termin płatności jeszcze nie minął.
• 1–30 dni — termin płatności przekroczony od 1 do 30 dni.
• 31–60 dni — od 31 do 60 dni po terminie.
• 61–90 dni — od 61 do 90 dni po terminie.
• 90+ dni — ponad 90 dni po terminie (w niektórych branżach dalej: 90–180, 180+).

Przedziały nie są sztywnym standardem. Klient może chcieć 45/90/180 zamiast 30/60/90 — to parametr projektu, ustalany na etapie projektowania systemu BI, nie domyślne założenie. Uzgodniona definicja jest częścią projektu.

Cztery przyczyny rozbieżności między BI a Optimą

To jest serce sprawy. Kiedy liczby się różnią, powód jest zwykle jeden z czterech poniższych — nie błąd systemu.

1. Częściowe płatności

Najemca zapłacił 80% faktury. Optima wyświetla tę fakturę jako „częściowo opłaconą" lub pokazuje pozostałą kwotę. W BI muszę to wyliczyć: kwota faktury minus suma wpłat przypisanych do tej faktury. Kiedy kontrahent przelewa jedną kwotą globalne rozliczenie kilku faktur — muszę zdefiniować regułę przypisania. Najczęściej: najstarsza faktura najpierw. Ta reguła musi być zdefiniowana i konsekwentna, bo od niej zależy, która faktura trafia do którego przedziału aging.

2. Noty kredytowe i kompensaty

Klient ma fakturę na 10 000 PLN i notę kredytową (korektę) na -3 000 PLN. Zaległość netto: 7 000 PLN. Optima może to pokazać jako dwa osobne dokumenty lub jako jedno saldo — zależnie od konfiguracji raportu. W BI muszę obsłużyć oba podejścia i zdefiniować, które jest „prawdą" dla tej firmy. Kompensata (rozliczenie wzajemne) musi być uwzględniona — inaczej BI pokaże należność jako nieopłaconą, podczas gdy w Optimie jest już rozliczona.

3. Storna i dokumenty anulujące

Faktura wystawiona, zaksięgowana, a następnie anulowana stornem. W BI storno musi być powiązane z oryginalną fakturą — i obie muszą być wykluczone z aging lub potraktowane jako się kompensujące. Jeśli BI nie obsługuje storn poprawnie, stara faktura będzie widoczna jako zaległa, mimo że w Optimie jest anulowana. To jedna z częstszych przyczyn pozornych rozbieżności przy pierwszym uruchomieniu raportu.

4. Data odniesienia

Optima liczy aging na moment bieżący. Raport BI odświeżony o 06:00 liczy aging na moment odświeżenia. Jeśli ktoś porównuje wczorajszy raport BI z dzisiejszym raportem z Optimy — różnica jednej doby w dacie odniesienia przesuwa część faktur o jeden przedział. To nie jest błąd BI — to różnica dat. Dlatego dobrze zaprojektowany raport zawsze pokazuje datę i godzinę ostatniego odświeżenia.

Przykład z trzema fakturami jednego kontrahenta

Kontrahent ma trzy faktury:

• Faktura A: 5 000 PLN, termin płatności 90 dni temu — niezapłacona.
• Faktura B: 8 000 PLN, termin płatności 45 dni temu — zapłacono 6 000 PLN.
• Faktura C: 3 000 PLN, termin płatności za 10 dni — niezapłacona (bieżąca).

Prawidłowy aging dla tego kontrahenta:

• Current: 3 000 PLN (Faktura C — termin jeszcze nie minął).
• 31–60 dni: 2 000 PLN (Faktura B — niezapłacona część, termin 45 dni temu).
• 61–90 dni: 5 000 PLN (Faktura A — termin 90 dni temu).
• Łączna zaległość: 7 000 PLN.

Żeby to policzyć poprawnie, potrzebuję trzech rzeczy: przypisania częściowej płatności do właściwej faktury (Faktura B, nie A ani C), obliczenia pozostałej kwoty (8 000 – 6 000 = 2 000 PLN) oraz właściwego terminu płatności — nie daty wystawienia. Jeśli którykolwiek z tych elementów jest zaimplementowany inaczej niż w Optimie, liczby się różnią.

Która liczba jest „prawdziwa"

Uczciwa odpowiedź: oba systemy mogą być poprawne — pod warunkiem że liczą to samo. Różnice wynikają z różnych definicji, a nie z błędów. Optima ma swoje reguły obliczania salda, przypisywania płatności i prezentacji not kredytowych. System BI musi albo odwzorować te same reguły, albo — jeśli są inne potrzeby — stosować inne, ale jasno zdefiniowane i uzgodnione z klientem.

Kiedy logika jest uzgodniona i zaimplementowana w warstwie Silver — liczby z BI i z Optimy powinny być identyczne lub mieć tylko minimalną różnicę wynikającą z daty odświeżenia. Rozbieżności w trakcie wdrożenia są punktem weryfikacji, nie powodem do alarmu.

Istnieją też dwa różne widoki tych samych danych — oba przydatne: aging per kontrahent (jeden wiersz per kontrahent z sumami w przedziałach) i aging per faktura (każda faktura osobno z przypisanym przedziałem). Pierwszy daje szybki przegląd portfela należności, drugi pozwala zidentyfikować konkretne dokumenty wymagające działania.

Podsumowanie

Aging należności to nie proste policzenie dni od daty wystawienia faktury. Wymaga obsługi częściowych płatności, storn, kompensat i not kredytowych — oraz jasnej definicji terminu płatności jako daty referencyjnej. Każda z tych reguł jest częścią projektu BI, ustalana z klientem, nie zakładana domyślnie. Kiedy logika jest zbudowana w warstwie Silver i uzgodniona — działa konsekwentnie w każdym raporcie. A rozbieżności między BI a Optimą, które pojawiają się na początku, przestają być źródłem niepokoju i stają się checklistą do weryfikacji implementacji.