---
title: "Art. 14 UoR — Dziennik"
description: "Dziennik — chronologiczne ujęcie wszystkich zdarzeń gospodarczych, kolejna numeracja, ciągłość obrotów, automatyczny numer pozycji i dane osoby odpowiedzialnej przy prowadzeniu ksiąg komputerem. Realizacja w Numify."
url: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik
review_status: internal
updated: 2026-04-16
---


<PolishTerm pl="Dziennik" en="Journal">Dziennik</PolishTerm>
to jedna z czterech obligatoryjnych ksiąg rachunkowych
(<LegalRef act="UoR" art="13" />). Jego funkcja jest prosta: zawiera
**wszystkie zdarzenia gospodarcze jednostki w kolejności
chronologicznej**, zapisane w sposób, który daje się uzgodnić z kontami
księgi głównej i powiązać z dowodami księgowymi. Bez poprawnego dziennika
nie ma poprawnych ksiąg.

<ComplianceDisclaimer />

## Definicja — art. 14 ust. 1 [#definicja--art-14-ust-1]

> Dziennik zawiera chronologiczne ujęcie zdarzeń, jakie nastąpiły w
> danym okresie sprawozdawczym. Bez względu na technikę prowadzenia
> ksiąg rachunkowych dziennik powinien umożliwiać uzgodnienie jego
> obrotów z obrotami zestawienia obrotów i sald kont księgi głównej.

Trzy kluczowe cechy wynikające z ust. 1:

1. **Chronologia** — zapisy idą w kolejności zdarzeń, nie np. według
   kontrahenta ani konta.
2. **Kompletność** — w dzienniku jest **każde** zdarzenie zarejestrowane
   w księgach, nie wybrane.
3. **Uzgadnialność** — suma obrotów dziennika = suma obrotów
   <PolishTerm pl="ZOiS" en="trial balance">zestawienia obrotów i sald</PolishTerm>
   kont księgi głównej. To jest tak zwana **kontrola dziennikowa** —
   wynika z zasady podwójnego zapisu i jest obligatoryjnym testem
   spójności ksiąg.

## Numeracja i powiązanie z dowodami — art. 14 ust. 2 [#numeracja-i-powiązanie-z-dowodami--art-14-ust-2]

> Zapisy w dzienniku muszą być kolejno numerowane, a sumy zapisów
> (obroty) liczone w sposób ciągły. Sposób dokonywania zapisów w
> dzienniku powinien umożliwiać ich jednoznaczne powiązanie ze
> sprawdzonymi i zatwierdzonymi dowodami księgowymi.

### Kolejna numeracja [#kolejna-numeracja]

Numer pozycji dziennika jest **ciągły w ramach okresu prowadzenia
dziennika** — najczęściej roku obrotowego. Nie wolno:

