--- title: "Art. 25 UoR — Ślad rewizyjny (storno, brak usuwania)" description: "Audit trail ksiąg rachunkowych — poprawianie błędów wyłącznie przez storno (zapisy dodatnie lub ujemne) przy prowadzeniu ksiąg komputerem, zakaz usuwania i nadpisywania zapisów. Realizacja w Numify." url: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny review_status: internal updated: 2026-04-16 --- Ś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 [#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) [#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 [#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: | Wariant | Jak wygląda | Gdy używać | | ----------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------- | | **Storno czarne** (zapisy dodatnie) | Drugi zapis o tej samej kwocie ale z odwróconymi stronami Dt/Ct | Gdy chcemy tylko cofnąć skutek błędu (np. zapisano na złe konto) | | **Storno czerwone** (zapisy ujemne) | Zapis z kwotą ujemną anulujący błędny zapis | Formalnie dozwolone — historycznie używane dla czytelności | 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 [#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 [#powiązane-artykuły] (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. 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 [#jak-numify-realizuje-art-25] ### Niemutowalność zapisów po zaksięgowaniu [#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--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) [#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: | Pole | Zawartość | | ---------------------- | -------------------------------------------- | | `userId` | Osoba wykonująca operację | | `entityType` | Typ encji (transaction, journal\_entry, ...) | | `entityId` | ID konkretnej encji | | `action` | Typ operacji (create/update/delete/...) | | `changes.before/after` | Przed/po zmianie (dla update) | | `ipAddress` | Adres IP osoby | | `createdAt` | Moment operacji | 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 [#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 [#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 . * **„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. 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`.