Art. 23 UoR — Zapis księgowy

Zapis księgowy to elementarna jednostka ksiąg rachunkowych — jedno zdarzenie gospodarcze zarejestrowane na kontach. UoR, art. 23 precyzyjnie wylicza, co musi zawierać i jak ma być utrwalony.

Zasada trwałości — ust. 1

Zapisy w księgach rachunkowych powinny być dokonane w sposób trwały, bez możliwości pomijania lub zmiany bezpośrednio jednego zapisu na drugi. Należy stosować właściwe procedury i środki chroniące przed zniszczeniem, modyfikacją lub ukryciem zapisu.

Przy prowadzeniu ksiąg rachunkowych przy użyciu komputera należy stosować właściwe procedury i środki chroniące przed zniszczeniem, modyfikacją lub ukryciem zapisu, a także zapewnić, że zawartość zapisów może być w każdym czasie przedstawiona w postaci wydruku lub przeniesiona na informatyczny nośnik danych.

Trzy komponenty trwałości:

1. Zakaz pomijania — sekwencja zapisów nie może mieć luk.
2. Zakaz modyfikacji — zapis raz dokonany nie może być zmieniony.
3. Zdolność odtworzenia — w każdym momencie system musi dać wydruk lub eksport.

Zakaz modyfikacji jest powtórzony i wzmocniony w art. 25 ust. 1 — korekta wyłącznie przez zapis korygujący (storno), nigdy przez edycję zapisu pierwotnego.

Siedem obligatoryjnych elementów — ust. 2

Zapis księgowy powinien zawierać co najmniej:

1. datę dokonania operacji gospodarczej,
2. określenie rodzaju i numer identyfikacyjny dowodu księgowego stanowiącego podstawę zapisu oraz jego datę, jeżeli różni się ona od daty dokonania operacji,
3. zrozumiały tekst, skrót lub kod opisu operacji, z tym że należy posiadać pisemne objaśnienia treści skrótów lub kodów,
4. kwotę i datę zapisu,
5. oznaczenie kont, których dotyczy.

Dodatkowo, przy komputerowym prowadzeniu ksiąg ust. 2 wymaga numeru identyfikacyjnego zapisu automatycznie nadanego przez system (patrz UoR, art. 14 ust. 4) oraz danych osoby odpowiedzialnej.

Mapowanie na strukturę zapisu w Numify

Każda pozycja w dzienniku (tabela journalEntries + journalLines) zawiera:

Nadmiar danych (technicznie przechowywanych ponad minimum UoR) służy audytowi: każdy zapis ma również createdAt, updatedAt, source (np. 'ksef', 'manual', 'bank_match').

Skróty i kody opisu operacji — ust. 2 pkt 3

Ciekawy przepis: dopuszcza skróty i kody w opisie operacji, pod warunkiem że jednostka ma pisemne objaśnienia.

W praktyce:

• Opis w pełnym tekście: „Faktura VAT nr 123/2026 za usługi księgowe za marzec 2026"
• Skrót: „FV 123/2026 US KSG III/2026" + tabela objaśnień w polityce rachunkowości.