* Pomijać numerów.
* Powtarzać numerów.
* Nadawać numeru wstecznie (nie: „chyba wstawię między 142 a 143
  jeszcze jeden").

### Ciągłe sumowanie obrotów [#ciągłe-sumowanie-obrotów]

Suma obrotów musi być liczona narastająco — każdy nowy zapis zwiększa
sumę dotychczasową. Jest to tożsame z wymogiem, że usunięcie zapisu
(np. przez administratora bazy) zmieniłoby sumę obrotów historycznych —
co jest niedozwolone (<LegalRef act="UoR" art="25" />, zobacz też
[Art. 25 — ślad rewizyjny](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny)).

### Powiązanie z dowodami księgowymi [#powiązanie-z-dowodami-księgowymi]

Każdy zapis musi wskazywać **dowód**, na podstawie którego został
wprowadzony — fakturę, wyciąg bankowy, polecenie księgowania, notę
korygującą itd. Obowiązkowe elementy dowodu księgowego są wymienione
w <LegalRef act="UoR" art="21" />, a zasady postępowania z dowodami
(rzetelność, kompletność, korygowanie błędów w dowodach) w
<LegalRef act="UoR" art="22" />.

## Dzienniki częściowe — art. 14 ust. 3 [#dzienniki-częściowe--art-14-ust-3]

> Jeżeli stosuje się dzienniki częściowe, grupujące zdarzenia według ich
> rodzajów, to należy sporządzić zestawienie obrotów tych dzienników
> za dany okres sprawozdawczy.

<PolishTerm pl="Dzienniki częściowe" en="Sub-journals">Dzienniki
częściowe</PolishTerm> to tradycyjny podział dziennika według rodzaju
operacji — np. osobny dziennik sprzedaży, dziennik zakupu, dziennik
kasowy. Jeśli jednostka je stosuje, nadal musi sporządzić **wspólne
zestawienie obrotów**, aby suma się zgadzała.

Numify domyślnie prowadzi **jeden dziennik ogólny** — wszystkie zapisy
są w jednej tabeli `journal_entries` z polem `source` opisującym
pochodzenie (`auto_invoice`, `auto_bank`, `manual`). Nie ma odrębnych
dzienników częściowych, więc art. 14 ust. 3 nie wymaga dodatkowych
zestawień.

## Wymogi dla ksiąg prowadzonych komputerem — art. 14 ust. 4 [#wymogi-dla-ksiąg-prowadzonych-komputerem--art-14-ust-4]

> Przy prowadzeniu ksiąg rachunkowych przy użyciu komputera zapis
> księgowy powinien posiadać automatycznie nadany numer pozycji, pod
> którą został wprowadzony do dziennika, a także dane pozwalające na
> ustalenie osoby odpowiedzialnej za treść zapisu.

Dwa dodatkowe wymogi dla systemów komputerowych:

1. **Automatycznie nadany numer pozycji** — numer nie może być
   wprowadzany ręcznie przez użytkownika, musi być generowany przez
   system.
2. **Dane osoby odpowiedzialnej za treść zapisu** — system musi
   rejestrować kto utworzył / zatwierdził / zaksięgował zapis.

Oba wymogi są spełniane w Numify:

* Numer pozycji (`entryNumber`) jest obliczany w transakcji jako
  `max(entryNumber) + 1` z ograniczeniem unikalności w obrębie roku
  obrotowego — wraz z mechanizmem retry na kolizji `unique constraint`
  (`src/lib/services/auto-journal.ts`, pole `entry_number` + indeks
  unikalny `(company_id, fiscal_year, entry_number)`).
* Osoba odpowiedzialna za zapis jest zapisywana w kolumnie `created_by`
  (`journal_entries`) oraz w logu audytowym
  <ServiceRef path="src/lib/audit.ts">audit.ts</ServiceRef> (patrz
  [Art. 25 — ślad rewizyjny](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny)).

## Jak Numify realizuje art. 14 [#jak-numify-realizuje-art-14]

Przepływ tworzenia zapisu w dzienniku (dla zaksięgowanej
transakcji):

```
Transakcja (zweryfikowana)
      ↓
  lookup mapowania kategoria → konto księgowe
      ↓
  ensurePeriodOpen(rok, miesiąc)
      ↓
  obliczenie entryNumber = max(entryNumber) + 1
      ↓
  INSERT journal_entries + INSERT journal_lines (w jednej transakcji DB)
      ↓
  zapis do audit log (fire-and-forget)
```

Pliki:

* <ServiceRef path="src/lib/services/auto-journal.ts">auto-journal.ts</ServiceRef>
  — tworzenie zapisu w dzienniku z transakcji (z zachowaniem reguł
  reverse charge, <LegalRef act="VAT" art="28b" />).
* <ServiceRef path="src/lib/services/fiscal-periods.ts">fiscal-periods.ts</ServiceRef>
  — blokowanie zapisów w zamkniętych okresach.
* <ServiceRef path="src/lib/audit.ts">audit.ts</ServiceRef> — rejestracja
  operacji w `audit_log`.

Tabele bazodanowe:

| Tabela            | Rola                                                         |
| ----------------- | ------------------------------------------------------------ |
| `journal_entries` | Nagłówek zapisu — data, numer pozycji, opis, dokument, osoba |
| `journal_lines`   | Wiersze zapisu (debet / kredyt na kontach)                   |
| `audit_log`       | Historia operacji na zapisach (kto, kiedy, co)               |

## Weryfikacja poprawności [#weryfikacja-poprawności]

W dashboardzie Numify **suma debetów = suma kredytów** jest testowana
na każdy zapis (wymóg <LegalRef act="UoR" art="15" /> — podwójny
zapis). Na poziomie dziennika obowiązuje test z <LegalRef act="UoR" art="14" paragraph="1" />:
suma obrotów dziennika = suma obrotów ZOiS. Ten test jest automatyczny —
opiera się na `generateTrialBalance` w
<ServiceRef path="src/lib/services/trial-balance.ts">trial-balance.ts</ServiceRef>
i sprawdza, że `totals.periodDebit === totals.periodCredit` dla okresu.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnym tekście art. 14 UoR (Dz.U. 2023
    poz. 120) oraz na implementacji `auto-journal.ts` i schemacie tabel
    `journal_entries`/`journal_lines`.
  </ChangeEntry>
</ChangeHistory>