---
title: "Transakcje"
description: "Rejestr wszystkich operacji gospodarczych spółki — przychody, koszty, przelewy. Weryfikacja, dekretacja i automatyczne tworzenie zapisów w dzienniku zgodnie z zasadą zapisu podwójnego i wymogami art. 20 i 23 UoR."
url: https://numifyai.com/docs/korzystanie-z-numify/transakcje
review_status: numify-source
updated: 2026-04-16
---


**Transakcje** to środkowa warstwa księgowości w Numify — pomiędzy
<FeatureRef slug="dokumenty">dokumentami</FeatureRef> (surowe dowody) a
<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">dziennikiem</FeatureRef>
(chronologiczny rejestr zapisów). Każda transakcja to **jedna operacja
gospodarcza**: przychód, koszt albo przelew.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /transactions — karty sumaryczne + tabela z kolumnami Data/Opis/Kontrahent/Netto/VAT/Brutto/Status */}

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

<LegalRef act="UoR" art="20" paragraph="1" /> wymaga, aby **każde zdarzenie**
gospodarcze zostało wprowadzone do ksiąg jako zapis. Samo zapisanie dowodu
(faktury) to jednak jeszcze nie zapis księgowy. Transakcja to pośredni
byt:

1. **Materializuje** dane z dokumentu w postaci kwot, dat i stron operacji.
2. **Przechowuje weryfikację** (pole `isVerified`) — zabezpieczenie przed zaksięgowaniem niesprawdzonych danych.
3. **Jest źródłem** zapisu w dzienniku — po zweryfikowaniu Numify automatycznie tworzy proste i przejrzyste zapisy podwójne.

## Typy transakcji [#typy-transakcji]

| Typ                      | Zastosowanie                                     | Typowe konta                                                                                                                  |
| ------------------------ | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **Przychód** (`income`)  | Sprzedaż produktów / towarów / usług.            | Dt <AccountRef code="201" /> → Ct <AccountRef code="700" /> / <AccountRef code="702" /> / 703 + VAT <AccountRef code="220" /> |
| **Koszt** (`expense`)    | Zakup materiałów, energii, usług obcych.         | Dt 4xx (np. <AccountRef code="401" />) + VAT <AccountRef code="221" /> → Ct <AccountRef code="202" />                         |
| **Przelew** (`transfer`) | Przeniesienie między rachunkami własnymi spółki. | Dt <AccountRef code="130" /> / <AccountRef code="135" /> → Ct drugi rachunek                                                  |

Typy mapują się na konkretne konta zespołów 4/7/2 według **planu kont
seedowanego** w Numify (<ServiceRef path="src/db/seed-accounts.ts">seed-accounts.ts</ServiceRef>).

## Weryfikacja (isVerified) [#weryfikacja-isverified]

Transakcje mają dwie fazy:

1. **Utworzone, niezweryfikowane** — pochodzą z AI-parsowanego dokumentu lub z formularza ręcznego. W UI pokazywane z badgem „niezweryfikowane". &#x2A;*Nie trafiają jeszcze do dziennika.**
2. **Zweryfikowane** — po kliknięciu „Zweryfikuj" (lub masowej weryfikacji z tabeli) transakcja:
   * jest oznaczona `isVerified = true`,
   * zostaje **automatycznie zaksięgowana** w dzienniku (zapis podwójny),
   * nie można już edytować jej kwot bez korekty (→ storno).