Numify domyślnie używa pełnych opisów — generator automatyczny składa czytelny tekst z danych faktury (np. „Faktura zakupu FV/123/2026 — Usługi doradcze"). Skróty w ręcznych zapisach są dozwolone, ale obowiązek objaśnień spoczywa na użytkowniku: jeśli używasz własnych skrótów, udokumentuj je w polityce rachunkowości.

Data operacji vs data zapisu — ust. 2 pkt 4

Rozróżnienie tych dwóch dat ma znaczenie dla przyporządkowania do okresu sprawozdawczego:

• Data operacji — gdy zdarzenie gospodarcze nastąpiło. Dla faktury zakupowej typowo data sprzedaży / data dostawy.
• Data zapisu — gdy zapis trafił do dziennika. Typowo późniejsza (np. faktura z 15 marca zaksięgowana 20 marca).

Zasada: zapis idzie do okresu daty operacji, nie daty zapisu — pod warunkiem że księgi za ten okres nie zostały jeszcze zamknięte (ust. 3). Faktura marcowa zaksięgowana 20 marca → okres 2026/03. Faktura marcowa odnaleziona 10 kwietnia, księgi marca już zamknięte → storno / korekta w okresie 2026/04.

Zapisy w okresie — ust. 3

Zapisy w dzienniku i na kontach księgi głównej uważa się za dokonane w danym okresie sprawozdawczym, jeżeli zostały wprowadzone przed zamknięciem ksiąg za ten okres sprawozdawczy.

To jest prawny odpowiednik statusu open / closed okresu w fiscal-periods. Po zamknięciu okresu zapisy z datą operacji z tego okresu można wprowadzać tylko w okresie bieżącym — jako korekty (storno + nowy zapis).

Zasada podwójnego zapisu — kontekst z art. 15

Każdy zapis księgowy (z jednym wyjątkiem — konta pozabilansowe) ma co najmniej dwie pozycje po stronach Wn i Ma na różnych kontach, z sumami równymi (UoR, art. 15 ust. 1).

Przykład — zapłata faktury 1 230 zł z rachunku:

Nr    Data         Opis                        Wn      Ma
42    2026-03-20   Zapłata FV 123/2026
                   202 Rozrachunki z dostawcą  1230,00
                   130 Rachunek bieżący                 1230,00
                                              -------  -------
                                              1230,00  1230,00

Suma Wn = Suma Ma jest testowana przez Numify w validateJournalBalance przy każdym zapisie — niezbilansowany zapis jest odrzucany zanim trafi do bazy.

Realizacja w Numify

Numeracja pozycji

entryNumber w tabeli journalEntries jest nadawany atomowo:

entryNumber = MAX(entryNumber WHERE companyId = X AND fiscalYear = Y) + 1

Jest to transakcja bazodanowa z izolacją serializowalną — dwa jednoczesne requesty nie mogą dostać tego samego numeru (retry przy 23505 unique violation). Wymaga ciągłej numeracji (UoR, art. 14 ust. 2) bez luk i duplikatów.

Wydruk w każdym czasie — ust. 1

Wymóg „zawartość zapisów może być w każdym czasie przedstawiona w postaci wydruku" spełnia:

• Widok dziennika z filtrami rok/miesiąc.
• Eksport CSV dziennika (zobacz exports).
• Eksport JPK_KR_PD jako wzorcowa forma wydruku ksiąg (Ustawa o CIT, art. 9 ust. 1c).

Zmienność atrybutów niepodstawowych

Warto zaznaczyć: istnieją pola, które można zmieniać bez naruszenia ust. 1, np. status powiązania płatności, flaga „weryfikowane przez księgową" itp. To są atrybuty operacyjne wokół zapisu, nie jego treść księgowa. UoR wymaga niezmienności tylko elementów zapisu z ust. 2 — daty, kwot, kont, opisu, dowodu, podpisu.

Numify respektuje tę granicę: edycja zapisu w dzienniku jest zablokowana (wymuszone storno), ale metadane operacyjne (np. kategoryzacja, tagi) można zmienić.

Częste błędy

• Błąd w koncie — po zaksięgowaniu nie edytuj accountCode. Użyj storna + zapisu na prawidłowym koncie.
• Błąd w kwocie — to samo. Storno całej kwoty błędnej + zapis z prawidłową. Nie storno tylko różnicy — to naruszenie zasady „pełnego zapisu korygującego" z UoR, art. 25.
• Data operacji przed datą rejestracji spółki — Numify zablokuje (zobacz opening-balance); ale warto zweryfikować, że data operacji nie została pomyłkowo wpisana „na historię" zamiast bieżącej korekty.
• Brak daty zapisu — przy imporcie z zewnętrznego systemu sprawdź, czy postedAt jest wypełniony. Pole puste oznacza zapis techniczny niezatwierdzony — nie wchodzi do ZOiS ani raportów.