Art. 25 UoR — Ślad rewizyjny (storno, brak usuwania)

Ślad rewizyjny to jedno z najważniejszych wymogów polskiej rachunkowości. Księgi rachunkowe nie są „aktualnym stanem rzeczy" — są historycznym rejestrem wszystkich zdarzeń, w tym błędów i ich korekt. Ustawa nie pozwala „zamieść błędu pod dywan" przez nadpisanie lub usunięcie zapisu. Każda korekta musi zostawić widoczny ślad.

Definicja — art. 25 ust. 1

Stwierdzone błędy w zapisach poprawia się:

1. przez skreślenie dotychczasowej treści i wpisanie nowej, z zachowaniem czytelności błędnego zapisu, oraz podpisanie poprawki i umieszczenie daty; poprawki takie muszą być dokonane jednocześnie we wszystkich księgach rachunkowych i nie mogą nastąpić po zamknięciu miesiąca lub
2. przez wprowadzenie do ksiąg rachunkowych dowodu zawierającego korekty błędnych zapisów, dokonywane tylko zapisami dodatnimi albo tylko ujemnymi.

Dwa dopuszczalne sposoby:

Sposób 1 — skreślenie (tylko dla ksiąg papierowych przed zamknięciem)

Historyczny sposób stosowany w księgach prowadzonych ręcznie:

• Skreślić błędną treść tak, żeby pozostała czytelna.
• Wpisać nad spodem poprawną treść.
• Podpisać poprawkę i umieścić datę.
• Zrobić to jednocześnie we wszystkich księgach (np. dzienniku i księdze głównej — ten sam błąd poprawić wszędzie).
• Termin: przed zamknięciem miesiąca. Po zamknięciu miesiąca ten sposób jest niedozwolony.

Sposób 2 — storno / dowód korygujący

Wprowadzenie do ksiąg nowego dowodu, który zawiera korektę błędnego zapisu. Obowiązują dwa warianty:

W obu wariantach oryginalny błędny zapis zostaje w księgach. Nadal jest widoczny w dzienniku i księdze głównej, tylko obok pojawia się zapis korygujący.

Reguła dla ksiąg komputerowych — art. 25 ust. 2

W razie ujawnienia błędów po zamknięciu miesiąca lub prowadzenia ksiąg rachunkowych przy użyciu komputera, dozwolone są tylko korekty dokonane w sposób określony w ust. 1 pkt 2.

To kluczowe: jeżeli księgi są prowadzone komputerem, sposób 1 (skreślenie) w ogóle nie ma zastosowania. Jedyna dozwolona forma korekty to dowód zawierający storno.

Konsekwencje praktyczne dla systemu księgowego:

• Baza danych nie może pozwalać na edycję wcześniej zaksięgowanych zapisów (UPDATE na journal_entries.is_posted = true → zablokowane).
• Baza danych nie może pozwalać na usuwanie zapisów (DELETE → zablokowane).
• Korekta = utworzenie nowego zapisu, nie modyfikacja istniejącego.

Powiązane artykuły

UoR, art. 23 (Zasady dokonywania zapisów w księgach rachunkowych) w ust. 2 wymaga, żeby każdy zapis wskazywał rodzaj i numer identyfikacyjny dowodu księgowego stanowiącego podstawę zapisu, wraz z jego datą. Dowód korygujący (storno) musi być osobnym dokumentem — nie ten sam co oryginalny błędny dowód. Najczęściej jest to nota księgowa własna opisująca przyczynę korekty.

UoR, art. 24 nakłada cztery cechy prowadzenia ksiąg:

• Rzetelnie — zgodnie ze stanem rzeczywistym.
• Bezbłędnie — bez pomyłek rachunkowych / logicznych.
• Sprawdzalnie — z możliwością prześledzenia każdego zapisu do dowodu źródłowego.
• Bieżąco — w terminach umożliwiających sporządzenie obowiązkowych sprawozdań.

„Sprawdzalnie" oznacza wprost, że historia zapisów musi być zachowana.

Jak Numify realizuje art. 25

Niemutowalność zapisów po zaksięgowaniu

Zapisy w journal_entries z flagą is_posted = true nie mogą być modyfikowane przez interfejs użytkownika ani przez endpointy API:

• Mutacje są blokowane w warstwie serwisów przed dotarciem do bazy.
• Edycja dozwolona jest tylko dla zapisów w stanie roboczym (is_posted = false), które nie zostały jeszcze „wysłane do ksiąg".

Korekta = storno

Korekta błędnego zaksięgowania wymaga utworzenia nowego zapisu o odwrotnym skutku. Dwa typowe scenariusze:

• Faktura zaksięgowana na złe konto — tworzony jest zapis storno (odwrotny) oraz nowy prawidłowy zapis. W dzienniku widać: oryginał, storno, nowy zapis.
• Faktura skorygowana fakturą korygującą — korekta ma własny dowód (faktura korygująca) i osobny zapis w dzienniku. Nie modyfikuje oryginalnej faktury.

Audit log — uzupełnienie art. 25 (nie wymóg UoR)

Niezależnie od wymogów art. 25, Numify prowadzi dziennik audytu (audit_log) rejestrujący wszystkie operacje na kluczowych encjach:

Wpisy do audit log są fire-and-forget (błąd logowania nie blokuje operacji głównej) i immutable (brak możliwości edycji lub usunięcia wpisów) — implementacja w audit.ts.

Audit log wykracza poza minimum art. 25 — przechowuje historię zmian także dla operacji, które nie są zapisami księgowymi (np. zmiana danych kontrahenta, akceptacja dokumentu). Jest pomocniczy dla kontroli wewnętrznej i w razie audytu.

Fiscal periods — blokada edycji przeszłych okresów

Uzupełniająco, moduł okresów obrachunkowych (fiscal-periods.ts) pozwala zamknąć miesiąc lub cały rok. Zamknięcie wywołuje:

• ensurePeriodOpen rzuca błąd przy próbie utworzenia zapisu w zamkniętym okresie.
• Po zamknięciu jedyną drogą do korekty jest zapis w bieżącym okresie korygujący wstecz (data dokumentu może odnosić się do przeszłości, ale data księgowania w dzienniku jest z bieżącego okresu).
• Ponowne otwarcie zamkniętego okresu jest możliwe (metoda reopenPeriod), ale wymaga wyraźnej akcji i jest logowane w audit log.

Częste problemy z art. 25

• „Usunąłem zapis w bazie bezpośrednio" — to naruszenie art. 25. Ślad po zapisie musi pozostać w dzienniku. Bezpośrednia modyfikacja bazy przez administratora (nawet z legalnym dostępem technicznym) łamie wymóg „sprawdzalności" z UoR, art. 24.
• „Chcę wycofać fakturę która okazała się pomyłką" — nie wycofuje się, wystawia się fakturę korygującą na kwoty przeciwne i księguje ją jako nowy dowód. Oryginalna faktura zostaje w księgach.
• „Poprawiłem literówkę w opisie zapisu" — czysty opis (pole description) może być modyfikowany w okresie otwartym, ale zmiana jest logowana w audit log. Po zamknięciu miesiąca edycja opisu jest już zablokowana razem z całym zapisem.

Historia zmian podstawy prawnej

1. 2026-04-16Phase 3a

   Pierwsza wersja — oparta na aktualnym tekście art. 25 UoR (Dz.U. 2023 poz. 120) oraz implementacji audit.ts, fiscal-periods.ts i schematu journal_entries z flagą is_posted.