To rozbicie realizuje **human-in-the-loop**: AI proponuje, człowiek
akceptuje, dopiero wtedy liczby są „prawdziwe" — i zgodne z wymogiem
<LegalRef act="UoR" art="23" paragraph="2" /> pkt 5 („oznaczenie kont, których
dotyczy" — świadomie wskazane przez użytkownika).

## Automatyczne tworzenie zapisu w dzienniku [#automatyczne-tworzenie-zapisu-w-dzienniku]

Po weryfikacji transakcji Numify buduje wielowierszowy zapis spełniający
<LegalRef act="UoR" art="23" paragraph="2" />:

* data operacji gospodarczej,
* rodzaj i numer dowodu (z powiązanej faktury / dokumentu),
* opis,
* kwota i data zapisu,
* oznaczenie kont (wielo-wierszowe).

<ServiceRef path="src/lib/services/auto-journal.ts" tests="15">
  auto-journal.ts
</ServiceRef>

### Zapis podwójny [#zapis-podwójny]

Każdy zapis zaczyna się i kończy zerem — suma kwot **debet = suma kwot
kredyt**. Numify zawsze generuje wszystkie niezbędne wiersze:

**Faktura sprzedaży (przychód z VAT 23 %)**

| Konto                                              | Debet    | Kredyt   |
| -------------------------------------------------- | -------- | -------- |
| <AccountRef code="201" /> Rozrachunki z odbiorcami | 1 230,00 | —        |
| <AccountRef code="700" /> Sprzedaż produktów       | —        | 1 000,00 |
| <AccountRef code="220" /> VAT należny              | —        | 230,00   |

**Faktura kosztowa (usługi obce, VAT 23 %)**

| Konto                                              | Debet    | Kredyt   |
| -------------------------------------------------- | -------- | -------- |
| <AccountRef code="402" /> Usługi obce              | 1 000,00 | —        |
| <AccountRef code="221" /> VAT naliczony            | 230,00   | —        |
| <AccountRef code="202" /> Rozrachunki z dostawcami | —        | 1 230,00 |

### Obsługa walut obcych [#obsługa-walut-obcych]

Transakcje w EUR / USD mają trzy reprezentacje kwoty:

* **`amountGross`** — w walucie oryginalnej (np. 100 EUR = 10 000 centów).
* **`amountGrossPln`** — przeliczone po kursie NBP z dnia poprzedzającego obowiązek podatkowy (zgodnie z <LegalRef act="UoR" art="30" paragraph="2" />).
* **`exchangeRate`** — użyty kurs, zapisany na transakcji dla audytu.

Różnice kursowe powstają dopiero **przy zapłacie** — obsługuje je moduł
<FeatureRef slug="konta-bankowe">Konta bankowe</FeatureRef>.

## Tabela i filtry [#tabela-i-filtry]

Tabela transakcji pozwala filtrować po:

* Typie (przychód / koszt / przelew),
* Statusie weryfikacji (zweryfikowane / niezweryfikowane),
* Statusie zapłaty (opłacone / nieopłacone),
* Zakresie dat,
* Wyszukiwarce (po opisie / kontrahencie).

Karty sumaryczne w górnej części ekranu pokazują przychody, koszty i saldo
netto **wyłącznie dla transakcji zweryfikowanych** — niezweryfikowane
liczone są osobno (zabezpieczenie przed pokazywaniem niespójnych agregatów
przy niezweryfikowanych walutach).

## Korekty (storno) [#korekty-storno]

<LegalRef act="UoR" art="25" paragraph="1 pkt 2" /> zabrania usuwania zapisów
w księgach po zamknięciu miesiąca. Dla korekty kwoty, konta lub daty
transakcji zweryfikowanej **nie edytuje się** oryginału — zamiast tego:

1. Tworzy się **transakcję korygującą** (storno) o przeciwnym znaku kwot.
2. Oryginał pozostaje w historii; ma widoczny link do storna.
3. Efekt netto w księdze głównej się zeruje, a poprawna wartość dodaje się przez nową transakcję.

To główny mechanizm śladu rewizyjnego (→ <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny">art. 25 UoR</FeatureRef>).

## Ograniczenia [#ograniczenia]

1. **Transakcja = jedno zdarzenie** — nie modelujemy dziś skomplikowanych operacji wielostronnych (np. kompensaty trójstronnej) jako pojedynczej transakcji. Takie operacje wymagają kilku transakcji lub zapisu bezpośrednio w dzienniku.
2. **Auto-journal pokrywa typowe przypadki** — faktury VAT 23 / 8 / 5 / 0, WNT / WDT, odwrotne obciążenie, MPP. Nietypowe (np. import z kraju trzeciego z cłem, zakup środka trwałego z kosztami transportu) wymagają ręcznej korekty dekretacji.
3. **Brak edycji zweryfikowanej transakcji** — to cecha (zgodność z <LegalRef act="UoR" art="25" />), nie bug. Jeśli pomyliłaś coś w zweryfikowanej transakcji, stwórz korektę.
4. **Połączenie z <FeatureRef slug="konta-bankowe">kontami bankowymi</FeatureRef>** — transakcja staje się „opłacona" dopiero po dopasowaniu wiersza wyciągu bankowego do niej (lub przez ręczną flagę w UI).

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Z przychodzącego dokumentu** (parsing AI) → Numify tworzy niezweryfikowaną transakcję.
2. **Otwórz ją**, sprawdź kwoty, stawki VAT, kontrahenta i kategorię kosztu.
3. **Popraw**, jeśli AI pomyliło się w dekretacji — np. faktura za usługi obce klasyfikowana jako „zużycie materiałów".
4. **Zweryfikuj** — Numify tworzy zapis w dzienniku i aktualizuje księgę główną.
5. **Przed wysłaniem JPK\_V7M** — użyj tabeli z filtrem „niezweryfikowane" i domknij pozostałe; JPK nie powinno obejmować niepełnych danych.
6. **Dla korekt** — zawsze przez storno, nigdy przez edycję oryginału.

{/* SCREENSHOT: pojedyncza transakcja — widok szczegółów z sekcją "Zapis w dzienniku" pokazującą kont debet/kredyt */}

## Powiązane [#powiązane]

* <FeatureRef slug="dokumenty">dokumenty</FeatureRef> — źródło transakcji przychodzących.
* <FeatureRef slug="faktury">faktury</FeatureRef> — źródło transakcji sprzedaży.
* <FeatureRef slug="konta-bankowe">konta bankowe</FeatureRef> — dopasowanie płatności do transakcji → status „opłacona".
* <FeatureRef slug="kontrahenci">kontrahenci</FeatureRef> — każda transakcja ma przypisanego kontrahenta.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">UoR — dziennik</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-15-ksiega-glowna">UoR — księga główna</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny">UoR — ślad rewizyjny</FeatureRef>.