---
title: "Dziennik"
description: "Dziennik zapisów księgowych (chronologiczny księgowy log) z numeracją ciągłą, kontrolą bilansowania Wn = Ma oraz trzema źródłami zapisów — automatyczne z faktur, automatyczne z banku, ręczne."
url: https://numifyai.com/docs/korzystanie-z-numify/journal
review_status: numify-source
updated: 2026-04-17
---


**Dziennik** to chronologiczny rejestr wszystkich zapisów księgowych spółki.
Każda faktura, każda operacja bankowa i każda korekta trafia tutaj — z numerem
pozycji, datą, opisem oraz co najmniej dwiema liniami po stronach Wn/Ma, które
muszą się sumować do zera.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /journal — filtr roku/miesiąca u góry, tabela zapisów z kolumnami Nr / Data / Opis / Źródło / Wn / Ma / Status */}

## Po co to w Numify [#po-co-to-w-numify]

Dziennik jest jednym z pięciu obowiązkowych elementów ksiąg rachunkowych
(<LegalRef act="UoR" art="13" paragraph="1" />). Zawiera **chronologiczne
ujęcie zdarzeń** w danym okresie sprawozdawczym — każdą operację gospodarczą
spółki, niezależnie od tego, czy pochodzi z faktury zakupu, wpłaty na rachunku
bankowym, czy z ręcznego zapisu polecenia księgowania (PK).

Dwa twarde wymagania UoR, które Numify egzekwuje automatycznie:

* **Numeracja ciągła** (<LegalRef act="UoR" art="14" paragraph="2" />) — każdy
  zapis dostaje automatycznie nadany `entryNumber`, unikalny w obrębie roku
  obrotowego. Numery nie mogą mieć luk.
* **Podwójny zapis** (<LegalRef act="UoR" art="15" paragraph="1" />) — suma
  debetów musi równać się sumie kredytów (Wn = Ma). Numify blokuje zapisanie
  niezbilansowanego zapisu.

## Model danych [#model-danych]

`journal_entries` (nagłówek zapisu) — kluczowe pola:

| Pole                           | Opis                                                                                                                                                                    |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `entryNumber`                  | Automatyczny numer pozycji w obrębie `(companyId, fiscalYear)`. Wymagany przez <LegalRef act="UoR" art="14" paragraph="4" />.                                           |
| `date`                         | Data dokonania operacji gospodarczej (nie data zapisu).                                                                                                                 |
| `description`                  | Treść opisu operacji — wymagany przez <LegalRef act="UoR" art="23" paragraph="2" />.                                                                                    |
| `source`                       | `auto_invoice`, `auto_bank`, `manual`, `opening_balance` — skąd pochodzi zapis.                                                                                         |
| `documentId` / `transactionId` | Powiązanie z dowodem księgowym — identyfikator dowodu, którego wymaga <LegalRef act="UoR" art="23" paragraph="2" />.                                                    |
| `fiscalYear` / `fiscalMonth`   | Okres sprawozdawczy, do którego należy zapis.                                                                                                                           |
| `isPosted`                     | Flaga „zaksięgowane" — zapis trafia do księgi głównej i ewidencji tylko po `isPosted = true`.                                                                           |
| `postedAt` / `postedBy`        | Znacznik czasu i użytkownik, który zaksięgował — „dane pozwalające na ustalenie osoby odpowiedzialnej za treść zapisu" z <LegalRef act="UoR" art="14" paragraph="4" />. |

`journal_lines` (linie zapisu) — każda linia wskazuje konto i stronę:

