Termin płatności faktury: jak kontrolować datę bazową i warunki płatności
Ta sama faktura może mieć inny termin płatności zależnie od daty bazowej, warunków kontraktu i konfiguracji systemu. Dlatego AP powinno umieć odtworzyć obliczenie, zanim dokument trafi do propozycji płatności.
Termin płatności nie jest polem do mechanicznego przepisania z dokumentu. System może obliczać go z daty faktury, daty wpływu, daty księgowania albo innej uzgodnionej daty bazowej. Do tego dochodzą warunki netto, koniec miesiąca, dzień miesiąca, rabaty i kalendarze płatnicze. Poniższy model służy kontroli danych w procesie klienta; nie zastępuje umowy, jego polityki płatniczej ani decyzji osoby uprawnionej.
1. Rozdziel cztery daty na wejściu
Microsoft rozróżnia na fakturze dostawcy datę wpływu, datę faktury, datę księgowania i termin płatności. W opisanym systemie termin może początkowo wynikać z daty księgowania i warunków płatności, a po wprowadzeniu daty faktury zostać przeliczony. To pokazuje, dlaczego sama wartość w polu „due date” nie wystarcza.
AP powinno zapisać źródło każdej daty i wskazać, która uruchamia liczenie. Data wpływu pochodzi z kanału odbioru, data faktury z dokumentu, data księgowania z okresu finansowego, a termin płatności jest wynikiem reguły. Pomieszanie tych ról może niepotrzebnie skrócić albo wydłużyć czas płatności.
2. Ustal hierarchię źródeł warunków płatności
Warunki mogą pochodzić z zamówienia, kartoteki dostawcy, umowy lub ustawień domyślnych. Oracle opisuje, że przy wskazanym PO warunki mogą domyślnie pochodzić z zamówienia, a bez niego z lokalizacji dostawcy lub opcji faktur. SAP wskazuje także propozycję warunków z zamówienia albo danych dostawcy.
Kontrola powinna porównać kod warunków z dokumentem źródłowym i wyjaśnić każdą ręczną zmianę. Nie wystarczy zgodność z kartoteką, jeżeli konkretna umowa przewiduje inne zasady. Dla wielu zamówień trzeba uważać, które z nich dostarczyło wartość domyślną.
3. Odtwórz obliczenie krok po kroku
Najprostszy wariant netto dodaje określoną liczbę dni do daty bazowej. Inne reguły liczą od końca miesiąca, używają konkretnego dnia miesiąca albo przesuwają termin po przekroczeniu dnia granicznego. Oracle opisuje również terminy stałe, kalendarzowe i reguły „day of month” z cutoff day oraz months ahead.
W rejestrze kontroli warto zapisać: datę bazową, kod warunków, parametry reguły, wynik przed korektą kalendarza i końcowy termin. Dzięki temu druga osoba może odtworzyć wynik bez zgadywania, a zmiana ustawień nie zaciera podstawy wcześniejszej decyzji.
4. Oddziel termin netto od rabatu
Termin płatności i data rabatu za wcześniejszą zapłatę to różne wyniki. SAP opisuje warunki obejmujące kolejne poziomy rabatu i termin netto, a Oracle rozdziela due dates i discount dates. Wcześniejsza data rabatu nie oznacza, że faktura staje się wtedy przeterminowana.
Proces powinien pokazywać kwotę i datę rabatu osobno oraz wymagać zgodności z umową. Korzystna ekonomicznie wcześniejsza płatność nadal podlega kontroli duplikatu, akceptacji i dostępności środków. AP nie powinno zmieniać warunków tylko po to, aby uzyskać rabat.
5. Kontroluj wyjątki i ręczne nadpisania
Ręczne nadpisanie może być uzasadnione korektą błędnej daty, aneksem, sporem lub decyzją właściciela procesu. Każda zmiana powinna mieć poprzednią wartość, nową wartość, przyczynę, dowód, autora i czas. Osoba zmieniająca termin nie powinna samodzielnie zatwierdzać wyjątku ponad przyznany limit.
Szczególnej uwagi wymagają faktury otrzymane z opóźnieniem, daty z zamkniętego okresu, dokumenty obejmujące kilka zamówień i terminy wypadające w dni wolne. Pilność uruchamia eskalację, ale nie jest podstawą do usunięcia śladu decyzji.
6. Checklista przed propozycją płatności
Sprawdź: źródło daty faktury i wpływu, datę bazową, kod oraz hierarchię warunków, obliczenie terminu, kalendarz dni wolnych, rabat, blokady i historię zmian. Następnie porównaj wynik z umową lub zamówieniem i potwierdź właściciela wyjątku.
Dobry proces nie polega na ręcznym „ustawieniu właściwej daty”, lecz na udowodnieniu, dlaczego wynik jest właściwy. Tak przygotowane dane ograniczają płatności przed czasem, spóźnienia, utracone rabaty i spory z dostawcami.
Źródła i zakres poradnika
Dokumentację Microsoft, SAP i Oracle sprawdzono 28 października 2026 r. Funkcje zależą od produktu i konfiguracji. Proponowana hierarchia, rejestr zmian i checklista są modelem redakcyjnym do uzgodnienia z właścicielem procesu. Poradnik nie jest instrukcją księgowania ani zgodą na płatność.
FAQ
Czy termin na fakturze zawsze jest wiążący?
Nie zawsze. Trzeba porównać go z umową, zamówieniem i polityką klienta oraz wyjaśnić rozbieżność.
Czym jest data bazowa?
To data, od której system liczy dni lub okres wskazany w warunkach płatności.
Czy data rabatu jest terminem wymagalności?
Nie. To osobna data uprawniająca do rabatu; termin netto określa wymagalność bez rabatu.
Co zapisać przy zmianie terminu?
Wartość przed i po zmianie, przyczynę, dowód, autora, czas oraz zatwierdzenie zgodne z uprawnieniami.
