--- title: "Art. 23 UoR — Zapis księgowy" description: "Siedem obligatoryjnych elementów zapisu księgowego (art. 23 ust. 2) — data operacji, identyfikator dowodu, opis, kwota, data zapisu, oznaczenie kont, oznaczenie osoby odpowiedzialnej. Trwałość zapisów i zakaz modyfikacji. Realizacja w Numify." url: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-23-zapis-ksiegowy review_status: internal updated: 2026-04-17 --- **Zapis księgowy** to elementarna jednostka ksiąg rachunkowych — jedno zdarzenie gospodarcze zarejestrowane na kontach. precyzyjnie wylicza, co musi zawierać i jak ma być utrwalony. ## Zasada trwałości — ust. 1 [#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](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny) — korekta wyłącznie przez **zapis korygujący (storno)**, nigdy przez edycję zapisu pierwotnego. ## Siedem obligatoryjnych elementów — ust. 2 [#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 ) oraz **danych osoby odpowiedzialnej**. ### Mapowanie na strukturę zapisu w Numify [#mapowanie-na-strukturę-zapisu-w-numify] Każda pozycja w [dzienniku](/docs/korzystanie-z-numify/journal) (tabela `journalEntries` + `journalLines`) zawiera: | Element art. 23 ust. 2 | Pole w Numify | | ----------------------------- | -------------------------------------------------------------------------------- | | (1) Data operacji | `journalEntries.date` | | (2) Rodzaj + numer dowodu | `journalEntries.sourceType` + `sourceDocumentId` (link do faktury lub dokumentu) | | (2) Data dowodu (jeśli różna) | `documents.issuedAt` | | (3) Opis operacji | `journalEntries.description` + `journalLines.description` | | (4) Kwota | `journalLines.debitAmount` / `creditAmount` (w groszach) | | (4) Data zapisu | `journalEntries.postedAt` | | (5) Oznaczenie kont | `journalLines.accountCode` + `accountId` | | Numer ID zapisu | `journalEntries.entryNumber` (ciągła numeracja w ramach roku obrotowego) | | Osoba odpowiedzialna | `journalEntries.createdBy` (UUID użytkownika) | **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 [#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](/docs/korzystanie-z-numify/accounting-policy). ## Data operacji vs data zapisu — ust. 2 pkt 4 [#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-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](/docs/korzystanie-z-numify/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 [#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 (). 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 [#realizacja-w-numify] ### Numeracja pozycji [#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 () bez luk i duplikatów. ### Wydruk w każdym czasie — ust. 1 [#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](/docs/korzystanie-z-numify/journal) z filtrami rok/miesiąc. * Eksport CSV dziennika (zobacz [exports](/docs/korzystanie-z-numify/exports)). * Eksport JPK\_KR\_PD jako wzorcowa forma wydruku ksiąg (). ### Zmienność atrybutów niepodstawowych [#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 [#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 . * **Data operacji przed datą rejestracji spółki** — Numify zablokuje (zobacz [opening-balance](/docs/korzystanie-z-numify/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.