| Pole                           | Opis                                                                                                   |
| ------------------------------ | ------------------------------------------------------------------------------------------------------ |
| `accountId` / `accountCode`    | Konto z planu kont (np. <AccountRef code="400" />).                                                    |
| `debitAmount` / `creditAmount` | Kwota w groszach (PLN × 100). Dokładnie jedno z dwóch pól jest > 0 — linia to zawsze albo Wn, albo Ma. |
| `description`                  | Opis linii — doprecyzowuje opis nagłówka (np. „VAT 23% od faktury FV/2026/003").                       |

## Trzy źródła zapisów [#trzy-źródła-zapisów]

### 1. Automatyczny z faktur (`source = "auto_invoice"`) [#1-automatyczny-z-faktur-source--auto_invoice]

Gdy użytkownik **zweryfikuje** transakcję pochodzącą z dokumentu (faktury
zakupu, faktury sprzedaży), <ServiceRef path="src/lib/services/auto-journal.ts" tests="15" />
tworzy zapis automatycznie na podstawie **mapowania kategorii na konta**
(`categoryAccountMappings`).

Przykład — faktura zakupu materiałów biurowych 100,00 zł netto + 23 zł VAT =
123 zł brutto, kategoria `office_supplies`, mapowanie: Wn <AccountRef code="400" />,
Ma <AccountRef code="202" />, VAT <AccountRef code="221" />:

| Linia | Konto                          | Wn     | Ma     |
| ----- | ------------------------------ | ------ | ------ |
| 1     | `400` Zużycie materiałów       | 100,00 | —      |
| 2     | `221` VAT naliczony            | 23,00  | —      |
| 3     | `202` Rozrachunki z dostawcami | —      | 123,00 |

Suma Wn = 123,00, suma Ma = 123,00. Zapis powstaje z `isPosted: true` — faktura
już przeszła weryfikację, więc trafia od razu do ksiąg.

Idempotencja: jeśli zapis dla danej transakcji już istnieje, funkcja zwraca
`null` i nie tworzy duplikatu. To samo dotyczy transakcji nieuznanych
(`isRejected`) oraz usuniętych (`deletedAt != null`).

### 2. Automatyczny z banku (`source = "auto_bank"`) [#2-automatyczny-z-banku-source--auto_bank]

Gdy wiersz wyciągu bankowego zostanie **dopasowany** (automatycznie lub
ręcznie) do faktury, <ServiceRef path="src/lib/services/payment-journal.ts" />
tworzy zapis rozliczający rozrachunek — przykład dla zapłaty faktury sprzedaży
123,00 zł:

| Linia | Konto                          | Wn     | Ma     |
| ----- | ------------------------------ | ------ | ------ |
| 1     | `130` Rachunek bieżący         | 123,00 | —      |
| 2     | `201` Rozrachunki z odbiorcami | —      | 123,00 |

Szczegółowo opisane w <FeatureRef slug="konta-bankowe">kontach bankowych</FeatureRef>,
łącznie z obsługą różnic kursowych i częściowych płatności.

### 3. Ręczny (`source = "manual"`) [#3-ręczny-source--manual]

Niektóre zdarzenia nie mają dowodu w postaci faktury ani wiersza wyciągu i
wymagają ręcznego zapisu PK (polecenie księgowania) — amortyzacja środków
trwałych, korekty międzyokresowe, przeksięgowania na koniec miesiąca,
rozliczenie wyniku finansowego.

Ekran `/journal&#x60; → przycisk &#x2A;*„Nowy zapis"** otwiera dialog, w którym wybierasz:

1. Datę operacji i opis (co najmniej 3 znaki).
2. Jedną lub więcej par linii Wn/Ma z wyborem konta z planu kont i kwotą w PLN.
3. Opcjonalnie — powiązanie z dokumentem lub transakcją (jeśli istnieje dowód).

Numify waliduje podwójny zapis przed zapisaniem: `sum(debit) === sum(credit)`,
w przeciwnym razie zapis nie zostanie utworzony. Zapis powstaje w stanie
`isPosted: false&#x60; — musisz potwierdzić go przyciskiem &#x2A;*„Zaksięguj"**, co
ustawia `postedAt` i `postedBy`.

### 4. Bilans otwarcia (`source = "opening_balance"`) [#4-bilans-otwarcia-source--opening_balance]

Zapis tworzony raz, podczas konfiguracji firmy — zob. <FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilans otwarcia</FeatureRef>.

## Cykl życia zapisu: `isPosted` [#cykl-życia-zapisu-isposted]

Zapis przechodzi przez dwa stany:

1. **Szkic** (`isPosted: false`) — widoczny w `/journal` z badge'em „Szkic",
   ale **nie wchodzi do obrotów księgi głównej**, nie wpływa na zestawienie
   obrotów i sald ani na bilans/RZiS. Można go edytować lub usunąć.
2. **Zaksięgowany** (`isPosted: true`) — trafia do księgi głównej i wszystkich
   raportów. Od tej chwili obowiązuje zakaz modyfikacji z
   <LegalRef act="UoR" art="23" paragraph="1" /> — zmian dokonuje się wyłącznie
   przez **zapis korygujący** (storno).

Auto-zapisy z faktur i z banku powstają od razu jako `isPosted: true`, bo
pochodzą z już zweryfikowanych dowodów. Zapisy ręczne wymagają wyraźnego
„Zaksięguj".

## Numeracja i ciągłość [#numeracja-i-ciągłość]

`entryNumber` jest unikalny w parze `(companyId, fiscalYear)` — baza wymusza
to przez `uniqueIndex("journal_entries_number_idx")`. Numery są przydzielane
sekwencyjnie, bez luk.

Zestawienie obrotów dziennika za okres musi się zgadzać z obrotami zestawienia
obrotów i sald kont księgi głównej (<LegalRef act="UoR" art="14" paragraph="1" />).
Numify uzgadnia to automatycznie — obie liczby wynikają z tych samych
`journal_lines`.

## Storno (zapis korygujący) [#storno-zapis-korygujący]

Jeśli zaksięgowany zapis zawiera błąd, **nie usuwa się go** — wprowadza się
zapis korygujący (storno czarne lub storno czerwone), który odwraca skutek
oryginału. Pierwotny zapis pozostaje w dzienniku jako ślad rewizyjny.

Numify nie ma jeszcze dedykowanego przycisku „Storno" — rekomendowany workflow
ręczny: utwórz nowy zapis ręczny z odwrotnymi stronami Wn/Ma, w opisie podaj
numer korygowanego zapisu (np. „Storno PK nr 42 — błędna kategoria").

Szczegóły koncepcyjne — zob. <FeatureRef slug="/docs/koncepcje">koncepcje → storno</FeatureRef>
(strona w przygotowaniu). Podstawa prawna: <LegalRef act="UoR" art="25" paragraph="1" />.

## Filtry i wyszukiwanie [#filtry-i-wyszukiwanie]

Górny pasek `/journal` pozwala filtrować:

* **Rok obrotowy** — zakres wynika z daty rejestracji spółki (`registrationDate` z KRS).
* **Miesiąc** — opcjonalnie; puste = cały rok.

Lista pokazuje maksymalnie 200 ostatnich zapisów. Klik w zapis otwiera
szczegóły — wszystkie linie Wn/Ma z kwotami, powiązanie z dokumentem lub
transakcją, oraz historię zmian stanu.

{/* SCREENSHOT: dialog szczegółów zapisu — linie Wn/Ma w dwóch kolumnach, suma na dole, przycisk "Zaksięguj" jeśli szkic */}

## Gwarancje techniczne (z testów) [#gwarancje-techniczne-z-testów]

<ServiceRef path="src/lib/services/auto-journal.ts" tests="15" /> pokrywa
m.in. te scenariusze (plik `auto-journal.test.ts`):

* Wydatek netto + VAT → 3 linie (koszt Wn, VAT Wn, zobowiązanie Ma), suma Wn = suma Ma.
* Wydatek bez VAT → 2 linie (koszt Wn, zobowiązanie Ma) na kwotę netto.
* Przychód netto + VAT → 3 linie (należność Wn gross, przychód Ma net, VAT Ma).
* Reverse charge (WNT, usługi unijne) → dodatkowa para VAT należny/naliczony w tej samej kwocie.
* Idempotencja — powtórne wywołanie dla tej samej transakcji zwraca `null`, bez duplikatu.
* Transakcje nieuznane (`isRejected`) i usunięte (`deletedAt`) są pomijane.

Walidacja `validateJournalBalance()` jest wołana przed każdym zapisem — zapis
niezbilansowany nie powstanie.

## Ograniczenia [#ograniczenia]

* **Brak przycisku storno** — korekta wymaga ręcznego zapisu (zob. sekcja
  powyżej). Zaplanowane jako osobna funkcja.
* **Brak wielu dzienników częściowych** — Numify prowadzi jeden dziennik
  chronologiczny; dzienniki częściowe (sprzedaży, zakupu, kasowy)
  z <LegalRef act="UoR" art="14" paragraph="3" /> nie są obecnie wymagane dla
  spółek o typowej skali działalności.
* **Brak eksportu do CSV/PDF z poziomu `/journal`** — dane są dostępne przez
  raporty i JPK\_KR\_PD (zob. <FeatureRef slug="exports">eksporty</FeatureRef>,
  strona w przygotowaniu).

## Powiązane ekrany [#powiązane-ekrany]

* <FeatureRef slug="general-ledger">Księga główna</FeatureRef> — ten sam
  zestaw zapisów, ale pogrupowany po kontach syntetycznych (ujęcie
  systematyczne z <LegalRef act="UoR" art="15" paragraph="1" />).
* <FeatureRef slug="trial-balance">Zestawienie obrotów i sald</FeatureRef> —
  podsumowanie, które musi uzgodnić się z obrotami dziennika.
* <FeatureRef slug="dokumenty">Dokumenty</FeatureRef> i
  <FeatureRef slug="transakcje">transakcje</FeatureRef> — źródła zapisów
  automatycznych.
* <FeatureRef slug="konta-bankowe">Konta bankowe</FeatureRef> — źródło
  zapisów `auto_bank`.

## Dowód z ksiąg w postępowaniu podatkowym [#dowód-z-ksiąg-w-postępowaniu-podatkowym]

Zgodnie z <LegalRef act="OrdPod" art="193" paragraph="1" />, księgi podatkowe
prowadzone rzetelnie i w sposób niewadliwy stanowią dowód tego, co z nich
wynika. Wymagania UoR wobec dziennika (numeracja ciągła, podwójny zapis, ślad
rewizyjny, osoba odpowiedzialna za zapis) to warunki „niewadliwości" z § 3
tego artykułu. Przestrzeganie ich — co Numify egzekwuje automatycznie — jest
podstawą, na której dziennik zachowuje moc dowodową w razie kontroli.