# Numify AI — Pełna dokumentacja

Dokumentacja narzędzia księgowego Numify AI dla polskich spółek z o.o.
Wszystkie strony zebrane w jednym pliku dla AI (RAG / context loading).

Liczba stron: 91
Wygenerowano: 2026-04-22T17:59:17.034Z

---

# Dokumentacja Numify AI
URL: https://numifyai.com/docs
Description: Kompletna dokumentacja narzędzia księgowego Numify AI — funkcje, zgodność z polskim prawem, procesy, integracje i dokumentacja deweloperska.
Review status: internal
Updated: 2026-04-16



Witaj w dokumentacji **Numify AI** — narzędzia do księgowości dla polskich spółek z o.o.
Dokumentacja jest pisana po polsku i stale aktualizowana. Każda strona ma widoczny
status weryfikacji i podstawę prawną, jeśli dotyczy.

## Co znajdziesz w dokumentacji [#co-znajdziesz-w-dokumentacji]

<Cards>
  <Card title="Pierwsze kroki" description="Założenie firmy w Numify, plan kont, bilans otwarcia, pierwsze dokumenty." href="/docs/pierwsze-kroki" />

  <Card title="Korzystanie z Numify" description="Jeden artykuł na funkcję — dokumenty, transakcje, faktury, dziennik, VAT, raporty." href="/docs/korzystanie-z-numify" />

  <Card title="Procesy" description="Codzienne, miesięczne, kwartalne i roczne procedury księgowe." href="/docs/procesy" />

  <Card title="Zgodność z prawem" description="Ustawa o rachunkowości, VAT, KSeF, CIT, sprawozdania finansowe, terminy." href="/docs/zgodnosc-z-prawem" />

  <Card title="Koncepcje" description="Zapis podwójny, ślad rewizyjny, kursy NBP, grosze, korekty storno." href="/docs/koncepcje" />

  <Card title="Poradniki" description="Jak zaksięgować fakturę w walucie obcej, zamknąć rok, wyeksportować JPK_V7M." href="/docs/poradniki" />

  <Card title="Integracje" description="KSeF, NBP, GUS, KRS, biała lista, VIES." href="/docs/integracje" />

  <Card title="Dla deweloperów" description="Architektura, schemat bazy, dokumentacja API, zadania w tle." href="/docs/dla-deweloperow" />
</Cards>

## System zaufania [#system-zaufania]

Każda strona dokumentacji ma **widoczny status weryfikacji**:

* <ReviewBadge status="szkic" /> — szkic, nie weryfikowane
* <ReviewBadge status="needs-review" /> — do weryfikacji
* <ReviewBadge status="internal" /> — zweryfikowane wewnętrznie
* <ReviewBadge status="expert" /> — zweryfikowane przez doradcę podatkowego lub biegłego rewidenta
* <ReviewBadge status="numify-source" /> — strona funkcji pokryta testami

Wszystkie odniesienia prawne są cytowane z numerem artykułu i linkiem do ISAP
(np. <LegalRef act="UoR" art="14" />). Metodologia weryfikacji jest
opisana na stronie [Jak weryfikujemy dokumentację](/docs/jak-weryfikujemy).

<ComplianceDisclaimer />

## Format przyjazny AI [#format-przyjazny-ai]

Dokumentacja jest gotowa do użycia przez AI:

* [`/llms.txt`](/llms.txt) — indeks wszystkich stron
* [`/llms-full.txt`](/llms-full.txt) — pełna treść w jednym pliku
* Dodaj `.mdx` do dowolnego URL-a (np. `/docs/jak-weryfikujemy.mdx`), żeby dostać
  surowy markdown
* Nagłówek `Accept: text/markdown` zwraca markdown zamiast HTML-a
* Przycisk **Zapytaj AI** w pasku bocznym — asystent odpowiada na podstawie
  dokumentacji, z cytatami i statusem weryfikacji źródła


---

# Jak weryfikujemy dokumentację
URL: https://numifyai.com/docs/jak-weryfikujemy
Description: Metodologia weryfikacji treści, cytowania prawa, przeglądów eksperckich i zgłaszania błędów.
Review status: internal
Updated: 2026-04-16



Ta strona opisuje, **jak powstaje i jest weryfikowana dokumentacja Numify AI**.
Kompromis jest jednoznaczny: dokumentacja dotycząca zgodności z polskim prawem
musi być albo **w 100 % poprawna i aktualna**, albo jawnie oznaczona jako
niezweryfikowana. Zamiatanie błędów pod dywan nie wchodzi w grę.

## Pięć poziomów weryfikacji [#pięć-poziomów-weryfikacji]

Każda strona dokumentacji nosi **badge statusu** u góry. Status jest zapisany
we frontmatter pliku MDX i widoczny dla czytelnika.

| Badge                                  | Znaczenie                                                                             | Kiedy                                                              |
| -------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| <ReviewBadge status="szkic" />         | Automatyczny szkic lub pierwsza wersja napisana przez inżyniera, **nie weryfikowana** | Pierwszy commit strony                                             |
| <ReviewBadge status="needs-review" />  | Treść gotowa, oznaczona do weryfikacji pod kątem zgodności                            | Domyślny status dla stron zgodności, dopóki nie zostaną sprawdzone |
| <ReviewBadge status="internal" />      | Skonfrontowana z tekstem ustawy **oraz** implementacją w Numify                       | Po wewnętrznym przeglądzie                                         |
| <ReviewBadge status="expert" />        | Zweryfikowana przez **doradcę podatkowego** lub **biegłego rewidenta**                | Najwyższy poziom                                                   |
| <ReviewBadge status="numify-source" /> | Strona funkcji — pokryta działającymi testami                                         | Strony opisujące konkretne funkcje Numify                          |

Obecnie maksymalny poziom weryfikacji to
<ReviewBadge status="internal" /> — &#x2A;*nie współpracujemy jeszcze z żadnym
doradcą podatkowym ani biegłym rewidentem na stałe.** Kiedy taka współpraca
powstanie, strony sukcesywnie przejdą do <ReviewBadge status="expert" />.

## Jak cytujemy prawo [#jak-cytujemy-prawo]

Każde stwierdzenie prawne musi mieć **konkretne źródło**. Nie piszemy
„zgodnie z polskim prawem" bez podania artykułu.

### Hierarchia źródeł [#hierarchia-źródeł]

1. **Tekst ustawy na ISAP** (`isap.sejm.gov.pl`) — podstawowe źródło.
   Cytujemy: akt + artykuł + numer Dziennika Ustaw.
   Przykład: <LegalRef act="UoR" art="14" /> — klikalny link do
   ISAP z tekstem danego artykułu.
2. **Oficjalne interpretacje MF** — `podatki.gov.pl`, Krajowa Informacja
   Skarbowa.
3. **Orzecznictwo** — wyroki NSA i WSA z `orzeczenia.nsa.gov.pl`.

Centralny rejestr cytowanych aktów znajduje się w pliku
[`_meta/legal-acts.json`](https://github.com/kacperkwapisz/numifyai/blob/master/src/content/docs/_meta/legal-acts.json).
Zawiera aktualne numery Dz.U. i linki do ISAP.

### Automatyczne oznaczanie zmian w prawie [#automatyczne-oznaczanie-zmian-w-prawie]

Gdy ustawa zostanie znowelizowana:

1. Aktualizujemy wpis w `legal-acts.json`.
2. Każda strona cytująca dany akt dostaje automatycznie banner
   ⚠️ &#x2A;*„Podstawa prawna zaktualizowana — strona wymaga ponownej weryfikacji"**.
3. Status strony cofa się do <ReviewBadge status="needs-review" />.

Dzięki temu **nigdy nie prezentujemy treści opartej na starym tekście ustawy
bez ostrzeżenia**.

## Kto weryfikuje treści [#kto-weryfikuje-treści]

Recenzenci są zapisani w pliku
[`_meta/reviewers.json`](https://github.com/kacperkwapisz/numifyai/blob/master/src/content/docs/_meta/reviewers.json)
wraz z:

* imieniem i nazwiskiem,
* rolą (inżynier, doradca podatkowy, biegły rewident, …),
* numerem wpisu (np. wpis na listę doradców podatkowych) jeśli dotyczy,
* maksymalnym poziomem weryfikacji, jaki mogą nadać.

Obecni recenzenci:

* **Kacper Kwapisz** — inżynier / właściciel produktu. Nie jest doradcą
  podatkowym. Może nadawać status maksymalnie
  <ReviewBadge status="internal" />.
* **Redakcja Numify** — wewnętrzny proces redakcyjny, który porównuje
  treść strony z aktualnym tekstem ustawy w ISAP oraz z implementacją
  funkcji w kodzie produktu. Może nadawać status maksymalnie
  <ReviewBadge status="internal" />. Proces jest wspomagany narzędziami
  i nadzorowany przez właściciela produktu; nie zastępuje weryfikacji
  przez doradcę podatkowego ani biegłego rewidenta.

## Jak często przeglądamy treści [#jak-często-przeglądamy-treści]

* **Strony zgodności z prawem**: minimum **raz na kwartał**, szczególnie
  po nowelizacjach ustaw. Pole `last_law_check` w frontmatter śledzi datę
  ostatniego sprawdzenia.
* **Strony funkcji**: przy każdej zmianie kodu, której dotyczy artykuł.
  `<ServiceRef>` automatycznie pokazuje liczbę testów integracyjnych
  pokrywających daną funkcję.
* **Koncepcje i poradniki**: raz na rok lub przy istotnych zmianach w
  produkcie.

## Zgłaszanie błędów [#zgłaszanie-błędów]

Każda strona ma na dole link &#x2A;*„Zgłoś poprawkę ↗"** — otwiera issue
na GitHubie z prefillowanym tytułem zawierającym ścieżkę pliku. Wszystkie
issue są publiczne.

Szczególnie prosimy o zgłoszenia, jeśli:

* Cytowany artykuł ustawy został zmieniony.
* Wynik podawany jako przykład jest niezgodny z aktualnymi stawkami lub
  limitami.
* Opisana funkcja Numify działa inaczej niż dokumentujemy.

## Zastrzeżenie prawne [#zastrzeżenie-prawne]

<ComplianceDisclaimer />

Numify AI jest narzędziem księgowym, nie kancelarią. Dokumentacja ma
**charakter edukacyjny** i nie stanowi indywidualnej porady podatkowej ani
prawnej. W sprawach skomplikowanych — szczególnie IP BOX, transakcji
transgranicznych, reorganizacji spółek — **skontaktuj się z doradcą
podatkowym**.

## Historia decyzji metodologicznych [#historia-decyzji-metodologicznych]

* **2026-04-16**: uruchomienie dokumentacji. Startujemy z pięciostopniowym
  systemem weryfikacji, centralnym rejestrem aktów prawnych w
  `_meta/legal-acts.json` i publiczną listą recenzentów w
  `_meta/reviewers.json`.
* **2026-04-16**: wprowadzenie recenzenta `numify-editorial` —
  wewnętrznego procesu redakcyjnego. Dzięki niemu strony zgodności
  mogą otrzymywać status <ReviewBadge status="internal" /> bez
  konieczności ręcznego przeglądu przez Kacpra, przy zachowaniu tej
  samej metodyki (ISAP + kod produktu). Właściciel produktu może
  w każdym momencie wycofać lub podwyższyć status.


---

# Obowiązki sp. z o.o. — przegląd
URL: https://numifyai.com/docs/zgodnosc-z-prawem
Description: Kompletna mapa obowiązków księgowych, podatkowych i sprawozdawczych polskiej spółki z ograniczoną odpowiedzialnością — ksiąg rachunkowych, VAT, CIT, KSeF i sprawozdania finansowego.
Review status: internal
Updated: 2026-04-16



Spółka z ograniczoną odpowiedzialnością (<PolishTerm pl="sp. z o.o." en="limited liability company">sp. z o.o.</PolishTerm>)
jest zobowiązana do prowadzenia **pełnej księgowości** — niezależnie od
wielkości przychodów, liczby pracowników czy formy działalności
(<LegalRef act="UoR" art="2" />). Ten przegląd pokazuje wszystkie obowiązki
sprawozdawcze i podatkowe w jednym miejscu, z linkami do szczegółowych
artykułów.

<ComplianceDisclaimer />

## Księgi rachunkowe (Art. 13–25 UoR) [#księgi-rachunkowe-art-1325-uor]

Podstawa prawna: <LegalRef act="UoR" art="13" />. Spółka prowadzi zbiór
ksiąg rachunkowych, na które składają się:

| Księga             | Polski termin                                                     | Podstawa prawna                 |
| ------------------ | ----------------------------------------------------------------- | ------------------------------- |
| Journal            | <PolishTerm pl="Dziennik" en="Journal" />                         | <LegalRef act="UoR" art="14" /> |
| General Ledger     | <PolishTerm pl="Księga Główna" en="General Ledger" />             | <LegalRef act="UoR" art="15" /> |
| Subsidiary Ledgers | <PolishTerm pl="Księgi Pomocnicze" en="Subsidiary Ledgers" />     | <LegalRef act="UoR" art="16" /> |
| Trial Balance      | <PolishTerm pl="Zestawienie Obrotów i Sald" en="Trial Balance" /> | <LegalRef act="UoR" art="18" /> |
| Inventory          | <PolishTerm pl="Inwentarz" en="Inventory" />                      | <LegalRef act="UoR" art="19" /> |

Wszystkie kwoty w księgach muszą być wyrażone w **złotych polskich**
(<LegalRef act="UoR" art="9" />) — w Numify przechowujemy je w groszach
jako liczby całkowite, żeby uniknąć błędów zaokrąglenia. Każda pozycja w
dzienniku musi być **zapisana dwustronnie** — suma debetów = suma kredytów
(<LegalRef act="UoR" art="15" />).

Od 1 stycznia 2026 r. dla typowych sp. z o.o. — podatników CIT
składających JPK\_V7M — księgi rachunkowe muszą być prowadzone
**w formie elektronicznej**, bo wynika to z obowiązku składania
JPK\_KR\_PD za rok 2026 (szczegóły: [Zmiany w 2026](/docs/zgodnosc-z-prawem/zmiany-w-2026)).

## VAT — podatek od towarów i usług [#vat--podatek-od-towarów-i-usług]

Podstawa: <LegalRef act="VAT" />. Najważniejsze obowiązki miesięczne:

* <DeadlineBadge type="jpk-v7m" /> — plik JPK\_V7M(3) z deklaracją i
  ewidencją VAT, <LegalRef act="VAT" art="99" />.
* <DeadlineBadge type="vat-ue" /> — informacja podsumowująca VAT-UE, jeśli
  występują transakcje wewnątrzwspólnotowe, <LegalRef act="VAT" art="100" />.

Stawki podatku: <VatRate rate="23" />, <VatRate rate="8" />, <VatRate rate="5" />,
<VatRate rate="0" /> (eksport, WDT), <VatRate rate="zw" /> (zwolnienie
przedmiotowe), <VatRate rate="np" /> (niepodlegające).

Od 1 stycznia 2026 r. limit zwolnienia podmiotowego z VAT został
podniesiony do **240 000 zł** rocznej sprzedaży — szczegóły w
[Zmianach w 2026](/docs/zgodnosc-z-prawem/zmiany-w-2026).

## CIT — podatek dochodowy [#cit--podatek-dochodowy]

Podstawa: <LegalRef act="CIT" />. Dla sp. z o.o.:

* **Stawka 9 %** — podatnicy, u których wartość przychodu ze sprzedaży (wraz
  z VAT) nie przekroczyła w poprzednim roku **2 mln EUR**, <LegalRef act="CIT" art="19" />.
* **Stawka 19 %** — pozostali podatnicy.
* <DeadlineBadge type="cit-zaliczka" /> — zaliczka na CIT za poprzedni
  miesiąc.
* <DeadlineBadge type="cit-8" /> — zeznanie CIT-8 za rok podatkowy,
  <LegalRef act="CIT" art="27" />.

Od roku podatkowego 2026 (deklaracja składana do 31 marca 2027 r.)
dochodzi obowiązek przekazania ksiąg rachunkowych w strukturze logicznej
**JPK\_KR\_PD** oraz ewidencji środków trwałych **JPK\_ST\_KR**
(<LegalRef act="JPK_KR_PD" />).

## KSeF — Krajowy System e-Faktur [#ksef--krajowy-system-e-faktur]

Od &#x2A;*1 kwietnia 2026 r.** wszystkie faktury B2B muszą być wystawiane
przez Krajowy System e-Faktur (<LegalRef act="KSEF" />). Przegląd:

<Cards>
  <Card title="KSeF — przegląd" description="Executive summary, cele, zakres obowiązku, grace period do końca 2026." href="/docs/zgodnosc-z-prawem/ksef" />

  <Card title="Harmonogram wdrożenia" description="Kto, kiedy, grupy podatników, okres przejściowy, wyjątki niskowartościowe." href="/docs/zgodnosc-z-prawem/ksef/harmonogram" />

  <Card title="Format FA(3)" description="Struktura XML faktury ustrukturyzowanej, wymagane pola, identyfikator KSeF." href="/docs/zgodnosc-z-prawem/ksef/format-fa3" />

  <Card title="Uwierzytelnianie" description="Podpis kwalifikowany, pieczęć elektroniczna, certyfikaty KSeF, wygaśnięcie Profilu Zaufanego." href="/docs/zgodnosc-z-prawem/ksef/uwierzytelnianie" />
</Cards>

## Sprawozdanie finansowe (Art. 45–53 UoR) [#sprawozdanie-finansowe-art-4553-uor]

Roczne sprawozdanie finansowe (<PolishTerm pl="SF" en="financial statement">SF</PolishTerm>)
składa się z co najmniej:

* **Bilans** (<PolishTerm pl="Bilans" en="Balance Sheet" />) —
  aktywa = pasywa, <LegalRef act="UoR" art="46" />.
* **Rachunek zysków i strat** (<PolishTerm pl="RZiS" en="Profit and Loss Statement">RZiS</PolishTerm>) —
  <LegalRef act="UoR" art="47" />.
* **Informacja dodatkowa** — <LegalRef act="UoR" art="48" />.

Dla jednostek małych (<PolishTerm pl="Jednostka Mała" en="Small Entity" />) —
aktywa \< 33 mln zł, przychody \< 66 mln zł, zatrudnienie \< 50 (progi po
nowelizacji Dz.U. 2024 poz. 1863, obowiązujące od 1 stycznia 2025 r.,
<LegalRef act="UoR" art="3" paragraph="1" /> pkt 1b) — dostępna jest
uproszczona forma sprawozdania (Załącznik nr 5 do UoR), bez rachunku
przepływów pieniężnych i zestawienia zmian w kapitale. Szczegóły:
[Załącznik 5 — jednostka mała](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-5).

Terminy:

1. **Sporządzenie SF** — w ciągu 3 miesięcy od końca roku obrotowego
   (31 marca dla roku kalendarzowego), <LegalRef act="UoR" art="52" />.
2. **Zatwierdzenie przez Zgromadzenie Wspólników** — w ciągu 6 miesięcy
   (30 czerwca), <LegalRef act="UoR" art="53" />.
3. **Złożenie w eKRS** — w ciągu 15 dni od zatwierdzenia
   (<DeadlineBadge type="sf-krs" />).

## Pełny kalendarz terminów [#pełny-kalendarz-terminów]

Wszystkie comiesięczne i roczne terminy — JPK\_V7M, zaliczki CIT, ZUS,
VAT-UE, SF, CIT-8, JPK\_KR\_PD — zebrane w jednym miejscu:

[📅 Kalendarz terminów](/docs/zgodnosc-z-prawem/kalendarz-terminow)

## Przechowywanie dokumentów [#przechowywanie-dokumentów]

Każda grupa dokumentów ma inny wymagany okres przechowywania — od
5 lat (faktury, księgi) do bezterminowo (zatwierdzone sprawozdania
finansowe) i 50 lat (akta pracownicze sprzed 2019 r.).
Pełne zestawienie: [Przechowywanie dokumentów](/docs/zgodnosc-z-prawem/przechowywanie-dokumentow).

## Zmiany w 2026 r. [#zmiany-w-2026-r]

Najważniejsze zmiany, które wchodzą w życie w 2026 r.:

* Obowiązkowy KSeF od 1 kwietnia 2026 r. (duzi podatnicy — od 1 lutego).
* JPK\_V7M(3) z numerem KSeF od 1 lutego 2026 r.
* Wyłącznie elektroniczne księgi rachunkowe od 1 stycznia 2026 r.
* JPK\_KR\_PD + JPK\_ST\_KR dla roku podatkowego 2026 (pierwsza deklaracja
  w marcu 2027 r.).
* Podniesiony limit zwolnienia podmiotowego z VAT do 240 000 zł.

Szczegóły: [Zmiany w 2026](/docs/zgodnosc-z-prawem/zmiany-w-2026).


---

# Przechowywanie dokumentów
URL: https://numifyai.com/docs/zgodnosc-z-prawem/przechowywanie-dokumentow
Description: Obowiązkowe okresy przechowywania ksiąg rachunkowych, dokumentów źródłowych, dokumentów VAT, akt pracowniczych i sprawozdań finansowych zgodnie z ustawą o rachunkowości i ustawą o VAT.
Review status: internal
Updated: 2026-04-16



Obowiązek archiwizacji dokumentów księgowych nie kończy się wraz z
końcem roku obrotowego. UoR i ustawa o VAT narzucają konkretne okresy
przechowywania — różne dla różnych kategorii. Poniższe zestawienie
pokazuje, co, jak długo i w jakiej formie musi być zachowane.

<ComplianceDisclaimer />

## Okresy przechowywania — szybka tabela [#okresy-przechowywania--szybka-tabela]

| Kategoria                                         | Okres                                                              | Podstawa prawna                                            |
| ------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------- |
| Zatwierdzone roczne sprawozdania finansowe        | **Trwałe**                                                         | <LegalRef act="UoR" art="74" /> ust. 1                     |
| Księgi rachunkowe (dziennik, księga główna, ZOiS) | **5 lat**                                                          | <LegalRef act="UoR" art="74" /> ust. 2 pkt 1               |
| Karty wynagrodzeń / listy płac                    | **5 lat** (+ 50 lat ewidencja ZUS ZUA dla akt starszych niż 2019)  | <LegalRef act="UoR" art="74" /> ust. 2 pkt 8               |
| Dowody księgowe (faktury, wyciągi, noty)          | **5 lat**                                                          | <LegalRef act="UoR" art="74" /> ust. 2 pkt 4               |
| Dokumenty inwentaryzacyjne                        | **5 lat**                                                          | <LegalRef act="UoR" art="74" /> ust. 2 pkt 5               |
| Pozostałe dowody i dokumenty                      | **5 lat**                                                          | <LegalRef act="UoR" art="74" /> ust. 2 pkt 8               |
| Faktury i ewidencja VAT                           | **5 lat** od końca roku, w którym upłynął termin płatności podatku | <LegalRef act="VAT" art="112" />                           |
| Akta pracownicze (zatrudnieni od 2019 r.)         | **10 lat** od końca roku ustania stosunku pracy                    | Kodeks pracy, art. 94⁵                                     |
| Akta pracownicze (zatrudnieni przed 2019 r.)      | **50 lat**                                                         | Kodeks pracy (przed nowelizacją)                           |
| Dokumenty ZUS (deklaracje, raporty)               | **5 lat** od dnia przekazania do ZUS                               | Ustawa o systemie ubezpieczeń społecznych, art. 47 ust. 3c |

## Kiedy zaczyna biec termin [#kiedy-zaczyna-biec-termin]

Bieg 5-letniego terminu dla ksiąg i dokumentów **liczy się od początku
roku następującego po roku obrotowym**, którego dokumenty dotyczą
(<LegalRef act="UoR" art="74" /> ust. 3).

**Przykład:** faktury zakupowe z 2025 r. przechowuje się do końca 2030 r.
(początek biegu: 1 stycznia 2026 r., koniec: 31 grudnia 2030 r.).

Dla faktur VAT i ewidencji VAT bieg liczony jest inaczej:
**5 lat od końca roku kalendarzowego, w którym upłynął termin płatności
podatku** (<LegalRef act="VAT" art="112" />). W praktyce dla większości
spółek terminy się pokrywają, ale dla faktur wystawionych w grudniu
różnica może sięgnąć jednego roku — ze względu na termin rozliczenia
VAT (25. stycznia następnego roku).

## Wymagania formalne [#wymagania-formalne]

Ustawa o rachunkowości nakłada konkretne wymagania na formę i sposób
przechowywania (<LegalRef act="UoR" art="73" /> — <LegalRef act="UoR" art="74" />):

* **Dostępność** — dokumenty muszą być możliwe do odczytania przez cały
  okres przechowywania. Jeżeli jednostka zmienia system informatyczny,
  musi zapewnić odczyt starych plików.
* **Czytelność** — dokumenty elektroniczne muszą być odporne na
  przypadkową modyfikację (brak edytowalności plików, hashowanie, podpis
  cyfrowy lub zapis w systemie księgowym z pełnym śladem rewizyjnym).
* **Miejsce przechowywania** — w siedzibie jednostki lub u biura
  rachunkowego; przechowywanie poza UE wymaga zgłoszenia US.
* **Porządek chronologiczny** — w układzie pozwalającym na łatwą
  identyfikację.

### Forma elektroniczna — Numify [#forma-elektroniczna--numify]

Od 1 stycznia 2026 r. sp. z o.o. prowadzą księgi **wyłącznie w formie
elektronicznej** — nie ma możliwości księgowania na papierze. Numify
przechowuje:

* **Pliki dokumentów źródłowych** (PDF faktury, skany paragonów) —
  w <PolishTerm pl="Cloudflare R2" en="Cloudflare R2 object storage" />
  z retencją dożywotnią (nie ma auto-delete).
* **Zapisy księgowe** (journal\_entries, journal\_lines, rejestr VAT) —
  w PostgreSQL z pełnym śladem rewizyjnym (tabela `audit_log`,
  <LegalRef act="UoR" art="25" />).
* **Wygenerowane pliki JPK** (JPK\_V7M, JPK\_KR\_PD, JPK\_ST\_KR) —
  archiwizowane po wysłaniu, odnawialne z danych źródłowych.

Pełna polityka retencji jest zaimplementowana w
<ServiceRef path="src/lib/services/backup-retention.ts">backup-retention.ts</ServiceRef>.

## Dokumenty specjalne [#dokumenty-specjalne]

### Sprawozdania finansowe [#sprawozdania-finansowe]

Zatwierdzone sprawozdania finansowe przechowuje się **trwale**
(<LegalRef act="UoR" art="74" /> ust. 1) — zarówno w formie lokalnej,
jak i w repozytorium eKRS. Republika Polska przechowuje wpisy eKRS
bezterminowo, więc nawet przy likwidacji spółki dane SF pozostają
publicznie dostępne.

### Dokumenty do IP BOX / B+R [#dokumenty-do-ip-box--br]

Dokumentacja ewidencji czasu pracy nad B+R oraz ewidencja projektów IP
BOX — przechowywane **5 lat** na zasadach ogólnych UoR. W praktyce
rekomenduje się przechowywanie dłużej, bo urzędy skarbowe mogą wnosić
o weryfikację w ramach kontroli post-factum.

### Dokumenty KSeF [#dokumenty-ksef]

Faktury wystawione lub otrzymane przez KSeF są **automatycznie
archiwizowane przez Ministerstwo Finansów na 10 lat**. Spółka nie ma
obowiązku samodzielnego przechowywania faktur KSeF — identyfikator KSeF
pozwala odtworzyć dokument w dowolnym momencie. Numify zachowuje
lokalnie zbuforowane kopie XML dla szybszego dostępu.

## Usuwanie po upływie terminu [#usuwanie-po-upływie-terminu]

Po upływie okresu przechowywania jednostka **może** (nie musi) usunąć
dokumenty. Przed usunięciem warto:

1. Sprawdzić, czy dokumenty nie są przedmiotem trwającej kontroli
   podatkowej — wtedy termin **przedłuża się** do zakończenia kontroli.
2. Sprawdzić, czy dokumenty nie są powiązane z nierozstrzygniętą sprawą
   sądową lub odwoławczą.
3. Zabezpieczyć dane pracownicze zgodnie z RODO
   (<LegalRef act="RODO" />) — minimalizacja danych po upływie
   prawnie uzasadnionej retencji.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/POLISH-COMPLIANCE-REFERENCE.md`
    oraz art. 71–74 UoR + art. 112 VAT.
  </ChangeEntry>
</ChangeHistory>


---

# Kalendarz terminów
URL: https://numifyai.com/docs/zgodnosc-z-prawem/kalendarz-terminow
Description: Wszystkie comiesięczne, kwartalne i roczne terminy księgowe i podatkowe dla polskiej spółki z o.o. — JPK_V7M, zaliczki CIT, ZUS, VAT-UE, sprawozdanie finansowe.
Review status: internal
Updated: 2026-04-16



Spółka z o.o. podlega kilkunastu terminom rocznie. Przegapienie
któregokolwiek oznacza odsetki od zaległości podatkowych, a w przypadku
KRS — sankcje do postępowania przymuszającego sąd rejestrowy.
Poniżej komplet terminów z podstawą prawną i linkiem do odpowiedniego
modułu w Numify.

<ComplianceDisclaimer />

## Terminy comiesięczne [#terminy-comiesięczne]

| Termin                                      | Obowiązek                                                                 | Podstawa prawna                                    |
| ------------------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------- |
| <DeadlineBadge type="zus" /> (15.)          | Składki ZUS za poprzedni miesiąc (dla sp. z o.o. — 15., nie 20.)          | Ustawa o systemie ubezpieczeń społecznych, art. 47 |
| <DeadlineBadge type="cit-zaliczka" /> (20.) | Zaliczka na CIT za poprzedni miesiąc                                      | <LegalRef act="CIT" art="25" />                    |
| <DeadlineBadge type="pit-zaliczka" /> (20.) | Zaliczka PIT-4 od wynagrodzeń (jeśli są pracownicy)                       | Ustawa o PIT, art. 38                              |
| <DeadlineBadge type="jpk-v7m" /> (25.)      | JPK\_V7M(3) — deklaracja VAT + ewidencja                                  | <LegalRef act="VAT" art="99" />                    |
| <DeadlineBadge type="vat-ue" /> (25.)       | Informacja podsumowująca VAT-UE (jeśli są transakcje wewnątrzwspólnotowe) | <LegalRef act="VAT" art="100" />                   |

> Dla transakcji WNT/WDT/usług wewnątrzwspólnotowych VAT-UE jest
> **obowiązkowa** — nie jest to opcja dla wybranych podatników. Brak
> VAT-UE przy istniejących transakcjach to ten sam błąd co brak JPK\_V7M.

## Terminy roczne [#terminy-roczne]

### Sprawozdanie finansowe (rok obrotowy = kalendarzowy) [#sprawozdanie-finansowe-rok-obrotowy--kalendarzowy]

| Etap                                                 | Termin                                                    | Podstawa prawna                 |
| ---------------------------------------------------- | --------------------------------------------------------- | ------------------------------- |
| Sporządzenie SF (bilans, RZiS, informacja dodatkowa) | 31 marca (3 miesiące od końca roku)                       | <LegalRef act="UoR" art="52" /> |
| Zatwierdzenie przez ZZW                              | 30 czerwca (6 miesięcy od końca roku)                     | <LegalRef act="UoR" art="53" /> |
| Złożenie w repozytorium eKRS                         | <DeadlineBadge type="sf-krs" /> (15 dni od zatwierdzenia) | <LegalRef act="UoR" art="69" /> |

**Zgromadzenie Wspólników** (<PolishTerm pl="ZZW" en="Annual General Meeting">Zwyczajne Zgromadzenie Wspólników</PolishTerm>)
to obligatoryjny organ — sp. z o.o. nie może zatwierdzić SF bez uchwały
wspólników.

### CIT roczny [#cit-roczny]

| Obowiązek                                       | Termin (dla roku 2025)                             | Podstawa prawna                 |
| ----------------------------------------------- | -------------------------------------------------- | ------------------------------- |
| <DeadlineBadge type="cit-8" /> — zeznanie CIT-8 | 31 marca 2026 r.                                   | <LegalRef act="CIT" art="27" /> |
| JPK\_KR\_PD (księgi podatkowe)                  | 31 marca 2027 r. — pierwsza deklaracja za rok 2026 | <LegalRef act="JPK_KR_PD" />    |
| JPK\_ST\_KR (ewidencja środków trwałych)        | 31 marca 2027 r. — pierwsza deklaracja za rok 2026 | <LegalRef act="JPK_KR_PD" />    |

### ZUS — dokumenty roczne [#zus--dokumenty-roczne]

| Dokument | Termin      | Dotyczy                                                                                       |
| -------- | ----------- | --------------------------------------------------------------------------------------------- |
| ZUS IWA  | 31 stycznia | Tylko spółki zatrudniające ≥ 10 osób średnio w roku (dane do różnicowanej składki wypadkowej) |

> Roczne rozliczenie składki zdrowotnej (do 20 maja) **nie dotyczy**
> sp. z o.o. za samą spółkę ani członków zarządu pobierających
> wynagrodzenie z tytułu powołania — zgodnie z ustawą o NFZ
> rozliczenie roczne dotyczy wyłącznie osób prowadzących pozarolniczą
> działalność gospodarczą (np. jeśli członek zarządu ma dodatkowo JDG).
> Składka zdrowotna z tytułu powołania to stała miesięczna kwota,
> rozliczana w ramach comiesięcznej deklaracji ZUS.

## Terminy KSeF [#terminy-ksef]

| Grupa                                                  | Od kiedy KSeF obowiązkowy | Podstawa                |
| ------------------------------------------------------ | ------------------------- | ----------------------- |
| Duzi podatnicy (sprzedaż > 200 mln zł w 2024 r.)       | **1 lutego 2026 r.**      | <LegalRef act="KSEF" /> |
| Pozostali podatnicy VAT (w tym większość sp. z o.o.)   | **1 kwietnia 2026 r.**    | <LegalRef act="KSEF" /> |
| Mikroprzedsiębiorcy (sprzedaż miesięczna \< 10 000 zł) | **1 stycznia 2027 r.**    | <LegalRef act="KSEF" /> |

**Grace period** — brak kar finansowych za błędy do 31 grudnia 2026 r.
Od 1 stycznia 2027 r. kary do 100 % kwoty VAT na fakturze wystawionej
poza KSeF (lub 18,7 % kwoty brutto dla zwolnionych).

Szczegóły w [KSeF — harmonogram](/docs/zgodnosc-z-prawem/ksef/harmonogram).

## Reguła przeniesienia terminu [#reguła-przeniesienia-terminu]

Jeżeli termin przypada na sobotę, niedzielę lub dzień ustawowo wolny od
pracy — przesuwa się automatycznie na najbliższy dzień roboczy
(<LegalRef act="OrdPod" art="12" paragraph="5" />).
Numify uwzględnia tę regułę w przypomnieniach o terminach.

## Kalendarz poglądowy — rok 2026 [#kalendarz-poglądowy--rok-2026]

| Miesiąc             | 15.                 | 20.                 | 25.              | Ważne roczne                               |
| ------------------- | ------------------- | ------------------- | ---------------- | ------------------------------------------ |
| Styczeń             | ZUS · ZUS IWA (31.) | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | —                                          |
| Luty                | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | **KSeF dla dużych** (1.)                   |
| Marzec              | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | **Sporządzenie SF** (31.), **CIT-8** (31.) |
| Kwiecień            | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | **KSeF obowiązkowy dla wszystkich** (1.)   |
| Maj                 | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | —                                          |
| Czerwiec            | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | **Zatwierdzenie SF** (30.)                 |
| Lipiec              | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | **Złożenie SF w KRS** (15.)                |
| Sierpień – Grudzień | ZUS                 | Zaliczka CIT, PIT-4 | JPK\_V7M, VAT-UE | —                                          |

> Powyższy kalendarz zakłada rok obrotowy = kalendarzowy i brak
> transakcji ICT wymagających Intrastat. Spółki z handlem towarowym w UE
> mogą dodatkowo podlegać Intrastat (do 10. dnia następnego miesiąca).

## Jak Numify pilnuje terminów [#jak-numify-pilnuje-terminów]

Panel główny zawiera widget &#x2A;*„Nadchodzące terminy"**, który renderuje
każdy termin jako kolorowy badge (czerwony — do 3 dni, pomarańczowy —
do 10 dni, zielony — dalej). Stan pobierany jest z modułu
<ServiceRef path="src/lib/services/compliance-reminders.ts">compliance-reminders</ServiceRef>.

Pełna konfiguracja terminów jest w
<ServiceRef path="src/lib/docs/deadlines.ts">deadlines.ts</ServiceRef> —
zmiana daty wymaga commitu do repozytorium, nie edycji w aplikacji.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja kalendarza — zagregowane terminy z komponentów
    compliance-reminders oraz `_legacy/POLISH-COMPLIANCE-REFERENCE.md`.
  </ChangeEntry>
</ChangeHistory>


---

# Zmiany w 2026 r.
URL: https://numifyai.com/docs/zgodnosc-z-prawem/zmiany-w-2026
Description: Najważniejsze zmiany w prawie księgowym i podatkowym wchodzące w życie w 2026 r. — obowiązkowy KSeF, JPK_V7M(3), elektroniczne księgi, nowy próg zwolnienia z VAT, JPK_KR_PD dla roku 2026.
Review status: internal
Updated: 2026-04-16



Rok 2026 jest największą reformą obowiązków sprawozdawczych od wielu
lat. Praktycznie każdy element księgowości — fakturowanie, ewidencja
VAT, księgi rachunkowe, CIT — dostaje nową formę elektroniczną lub nowy
obowiązek sprawozdawczy. Poniższa strona zbiera wszystkie zmiany w
chronologicznej kolejności wejścia w życie.

<ComplianceDisclaimer />

## 1 stycznia 2026 — zmiany w VAT i księgach [#1-stycznia-2026--zmiany-w-vat-i-księgach]

### Zwolnienie podmiotowe z VAT — nowy próg 240 000 zł [#zwolnienie-podmiotowe-z-vat--nowy-próg-240-000-zł]

Limit zwolnienia podmiotowego z VAT został podniesiony z **200 000 zł**
do **240 000 zł** rocznej sprzedaży (<LegalRef act="VAT" art="113" />).
Zmiana dotyczy podatników, którzy w **poprzednim roku** nie przekroczyli
nowego limitu — próg obowiązuje już w rozliczeniach za 2025 r.

Przykład: spółka ze sprzedażą 210 000 zł w 2025 r. może korzystać ze
zwolnienia podmiotowego w 2026 r., mimo że poprzednio takiego prawa
nie miała.

### Wyłącznie elektroniczne księgi rachunkowe [#wyłącznie-elektroniczne-księgi-rachunkowe]

Dla podatników CIT składających miesięczne JPK\_V7M (typowa sp. z o.o.),
od 1 stycznia 2026 r. **księgi rachunkowe muszą być prowadzone
w formie elektronicznej** — w sposób umożliwiający przekazanie
struktury JPK\_KR\_PD fiskusowi za rok 2026. Podstawa:
<LegalRef act="CIT" art="9" paragraph="1c" /> oraz
<LegalRef act="JPK_KR_PD" />. UoR nie zabrania papieru, ale obowiązek
składania JPK\_KR\_PD de facto wymusza formę elektroniczną.

> Dla największych podatników CIT (przychód > 50 mln EUR) obowiązek
> wszedł już 1 stycznia 2025 r. Dla podatników CIT składających
> JPK\_V7K (kwartalnie) — wchodzi 1 stycznia 2027 r.

W praktyce większość sp. z o.o. już od lat prowadzi księgi cyfrowo,
ale od 2026 r. jest to wymuszone przez fiskusa, nie tylko dobrowolne.

Konsekwencje:

* Wymagane są mechanizmy zabezpieczające integralność zapisów
  (ślad rewizyjny, <LegalRef act="UoR" art="25" />).
* Dostępność zapisów musi być zapewniona przez cały okres
  przechowywania (5 lat + trwałe dla SF).
* System informatyczny musi być opisany w **polityce rachunkowości**
  (<LegalRef act="UoR" art="10" />).

## 1 lutego 2026 — JPK\_V7M(3) z numerem KSeF [#1-lutego-2026--jpk_v7m3-z-numerem-ksef]

Nowa struktura JPK\_V7M (wersja 3) zawiera &#x2A;*obowiązkowe pole
`NrKSeF`** dla każdej faktury wystawionej lub otrzymanej przez KSeF.
Dodatkowo nowe znaczniki:

| Znacznik | Znaczenie                                                         |
| -------- | ----------------------------------------------------------------- |
| `NrKSeF` | Unikalny identyfikator faktury w KSeF                             |
| `OFF`    | Faktura wystawiona w trybie offline — KSeF był niedostępny        |
| `BFK`    | Faktura bez KSeF (wyjątki: B2C, niskowartościowe, transgraniczne) |
| `DI`     | Inny dokument (np. dokument wewnętrzny, nie faktura)              |

Termin pierwszego JPK\_V7M(3): &#x2A;*25 marca 2026 r.** (za luty 2026).

## 1 lutego 2026 — KSeF obowiązkowy dla dużych podatników [#1-lutego-2026--ksef-obowiązkowy-dla-dużych-podatników]

Podatnicy, u których sprzedaż wraz z kwotą VAT przekroczyła
**200 mln zł** w 2024 r., muszą wystawiać wszystkie faktury B2B przez
KSeF od 1 lutego 2026 r. (<LegalRef act="KSEF" />).

Większości sp. z o.o. nie dotyczy — próg jest wysoki. Szczegóły:
[KSeF — harmonogram](/docs/zgodnosc-z-prawem/ksef/harmonogram).

## 1 kwietnia 2026 — KSeF obowiązkowy dla wszystkich podatników VAT [#1-kwietnia-2026--ksef-obowiązkowy-dla-wszystkich-podatników-vat]

To główny milestone reformy KSeF — od tego dnia **każda sp. z o.o.
będąca podatnikiem VAT** musi wystawiać faktury B2B przez KSeF.
Fakturowanie poza systemem jest dozwolone tylko w wyjątkach:

* Faktury B2C (dla osób fizycznych).
* Faktury transgraniczne (odbiorca zagraniczny bez polskiego NIP).
* Faktury niskowartościowe — do 30 września 2026 r., jednostkowo do
  <Grosze value="45000" /> brutto i łącznie do <Grosze value="1000000" />
  miesięcznie.
* Specyficzne usługi (np. bilety komunikacji pasażerskiej, autostrady).

**Grace period** — brak kar finansowych za błędy do 31 grudnia 2026 r.

## 31 marca 2026 — wygaśnięcie Profilu Zaufanego jako metody logowania do KSeF [#31-marca-2026--wygaśnięcie-profilu-zaufanego-jako-metody-logowania-do-ksef]

Do &#x2A;*31 marca 2026 r.** można logować się do KSeF za pomocą Profilu
Zaufanego. Od 1 kwietnia 2026 r. pozostają wyłącznie:

* Kwalifikowany podpis elektroniczny.
* Kwalifikowana pieczęć elektroniczna.
* Certyfikat KSeF (certyfikat programowy wydawany przez MF).

Szczegóły: [KSeF — uwierzytelnianie](/docs/zgodnosc-z-prawem/ksef/uwierzytelnianie).

## 30 września 2026 — koniec ulgi dla faktur niskowartościowych [#30-września-2026--koniec-ulgi-dla-faktur-niskowartościowych]

Do 30 września 2026 r. faktury jednostkowo do <Grosze value="45000" />
brutto i miesięcznie do <Grosze value="1000000" /> można wystawiać poza
KSeF. &#x2A;*Od 1 października 2026 r.** — wszystkie faktury B2B muszą być
w KSeF, niezależnie od kwoty.

## 1 stycznia 2027 — mikroprzedsiębiorcy w KSeF [#1-stycznia-2027--mikroprzedsiębiorcy-w-ksef]

Ostatni etap wdrożenia KSeF — obowiązek obejmuje mikroprzedsiębiorców
(miesięczna sprzedaż \< 10 000 zł). Równocześnie **kończy się grace
period** — od 1 stycznia 2027 r. kary do 100 % kwoty VAT na fakturze
wystawionej poza KSeF (lub 18,7 % kwoty brutto dla zwolnionych).

## Rok obrotowy 2026 — JPK\_KR\_PD i JPK\_ST\_KR [#rok-obrotowy-2026--jpk_kr_pd-i-jpk_st_kr]

Za rok podatkowy 2026 (deklaracja do &#x2A;*31 marca 2027 r.**) spółka
składa po raz pierwszy:

* **JPK\_KR\_PD** — księgi rachunkowe z dodatkowymi znacznikami
  podatkowymi (KUP, NKUP, przychody podatkowe / niepodatkowe)
  zgodnie z <LegalRef act="JPK_KR_PD" />.
* **JPK\_ST\_KR** — ewidencja środków trwałych w strukturze JPK.

Każde konto w planie kont musi mieć przypisany **znacznik podatkowy PD**
zgodnie z Załącznikiem do rozporządzenia MF z 16 sierpnia 2024 r.
Numify ma to pole zaimplementowane — zob.
<ServiceRef path="src/lib/services/jpk-kr-pd-generator.ts">jpk-kr-pd-generator.ts</ServiceRef>.

## Oś czasu — 2026 w skrócie [#oś-czasu--2026-w-skrócie]

```
2026-01-01  ┃  VAT: limit 240k · księgi elektroniczne · polityka rach.
2026-02-01  ┃  KSeF mandatory (duzi podatnicy) · JPK_V7M(3)
2026-03-31  ┃  Profil Zaufany przestaje działać jako login do KSeF
2026-04-01  ┃  KSeF mandatory (WSZYSCY podatnicy VAT)
2026-09-30  ┃  Koniec ulgi niskowartościowej (450 zł / 10 000 zł)
2026-12-31  ┃  Koniec grace period (bez kar)
2027-01-01  ┃  Kary KSeF · mikroprzedsiębiorcy w KSeF
2027-03-31  ┃  Pierwsze JPK_KR_PD i JPK_ST_KR (za rok 2026) · CIT-8
```

## Co robi Numify, żeby być gotowym [#co-robi-numify-żeby-być-gotowym]

Poniższa tabela pokazuje stan implementacji w kodzie. Status
&#x2A;*„Gotowe w kodzie”** oznacza, że serwis / generator istnieje i jest
pokryty testami — **nie zastępuje konfiguracji środowiska**
(certyfikat KSeF, zmienna `KSEF_ENV=production`, klucze API).
Domyślnie `KSEF_ENV=test` — realne działanie na produkcyjnym KSeF
wymaga zmiany konfiguracji i wydania certyfikatu.

| Zmiana                                               | Status w kodzie                                                                                                  |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| KSeF (wystawianie + odbieranie + XML FA(3))          | Gotowe w kodzie — <ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>               |
| JPK\_V7M(3) z polem NrKSeF i znacznikami OFF/BFK/DI  | Gotowe w kodzie — <ServiceRef path="src/lib/services/jpk-vat-generator.ts">jpk-vat-generator.ts</ServiceRef>     |
| Tryb Offline24 dla KSeF                              | Gotowe w kodzie (flaga `OFF` na wpisach VAT)                                                                     |
| QR kod na PDF faktury                                | Gotowe w kodzie — <ServiceRef path="src/lib/services/ksef-qr.ts">ksef-qr.ts</ServiceRef>                         |
| Znaczniki podatkowe PD na planie kont                | Gotowe w kodzie (pole `jpkPdMarker` na `chart_accounts`)                                                         |
| JPK\_KR\_PD generator XML                            | Gotowe w kodzie — <ServiceRef path="src/lib/services/jpk-kr-pd-generator.ts">jpk-kr-pd-generator.ts</ServiceRef> |
| JPK\_ST\_KR generator XML                            | Gotowe w kodzie — <ServiceRef path="src/lib/services/jpk-st-kr-generator.ts">jpk-st-kr-generator.ts</ServiceRef> |
| Podniesiony limit 240 000 zł w logice zwolnienia VAT | Gotowe w kodzie                                                                                                  |
| Nowa polityka rachunkowości z opisem systemu IT      | Gotowe w kodzie — <ServiceRef path="src/lib/services/accounting-policy.ts">accounting-policy.ts</ServiceRef>     |
| Cykliczne pobieranie faktur zakupu (BullMQ)          | ❌ Odroczone — synchronizacja manualna z `/ksef`                                                                  |
| Numer KSeF w przelewach bankowych                    | ❌ Odroczone — egzekwowane dopiero od końca 2026 r.                                                               |

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/POLISH-COMPLIANCE-REFERENCE.md`
    (sekcja „Key 2026 Changes") oraz oficjalnych komunikatów Ministerstwa
    Finansów dot. KSeF 2.0.
  </ChangeEntry>
</ChangeHistory>


---

# KSeF — przegląd
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef
Description: Krajowy System e-Faktur — czym jest, kogo dotyczy, od kiedy obowiązuje. Cele systemu, zakres wyjątków, grace period, korzyści dla podatników.
Review status: internal
Updated: 2026-04-16



**Krajowy System e-Faktur** (KSeF) to centralna platforma Ministerstwa
Finansów, przez którą wystawiane są wszystkie faktury B2B w Polsce.
Zastępuje dotychczasowy model, w którym faktura mogła być dokumentem
papierowym, PDF-em lub plikiem w dowolnym formacie — odtąd jedyną
legalną formą faktury B2B jest **faktura ustrukturyzowana** w formacie
XML FA(3), przesłana przez KSeF.

<ComplianceDisclaimer />

## Co to zmienia [#co-to-zmienia]

| Przed KSeF                          | Po KSeF                                                    |
| ----------------------------------- | ---------------------------------------------------------- |
| Faktura PDF / papier / e-mail       | XML FA(3) w centralnym systemie                            |
| Podatnik archiwizuje faktury 5 lat  | MF archiwizuje 10 lat; podatnik nie musi                   |
| Numer faktury nadaje wystawca       | Wystawca nadaje własny numer + KSeF nadaje globalny NrKSeF |
| Odbiorca „dostaje" fakturę e-mailem | Odbiorca „pobiera" fakturę z KSeF                          |
| Zwrot VAT 60 dni                    | Zwrot VAT **40 dni** (bonus compliance)                    |
| Audyt post-factum                   | Audyt real-time (MF ma dane natychmiast)                   |

## Kogo obejmuje [#kogo-obejmuje]

Wszystkich **czynnych podatników VAT** z siedzibą lub stałym miejscem
prowadzenia działalności w Polsce — w tym spółki z o.o. Grupy i daty
wdrożenia:

| Grupa                   | Data obowiązkowa    | Próg                             |
| ----------------------- | ------------------- | -------------------------------- |
| Duzi podatnicy          | **1 lutego 2026**   | Sprzedaż > 200 mln zł w 2024 r.  |
| Pozostali podatnicy VAT | **1 kwietnia 2026** | —                                |
| Mikroprzedsiębiorcy     | **1 stycznia 2027** | Miesięczna sprzedaż \< 10 000 zł |

Szczegóły: [Harmonogram wdrożenia](/docs/zgodnosc-z-prawem/ksef/harmonogram).

## Co musi być wystawione przez KSeF [#co-musi-być-wystawione-przez-ksef]

| Typ dokumentu                                | KSeF wymagany          |
| -------------------------------------------- | ---------------------- |
| Faktura sprzedaży B2B                        | ✅ Tak                  |
| Faktura zakupu B2B                           | ✅ Odbierana przez KSeF |
| Faktura korygująca                           | ✅ Tak                  |
| Faktura zaliczkowa                           | ✅ Tak                  |
| Faktura B2C (konsument)                      | ❌ Opcjonalnie          |
| Faktura transgraniczna (odbiorca bez PL NIP) | ❌ Zwolniona            |
| Paragony fiskalne                            | ❌ Poza zakresem KSeF   |

## Wyjątki i zwolnienia [#wyjątki-i-zwolnienia]

KSeF **nie jest wymagany** dla:

* **Faktur B2C** — dla osób fizycznych nieprowadzących działalności
  gospodarczej (<LegalRef act="VAT" art="106ga" /> ust. 2).
* **Transakcji transgranicznych** — kiedy odbiorca jest podmiotem
  zagranicznym bez rejestracji VAT w Polsce.
* **Określonych usług** — biletów jednorazowych komunikacji pasażerskiej,
  opłat autostradowych, niektórych usług finansowych i
  ubezpieczeniowych (szczegóły w <LegalRef act="KSEF" />).

### Ulga niskowartościowa (do 30 września 2026 r.) [#ulga-niskowartościowa-do-30-września-2026-r]

Do 30 września 2026 r. można wystawiać poza KSeF faktury:

* Pojedynczo — do <Grosze value="45000" /> brutto.
* Łącznie miesięcznie — do <Grosze value="1000000" />.

Od 1 października 2026 r. wyłączenie wygasa — każda faktura B2B, nawet
za 1 zł, musi być w KSeF.

## Grace period i kary [#grace-period-i-kary]

**Do 31 grudnia 2026 r.** obowiązuje okres przejściowy — MF nie nakłada
kar finansowych za błędy formalne (np. faktura wystawiona poza KSeF,
faktura z opóźnieniem, niespójny numer KSeF).

Od &#x2A;*1 stycznia 2027 r.** kary są konkretne:

| Sytuacja                                         | Kara                           |
| ------------------------------------------------ | ------------------------------ |
| Faktura wystawiona poza KSeF mimo obowiązku      | Do 100 % kwoty VAT na fakturze |
| Ta sama dla zwolnionych z VAT                    | 18,7 % kwoty brutto            |
| Opóźnienie przesłania offline po 1 dniu roboczym | Do 100 % kwoty VAT             |
| Fałszywy znacznik `OFF` / `BFK`                  | Kara jak za fakturę poza KSeF  |

## Korzyści z KSeF [#korzyści-z-ksef]

Poza obligatoryjnością KSeF oferuje kilka praktycznych korzyści:

* **Szybszy zwrot VAT** — 40 dni zamiast 60 (<LegalRef act="VAT" art="87" />).
* **Darmowa archiwizacja** — MF przechowuje faktury 10 lat, podatnik nie
  musi utrzymywać własnego archiwum PDF.
* **Mniejsze ryzyko audytu** — MF widzi faktury w momencie wystawienia;
  nie ma „odkrycia" błędów po roku.
* **Brak zagubionych faktur** — faktura zakupu trafia do podatnika
  zawsze, niezależnie od e-maila czy poczty.
* **Wymierzalne numery** — `NrKSeF` jest globalnie unikalny, niezależny
  od numeru nadanego przez wystawcę.

## Jak Numify realizuje KSeF [#jak-numify-realizuje-ksef]

Servisy KSeF są **gotowe w kodzie i pokryte testami** — wystarczy
skonfigurować środowisko (`KSEF_ENV=production` + certyfikat KSeF
spółki), żeby działać na produkcyjnym KSeF. Domyślnie Numify działa
w trybie testowym (`ksef-test.mf.gov.pl`).

* Wystawianie faktur przez KSeF:
  <ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>
* Parsowanie otrzymanych faktur FA(3):
  <ServiceRef path="src/lib/services/ksef-fa3-parser.ts">ksef-fa3-parser.ts</ServiceRef>
* Generator XML FA(3):
  <ServiceRef path="src/lib/services/ksef-fa3-generator.ts">ksef-fa3-generator.ts</ServiceRef>
* QR kod do PDF faktury:
  <ServiceRef path="src/lib/services/ksef-qr.ts">ksef-qr.ts</ServiceRef>

Schematy baz danych dla `ksef_credentials` i `ksef_sessions` są w
[`src/db/schema.ts`](https://github.com/kacperkwapisz/numifyai/blob/master/src/db/schema.ts).

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md`.
  </ChangeEntry>
</ChangeHistory>


---

# KSeF — harmonogram wdrożenia
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/harmonogram
Description: Szczegółowy harmonogram obowiązkowego KSeF 2.0 — kto i kiedy musi przejść na faktury ustrukturyzowane, progi wdrożenia, okresy przejściowe, grace period.
Review status: internal
Updated: 2026-04-16



Wdrożenie obowiązkowego KSeF zostało podzielone na trzy grupy
podatników z różnymi datami startowymi oraz serię okresów przejściowych.
Ta strona pokazuje, **kto i kiedy** musi wystawiać faktury przez KSeF,
wraz z pełną osią czasu do stycznia 2027 r.

<ComplianceDisclaimer />

## Trzy grupy podatników [#trzy-grupy-podatników]

### Grupa 1 — duzi podatnicy (od 1 lutego 2026 r.) [#grupa-1--duzi-podatnicy-od-1-lutego-2026-r]

Obejmuje podatników, których **sprzedaż wraz z kwotą VAT przekroczyła
w 2024 r. 200 mln zł**. W praktyce: największe spółki akcyjne, grupy
kapitałowe, duzi producenci i handlowcy. **Większości sp. z o.o. nie
dotyczy** — próg jest bardzo wysoki.

Kontrola progu — na podstawie deklaracji VAT-7 / JPK\_V7M za rok 2024.

### Grupa 2 — pozostali podatnicy VAT (od 1 kwietnia 2026 r.) [#grupa-2--pozostali-podatnicy-vat-od-1-kwietnia-2026-r]

Główna grupa — &#x2A;*obejmuje praktycznie wszystkie sp. z o.o.**, które
są czynnymi podatnikami VAT. Nie ma progu kwotowego — wystarczy bycie
zarejestrowanym jako podatnik VAT czynny.

Dotyczy również:

* Podatników zwolnionych podmiotowo z VAT, jeśli wystawiają fakturę
  (opcjonalnie, ale kiedy wystawiają — musi być przez KSeF).
* Spółek nowo zarejestrowanych po 1 kwietnia 2026 r. — od pierwszej
  faktury.

### Grupa 3 — mikroprzedsiębiorcy (od 1 stycznia 2027 r.) [#grupa-3--mikroprzedsiębiorcy-od-1-stycznia-2027-r]

Obejmuje podatników, których **sprzedaż miesięczna nie przekracza
10 000 zł**. Formalnie to nie sp. z o.o. w większości przypadków
(spółka ma zazwyczaj większe obroty), ale próg pozostaje dostępny dla
minimalnie działających podmiotów.

Od 1 stycznia 2027 r. — **zero wyjątków** na podstawie wielkości.

## Okresy przejściowe [#okresy-przejściowe]

### Grace period — brak kar do 31 grudnia 2026 r. [#grace-period--brak-kar-do-31-grudnia-2026-r]

Do końca 2026 r. MF **nie nakłada kar finansowych** za błędy formalne:

* Faktura wystawiona poza KSeF mimo obowiązku.
* Faktura wystawiona z opóźnieniem.
* Fałszywy znacznik `OFF` / `BFK`.
* Niespójny numer KSeF na fakturze papierowej / PDF.

Grace period **nie zwalnia z obowiązku** — wystawienie faktury poza
KSeF jest nielegalne, tylko nie pociąga sankcji. MF rekomenduje
traktowanie tego okresu jako fazy testowej.

### Ulga niskowartościowa — do 30 września 2026 r. [#ulga-niskowartościowa--do-30-września-2026-r]

Przez pierwsze 6 miesięcy po wejściu obowiązku dla „pozostałych
podatników" (kwiecień – wrzesień 2026) można wystawiać poza KSeF
faktury:

* Jednostkowo do <Grosze value="45000" /> brutto.
* Łącznie miesięcznie do <Grosze value="1000000" />.

Ulga jest opcjonalna — można dobrowolnie wystawiać każdą fakturę
przez KSeF od pierwszego dnia. &#x2A;*Od 1 października 2026 r.** ulga
wygasa — wszystkie faktury, nawet za 1 zł, muszą być w KSeF.

### Wygaśnięcie Profilu Zaufanego — 31 marca 2026 r. [#wygaśnięcie-profilu-zaufanego--31-marca-2026-r]

Metoda logowania przez **Profil Zaufany** była dostępna tylko do
31 marca 2026 r. Od 1 kwietnia 2026 r. pozostają:

* Kwalifikowany podpis elektroniczny.
* Kwalifikowana pieczęć elektroniczna.
* Certyfikat KSeF wydawany przez MF.

Szczegóły: [KSeF — uwierzytelnianie](/docs/zgodnosc-z-prawem/ksef/uwierzytelnianie).

## Pełna oś czasu [#pełna-oś-czasu]

```
2025-06-01  ┃  Publikacja finalnej wersji API KSeF 2.0 przez MF
2025-10-01  ┃  Udostępnienie środowiska testowego ksef-test.mf.gov.pl
2026-01-01  ┃  E-księgi rachunkowe dla podatników CIT z JPK_V7M
2026-02-01  ┃  ★ KSeF mandatory (duzi podatnicy, > 200 mln zł w 2024)
2026-02-01  ┃  JPK_V7M(3) z polem NrKSeF oraz znacznikami OFF/BFK/DI
2026-03-31  ┃  Ostatni dzień logowania do KSeF przez Profil Zaufany
2026-04-01  ┃  ★ KSeF mandatory (WSZYSCY podatnicy VAT)
2026-09-30  ┃  Koniec ulgi niskowartościowej (450 zł / 10 000 zł)
2026-10-01  ┃  Każda faktura B2B bez wyjątków musi być w KSeF
2026-12-31  ┃  Koniec grace period — od 2027 r. kary finansowe
2027-01-01  ┃  ★ KSeF mandatory (mikroprzedsiębiorcy) · start kar
2027-03-31  ┃  Pierwsza deklaracja JPK_KR_PD (za rok 2026, JPK_V7M)
```

## Jak sprawdzić, do której grupy należę [#jak-sprawdzić-do-której-grupy-należę]

1. **Sprawdź status VAT.** Podatnik VAT czynny → grupa 2 (najpóźniej
   od 1 kwietnia 2026 r.).
2. **Sprawdź próg 200 mln zł.** Suma sprzedaży z VAT w JPK\_V7M za
   12 miesięcy 2024 r. > 200 mln zł → grupa 1 (od 1 lutego 2026 r.).
3. **Sprawdź mikropróg.** Sprzedaż miesięczna \< 10 000 zł przez cały
   okres 2024 / 2025 → grupa 3 (od 1 stycznia 2027 r.).

Dla większości sp. z o.o. odpowiedź to &#x2A;*grupa 2 — od 1 kwietnia 2026 r.**

## Co musi być gotowe przed datą wdrożenia [#co-musi-być-gotowe-przed-datą-wdrożenia]

Checklist dla grupy 2 (sp. z o.o. „typowe") przed 1 kwietnia 2026 r.:

* [ ] Założone konto w KSeF (ksef.mf.gov.pl lub przez system księgowy).
* [ ] Wydany certyfikat KSeF lub kwalifikowany podpis / pieczęć dla
  osoby uprawnionej (zarząd, prokurent, pracownik z pełnomocnictwem).
* [ ] System księgowy wspiera wystawianie faktur w formacie FA(3)
  i przesyłanie do KSeF.
* [ ] Szablon PDF faktury zawiera miejsce na QR kod KSeF.
* [ ] Wewnętrzne procedury — kto wystawia, kto akceptuje, co robić przy
  awarii KSeF (tryb Offline24).
* [ ] Pracownicy przeszkoleni z nowego flow.

W Numify większość tych elementów jest gotowa out-of-the-box:
<ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>,
<ServiceRef path="src/lib/services/ksef-fa3-generator.ts">ksef-fa3-generator.ts</ServiceRef>,
<ServiceRef path="src/lib/services/ksef-qr.ts">ksef-qr.ts</ServiceRef>.
Brakuje tylko konfiguracji po stronie spółki (kredencjali KSeF).

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md`.
  </ChangeEntry>
</ChangeHistory>


---

# KSeF - odbieranie faktur zakupu
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/odbieranie
Description: Pobieranie faktur zakupowych z Krajowego Systemu e-Faktur - polling, parsowanie FA(3), auto-reconciliation z ręcznie przesłanymi dokumentami.
Review status: internal
Updated: 2026-04-16



Od kiedy KSeF jest obowiązkowy, **faktura zakupu nie trafia do spółki
przez e-mail** - dostawca wystawia fakturę w KSeF, a odbiorca
samodzielnie pobiera ją z systemu. Zmienia to proces akceptacji i
księgowania - spółka musi aktywnie sprawdzać, czy nie ma nowych faktur
zakupowych.

<ComplianceDisclaimer />

## Model doręczenia [#model-doręczenia]

```
Dostawca → [XML FA(3)] → KSeF → ⏸️ oczekuje na odbiór
                                         ↓
                     [odbiorca pobiera z KSeF]
                                         ↓
                     [księgowanie w systemie odbiorcy]
```

**Data otrzymania faktury** = data przyjęcia przez KSeF (tj. data
wystawienia przez dostawcę). Nie zależy od momentu, w którym odbiorca
fizycznie pobierze fakturę - odliczenie VAT liczy się od dnia
wystawienia (<LegalRef act="VAT" art="86" />).

Oznacza to, że **odbiorca powinien regularnie sprawdzać nowe faktury**

* zaniedbanie nie przesuwa terminu.

## Dostęp do faktur zakupu [#dostęp-do-faktur-zakupu]

Odbiorca ma trzy sposoby pobierania faktur zakupu:

### 1. Interfejs WWW `ksef.mf.gov.pl` [#1-interfejs-www-ksefmfgovpl]

Dostępny dla każdego uprawnionego użytkownika (zarząd, prokurent,
pełnomocnik). Pozwala ręcznie przeglądać, filtrować i pobierać
faktury. Dobre dla spółek z małą liczbą faktur miesięcznie.

### 2. System księgowy z integracją (rekomendowane) [#2-system-księgowy-z-integracją-rekomendowane]

System księgowy pobiera faktury przez API KSeF automatycznie - np.
co 15 minut. Nowe faktury trafiają do kolejki "do akceptacji", gdzie
użytkownik może je przejrzeć i zaksięgować.

Numify działa w tym modelu:
<ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>
zawiera metodę `syncReceivedInvoices()`, wywoływaną przez endpoint
`POST /api/ksef/sync`. Szczegóły UI — zobacz sekcję „Częstotliwość
synchronizacji” poniżej.

### 3. Pobranie zbiorcze [#3-pobranie-zbiorcze]

API KSeF pozwala pobrać zestaw faktur za wybrany okres jako ZIP z
plikami XML. Przydatne do migracji danych lub audytu.

## Flow auto-reconciliation w Numify [#flow-auto-reconciliation-w-numify]

Kiedy Numify pobierze nową fakturę z KSeF:

1. **Parsowanie FA(3)** - XML jest parsowany do struktur wewnętrznych:
   <ServiceRef path="src/lib/services/ksef-fa3-parser.ts">ksef-fa3-parser.ts</ServiceRef>.
   Wyodrębniane są: dostawca (NIP + nazwa), numer faktury, daty, pozycje,
   kwoty netto / VAT / brutto, ewentualne GTU / MPP.

2. **Weryfikacja kontrahenta** - NIP sprawdzany przeciwko rejestrowi
   kontrahentów. Jeśli kontrahent istnieje - link. Jeśli nie - nowy
   rekord z danymi z FA(3).

3. **Auto-reconciliation z ręcznie przesłanym dokumentem** - jeśli
   użytkownik wcześniej wgrał PDF tej samej faktury (zanim KSeF ją
   zsynchronizował), Numify łączy oba rekordy. Kryteria matchowania:
   * NIP dostawcy.
   * Numer faktury.
   * Data wystawienia (tolerancja ±3 dni).
   * Kwota brutto (tolerancja ±1 grosz).

4. **Proponowana dekretacja** - AI proponuje kategorię kosztu i konta
   księgowe. Użytkownik akceptuje lub koryguje.

5. **Księgowanie** - po akceptacji tworzone są:
   * Wpis w dzienniku (DR koszt / DR 221 VAT naliczony / CR 202 Rozrachunki).
   * Wpis w rejestrze VAT zakupu z polem `NrKSeF`.

## Specyfika reverse charge (import usług) [#specyfika-reverse-charge-import-usług]

Kiedy otrzymujemy fakturę od kontrahenta zagranicznego (poza KSeF),
zastosowanie mają zasady odwrotnego obciążenia
(<LegalRef act="VAT" art="28b" />). Ta faktura **nie jest w KSeF** -
dostawca zagraniczny nie ma do niego dostępu.

Numify detektuje takie faktury po:

* Braku polskiego NIP dostawcy.
* Kraju dostawcy ≠ Polska.

I tworzy dwa wpisy w rejestrze VAT: output VAT (należny, K\_29/K\_30) i
input VAT (naliczony, K\_42/K\_43) - z tą samą kwotą, zerujące się
nawzajem w JPK\_V7M.

## Częstotliwość synchronizacji [#częstotliwość-synchronizacji]

W bieżącej wersji synchronizacja jest **manualna** — uruchamiana ze
strony **KSeF** w aplikacji (`/ksef`). Użytkownik wybiera zakres dat
(domyślnie ostatnie 30 dni) i klika przycisk synchronizacji —
endpoint `POST /api/ksef/sync` wywołuje `syncReceivedInvoices()`,
która pobiera faktury zakupowe z KSeF API i zapisuje je lokalnie
ze statusem `PENDING`.

Docelowo planowane jest cykliczne zadanie w tle (BullMQ) —
np. co 15 minut w godzinach 6:00–22:00 oraz co godzinę w nocy.
Do tego czasu odpowiedzialność za regularne uruchamianie
synchronizacji spoczywa na użytkowniku.

## Akceptacja i księgowanie [#akceptacja-i-księgowanie]

Każda pobrana faktura KSeF trafia jako **dokument** do kolejki
parsowania (status `pending`, potem `processing`, końcowo `completed`).
Nie jest automatycznie księgowana — użytkownik musi ją zaakceptować
przed utworzeniem transakcji i wpisów księgowych:

* **Akceptuj** — tworzy transakcję, wpisy w dzienniku i rejestrze VAT.
* **Odrzuć** — oznacza dokument jako nieistotny (np. wysłany omyłkowo).
* **Koryguj kontrahenta / kategorię** — poprawa propozycji AI przed
  zaksięgowaniem (dekretacja).

Zaksięgowana faktura jest widoczna w rejestrze VAT oraz w JPK\_V7M za
odpowiedni okres.

Nie ma automatycznej akceptacji bez interakcji człowieka - zgodnie z
zasadą **human-in-the-loop** (zob. [Akceptacja ludzka](/docs/koncepcje/akceptacja-ludzka) - docelowo w Phase 5).

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja - zagregowana z `_legacy/KSEF-REFERENCE.md` oraz
    implementacji `ksef-service.ts` i `ksef-fa3-parser.ts` w Numify.
  </ChangeEntry>
</ChangeHistory>


---

# KSeF — wystawianie faktur
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/wystawianie
Description: Tryby wystawiania faktur przez Krajowy System e-Faktur — online real-time, Offline24, wyjątki z obowiązku KSeF.
Review status: internal
Updated: 2026-04-16



Wystawienie faktury przez KSeF polega na przesłaniu XML FA(3) do
centralnego systemu MF, który w odpowiedzi nadaje unikalny
identyfikator (`NrKSeF`). Dopiero faktura z `NrKSeF` jest prawnie
skuteczna w obrocie B2B (<LegalRef act="KSEF" />,
<LegalRef act="VAT" art="106ga" />).

<ComplianceDisclaimer />

## Dwa tryby wystawiania [#dwa-tryby-wystawiania]

### Online (real-time) — tryb domyślny [#online-real-time--tryb-domyślny]

Faktura przesyłana jest do KSeF w momencie wystawienia. System MF
odpowiada w ciągu kilku sekund:

```
Wystawca → [XML FA(3)] → KSeF API → [NrKSeF + Data przyjęcia]
```

Zgodnie z <LegalRef act="VAT" art="106na" />: **data wystawienia
faktury = data jej przesłania do KSeF**, a &#x2A;*data otrzymania przez
nabywcę = data nadania `NrKSeF`**. Dopóki KSeF nie odpowie pozytywnie,
faktura nie jest jeszcze doręczona odbiorcy (choć prawnie
wystawiona).

### Offline24 — tryb awaryjny [#offline24--tryb-awaryjny]

Jeśli KSeF jest niedostępny (awaria systemu, problem z połączeniem
internetowym), faktura może być wystawiona lokalnie z następującymi
obowiązkami:

* Faktura musi być oznaczona znacznikiem `OFF` w JPK\_V7M.
* **Musi być przesłana do KSeF w ciągu 1 dnia roboczego** od wystawienia
  (<LegalRef act="VAT" art="106nf" />).
* Data wystawienia = data lokalna, nie data wysłania do KSeF.

Szczegóły: [Tryb Offline24](/docs/zgodnosc-z-prawem/ksef/tryb-offline24).

## Typy faktur wystawianych przez KSeF [#typy-faktur-wystawianych-przez-ksef]

| Typ                              | W KSeF                                                                  |
| -------------------------------- | ----------------------------------------------------------------------- |
| Faktura VAT sprzedaży B2B        | ✅ Obowiązkowo                                                           |
| Faktura korygująca (korekta)     | ✅ Obowiązkowo                                                           |
| Faktura zaliczkowa               | ✅ Obowiązkowo                                                           |
| Faktura końcowa (po zaliczkach)  | ✅ Obowiązkowo                                                           |
| Nota korygująca (drobne korekty) | ❌ Nie jest fakturą — nie dotyczy KSeF                                   |
| Faktura pro-forma                | ❌ Nie jest fakturą — dokument wewnętrzny                                |
| Paragon fiskalny                 | ❌ Poza zakresem KSeF                                                    |
| Rachunek (podatnicy zwolnieni)   | ✅ Opcjonalnie — jeśli wystawca jest zwolniony, może wystawiać poza KSeF |

## Wyjątki od obowiązku KSeF [#wyjątki-od-obowiązku-ksef]

Zwolnienia **z obowiązku** wystawiania przez KSeF:

### B2C — faktury dla osób fizycznych [#b2c--faktury-dla-osób-fizycznych]

Faktury dla konsumentów (osób fizycznych nieprowadzących działalności
gospodarczej) mogą być wystawiane **poza KSeF** — w dowolnej formie
(PDF, papier, e-mail).

Kryterium: brak NIP nabywcy (PESEL lub brak numeru identyfikacji).

### Transgraniczne [#transgraniczne]

Faktury wystawiane kontrahentom zagranicznym bez polskiej rejestracji
VAT są zwolnione. Przykład: usługa dla klienta z Niemiec — faktura
wystawiana poza KSeF, z zastosowaniem reverse charge
(<LegalRef act="VAT" art="28b" />).

### Specyficzne usługi [#specyficzne-usługi]

Zwolnione z KSeF są m.in.:

* Bilety jednorazowe komunikacji pasażerskiej (pociąg, autobus,
  samolot).
* Opłaty autostradowe.
* Niektóre usługi bankowe i ubezpieczeniowe (gdy wystawiają je banki
  i TU — zob. <LegalRef act="KSEF" />).

### Faktury niskowartościowe (do 30 września 2026 r.) [#faktury-niskowartościowe-do-30-września-2026-r]

Tymczasowo, przez pierwsze 6 miesięcy od wprowadzenia obowiązku dla
„pozostałych podatników":

* Pojedynczo do <Grosze value="45000" /> brutto.
* Łącznie miesięcznie do <Grosze value="1000000" />.

**Po 1 października 2026 r. — bez wyjątków na podstawie kwoty.**

## Flow wystawiania w Numify [#flow-wystawiania-w-numify]

Proces od kliknięcia „Wystaw fakturę" do otrzymania `NrKSeF`:

1. Użytkownik uzupełnia dane w formularzu faktury (nabywca, pozycje,
   termin płatności).
2. Numify waliduje dane (NIP przez GUS / VIES, biała lista dla kwot
   > <Grosze value="1500000" />).
3. Generator FA(3) tworzy XML:
   <ServiceRef path="src/lib/services/ksef-fa3-generator.ts">ksef-fa3-generator.ts</ServiceRef>.
4. Numify wysyła XML do KSeF API przez zabezpieczoną sesję:
   <ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>.
5. KSeF odpowiada `NrKSeF` + data przyjęcia.
6. Numify:
   * Zapisuje `NrKSeF` na fakturze.
   * Tworzy wpis w dzienniku (DR kontrahent / CR 702 + VAT).
   * Tworzy wpis w rejestrze VAT sprzedaży.
   * Generuje PDF faktury z QR kodem KSeF (zob. [Kody QR](/docs/zgodnosc-z-prawem/ksef/kody-qr)).

W przypadku błędu KSeF (np. awaria API, niezgodny XSD) — Numify
automatycznie przełącza się w tryb Offline24, zapisuje fakturę z
flagą `OFF` i kolejkuje ponowną próbę przesłania do czasu
odzyskania łączności.

## Numer faktury a `NrKSeF` [#numer-faktury-a-nrksef]

**Numer faktury** (np. `FV/2026/04/001`) nadaje wystawca — jest to
numer z własnej sekwencji spółki, widoczny na PDF-ie i w księgach.

**`NrKSeF`** (np. `1234567890-20260416-ABCDEF12-34`) nadaje KSeF —
jest to globalny identyfikator w systemie MF.

Obie informacje są drukowane na PDF-ie faktury i zapisywane w JPK\_V7M.

## Korekty faktur KSeF [#korekty-faktur-ksef]

Faktura korygująca musi **odnosić się** do pierwotnej faktury przez
`NrKSeF`. Format:

```xml
<Fa>
  <RodzajFaktury>KOR</RodzajFaktury>
  <DaneFakturyKorygowanej>
    <NrKSeFFakturyKorygowanej>1234567890-20260401-ABCDEF12-34</NrKSeFFakturyKorygowanej>
    <DataFakturyKorygowanej>2026-04-01</DataFakturyKorygowanej>
    <NumerFakturyKorygowanej>FV/2026/04/001</NumerFakturyKorygowanej>
  </DaneFakturyKorygowanej>
  <!-- Nowe, skorygowane pozycje -->
</Fa>
```

Korekta musi być w KSeF nawet jeśli pierwotna faktura była zwolniona
(np. jako niskowartościowa) — korekta zawsze przechodzi przez KSeF.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md`.
  </ChangeEntry>
</ChangeHistory>


---

# KSeF — uwierzytelnianie
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/uwierzytelnianie
Description: Metody logowania i autoryzacji do Krajowego Systemu e-Faktur — podpis kwalifikowany, pieczęć elektroniczna, certyfikaty KSeF, wygaśnięcie Profilu Zaufanego.
Review status: internal
Updated: 2026-04-16



KSeF wymaga silnego uwierzytelnienia każdego podmiotu, który wystawia
lub odbiera faktury. Metody uwierzytelniania są wymienione w ustawie
(<LegalRef act="KSEF" />) — ta strona omawia każdą z nich oraz
praktyczne konsekwencje dla sp. z o.o.

<ComplianceDisclaimer />

## Dostępne metody [#dostępne-metody]

| Metoda                              | Dostępność              | Koszt roczny  | Typowe zastosowanie                        |
| ----------------------------------- | ----------------------- | ------------- | ------------------------------------------ |
| Kwalifikowany podpis elektroniczny  | Trwała                  | \~300–500 zł  | Osoba fizyczna (prezes, prokurent)         |
| Kwalifikowana pieczęć elektroniczna | Trwała                  | \~600–1200 zł | Spółka jako podmiot (automatyczne systemy) |
| Certyfikat KSeF                     | Trwała                  | **Bezpłatny** | Integracje systemów księgowych             |
| Profil Zaufany                      | **Do 31 marca 2026 r.** | Bezpłatny     | Tymczasowo — potem wygasa                  |

## Kwalifikowany podpis elektroniczny [#kwalifikowany-podpis-elektroniczny]

Elektroniczny podpis wystawiany osobie fizycznej przez kwalifikowanego
dostawcę (np. KIR/Szafir, Certum, EuroCert). Weryfikuje tożsamość
konkretnej osoby — np. członka zarządu lub prokurenta.

**Jak działa w KSeF:**

* Członek zarządu loguje się własnym podpisem.
* Może wystawiać faktury w imieniu spółki.
* Może nadawać pełnomocnictwa innym osobom (np. księgowej) do
  logowania w imieniu spółki.

**Wady:**

* Ważność 1–2 lata, wymaga odnowienia.
* Koszt rzędu 300–500 zł rocznie.
* Fizyczna karta z czytnikiem lub token USB.

## Kwalifikowana pieczęć elektroniczna [#kwalifikowana-pieczęć-elektroniczna]

Odpowiednik podpisu, ale nadawany **podmiotowi prawnemu** (spółce),
nie osobie fizycznej. Wystawiana na NIP spółki.

**Zalety:**

* Nie jest zawężona do konkretnego człowieka — dowolna osoba z
  dostępem do klucza prywatnego pieczęci może z niej korzystać.
* Dobra do **systemów zautomatyzowanych** — np. integracji księgowej,
  która wystawia faktury w tle.

**Wady:**

* Droższa od podpisu osobistego (600–1200 zł rocznie).
* Wymaga rygorystycznej ochrony klucza prywatnego.

## Certyfikat KSeF (rekomendowany dla integracji) [#certyfikat-ksef-rekomendowany-dla-integracji]

Certyfikat programowy wystawiany przez Ministerstwo Finansów
bezpłatnie. Wydawany po uprzednim zalogowaniu kwalifikowanym podpisem /
pieczęcią — służy jako **trwałe kredencjale do API KSeF** dla integracji
księgowych.

**Jak uzyskać:**

1. Zaloguj się na `ksef.mf.gov.pl` kwalifikowanym podpisem albo
   pieczęcią.
2. Wygeneruj wniosek o certyfikat KSeF (NIP + okres ważności).
3. Podpisz wniosek podpisem kwalifikowanym.
4. Pobierz certyfikat `.p12` — waży kilka kB.

**Zalety:**

* Bezpłatny.
* Waży mało, łatwo integrować z aplikacją.
* Nie wygasa przy wygaśnięciu osobistego podpisu członka zarządu.

**Wady:**

* Pierwsze wydanie wymaga mimo wszystko podpisu / pieczęci.
* Jest wiązany z NIP spółki — przy zmianie właściciela wymaga nowego.

## Profil Zaufany (tymczasowo, do 31 marca 2026 r.) [#profil-zaufany-tymczasowo-do-31-marca-2026-r]

Profil Zaufany (<PolishTerm pl="PZ" en="Trusted Profile">PZ</PolishTerm>)
pozwalał na logowanie do KSeF bez posiadania kwalifikowanego podpisu —
wystarczył PZ połączony z bankowością elektroniczną lub wizytą w
urzędzie.

**Od 1 kwietnia 2026 r. Profil Zaufany NIE jest już dostępny jako
metoda logowania do KSeF.** Osoby, które korzystały wyłącznie z PZ,
muszą przed tą datą:

1. Kupić kwalifikowany podpis, pieczęć lub
2. Wydać certyfikat KSeF (wymaga jednorazowego podpisu / pieczęci —
   można pożyczyć od księgowej, biura rachunkowego, kogoś z zarządu).

## Pełnomocnictwa w KSeF [#pełnomocnictwa-w-ksef]

Wewnątrz KSeF można nadawać **pełnomocnictwa** — delegowanie uprawnień
do wystawiania / odbierania faktur innej osobie lub firmie.

**Typowe scenariusze:**

* **Biuro rachunkowe** — spółka nadaje pełnomocnictwo biuru do
  wystawiania faktur w jej imieniu.
* **Pracownik** — członek zarządu nadaje pełnomocnictwo księgowej.
* **System księgowy** — spółka wydaje certyfikat KSeF dla Numify
  (lub innego systemu), który następnie działa w jej imieniu.

Pełnomocnictwo można ograniczyć do konkretnych uprawnień:

* `wystawianie` — tylko wystawianie.
* `odbieranie` — tylko pobieranie faktur zakupu.
* `zarzadzanie_uprawnieniami` — nadawanie dalszych pełnomocnictw.

## Rekomendowana konfiguracja dla sp. z o.o. [#rekomendowana-konfiguracja-dla-sp-z-oo]

Typowa sp. z o.o. powinna mieć:

1. **Certyfikat KSeF spółki** — do komunikacji API z Numify / systemem
   księgowym.
2. **Podpis kwalifikowany prezesa / prokurenta** — do jednorazowych
   akcji wymagających osobistego uwierzytelnienia (np. zmiana
   pełnomocnictw, odnawianie certyfikatu).
3. **Opcjonalnie — pełnomocnictwo dla księgowej** — jeśli księgowa ma
   dostęp do KSeF w interfejsie przeglądarkowym.

## Implementacja w Numify [#implementacja-w-numify]

Certyfikat KSeF w Numify jest przechowywany **zaszyfrowany** (AES-256-CBC)
w tabeli `ksef_credentials`. Sesja z KSeF negocjowana jest przez
challenge-response i ma krótki czas życia — implementacja w
<ServiceRef path="src/lib/services/ksef-api.ts">ksef-api.ts</ServiceRef>
oraz <ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>
(`initSession` / `getOrInitSession`).

> Rotacja kluczy: certyfikat KSeF ma własny okres ważności (ustawiany
> przy wydawaniu przez MF). Pilnowanie daty wygaśnięcia i wydania
> nowego certyfikatu leży obecnie po stronie użytkownika —
> zautomatyzowane przypomnienia są planowane w kolejnym etapie.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md` oraz
    komunikatów MF o wygaśnięciu Profilu Zaufanego jako metody logowania.
  </ChangeEntry>
</ChangeHistory>


---

# KSeF — tryb Offline24
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/tryb-offline24
Description: Wystawianie faktur gdy KSeF jest niedostępny — znaczniki OFF i BFK, obowiązek przesłania w ciągu 1 dnia roboczego, zasady i ryzyko nadużycia.
Review status: internal
Updated: 2026-04-16



**Tryb Offline24** (znacznik `OFF`) to rozwiązanie awaryjne: kiedy
KSeF jest niedostępny z przyczyn technicznych, wystawca może wystawić
fakturę lokalnie pod warunkiem, że **prześle ją do KSeF w ciągu 1 dnia
roboczego** od wystawienia (<LegalRef act="VAT" art="106nf" />).

<ComplianceDisclaimer />

## Kiedy wolno korzystać z Offline24 [#kiedy-wolno-korzystać-z-offline24]

Tryb jest **awaryjny** — wolno go użyć tylko w konkretnych sytuacjach:

1. **Awaria po stronie KSeF** — MF ogłasza przerwy w dostępie lub API
   zwraca błędy HTTP 5xx przez dłuższy czas.
2. **Problemy z łącznością internetową** po stronie wystawcy — np.
   praca na laptopie w miejscu bez zasięgu, w trasie.
3. **Awaria po stronie systemu księgowego** — np. błąd certyfikatu,
   wygaśnięcie klucza.

**Nie wolno** używać Offline24 jako zwykłego trybu pracy — to nadużycie,
za które grożą kary (po zakończeniu grace period) do 100 % kwoty VAT
na fakturze.

## Znaczniki Offline [#znaczniki-offline]

| Znacznik | Znaczenie                                                                   | Kiedy                                 |
| -------- | --------------------------------------------------------------------------- | ------------------------------------- |
| `OFF`    | Offline24 — faktura wystawiona poza KSeF z powodu awarii                    | Awaria KSeF lub łączności             |
| `BFK`    | Bez faktury KSeF — wystawiona poza KSeF z legitymowanego wyjątku            | B2C, transgraniczna, niskowartościowa |
| `DI`     | Dokument inny — nie faktura (np. dokument wewnętrzny, dokument uproszczony) | Dokumenty niebędące fakturami         |

Znaczniki trafiają do JPK\_V7M(3) w odpowiednich polach — dzięki temu
MF wie, że faktura istnieje, nawet jeśli nie ma jej jeszcze w KSeF.

## Obowiązek 1 dnia roboczego [#obowiązek-1-dnia-roboczego]

Faktura wystawiona w trybie Offline24 musi być przesłana do KSeF
**najpóźniej następnego dnia roboczego** od wystawienia.

**Przykład 1:** faktura wystawiona w poniedziałek o 14:00 — termin
przesłania do KSeF: wtorek do końca dnia.

**Przykład 2:** faktura wystawiona w piątek o 16:00 — termin
przesłania: poniedziałek do końca dnia (piątek + 1 dzień roboczy).

**Przykład 3:** faktura wystawiona w przeddzień świąt (np. piątek
przed Bożym Narodzeniem) — termin przesłania przesuwa się na
pierwszy dzień roboczy po świętach (zgodnie z regułą
<LegalRef act="OrdPod" art="12" paragraph="5" />).

Przekroczenie terminu 1 dnia roboczego traktowane jest jako brak
wystawienia przez KSeF — w skutek kara do 100 % kwoty VAT (po grace
period).

## Flow Offline24 w Numify [#flow-offline24-w-numify]

Model docelowy (częściowo zaimplementowany, częściowo planowany):

1. **Próba wystawienia online.** Numify wysyła FA(3) do KSeF API.
   Przy sukcesie — nadany `NrKSeF`, PDF z QR, koniec.
2. **Tryb Offline24 w razie awarii.** Jeśli KSeF jest niedostępny,
   faktura zapisywana jest lokalnie z flagą `OFF` na wpisie VAT
   (pole `ksefFlag` obsługiwane przez
   <ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>).
3. **Wizualizacja PDF bez QR.** Dopóki nie ma `NrKSeF`, faktura nie
   jest drukowana z kodem QR — dopiero po synchronizacji.
4. **Ponowne wysyłanie.** Po przywróceniu łączności użytkownik
   uruchamia ponowną synchronizację ze strony **KSeF** (`/ksef`).
   Po otrzymaniu `NrKSeF` flaga `OFF` zostaje na wpisie VAT (bo
   zgodnie z przepisami tak trafia do JPK\_V7M za miesiąc wystawienia),
   a PDF jest regenerowany z QR.
5. **Automatyczne wykrycie awarii i auto-retry** — **planowane**,
   obecnie nie jest zaimplementowane. Odpowiedzialność za przesyłanie
   offline spoczywa na użytkowniku — musi on uważać, żeby nie
   przekroczyć 1 dnia roboczego od wystawienia.

Zob. <ServiceRef path="src/lib/services/ksef-service.ts">ksef-service.ts</ServiceRef>
oraz <ServiceRef path="src/lib/services/ksef-api.ts">ksef-api.ts</ServiceRef>.

## Co z JPK\_V7M w miesiącu awarii [#co-z-jpk_v7m-w-miesiącu-awarii]

Faktura Offline24 trafia do JPK\_V7M(3) **za miesiąc wystawienia** — nie
za miesiąc przesłania do KSeF. Znacznik `OFF` w pliku informuje MF,
że faktura przyszła z opóźnieniem, ale data wystawienia pozostaje
pierwotna.

Jeśli `NrKSeF` zostanie nadany już po wygenerowaniu JPK\_V7M — kolejny
JPK powinien zawierać korektę z uzupełnionym polem `NrKSeF`.

## Ryzyka i nadużycia [#ryzyka-i-nadużycia]

### Fałszywe `OFF` [#fałszywe-off]

Próba uniknięcia kar przez sztuczne oznaczanie faktur jako Offline24,
mimo że KSeF działał — **jest traktowana jako oszustwo**. MF może
zweryfikować każdy `OFF` przez logi dostępności KSeF z danego okresu.

Kara po grace period: jak za fakturę wystawioną poza KSeF (do 100 %
kwoty VAT).

### Przekroczenie 1 dnia roboczego [#przekroczenie-1-dnia-roboczego]

Faktura jest prawnie skuteczna dopiero po przesłaniu do KSeF.
Przekroczenie terminu oznacza, że faktura **nie była wystawiona
przez KSeF** — ryzykujemy kwestionowanie jej przez nabywcę przy
odliczeniu VAT oraz karę po grace period.

### Rekomendacja [#rekomendacja]

Jeśli w firmie regularnie pojawiają się potrzeby Offline24
(np. praca w trasie bez internetu) — rozważ:

* Wystawianie faktur **z opóźnieniem** (po powrocie do biura) zamiast
  Offline24.
* Kartę mobilnego internetu jako backup.
* Fakturowanie zawsze w biurze zamiast w terenie.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md` oraz
    art. 106nf Ustawy o VAT.
  </ChangeEntry>
</ChangeHistory>


---

# Kody QR na fakturach KSeF
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/kody-qr
Description: Obowiązek umieszczenia kodu QR KSeF na wizualizacjach PDF faktury — format URL weryfikacji, biblioteka generowania, weryfikacja po stronie odbiorcy.
Review status: internal
Updated: 2026-04-16



Faktura ustrukturyzowana w KSeF może być dodatkowo przedstawiona w
postaci **wizualizacji PDF** — np. wysłana klientowi e-mailem dla
wygody. Taka wizualizacja **musi zawierać kod QR** umożliwiający
weryfikację faktury w KSeF (<LegalRef act="KSEF" />). To jedyny
gwarant, że PDF odpowiada wystawionej fakturze, nie jest sfabrykowany.

<ComplianceDisclaimer />

## Kiedy QR jest wymagany [#kiedy-qr-jest-wymagany]

Kod QR musi być umieszczony, jeśli wystawca udostępnia fakturę w formie
innej niż sam XML z KSeF — w praktyce:

* PDF wysłany klientowi e-mailem „dla wygody".
* Wydruk papierowy (np. do teczki księgowej, audytu).
* Faktura wyświetlana w panelu klienta / portalu samoobsługowym.

QR **nie jest potrzebny** wewnątrz samego KSeF — tam faktura jest
identyfikowana przez `NrKSeF` i nie ma postaci PDF.

## Format kodu [#format-kodu]

QR zawiera URL w następującym formacie:

```
https://ksef.mf.gov.pl/web/verify/{NrKSeF}/{Hash}
```

Gdzie:

* `{NrKSeF}` — globalny identyfikator nadany przez KSeF.
* `{Hash}` — **SHA-256 treści XML FA(3) faktury** (hex), obliczany
  z identycznego bajt-za-bajtem XML, który został przesłany do KSeF.
  Hash zapobiega podmianie PDF-a — jeżeli ktoś zmieni treść XML,
  hash się nie zgodzi i strona weryfikacyjna MF pokaże niezgodność.

### Przykład [#przykład]

* `NrKSeF`: `1234567890-20260416-ABCDEF12-34`
* Hash XML: `a3f1b...` (64 znaki hex)
* QR URL:
  `https://ksef.mf.gov.pl/web/verify/1234567890-20260416-ABCDEF12-34/a3f1b...`

Skanowanie kodu prowadzi bezpośrednio na stronę weryfikacyjną KSeF,
gdzie można zobaczyć oryginalną treść faktury oraz potwierdzenie,
że przekazany hash zgadza się z zarejestrowaną wersją XML.

## Umiejscowienie na fakturze [#umiejscowienie-na-fakturze]

Rekomendowane (nie sztywno wymagane ustawą, ale przyjęte przez MF):

* **Prawy górny róg pierwszej strony** — obok numeru faktury.
* Minimalny rozmiar: **2×2 cm** (przy standardowej rozdzielczości
  druku 300 DPI).
* Poziom korekcji błędów: minimum `M` (rekomendowane `Q`).

Numify umieszcza QR kod w prawym górnym rogu w szablonie PDF faktury.
Szczegóły generowania wizualizacji zostaną udokumentowane w sekcji
Dla deweloperów (Phase 7).

## Weryfikacja po stronie odbiorcy [#weryfikacja-po-stronie-odbiorcy]

Odbiorca faktury może zeskanować QR smartfonem — prowadzi to do
strony MF:

```
https://ksef.mf.gov.pl/web/verify/1234567890-20260416-ABCDEF12-34/a3f1b2c4...
```

(64-znakowy hash na końcu to SHA-256 treści XML FA(3)). Strona pokazuje:

* Wystawcę (NIP + nazwa).
* Nabywcę (NIP + nazwa).
* Datę wystawienia.
* Łączną kwotę netto / VAT / brutto.
* Status: `Poprawna` (przyjęta przez KSeF) lub `Anulowana` (jeśli
  faktura została skorygowana zerującą fakturą korygującą).

Dzięki temu odbiorca ma pewność, że PDF nie jest podrobiony — może
porównać dane z PDF-u z danymi na stronie MF.

## Generowanie QR w Numify [#generowanie-qr-w-numify]

Numify generuje QR lokalnie, bez zewnętrznych zależności od serwisów
online — to ważne z punktu widzenia RODO i wydajności. Implementacja:
<ServiceRef path="src/lib/services/ksef-qr.ts">ksef-qr.ts</ServiceRef>.

Flow:

1. Po wystawieniu faktury i otrzymaniu `NrKSeF` z API KSeF.
2. Numify liczy &#x2A;*SHA-256 XML-a FA(3)** używając `node:crypto`
   (dokładnie tej samej treści XML, która została wysłana do KSeF).
3. Numify buduje URL weryfikacyjny
   `https://ksef.mf.gov.pl/web/verify/{NrKSeF}/{Hash}`.
4. Koduje URL jako SVG (wektorowa reprezentacja QR).
5. Wstawia SVG do wizualizacji PDF faktury.

Biblioteka QR — własna minimalna implementacja (bez zależności od
`qrcode-generator` i podobnych) — poziom korekcji `Q`, wersja dobierana
automatycznie do długości danych.

## Testowy URL [#testowy-url]

W środowisku testowym KSeF URL ma ten sam kształt, ale używa
hosta `ksef-test.mf.gov.pl`:

```
https://ksef-test.mf.gov.pl/web/verify/{NrKSeF}/{Hash}
```

Numify wybiera środowisko na podstawie zmiennej `KSEF_ENV`
(`production` lub `test`, domyślnie `test`) — zob.
<ServiceRef path="src/lib/services/ksef-qr.ts">ksef-qr.ts</ServiceRef>,
funkcja `generateKsefQr`.

## Typowe problemy [#typowe-problemy]

### QR się nie skanuje [#qr-się-nie-skanuje]

Przyczyny:

* **Zbyt mały rozmiar** — minimum 2×2 cm na drukowanej fakturze.
* **Niski poziom korekcji błędów** — użyj `Q` lub `H` jeśli PDF jest
  kserowany / skanowany.
* **Niska rozdzielczość PDF** — generuj SVG, nie rastrowany PNG.

### QR prowadzi do błędu 404 na stronie MF [#qr-prowadzi-do-błędu-404-na-stronie-mf]

* `NrKSeF` błędnie wygenerowany (brak kontrolnej, błędny format).
* Faktura została anulowana — wtedy strona pokaże status `Anulowana`,
  ale URL działa.

### QR w trybie Offline24 [#qr-w-trybie-offline24]

W trybie Offline24 faktura ma jeszcze tymczasowy, lokalny numer —
`NrKSeF` zostanie nadany dopiero po przesłaniu do KSeF. Do tego
momentu QR powinien prowadzić do placeholder'a lub być pominięty.

Numify w Offline24 &#x2A;*nie drukuje QR do momentu nadania `NrKSeF`** —
wizualizacja PDF trafia do odbiorcy dopiero po synchronizacji z KSeF
i regeneracji dokumentu z poprawnym kodem QR.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md` oraz
    implementacji `ksef-qr.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Format FA(3) — struktura XML
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ksef/format-fa3
Description: Struktura faktury ustrukturyzowanej FA(3) — sekcje XML, wymagane pola, identyfikator KSeF, relacja z polami JPK_V7M.
Review status: internal
Updated: 2026-04-16



**FA(3)** to oficjalna, trzecia wersja schematu XML dla faktur
ustrukturyzowanych w KSeF. Każda faktura wystawiona lub odebrana przez
KSeF występuje w tym formacie. FA(3) jest rozszerzeniem dotychczasowych
wymogów <LegalRef act="VAT" art="106e" /> — zawiera wszystkie obowiązkowe
elementy faktury VAT, ale w ściśle określonej strukturze maszynowej.

<ComplianceDisclaimer />

## Kiedy stosować FA(3) [#kiedy-stosować-fa3]

* Od 1 lutego 2026 r. — duzi podatnicy.
* Od 1 kwietnia 2026 r. — wszyscy pozostali podatnicy VAT.

Poprzednie wersje schematu (FA(1), FA(2)) zostały zastąpione FA(3)
przed rozpoczęciem obowiązku. Numify generuje i parsuje wyłącznie
FA(3).

## Sekcje dokumentu [#sekcje-dokumentu]

Faktura FA(3) składa się z następujących sekcji:

| Sekcja                   | Zawartość                                            |
| ------------------------ | ---------------------------------------------------- |
| `Naglowek`               | Metadane systemu (wersja schematu, data wystawienia) |
| `Podmiot1`               | Wystawca faktury (nazwa, NIP, adres)                 |
| `Podmiot2`               | Nabywca faktury (NIP lub PESEL, adres)               |
| `Podmiot3` (opcjonalnie) | Podmiot trzeci (np. faktoring)                       |
| `Fa`                     | Dane faktury (numer, daty, waluta, kwoty)            |
| `Fa/FaWiersz[]`          | Pozycje faktury                                      |
| `Stopka`                 | Podpis / informacje dodatkowe                        |

### Wymagane pola (art. 106e ustawy o VAT) [#wymagane-pola-art-106e-ustawy-o-vat]

Każdy dokument musi spełniać wymogi <LegalRef act="VAT" art="106e" />. Każda faktura FA(3) musi zawierać (zarówno w XML, jak i w ewentualnej
wizualizacji PDF):

* Datę wystawienia.
* Kolejny numer faktury (nadany przez wystawcę).
* NIP wystawcy (i pełną nazwę).
* NIP nabywcy (lub PESEL dla osób fizycznych B2C — wtedy faktura nie
  musi być w KSeF).
* Datę dostawy / wykonania usługi (jeśli inna niż data wystawienia).
* Nazwę towaru / usługi.
* Jednostkę miary, ilość.
* Cenę jednostkową netto.
* Kwotę rabatu.
* Wartość netto, stawkę VAT, wartość VAT, wartość brutto.
* Łączne kwoty netto, VAT, brutto — zgrupowane wg stawek.
* Sumę należności.

Dodatkowo w FA(3) obowiązkowo:

* **Kod walutowy** — ISO 4217 (PLN, EUR, USD, …).
* **Kurs waluty** — jeśli waluta inna niż PLN, kurs NBP z dnia
  poprzedzającego wystawienie (<LegalRef act="UoR" art="30" />).
* **Kod GTU** — dla towarów / usług z załącznika 15 do ustawy o VAT
  (GTU\_01 — GTU\_13). Np. GTU\_12 dla usług niematerialnych.
* **Znaczniki procedur** — np. `MPP` (split payment), `TT_WNT`,
  `I_42/I_63` dla procedur celnych.
* **KodFormularza** = `FA` wersja `3`.

## Identyfikator KSeF (`NrKSeF`) [#identyfikator-ksef-nrksef]

Każda faktura przesłana do KSeF otrzymuje **globalnie unikalny
identyfikator** w formacie:

```
NNNNNNNNNN-RRRRMMDD-XXXXXXXX-YY
│          │        │        └─ suma kontrolna
│          │        └────────── losowy identyfikator wystawcy
│          └─────────────────── data wystawienia (YYYYMMDD)
└────────────────────────────── NIP wystawcy (10 cyfr)
```

Identyfikator pozostaje z fakturą do końca jej cyklu życia — jest
umieszczany w:

* Pole `KodKontrolny` w XML FA(3).
* QR kod drukowany na wizualizacji PDF (zob. [Kody QR](/docs/zgodnosc-z-prawem/ksef/kody-qr)).
* Pole `NrKSeF` w JPK\_V7M(3) — zarówno po stronie sprzedawcy, jak i
  nabywcy.
* Odniesienia w fakturach korygujących i zaliczkowych.

## Schemat XML — fragment [#schemat-xml--fragment]

```xml
<Faktura xmlns="http://crd.gov.pl/wzor/2023/06/29/12648/">
  <Naglowek>
    <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
    <WariantFormularza>3</WariantFormularza>
    <DataWytworzeniaFa>2026-04-16T12:00:00Z</DataWytworzeniaFa>
    <SystemInfo>Numify AI 1.0</SystemInfo>
  </Naglowek>
  <Podmiot1>
    <DaneIdentyfikacyjne>
      <NIP>1234567890</NIP>
      <Nazwa>PERIER sp. z o.o.</Nazwa>
    </DaneIdentyfikacyjne>
    <Adres>
      <KodKraju>PL</KodKraju>
      <AdresL1>ul. Przykładowa 1</AdresL1>
      <AdresL2>00-001 Warszawa</AdresL2>
    </Adres>
  </Podmiot1>
  <Podmiot2>
    <DaneIdentyfikacyjne>
      <NIP>9876543210</NIP>
      <Nazwa>Kontrahent sp. z o.o.</Nazwa>
    </DaneIdentyfikacyjne>
    <!-- ... adres ... -->
  </Podmiot2>
  <Fa>
    <KodWaluty>PLN</KodWaluty>
    <P_1>2026-04-16</P_1> <!-- Data wystawienia -->
    <P_2>FV/2026/04/001</P_2> <!-- Numer faktury -->
    <P_6>2026-04-15</P_6> <!-- Data dostawy -->
    <P_13_1>1000.00</P_13_1> <!-- Suma netto 23% -->
    <P_14_1>230.00</P_14_1> <!-- Suma VAT 23% -->
    <P_15>1230.00</P_15> <!-- Kwota brutto -->
    <FaWiersz>
      <NrWierszaFa>1</NrWierszaFa>
      <P_7>Usługa hostingu — kwiecień 2026</P_7>
      <P_8A>szt.</P_8A>
      <P_8B>1</P_8B>
      <P_9A>1000.00</P_9A> <!-- Cena netto -->
      <P_11>1000.00</P_11> <!-- Wartość netto -->
      <P_12>23</P_12> <!-- Stawka VAT -->
    </FaWiersz>
  </Fa>
</Faktura>
```

## Walidacja [#walidacja]

Ministerstwo Finansów udostępnia oficjalny walidator na portalu
[`ksef.mf.gov.pl`](https://ksef.mf.gov.pl/). Numify dodatkowo:

* Wykonuje walidację XSD lokalnie przed wysłaniem do KSeF.
* Sprawdza zgodność sum (wiersze ↔ agregaty).
* Waliduje numer NIP względem rejestrów (biała lista, VIES).

## Implementacja w Numify [#implementacja-w-numify]

Generator FA(3) — tworzy XML z danych faktury w bazie:
<ServiceRef path="src/lib/services/ksef-fa3-generator.ts">ksef-fa3-generator.ts</ServiceRef>.

Parser FA(3) — odczytuje otrzymane faktury i mapuje na transakcje:
<ServiceRef path="src/lib/services/ksef-fa3-parser.ts">ksef-fa3-parser.ts</ServiceRef>.

Oba oparte o oficjalny XSD FA(3) z repozytorium CRD MF. Pełne klasy
DTO są w [`src/lib/services/ksef-types.ts`](https://github.com/kacperkwapisz/numifyai/blob/master/src/lib/services/ksef-types.ts).

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 2">
    Pierwsza wersja — zagregowana z `_legacy/KSEF-REFERENCE.md`
    oraz oficjalnej dokumentacji XSD FA(3) Ministerstwa Finansów.
  </ChangeEntry>
</ChangeHistory>


---

# Sprawozdanie finansowe — przegląd
URL: https://numifyai.com/docs/zgodnosc-z-prawem/sprawozdanie-finansowe
Description: Mapa obowiązków sp. z o.o. dotyczących rocznego sprawozdania finansowego — struktura SF, kaskada terminów sporządzenia/zatwierdzenia/złożenia w KRS, podział na jednostki mikro / małe / średnie / duże.
Review status: internal
Updated: 2026-04-16



**Sprawozdanie finansowe** (dalej: SF) to dokument księgowy podsumowujący
sytuację majątkową i wynik finansowy jednostki na koniec roku
obrotowego. Dla sp. z o.o. sporządzenie, zatwierdzenie i złożenie SF
w Krajowym Rejestrze Sądowym to **bezwarunkowy obowiązek
ustawowy** — nie zależy od wielkości firmy, przychodów ani tego, czy
spółka faktycznie prowadziła działalność. Kto nie złoży SF, naraża
zarząd na grzywnę i — po dwóch nieskutecznych wezwaniach — na
postępowanie przymuszające prowadzone przez KRS.

<ComplianceDisclaimer />

## Co składa się na SF [#co-składa-się-na-sf]

Zgodnie z <LegalRef act="UoR" art="45" paragraph="2" /> minimalne SF
obejmuje trzy elementy:

1. **Bilans** (<LegalRef act="UoR" art="46" />) — zestawienie aktywów
   i pasywów na dzień bilansowy.
2. **Rachunek zysków i strat** (<LegalRef act="UoR" art="47" />) —
   przychody, koszty i wynik za rok obrotowy, w wariancie
   kalkulacyjnym albo porównawczym.
3. **Informacja dodatkowa** (<LegalRef act="UoR" art="48" />) —
   wprowadzenie (polityka rachunkowości) + dodatkowe informacje
   i objaśnienia.

Dla jednostek innych niż mikro i małe (<LegalRef act="UoR" art="45" paragraph="3" />)
SF dodatkowo obejmuje:

* **Zestawienie zmian w kapitale (funduszu) własnym**.
* **Rachunek przepływów pieniężnych**.

Typowa sp. z o.o. spełniająca progi jednostki małej sporządza SF
w zakresie **Załącznika 5** do UoR — bez zestawienia zmian
w kapitale i rachunku przepływów. Progi i szczegółowa struktura:
[Załącznik 5](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-5).

## Kaskada terminów [#kaskada-terminów]

Trzy osobne terminy obowiązują **kolejno**:

| Etap           | Termin ustawowy                | Podstawa prawna                               | Dla roku 2025 (dzień bilansowy 31.12.2025)                       |
| -------------- | ------------------------------ | --------------------------------------------- | ---------------------------------------------------------------- |
| Sporządzenie   | 3 miesiące od dnia bilansowego | <LegalRef act="UoR" art="52" paragraph="1" /> | **31 marca 2026**                                                |
| Zatwierdzenie  | 6 miesięcy od dnia bilansowego | <LegalRef act="UoR" art="53" paragraph="1" /> | **30 czerwca 2026**                                              |
| Złożenie w KRS | 15 dni od zatwierdzenia        | <LegalRef act="UoR" art="69" paragraph="1" /> | **15 lipca 2026** (w praktyce, jeśli ZW odbędzie się 30 czerwca) |

Terminy są **graniczne, nie sztywne daty**. Jeśli zgromadzenie
wspólników zatwierdza SF już w kwietniu, złożenie w KRS następuje
w maju — nie czeka się do 15 lipca. Jeśli natomiast SF nie zostanie
zatwierdzone w terminie <LegalRef act="UoR" art="53" paragraph="1" />,
<LegalRef act="UoR" art="69" paragraph="2" /> nakazuje złożyć je w KRS
w ciągu 15 dni od upływu terminu (tj. do 15 lipca), a następnie
dodatkowo w ciągu 15 dni od późniejszego zatwierdzenia.

<DeadlineBadge type="sf-krs" />

Szczegóły poszczególnych etapów: [Złożenie do KRS](/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/zlozenie-do-krs).

## Kto podpisuje SF [#kto-podpisuje-sf]

Zgodnie z <LegalRef act="UoR" art="52" paragraph="2" /> SF podpisują:

* **Osoba, której powierzono prowadzenie ksiąg rachunkowych** (np.
  biuro rachunkowe, główny księgowy). Podpis potwierdza poprawność
  księgową.
* **Kierownik jednostki** — dla sp. z o.o. oznacza to **wszystkich
  członków zarządu**, z wyłączeniem prokurentów (<LegalRef act="UoR" art="3" paragraph="1" />
  pkt 6).

Dla zarządu wieloosobowego dopuszczalne jest uproszczenie
z <LegalRef act="UoR" art="52" paragraph="2" />, ust. 2b: SF podpisuje
jedna osoba z zarządu, a pozostali składają **oświadczenia**, że SF
spełnia wymogi ustawy (lub formalnie odmawiają — z uzasadnieniem).
Oświadczenia i odmowy są częścią SF i muszą zostać złożone do KRS wraz
z sprawozdaniem.

## Forma elektroniczna — bezwarunkowa od 2018 r. [#forma-elektroniczna--bezwarunkowa-od-2018-r]

<LegalRef act="UoR" art="45" paragraph="1f" /> wymaga, aby SF było
sporządzone w postaci elektronicznej i opatrzone:

* kwalifikowanym podpisem elektronicznym, albo
* podpisem zaufanym (profil zaufany ePUAP), albo
* podpisem osobistym (e-dowód).

Dla jednostek wpisanych do rejestru przedsiębiorców KRS
(<LegalRef act="UoR" art="45" paragraph="1g" />) SF musi być sporządzone
**w strukturze logicznej i formacie udostępnianych przez Ministerstwo
Finansów** na stronie BIP urzędu. Oznacza to plik XML zgodny ze schematem
XSD publikowanym przez MF (np. dla jednostek małych:
`JednostkaMala`). Excel, PDF czy wydruk nie spełniają wymogu.

Numify generuje plik XML zgodny ze schematem MF w
<ServiceRef path="src/lib/services/e-sprawozdanie.ts">e-sprawozdanie.ts</ServiceRef>
— funkcja `generateESprawozdanieXml` składa dane z trzech modułów
(bilans, RZiS, informacja dodatkowa) w jedno sprawozdanie finansowe
zgodne ze schematem `JednostkaMala` (Załącznik 5).

## Co dokumentujemy w tej sekcji [#co-dokumentujemy-w-tej-sekcji]

<Cards>
  <Card title="Bilans — art. 46 UoR" description="Struktura bilansu, zasada aktywa = pasywa, ujęcie składników po wartości księgowej pomniejszonej o odpisy, różnice między Załącznikiem 1 a Załącznikiem 5." href="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/bilans" />

  <Card title="Rachunek zysków i strat — art. 47 UoR" description="Warianty kalkulacyjny i porównawczy, kiedy który warto stosować, struktura pozycji, uproszczenia dla jednostki małej." href="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/rzis" />

  <Card title="Informacja dodatkowa — art. 48 UoR" description="Wprowadzenie do SF (polityka rachunkowości), dodatkowe informacje i objaśnienia, uproszczony zakres dla jednostek małych." href="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/informacja-dodatkowa" />

  <Card title="Złożenie do KRS — art. 69 UoR" description="Kaskada terminów, system eKRS, co składa się wraz z SF (uchwała, sprawozdanie z działalności), sankcje za niezłożenie w terminie." href="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/zlozenie-do-krs" />
</Cards>

## Co jest poza zakresem tej sekcji [#co-jest-poza-zakresem-tej-sekcji]

* **Badanie SF przez biegłego rewidenta** (<LegalRef act="UoR" art="64" />
  — 66) — obowiązek dotyczy jednostek przekraczających progi; typowa
  sp. z o.o. nie podlega badaniu. Proces badania jest poza systemem
  Numify.
* **Skonsolidowane SF grup kapitałowych** (<LegalRef act="UoR" art="55" />
  i nast.) — Numify jest projektowany pod pojedynczą jednostkę.
* **SF w MSR/MSSF** — Numify wspiera wyłącznie polski plan kont i
  polskie zasady wyceny wg UoR.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja sekcji. Struktura oparta na aktualnym tekście UoR
    (Dz.U. 2023 poz. 120 t.j.), z uwzględnieniem nowelizacji Dz.U. 2024
    poz. 1863 zmieniającej progi jednostek (art. 3 ust. 1 pkt 1a–1d).
  </ChangeEntry>
</ChangeHistory>


---

# Złożenie sprawozdania do KRS — art. 69 UoR
URL: https://numifyai.com/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/zlozenie-do-krs
Description: Składanie sprawozdania finansowego sp. z o.o. w Krajowym Rejestrze Sądowym — kaskada terminów, system eKRS, format eSF (XML), dokumenty składane łącznie, konsekwencje niezłożenia.
Review status: internal
Updated: 2026-04-16



Złożenie SF w Krajowym Rejestrze Sądowym to **ostatni, ale
krytyczny** krok cyklu rocznego sprawozdawczego sp. z o.o. W
przeciwieństwie do sporządzenia i zatwierdzenia, które są procedurami
wewnętrznymi, złożenie w KRS jest czynnością publiczną — od momentu
wpisu SF jest jawne i powszechnie dostępne.

<ComplianceDisclaimer />

## Kaskada trzech terminów [#kaskada-trzech-terminów]

Art. 52, 53 i 69 UoR tworzą sekwencję trzech terminów — dla roku
obrotowego = rok kalendarzowy (dzień bilansowy 31 grudnia):

| Etap                                        | Termin graniczny                  | Podstawa prawna                               |
| ------------------------------------------- | --------------------------------- | --------------------------------------------- |
| Sporządzenie SF przez kierownika jednostki  | **31 marca** (3 mies. od 31.12)   | <LegalRef act="UoR" art="52" paragraph="1" /> |
| Zatwierdzenie przez Zgromadzenie Wspólników | **30 czerwca** (6 mies. od 31.12) | <LegalRef act="UoR" art="53" paragraph="1" /> |
| Złożenie w KRS                              | **15 dni od zatwierdzenia**       | <LegalRef act="UoR" art="69" paragraph="1" /> |

<DeadlineBadge type="sf-krs" />

Terminy są **graniczne**. Jeśli ZW odbywa się np. 15 kwietnia,
złożenie w KRS ma nastąpić do 30 kwietnia. Dopiero **w najpóźniejszym
realistycznym scenariuszu** (ZW 30 czerwca) złożenie przypada na
15 lipca.

### Co jeśli SF nie zostało zatwierdzone w terminie [#co-jeśli-sf-nie-zostało-zatwierdzone-w-terminie]

<LegalRef act="UoR" art="69" paragraph="2" /> przewiduje **dwa
oddzielne obowiązki**:

> Jeżeli sprawozdanie finansowe nie zostało zatwierdzone w terminie
> określonym w art. 53 ust. 1, to należy je złożyć w rejestrze
> sądowym w ciągu 15 dni po tym terminie, a także 15 dni po jego
> zatwierdzeniu wraz z dokumentami, o których mowa w ust. 1.

Oznacza to **dwa złożenia**:

1. **Pierwsze — do 15 lipca** — SF niezatwierdzone. Zawiadamia KRS
   o samym fakcie sporządzenia.
2. **Drugie — 15 dni od późniejszego zatwierdzenia** — SF
   z uchwałą Zgromadzenia Wspólników i podziałem zysku / pokryciem
   straty.

Niedopełnienie pierwszego obowiązku (złożenia niezatwierdzonego SF
w ciągu 15 dni od upływu 30 czerwca) jest samodzielną podstawą do
wszczęcia postępowania przymuszającego przez KRS.

## Co składa się do KRS wraz z SF [#co-składa-się-do-krs-wraz-z-sf]

<LegalRef act="UoR" art="69" paragraph="1" /> wymienia zestaw
dokumentów:

| Dokument                                                         | Uwagi                                                                                                                                              |
| ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Roczne sprawozdanie finansowe                                    | Bilans + RZiS + informacja dodatkowa (+ zestawienie zmian w kapitale i rachunek przepływów dla > jednostki małej)                                  |
| Sprawozdanie z badania SF                                        | Tylko jeżeli SF podlegało obowiązkowi badania przez biegłego rewidenta (art. 64 UoR)                                                               |
| Odpis uchwały Zgromadzenia Wspólników                            | O zatwierdzeniu SF i podziale zysku / pokryciu straty                                                                                              |
| Sprawozdanie z działalności jednostki                            | Dla jednostek wymienionych w <LegalRef act="UoR" art="49" paragraph="1" /> — w praktyce większych spółek; sp. z o.o. mała zwykle **nie** sporządza |
| Sprawozdanie z atestacji sprawozdawczości zrównoważonego rozwoju | Wyłącznie dla jednostek z <LegalRef act="UoR" art="63r" /> — duże jednostki                                                                        |

Dla **typowej operacyjnej sp. z o.o. spełniającej progi jednostki
małej** zestaw obowiązkowy to:

1. SF (bilans + RZiS + informacja dodatkowa) — plik XML zgodny ze
   schematem `JednostkaMala`.
2. Odpis uchwały ZW o zatwierdzeniu SF (PDF).
3. Uchwała ZW o podziale zysku lub pokryciu straty (może być jedną
   uchwałą z powyższą lub oddzielną).

## Forma elektroniczna — obowiązkowa od 2018 r. [#forma-elektroniczna--obowiązkowa-od-2018-r]

<LegalRef act="UoR" art="45" paragraph="1g" /> wymaga, aby SF
jednostek wpisanych do rejestru przedsiębiorców KRS było sporządzone
**w strukturze logicznej i formacie udostępnianych przez Ministerstwo
Finansów**. Dla jednostek małych — plik XML zgodny ze schematem
`JednostkaMala` publikowanym przez MF w BIP.

Numify generuje taki XML w
<ServiceRef path="src/lib/services/e-sprawozdanie.ts">e-sprawozdanie.ts</ServiceRef>
— funkcja `generateESprawozdanieXml` zwraca gotowy do podpisania
plik. Struktura wynikowa obejmuje sekcje `Naglowek`, `Podmiot`,
`Wprowadzenie`, `Bilans`, `RZiS`, `InformacjaDodatkowa` oraz
opcjonalnie `Podpis`.

Plik musi być podpisany przez:

* Osobę, której powierzono prowadzenie ksiąg (np. biuro rachunkowe)
  — **kwalifikowanym podpisem elektronicznym** lub **podpisem
  zaufanym** (profil zaufany ePUAP) lub **podpisem osobistym**.
* Kierownika jednostki — w przypadku sp. z o.o. wszystkich członków
  zarządu (z możliwością uproszczenia z <LegalRef act="UoR" art="52" paragraph="2" />,
  ust. 2b — jedna osoba podpisuje, pozostali składają oświadczenia).

## System eKRS — gdzie składać [#system-ekrs--gdzie-składać]

Składanie SF odbywa się przez dedykowaną platformę Ministerstwa
Sprawiedliwości — &#x2A;*Repozytorium Dokumentów Finansowych (RDF)**
dostępne pod adresem `https://ekrs.ms.gov.pl/`. Złożenie wymaga:

1. Logowania osoby uprawnionej — członka zarządu z PESEL ujawnionym
   w KRS, z podpisem kwalifikowanym lub profilem zaufanym.
2. Wskazania spółki (KRS) i roku obrotowego.
3. Załączenia podpisanego pliku XML (SF) + PDF (uchwały).
4. Zatwierdzenia — system automatycznie wystawia potwierdzenie
   złożenia i rejestruje w aktach rejestrowych spółki.

Złożenie przez RDF jest **bezpłatne** (dla spółek wpisanych do KRS).

### Numify — zakres wsparcia [#numify--zakres-wsparcia]

Numify generuje **plik XML gotowy do złożenia** wraz z dokumentami
towarzyszącymi:

* Generator XML w `e-sprawozdanie.ts` składa dane z trzech modułów
  (bilans, RZiS, informacja dodatkowa) w jedno sprawozdanie.
* Eksport PDF (podgląd) pochodzi z funkcji `renderInformacjaDodatkowaHtml`
  renderowanej przez silnik HTML-to-PDF.

**Złożenie do eKRS pozostaje w odpowiedzialności użytkownika** —
Numify nie integruje się bezpośrednio z platformą RDF; użytkownik
pobiera wygenerowany plik, podpisuje go lokalnie i wgrywa przez
panel eKRS.

## Sankcje za niezłożenie w terminie [#sankcje-za-niezłożenie-w-terminie]

Konsekwencje prawne niezłożenia SF:

| Sankcja                                                    | Podstawa prawna                               | Skala                                                                                                    |
| ---------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Postępowanie przymuszające prowadzone przez sąd rejestrowy | Ustawa o KRS (art. 24)                        | Grzywna dla członków zarządu, ponawiana do skutku                                                        |
| Odpowiedzialność karna — niezłożenie SF                    | <LegalRef act="UoR" art="79" />               | Grzywna lub kara ograniczenia wolności                                                                   |
| Wpis o zaleganiu z SF do KRS                               | Praktyka sądów rejestrowych                   | Widoczne w publicznym odpisie KRS — sygnał dla kontrahentów i banków                                     |
| Problemy z wypłatą dywidendy                               | <LegalRef act="UoR" art="53" paragraph="3" /> | Dywidenda wypłacona bez zatwierdzenia SF (przez jednostki obowiązane do badania) — nieważna z mocy prawa |

**Pragmatycznie:** brak SF w RDF jest jedną z pierwszych rzeczy,
które kontrahenci i banki sprawdzają w due diligence. Nawet gdy
żadna sankcja formalna nie została wymierzona, niezłożone SF jest
„czerwoną flagą" reputacyjną.

## Cykl rocznego zamknięcia — harmonogram praktyczny [#cykl-rocznego-zamknięcia--harmonogram-praktyczny]

| Miesiąc           | Co robimy                                                                             |
| ----------------- | ------------------------------------------------------------------------------------- |
| Styczeń–luty      | Księgowanie operacji grudniowych, różnic kursowych, rezerw, amortyzacji grudnia       |
| Luty              | Wycena na dzień bilansowy, inwentaryzacja, uzgodnienie sald z kontrahentami           |
| Marzec            | Sporządzenie SF (termin 31 marca) — bilans, RZiS, informacja dodatkowa                |
| Marzec            | Obliczenie CIT rocznego, złożenie CIT-8 (termin: 3 miesiące od końca roku = 31 marca) |
| Kwiecień–czerwiec | Zwołanie Zgromadzenia Wspólników, zatwierdzenie SF i podziału zysku                   |
| Do 15 lipca       | Złożenie SF w RDF przez eKRS — 15 dni od zatwierdzenia                                |

Moduł rocznego zamknięcia roku w Numify obsługuje
<ServiceRef path="src/lib/services/year-end-close.ts">year-end-close.ts</ServiceRef>
— przygotowuje zestawienie sald kont zespołu 7 i 4 do przeksięgowania
na konto <AccountRef code="860" name="Wynik finansowy" />, a następnie
na <AccountRef code="820" name="Rozliczenie wyniku finansowego" />
(oczekując uchwały ZW o podziale).

## Typowe błędy [#typowe-błędy]

* **Składanie SF bez uchwały** — SF musi być składane łącznie
  z odpisem uchwały o zatwierdzeniu. RDF akceptuje SF bez uchwały,
  ale to nie zwalnia z obowiązku dostarczenia uchwały w ciągu 15 dni
  od zatwierdzenia.
* **Nieprawidłowa struktura XML** — plik niezgodny ze schematem MF
  jest odrzucany przez system. Numify waliduje strukturę w
  momencie generowania.
* **Brak kwalifikowanego podpisu któregoś z członków zarządu** —
  w zarządzie wieloosobowym wszyscy członkowie muszą podpisać SF
  (chyba że zastosowano uproszczenie z art. 52 ust. 2b —
  oświadczenia pozostałych).
* **Mylenie terminu z „podatkowym" 30 czerwca** — termin
  30 czerwca to deadline na **zatwierdzenie**, nie na złożenie.
  Wiele osób błędnie składa SF w RDF 30 czerwca, choć termin
  ustawowy to do 15 lipca.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 69 UoR (Dz.U. 2023 poz. 120
    t.j.) oraz implementacji `e-sprawozdanie.ts` i `year-end-close.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Informacja dodatkowa — art. 48 UoR
URL: https://numifyai.com/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/informacja-dodatkowa
Description: Informacja dodatkowa jako trzeci składnik sprawozdania finansowego — wprowadzenie z opisem polityki rachunkowości oraz dodatkowe informacje i objaśnienia, uproszczony zakres dla jednostki małej (Załącznik 5).
Review status: internal
Updated: 2026-04-16



**Informacja dodatkowa** to trzeci (po bilansie i RZiS) obowiązkowy
składnik SF jednostki małej. W przeciwieństwie do dwóch pierwszych
nie jest to zestawienie liczbowe — to dokument narracyjny, który
**wyjaśnia i uzupełnia** cyfry z bilansu i RZiS.

Zgodnie z <LegalRef act="UoR" art="48" paragraph="1" />, informacja
dodatkowa ma zawierać „istotne dane i objaśnienia niezbędne do tego,
aby sprawozdanie finansowe odpowiadało warunkom określonym w
<LegalRef act="UoR" art="4" paragraph="1" />" — tj. aby rzetelnie
i jasno przedstawiało sytuację majątkową i finansową oraz wynik
jednostki.

<ComplianceDisclaimer />

## Dwuczęściowa struktura [#dwuczęściowa-struktura]

<LegalRef act="UoR" art="48" paragraph="1" /> dzieli informację
dodatkową na **dwie obowiązkowe części**:

### Część 1 — Wprowadzenie do sprawozdania finansowego [#część-1--wprowadzenie-do-sprawozdania-finansowego]

> opis przyjętych zasad (polityki) rachunkowości, w tym metod
> wyceny i sporządzenia sprawozdania finansowego w zakresie, w jakim
> ustawa pozostawia jednostce prawo wyboru, oraz przedstawienie
> przyczyn i skutków ich ewentualnych zmian w stosunku do roku
> poprzedzającego.

W praktyce wprowadzenie zawiera:

| Element                    | Przykład                                                                                                 |
| -------------------------- | -------------------------------------------------------------------------------------------------------- |
| Dane identyfikacyjne       | Nazwa, KRS, NIP, REGON, siedziba                                                                         |
| Forma prawna               | Sp. z o.o.                                                                                               |
| Rok obrotowy               | Data od/do (najczęściej rok kalendarzowy)                                                                |
| Zasada kontynuacji         | Deklaracja, że SF sporządzono przy założeniu kontynuacji działalności (art. 5 ust. 2 UoR)                |
| Polityka rachunkowości     | Metody amortyzacji, metoda wyceny zapasów (FIFO/średnia ważona), metoda ewidencji kosztów (zespół 4 / 5) |
| Opis systemu komputerowego | Nazwa systemu księgowego (np. „NumifyAI"), wersja, wykaz zbiorów danych                                  |

### Część 2 — Dodatkowe informacje i objaśnienia [#część-2--dodatkowe-informacje-i-objaśnienia]

<LegalRef act="UoR" art="48" paragraph="1" /> wylicza cztery
podkategorie (pkt 2 lit. a–d):

1. **Objaśnienia do pozycji bilansu, RZiS, zestawienia zmian
   w kapitale i rachunku przepływów** — np. struktura środków
   trwałych, zmiana stanu kapitału, struktura należności wg terminów
   wymagalności.
2. **Proponowany podział zysku lub pokrycie straty** — projekt uchwały
   zgromadzenia wspólników (np. „Zarząd proponuje pozostawić zysk do
   decyzji zgromadzenia wspólników"). Decyzja formalna następuje
   później, przy zatwierdzeniu SF.
3. **Podstawowe informacje dotyczące pracowników i organów jednostki**
   — średnioroczne zatrudnienie w pełnych etatach, wynagrodzenia
   członków organów (jeżeli są).
4. **Inne istotne informacje** dla zrozumienia SF — np. zdarzenia po
   dniu bilansowym (art. 54 UoR), istotne ryzyko, spory sądowe.

## Zakres dla jednostki małej — Załącznik 5 [#zakres-dla-jednostki-małej--załącznik-5]

<LegalRef act="UoR" art="48" paragraph="4" /> dopuszcza uproszczony
zakres dla jednostek małych:

> Zakres informacji dodatkowej dla jednostek małych sporządzających
> uproszczoną informację dodatkową określa załącznik nr 5 do ustawy.

Uproszczony zakres z Załącznika 5 obejmuje:

* **Wprowadzenie** (bez istotnych różnic wobec pełnej wersji —
  wymagane dane identyfikacyjne, zasady rachunkowości, kontynuacja
  działalności).
* **Dodatkowe informacje i objaśnienia** w formie krótszego zestawu
  pozycji:
  * Podział należności i zobowiązań wg okresów wymagalności
    (krótkoterminowe / długoterminowe).
  * Struktura kosztów wg rodzajów (przy wariancie kalkulacyjnym RZiS).
  * Informacje o kursach walut i pozycjach walutowych.
  * Kluczowe dane podatkowe (nota podatkowa — zestawienie wyniku
    księgowego z wynikiem podatkowym).
  * Średnioroczne zatrudnienie.
  * Zdarzenia po dniu bilansowym.

Jednostka mała może też **dobrowolnie** sporządzić pełną informację
dodatkową (z Załącznika 1) — to dopuszczalne, ale nie obowiązkowe.

## Uproszczenie dla jednostki mikro — art. 48 ust. 3 [#uproszczenie-dla-jednostki-mikro--art-48-ust-3]

<LegalRef act="UoR" art="48" paragraph="3" /> przewiduje dalej idące
uproszczenie dla **jednostki mikro** (<LegalRef act="UoR" art="3" paragraph="1" />
pkt 1a — progi 2 mln zł aktywów / 4 mln zł przychodów / 10 osób):

> Jednostka mikro może nie sporządzać informacji dodatkowej (...)
> pod warunkiem że przedstawi informacje uzupełniające do bilansu
> określone w załączniku nr 4 do ustawy.

Innymi słowy — jednostka mikro w ogóle nie musi tworzyć odrębnego
dokumentu „Informacja dodatkowa"; zamiast niej pokazuje minimalne
informacje w formie przypisu pod bilansem (nazwa spółki, zasady
wyceny, kontynuacja działalności, zatrudnienie).

**Uwaga:** typowa operacyjna sp. z o.o. szybko przekracza progi
mikro (2 mln zł aktywów, 4 mln zł przychodów — rocznie). W praktyce
uproszczenie z ust. 3 jest dostępne głównie dla spółek holdingowych,
w likwidacji lub dopiero rozpoczynających działalność.

## Jak Numify generuje informację dodatkową [#jak-numify-generuje-informację-dodatkową]

Moduł
<ServiceRef path="src/lib/services/informacja-dodatkowa.ts">informacja-dodatkowa.ts</ServiceRef>
składa dane z bazy w strukturę `InformacjaDodatkowaResult` (pola
`wprowadzenie` + `dodatkowe`). Zaimplementowane bloki danych:

| Blok                          | Źródło danych                                                                                                                                                                              |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Dane identyfikacyjne          | Tabela `companies` — nazwa, KRS, NIP, REGON, adres                                                                                                                                         |
| Polityka rachunkowości        | Wartości domyślne + pola w tabeli `companies` (np. metoda wyceny zapasów)                                                                                                                  |
| Struktura przychodów          | Salda kont zespołu 7 (<AccountRef code="700" />, <AccountRef code="701" />, <AccountRef code="750" /> itd.)                                                                                |
| Struktura kosztów             | Salda kont zespołu 4 (<AccountRef code="400" /> – <AccountRef code="409" />)                                                                                                               |
| Nota podatkowa                | Funkcja `generateCitData` w <ServiceRef path="src/lib/services/cit-data.ts">cit-data.ts</ServiceRef> — zestawienie wyniku księgowego z wynikiem podatkowym (KUP/NKUP, przychody zwolnione) |
| Aging należności i zobowiązań | Podział salda kont zespołu 2 (<AccountRef code="200" />, <AccountRef code="201" />, <AccountRef code="220" />) na krótko- i długoterminowe                                                 |
| Pozycje walutowe              | Agregacja sald w walutach obcych z tabeli `journal_lines`                                                                                                                                  |
| Zmiany w kapitale             | Salda kont zespołu 8 (<AccountRef code="801" />, <AccountRef code="820" />, <AccountRef code="840" />)                                                                                     |
| Zdarzenia po dniu bilansowym  | Wolne pole `eventsAfterBalanceSheetDate` przekazywane jako input                                                                                                                           |

Renderowanie do HTML (podgląd PDF) — funkcja
`renderInformacjaDodatkowaHtml`. Eksport do XML (część schematu
`e-Sprawozdanie`) — integracja w
<ServiceRef path="src/lib/services/e-sprawozdanie.ts">e-sprawozdanie.ts</ServiceRef>.

## Nota podatkowa — zestawienie wyniku księgowego z podatkowym [#nota-podatkowa--zestawienie-wyniku-księgowego-z-podatkowym]

Najbardziej wartościowa merytorycznie część informacji dodatkowej
dla sp. z o.o. to **nota podatkowa** — pokazuje:

| Pozycja                                        | Przykładowa wartość |
| ---------------------------------------------- | ------------------- |
| Wynik księgowy brutto (RZiS poz. I)            | 180 000,00 zł       |
| + Koszty niestanowiące KUP (NKUP)              | 15 000,00 zł        |
| − Przychody nie będące przychodami podatkowymi | 0,00 zł             |
| **= Podstawa opodatkowania**                   | **195 000,00 zł**   |
| Stawka CIT (9 % mały podatnik / 19 %)          | 9 %                 |
| **CIT należny**                                | **17 550,00 zł**    |

Nota pokazuje czytelnikowi sprawozdania, dlaczego zaliczka CIT
w ciągu roku ≠ 19 % × wynik księgowy. Numify wylicza te wartości
w <ServiceRef path="src/lib/services/cit-data.ts">cit-data.ts</ServiceRef>
na bazie oznaczeń kont jako KUP/NKUP w planie kont.

## Typowe błędy [#typowe-błędy]

* **Pominięcie deklaracji o kontynuacji działalności** — UoR wymaga
  wyraźnego stwierdzenia („SF sporządzono przy założeniu kontynuacji
  działalności"). Jeśli jednostka jest w likwidacji, wymagane jest
  wskazanie, że SF jest sporządzone wg zasad z art. 29 UoR.
* **Brak opisu polityki rachunkowości** — informacja dodatkowa to
  nie tylko tabele, ale też **opis metod**. Nawet przy stosowaniu
  domyślnych zasad wymagane jest ich wyliczenie.
* **Niezgodność z polityką rachunkowości** — jeśli polityka
  rachunkowości firmy stanowi, że stosuje się FIFO, a wprowadzenie
  opisuje metodę średniej ważonej — to poważny błąd spójności.
* **Kopiowanie wprowadzenia z poprzedniego roku bez aktualizacji** —
  np. pozostawienie starego roku obrotowego lub informacji
  o nieaktualnej siedzibie.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 48 UoR (Dz.U. 2023 poz. 120
    t.j.) i implementacji `informacja-dodatkowa.ts` + `cit-data.ts`
    dla noty podatkowej.
  </ChangeEntry>
</ChangeHistory>


---

# Bilans — art. 46 UoR
URL: https://numifyai.com/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/bilans
Description: Bilans jako składnik sprawozdania finansowego — struktura aktywów i pasywów, zasada bilansowa, wycena na dzień bilansowy, różnice między Załącznikiem 1 i 5.
Review status: internal
Updated: 2026-04-16



**Bilans** to zestawienie stanu majątkowego jednostki na dzień
bilansowy — z jednej strony aktywa (to, co jednostka ma), z drugiej
pasywa (skąd to ma, czyli źródła finansowania). Naczelna zasada:
**aktywa = pasywa** w każdym momencie.

Podstawowe przepisy reguluje <LegalRef act="UoR" art="46" />,
szczegółową strukturę określają załączniki 1, 4, 5 i 6 UoR.

<ComplianceDisclaimer />

## Zasada bilansowa i układ dwustronny [#zasada-bilansowa-i-układ-dwustronny]

<LegalRef act="UoR" art="46" paragraph="1" /> nakazuje:

> W bilansie wykazuje się stany aktywów i pasywów na dzień kończący
> bieżący i poprzedni rok obrotowy.

Kluczowe elementy tego przepisu:

* **Dwie kolumny** — każdy bilans prezentuje wartości **na koniec
  bieżącego roku** i **na koniec roku poprzedniego**, co umożliwia
  szybką analizę zmian.
* **Suma aktywów = suma pasywów** — to nie formuła matematyczna, tylko
  odbicie podwójnego zapisu: każde zdarzenie gospodarcze ma w księgach
  dwie strony (Dt i Ct), więc suma sald debetowych = suma sald
  kredytowych.

Numify weryfikuje zachowanie tej równości przy generowaniu bilansu.
Funkcja `generateBalanceSheet` w
<ServiceRef path="src/lib/services/balance-sheet.ts">balance-sheet.ts</ServiceRef>
zwraca pole `isBalanced` oraz wartości `totalAssets` i
`totalLiabilities`. Jeśli `isBalanced === false`, oznacza to błąd
w ewidencji (niezbilansowany zapis, brak księgowania przeciwstawnej
strony) — SF w takiej postaci nie może być złożone.

## Wycena składników aktywów [#wycena-składników-aktywów]

<LegalRef act="UoR" art="46" paragraph="2" /> określa, że w aktywach
bilansu wartość poszczególnych składników aktywów wynika z **ich
wartości księgowej**, skorygowanej o:

1. Odpisy amortyzacyjne i umorzeniowe, w tym z tytułu trwałej utraty
   wartości aktywów trwałych.
2. Odpisy aktualizujące wartość rzeczowych składników aktywów
   obrotowych (np. przecena zapasów).
3. Odpisy aktualizujące wartość należności (np. od kontrahentów
   z ujawnioną niewypłacalnością).

Oznacza to, że np. środek trwały o wartości początkowej 100 000 zł
z umorzeniem 40 000 zł pokazuje się w bilansie **netto**, tj. jako
60 000 zł — a nie jako dwie linie (brutto + odpis). W planie kont
konto <AccountRef code="010" name="Środki trwałe" /> i
<AccountRef code="070" name="Umorzenie środków trwałych" /> kompensują
się w sumie bilansowej, ale pozostają odrębnymi saldami w księdze
głównej.

## Kompensata aktywów i zobowiązań — kiedy dopuszczalna [#kompensata-aktywów-i-zobowiązań--kiedy-dopuszczalna]

<LegalRef act="UoR" art="46" paragraph="2a" /> ogranicza kompensatę
w bilansie:

> Aktywa finansowe i zobowiązania finansowe wykazuje się w bilansie
> w kwocie netto po kompensacie, jeżeli jednostka ma bezwarunkowe
> prawo do kompensaty aktywów i zobowiązań danego rodzaju i zamierza
> je rozliczyć w kwocie netto albo jednocześnie wydać składnik
> aktywów finansowych i rozliczyć zobowiązanie finansowe.

W praktyce sp. z o.o. — kompensata w bilansie dopuszczalna bardzo
wąsko (np. rozrachunki z tym samym kontrahentem dłużnikiem
i wierzycielem, przy formalnej umowie kompensacyjnej). **Nie wolno**
kompensować należności od klienta A z zobowiązaniem wobec klienta B,
nawet jeśli saldo grupy 200 jest ujemne netto.

## Struktura bilansu — art. 46 ust. 5 [#struktura-bilansu--art-46-ust-5]

Struktura zależy od typu jednostki (<LegalRef act="UoR" art="46" paragraph="5" />):

| pkt | Dotyczy                                                      | Załącznik               |
| --- | ------------------------------------------------------------ | ----------------------- |
| 1   | Jednostki inne niż banki, zakłady ubezpieczeń i reasekuracji | **Załącznik 1** (pełny) |
| 2   | Banki                                                        | Załącznik 2             |
| 3   | Zakłady ubezpieczeń i reasekuracji                           | Załącznik 3             |
| 4   | Jednostki mikro — uproszczony bilans                         | Załącznik 4             |
| 5   | Jednostki małe — uproszczony bilans                          | **Załącznik 5**         |
| 6   | NGO (poza spółkami kapitałowymi)                             | Załącznik 6             |

Typowa sp. z o.o.:

* Jeśli **nie spełnia progów jednostki małej** — stosuje Załącznik 1.
* Jeśli **spełnia progi** (<LegalRef act="UoR" art="3" paragraph="1" />
  pkt 1b — 33 mln zł aktywów / 66 mln zł przychodów / 50 osób, dwa z trzech)
  — może wybrać Załącznik 5. Wybór podejmuje kierownik jednostki
  w polityce rachunkowości.

## Układ aktywów i pasywów — Załącznik 1 [#układ-aktywów-i-pasywów--załącznik-1]

Pełny bilans wg Załącznika 1 dzieli aktywa na cztery główne grupy:

| Pozycja | Nazwa                                | Przykładowe konta                                                                                          |
| ------- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| A       | Aktywa trwałe                        | <AccountRef code="010" />, <AccountRef code="020" />, <AccountRef code="030" />                            |
| B       | Aktywa obrotowe                      | <AccountRef code="310" />, <AccountRef code="330" />, <AccountRef code="200" />, <AccountRef code="130" /> |
| C       | Należne wpłaty na kapitał podstawowy | —                                                                                                          |
| D       | Udziały (akcje) własne               | —                                                                                                          |

Pasywa dzielą się na:

| Pozycja | Nazwa                                  | Przykładowe konta                                                               |
| ------- | -------------------------------------- | ------------------------------------------------------------------------------- |
| A       | Kapitał (fundusz) własny               | <AccountRef code="801" />, <AccountRef code="820" />, <AccountRef code="860" /> |
| B       | Zobowiązania i rezerwy na zobowiązania | <AccountRef code="220" />, <AccountRef code="229" />, <AccountRef code="230" /> |

## Układ w Załączniku 5 — uproszczony [#układ-w-załączniku-5--uproszczony]

Załącznik 5 (jednostki małe) stosuje tę samą ogólną strukturę, ale
**płyciej rozgałęzioną** — np. aktywa trwałe A są prezentowane jako
cztery pozycje łączne (wartości niematerialne, rzeczowe aktywa trwałe,
należności długoterminowe, inwestycje długoterminowe) zamiast
rozbicia na poziomie cyfry rzymskiej + litery + cyfry.

Numify mapuje konta planu kont na pozycje Załącznika 1 i Załącznika 5
przez pole `balanceSheetTag` w tabeli `chart_accounts`. Wartości tagów
(np. `AKT_A_II` = rzeczowe aktywa trwałe) pochodzą z
<ServiceRef path="src/db/seed-accounts.ts">seed-accounts.ts</ServiceRef>.

## Wycena na dzień bilansowy [#wycena-na-dzień-bilansowy]

Osobne zagadnienie — **wycena aktywów i pasywów na dzień bilansowy** —
reguluje rozdział 4 UoR (art. 28–44). Dla sp. z o.o. najważniejsze:

* Waluty obce (<LegalRef act="UoR" art="30" paragraph="1" />) —
  wycena po kursie NBP z dnia bilansowego; różnice kursowe jako
  przychody / koszty finansowe. Szczegóły: [Art. 30 — kursy walut](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut).
* Środki trwałe — wycena netto (po odpisach amortyzacyjnych i
  aktualizujących).
* Należności — wycena w kwocie wymaganej zapłaty z zachowaniem zasady
  ostrożności (odpisy aktualizujące dla wątpliwych).
* Zapasy — cena nabycia / wytworzenia, ale nie wyższa niż cena
  możliwa do uzyskania.

## Zasada ciągłości — bilans otwarcia = bilans zamknięcia [#zasada-ciągłości--bilans-otwarcia--bilans-zamknięcia]

Bilans otwarcia (BO) kolejnego roku obrotowego musi być identyczny
z bilansem zamknięcia (BZ) roku poprzedniego. To zasada ciągłości
bilansowej (<LegalRef act="UoR" art="5" paragraph="1" />) i fundament
porównywalności sprawozdań.

W Numify obsługuje to moduł
<ServiceRef path="src/lib/services/opening-balance.ts">opening-balance.ts</ServiceRef>
— po zamknięciu roku funkcja `createOpeningBalance` przenosi salda
kont bilansowych do księgi nowego okresu.

## Typowe błędy [#typowe-błędy]

* **Brak kompensaty kosztów i umorzeń** — np. wykazywanie środka trwałego
  w wartości brutto bez pomniejszenia o umorzenie. Narusza
  <LegalRef act="UoR" art="46" paragraph="2" />.
* **Niezbilansowane sprawozdanie** — najczęściej efekt zapisów
  księgowych po jednej stronie (np. storno bez przeciwwpisu). Numify
  odrzuca takie zapisy już w momencie zatwierdzania — ale jeśli
  wcześniejsze zapisy były niezgodne, trzeba je wykryć przed SF.
* **Kompensata niespełniająca warunków** — wykazywanie należności
  z klientem A i zobowiązania wobec tego samego klienta A w bilansie
  netto, gdy nie ma bezwarunkowego prawa do kompensaty.
* **Brak porównywalnego roku** — bilans bez kolumny roku
  poprzedzającego. Dla pierwszego roku działalności kolumna
  porównawcza pozostaje pusta (zapis `-`), co jest dopuszczalne.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na aktualnym tekście art. 46 UoR
    (Dz.U. 2023 poz. 120 t.j.) oraz implementacji `balance-sheet.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Rachunek zysków i strat — art. 47 UoR
URL: https://numifyai.com/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/rzis
Description: RZiS jako składnik sprawozdania finansowego — warianty kalkulacyjny i porównawczy, struktura pozycji A–L, wybór wariantu w polityce rachunkowości, uproszczenia dla jednostki małej.
Review status: internal
Updated: 2026-04-16



**Rachunek zysków i strat** (dalej: RZiS) to drugi obowiązkowy
składnik SF — pokazuje, **jak** jednostka osiągnęła wynik finansowy
za rok obrotowy, zestawiając przychody, koszty, zyski i straty oraz
obowiązkowe obciążenia wyniku. Zasadę ogólną określa
<LegalRef act="UoR" art="47" paragraph="1" />, strukturę — Załącznik 1
(pełny) lub Załącznik 5 (jednostki małe).

<ComplianceDisclaimer />

## Zakres RZiS — art. 47 ust. 1 [#zakres-rzis--art-47-ust-1]

> W rachunku zysków i strat wykazuje się oddzielnie przychody,
> koszty, zyski i straty oraz obowiązkowe obciążenia wyniku
> finansowego za bieżący i poprzedni rok obrotowy.

Cztery kategorie — nie tylko przychody i koszty:

| Kategoria              | Co obejmuje                                               | UoR                                                 |
| ---------------------- | --------------------------------------------------------- | --------------------------------------------------- |
| Przychody              | Przychody ze sprzedaży + pozostałe operacyjne + finansowe | <LegalRef act="UoR" art="3" paragraph="1" /> pkt 30 |
| Koszty                 | Koszty operacyjne + pozostałe operacyjne + finansowe      | <LegalRef act="UoR" art="3" paragraph="1" /> pkt 31 |
| Zyski i straty         | Z tytułu zbycia aktywów trwałych, zdarzenia losowe itp.   | <LegalRef act="UoR" art="3" paragraph="1" /> pkt 32 |
| Obowiązkowe obciążenia | Podatek dochodowy, inne obowiązkowe pomniejszenia         | <LegalRef act="UoR" art="47" paragraph="1" />       |

Tak jak w bilansie — wymagane są **dwie kolumny**: bieżący rok
obrotowy i rok poprzedni (dla pierwszego roku działalności kolumna
poprzedniego roku pozostaje pusta).

## Wybór wariantu — kalkulacyjny albo porównawczy [#wybór-wariantu--kalkulacyjny-albo-porównawczy]

<LegalRef act="UoR" art="47" paragraph="4" /> daje kierownikowi
jednostki **wybór** między dwoma wariantami:

> (...) w wariancie kalkulacyjnym albo porównawczym, zależnie od
> wyboru dokonanego przez kierownika jednostki.

Wybór jest elementem **polityki rachunkowości** — raz dokonany,
stosuje się go w kolejnych latach (zasada ciągłości). Zmiana wariantu
wymaga uzasadnienia i ujawnienia w informacji dodatkowej.

### Wariant porównawczy [#wariant-porównawczy]

Opiera się na **kosztach według rodzajów** (zespół 4 planu kont).
Przychody ze sprzedaży są korygowane o zmianę stanu produktów
i koszt wytworzenia produktów na własne potrzeby jednostki.

**Stosuje się gdy:** ewidencja kosztów jest prowadzona wyłącznie
w zespole 4 (<AccountRef code="400" />, <AccountRef code="401" />,
<AccountRef code="402" />, <AccountRef code="404" /> itd.) — typowe
dla usługowej sp. z o.o., gdzie nie ma ewidencji wyrobów gotowych
ani magazynu.

### Wariant kalkulacyjny [#wariant-kalkulacyjny]

Opiera się na **kosztach wg miejsc i rodzajów działalności** (zespół
5 — produkcja, sprzedaż, zarząd). Przychody ze sprzedaży są
zestawiane z kosztem własnym sprzedaży **bez** korekt o zmianę stanu
produktów.

**Stosuje się gdy:** jednostka prowadzi ewidencję kosztów w zespole
5 lub równolegle w 4 i 5 — typowe dla jednostek produkcyjnych
i handlowych z magazynem wyrobów gotowych.

### Który wybrać [#który-wybrać]

| Typ działalności                     | Zalecany wariant | Powód                                                   |
| ------------------------------------ | ---------------- | ------------------------------------------------------- |
| Usługowa sp. z o.o. (konsulting, IT) | **Porównawczy**  | Brak wyrobów gotowych, koszty liczone tylko w zespole 4 |
| Handlowa                             | Dowolny          | Zależy od potrzeb raportowania wewnętrznego             |
| Produkcyjna z magazynem              | **Kalkulacyjny** | Pokazuje koszt wytworzenia produktów sprzedanych osobno |

Numify implementuje wariant porównawczy — zobacz funkcję
`generateProfitLoss` w
<ServiceRef path="src/lib/services/profit-loss.ts">profit-loss.ts</ServiceRef>.
Struktura wynikowa wiernie odzwierciedla pozycje A–L Załącznika 1.

## Struktura pozycji — wariant porównawczy [#struktura-pozycji--wariant-porównawczy]

| Poz.  | Nazwa                                                    | Konta źródłowe (przykład)                                                                                  |
| ----- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| A     | Przychody netto ze sprzedaży i zrównane z nimi           | <AccountRef code="700" />, <AccountRef code="701" />, <AccountRef code="702" />, <AccountRef code="711" /> |
| B     | Koszty działalności operacyjnej                          | zespół 4 (<AccountRef code="400" /> – <AccountRef code="409" />) + wartość sprzedanych towarów             |
| **C** | **Zysk (strata) ze sprzedaży** (A − B)                   | — (wynik pośredni)                                                                                         |
| D     | Pozostałe przychody operacyjne                           | <AccountRef code="760" />, <AccountRef code="761" />                                                       |
| E     | Pozostałe koszty operacyjne                              | <AccountRef code="765" />, <AccountRef code="770" />, <AccountRef code="771" />                            |
| **F** | **Zysk (strata) z działalności operacyjnej** (C + D − E) | —                                                                                                          |
| G     | Przychody finansowe                                      | <AccountRef code="750" />, <AccountRef code="751" />                                                       |
| H     | Koszty finansowe                                         | <AccountRef code="755" />                                                                                  |
| **I** | **Zysk (strata) brutto** (F + G − H)                     | —                                                                                                          |
| J     | Podatek dochodowy                                        | <AccountRef code="870" />                                                                                  |
| K     | Pozostałe obowiązkowe zmniejszenia zysku                 | rzadko stosowane                                                                                           |
| **L** | **Zysk (strata) netto** (I − J − K)                      | <AccountRef code="860" /> (wynik finansowy)                                                                |

Pogrubione pozycje (C, F, I, L) są **wynikami pośrednimi** — wyliczane
na podstawie wcześniejszych pozycji, nie z kont bezpośrednio.

## Wariant dla jednostek małych — Załącznik 5 [#wariant-dla-jednostek-małych--załącznik-5]

Jednostka mała (<LegalRef act="UoR" art="3" paragraph="1" /> pkt 1b)
sporządza uproszczony RZiS wg Załącznika 5. Struktura ma również
podział A–L, ale szereg pozycji jest zagregowany:

* Przychody operacyjne są zbierane w mniejszej liczbie pozycji.
* Koszty operacyjne nie są rozbijane na amortyzację / materiały /
  usługi obce z taką szczegółowością jak w Załączniku 1.
* Pozycje „nadzwyczajne" (zyski/straty z wypadków losowych) zostały
  zniesione przez nowelizację z 2016 r. — obecnie klasyfikowane jako
  pozostałe przychody/koszty operacyjne (D/E).

Kierownik jednostki małej może wybrać wariant kalkulacyjny albo
porównawczy (<LegalRef act="UoR" art="47" paragraph="4" /> pkt 5).

## Zaprzestanie działalności — ust. 3 [#zaprzestanie-działalności--ust-3]

<LegalRef act="UoR" art="47" paragraph="3" /> wymaga wyodrębnienia
przychodów i kosztów działalności, której zaprzestania jednostka
przewiduje:

> W przypadku gdy jednostka przewiduje zaprzestanie określonego
> zakresu działalności (...) odpowiednie przychody i koszty z tym
> związane należy wykazać odrębnie od przychodów i kosztów
> działalności kontynuowanej.

Przykład — sp. z o.o. zdecydowała o likwidacji oddziału zajmującego
się sprzedażą hurtową. Przychody i koszty tego oddziału za rok
bilansowy muszą w RZiS być pokazane oddzielnie, aby czytelnik
sprawozdania mógł ocenić trwałą zdolność jednostki do generowania
wyniku.

## Typowe błędy [#typowe-błędy]

* **Zmiana wariantu RZiS bez uzasadnienia** — narusza zasadę
  ciągłości i wymaga ujawnienia w informacji dodatkowej.
* **Mieszanie pozycji „pozostałych operacyjnych" z finansowymi** —
  np. umieszczanie odsetek od należności w pozycji D/E zamiast G.
  Odsetki są **zawsze** finansowe, niezależnie od źródła.
* **Pomijanie zmiany stanu produktów przy wariancie porównawczym** —
  jeśli jednostka ma magazyn wyrobów gotowych, pozycja A musi
  uwzględniać zmianę stanu, inaczej wynik będzie zniekształcony.
* **Brak pozycji podatku** — nawet gdy jednostka wykazuje stratę,
  pozycja J (podatek dochodowy) musi istnieć (z wartością 0). Jej
  brak oznacza, że RZiS jest niepełny.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 47 UoR (Dz.U. 2023 poz. 120
    t.j.) i implementacji wariantu porównawczego w `profit-loss.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Ustawa o CIT — przegląd
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit
Description: Mapa najważniejszych przepisów Ustawy o podatku dochodowym od osób prawnych z 15 lutego 1992 r. dla spółki z o.o. — stawki 9/19 %, zaliczki, CIT-8, KUP/NKUP, ulga B+R, IP BOX oraz obowiązek przekazywania ksiąg w strukturze JPK_KR_PD i JPK_ST_KR.
Review status: internal
Updated: 2026-04-16



**Ustawa o podatku dochodowym od osób prawnych** (dalej: ustawa o CIT)
z 15 lutego 1992 r. reguluje opodatkowanie dochodów spółek i innych
osób prawnych. Dla sp. z o.o. jest to obok UoR i VAT trzeci
fundamentalny akt — określa dochód podatkowy, zaliczki w ciągu roku,
zeznanie roczne CIT-8, a od 2026 r. dodatkowo obowiązek przekazywania
**ksiąg rachunkowych w strukturze JPK**.

<ComplianceDisclaimer />

## Zakres podmiotowy — art. 1 [#zakres-podmiotowy--art-1]

<LegalRef act="CIT" art="1" paragraph="1" /> obejmuje **osoby prawne**
i spółki kapitałowe w organizacji. <LegalRef act="CIT" art="1" paragraph="3" />
rozszerza zakres m.in. na spółki komandytowe i komandytowo-akcyjne
mające siedzibę w Polsce, a także spółki jawne — w określonych
przypadkach.

**Sp. z o.o. jest bezwarunkowym podatnikiem CIT od dnia wpisu do KRS.**
Nie ma progu przychodów ani wyłączeń.

## Struktura ustawy [#struktura-ustawy]

Ustawa dzieli się na 9 rozdziałów:

| Rozdział | Zakres                                    | Kluczowe artykuły |
| -------- | ----------------------------------------- | ----------------- |
| 1        | Podmiot i przedmiot opodatkowania         | 1–9a              |
| 2        | Przychody                                 | 10–14a            |
| 3        | Koszty uzyskania przychodów               | 15–16m            |
| 4        | Zwolnienia przedmiotowe                   | 17                |
| 5        | Podstawa opodatkowania i wysokość podatku | 18–24m            |
| 6        | Pobór podatku                             | 25–28t            |
| 7        | Przepisy przejściowe i końcowe            | 29–42b            |
| 8        | Zmiany w przepisach obowiązujących        | 43–44             |
| 9        | Przepisy końcowe                          | 45                |

Ta sekcja dokumentacji obejmuje artykuł-po-artykule te przepisy,
które realizują się w codziennej pracy sp. z o.o. — zawsze z
odniesieniem do kodu Numify, gdzie taka realizacja istnieje.

## Co dokumentujemy w tej sekcji [#co-dokumentujemy-w-tej-sekcji]

<Cards>
  <Card title="Stawki CIT — art. 19" description="Dwie stawki w praktyce — 19 % podstawowa i 9 % dla małych podatników. Rozróżnienie dwóch progów 2 mln EUR (art. 19 ust. 1 pkt 2 vs art. 4a pkt 10), wyłączenia dla spółek przekształconych." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/stawki" />

  <Card title="Zaliczki na CIT — art. 25" description="Zaliczki miesięczne i kwartalne, forma uproszczona (1/12 zeszłorocznego podatku), termin do 20. dnia następnego miesiąca, próg 1 000 zł, wchłonięcie przez CIT-8." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/zaliczki" />

  <Card title="KUP i NKUP — art. 15 i 16" description="Definicja kosztów uzyskania przychodu i katalog wyłączeń (70+ pozycji) — reprezentacja, kary, odsetki od zaległości, PFRON, limity samochodów 225/150/100 tys. zł." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup" />

  <Card title="Roczne zeznanie CIT-8 — art. 27" description="Termin do końca 3. miesiąca następnego roku (31 marca), forma wyłącznie elektroniczna, załączniki (CIT/BR, CIT/IP, CIT-ST), przekazanie sprawozdania finansowego do KAS." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8" />

  <Card title="Ulga B+R — art. 18d" description="Dodatkowe odliczenie kosztów kwalifikowanych — 200 % dla wynagrodzeń pracowniczych, 100 % dla pozostałych. Wymóg odrębnej ewidencji (art. 9 ust. 1b), załącznik CIT/BR, pomniejszanie zaliczek PIT-4." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/ulga-br" />

  <Card title="IP BOX — art. 24d" description="Preferencyjna stawka 5 % dla kwalifikowanego dochodu z praw własności intelektualnej (najczęściej autorskie prawo do programu). Wskaźnik nexus, ewidencja odrębna (art. 24e), wymaga doradcy podatkowego." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/ip-box" />

  <Card title="JPK_KR_PD — art. 9 ust. 1c" description="Obowiązkowe przekazywanie ksiąg rachunkowych w strukturze JPK wraz ze znacznikami podatkowymi. Pierwsza deklaracja za FY 2026 dla typowej sp. z o.o. (do 31 marca 2027)." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd" />

  <Card title="JPK_ST_KR — środki trwałe" description="Druga struktura wprowadzona Rozp. MF z 16.08.2024 — ewidencja środków trwałych (wartość, amortyzacja, status). Składana łącznie z JPK_KR_PD." href="/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-st-kr" />
</Cards>

## Kalendarz obowiązków CIT [#kalendarz-obowiązków-cit]

| Obowiązek                       | Termin                                   | Podstawa                                       |
| ------------------------------- | ---------------------------------------- | ---------------------------------------------- |
| Zaliczki miesięczne / kwartalne | do 20. dnia następnego miesiąca/kwartału | <LegalRef act="CIT" art="25" paragraph="1a" /> |
| CIT-8 + zapłata różnicy         | do końca 3. miesiąca następnego roku     | <LegalRef act="CIT" art="27" paragraph="1" />  |
| JPK\_KR\_PD + JPK\_ST\_KR       | do końca 3. miesiąca (w terminie CIT-8)  | <LegalRef act="CIT" art="9" paragraph="1c" />  |
| Sprawozdanie finansowe do KAS   | 15 dni od zatwierdzenia przez ZW         | <LegalRef act="CIT" art="27" paragraph="2" />  |

Pełna lista terminów: [Kalendarz terminów](/docs/zgodnosc-z-prawem/kalendarz-terminow).

## Terminologia [#terminologia]

| Polski termin                                                                            | Angielski odpowiednik      | Uwaga                            |
| ---------------------------------------------------------------------------------------- | -------------------------- | -------------------------------- |
| <PolishTerm pl="Podatek dochodowy od osób prawnych" en="Corporate income tax" />         | Corporate income tax (CIT) | Ustawowy skrót                   |
| <PolishTerm pl="Koszt uzyskania przychodu" en="Tax-deductible cost" />                   | Tax-deductible expense     | W skrócie KUP                    |
| <PolishTerm pl="Niestanowiący kosztu uzyskania przychodu" en="Non-deductible expense" /> | Non-deductible expense     | W skrócie NKUP                   |
| <PolishTerm pl="Mały podatnik" en="Small taxpayer" />                                    | Small taxpayer             | Art. 4a pkt 10                   |
| <PolishTerm pl="Dochód podatkowy" en="Taxable income" />                                 | Taxable income             | Przychód − KUP, po korekcie NKUP |
| <PolishTerm pl="Zaliczka na podatek" en="Tax advance" />                                 | Tax advance                | Art. 25                          |
| <PolishTerm pl="Koszty kwalifikowane" en="Qualified R&D costs" />                        | Qualified R\&D costs       | Ulga B+R, art. 18d               |

## Co nie jest w zakresie tej sekcji [#co-nie-jest-w-zakresie-tej-sekcji]

* **Estoński CIT** (ryczałt od dochodów spółek — art. 28j–28t) —
  alternatywna forma, niewspierana przez Numify.
* **Minimalny podatek CIT** (art. 24ca) — obowiązuje firmy
  ponoszące stratę; nie implementowany w Numify.
* **Podatek od przychodów z budynków** (art. 24b) — dotyczy firm
  nieruchomościowych.
* **Ceny transferowe** (art. 11–11v) — dokumentacja cen transferowych
  to odrębny obszar compliance.
* **Podatkowe grupy kapitałowe** (art. 1a) — Numify obsługuje
  pojedynczą spółkę, nie grupę.
* **Podatek u źródła** (art. 21, 22, 26) — rozliczenia z
  nierezydentami; poza zakresem podstawowej dokumentacji.

## Źródło tekstu ustawy [#źródło-tekstu-ustawy]

Tekst jednolity obowiązuje na podstawie **Dz.U. 2025 poz. 278**
(obwieszczenie Marszałka Sejmu z 5 lutego 2025 r.), z późniejszymi
zmianami — kluczowe nowelizacje wchodzące w życie 1 stycznia 2026 r.:
Dz.U. 2025 poz. 1022, 1657, 1658, 1817. Cytowania w tej sekcji
odsyłają do [ISAP — karta aktu](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20250000278)
przez komponent `<LegalRef>`.

Rozporządzenie wykonawcze do art. 9 ust. 5 CIT (struktury
JPK\_KR\_PD, JPK\_ST\_KR): Rozp. MF z 16.08.2024 (Dz.U. 2024 poz. 1314),
znowelizowane Rozp. MF z 15.12.2025 (Dz.U. 2025 poz. 1828,
obowiązuje od 1.01.2026).

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja sekcji artykuł-po-artykule. Struktura oparta na
    aktualnym tekście jednolitym ustawy o CIT (Dz.U. 2025 poz. 278).
    Uwzględnia nowelizacje wchodzące w życie 1 stycznia 2026 r. oraz
    rozporządzenie JPK\_KR\_PD (Dz.U. 2024 poz. 1314 + Dz.U. 2025 poz. 1828).
  </ChangeEntry>
</ChangeHistory>


---

# IP BOX - art. 24d i 24e
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/ip-box
Description: Preferencyjna stawka 5 % CIT od kwalifikowanego dochodu z praw własności intelektualnej - patenty, autorskie prawo do programu komputerowego, wzory użytkowe. Wskaźnik nexus, obowiązek odrębnej ewidencji (art. 24e), połączenie z ulgą B+R (art. 24d ust. 9a).
Review status: internal
Updated: 2026-04-16



**IP BOX** (właściwe: opodatkowanie dochodu z kwalifikowanych praw
własności intelektualnej) to preferencja podatkowa polegająca na
opodatkowaniu **kwalifikowanego dochodu** stawką &#x2A;*5 %** - zamiast
9 % lub 19 %. Jest skierowana do podatników, którzy wytworzyli,
rozwinęli lub ulepszyli kwalifikowane IP w ramach własnej
działalności **badawczo-rozwojowej**.

<ComplianceDisclaimer />

## Stawka - art. 24d ust. 1 [#stawka---art-24d-ust-1]

<LegalRef act="CIT" art="24d" paragraph="1" />:

> Podatek od osiągniętego przez podatnika kwalifikowanego dochodu
> z kwalifikowanych praw własności intelektualnej wynosi **5 %
> podstawy opodatkowania**.

5 % zamiast 9/19 % stosuje się **wyłącznie** do dochodu z
kwalifikowanego IP - pozostała działalność dalej jest opodatkowana
na zasadach ogólnych.

## Kwalifikowane prawa własności intelektualnej - art. 24d ust. 2 [#kwalifikowane-prawa-własności-intelektualnej---art-24d-ust-2]

<LegalRef act="CIT" art="24d" paragraph="2" /> - zamknięty katalog
ośmiu typów praw:

| Pkt | Prawo                                                                     |
| --- | ------------------------------------------------------------------------- |
| 1   | Patent                                                                    |
| 2   | Prawo ochronne na wzór użytkowy                                           |
| 3   | Prawo z rejestracji wzoru przemysłowego                                   |
| 4   | Prawo z rejestracji topografii układu scalonego                           |
| 5   | Dodatkowe prawo ochronne dla patentu (produkt leczniczy / ochrony roślin) |
| 6   | Prawo z rejestracji produktu leczniczego / leczniczego weterynaryjnego    |
| 7   | Wyłączne prawo z ustawy o ochronie prawnej odmian roślin                  |
| 8   | **Autorskie prawo do programu komputerowego**                             |

Wspólny warunek dla wszystkich ośmiu typów: **przedmiot ochrony
został wytworzony, rozwinięty lub ulepszony przez podatnika w ramach
prowadzonej przez niego działalności badawczo-rozwojowej**.

Dla typowej polskiej sp. z o.o. **software** (pkt 8) - autorskie
prawo do programu komputerowego - jest praktycznie jedynym
realistycznym scenariuszem. Patentowanie i rejestracja wzorów
dotyczą głównie firm produkcyjnych i biotechnologicznych.

### Ekspektatywa - art. 24d ust. 12 [#ekspektatywa---art-24d-ust-12]

Zgłoszenie o udzielenie prawa (przed rejestracją) daje "ekspektatywę"

* podatnik może stosować 5 % już od dnia zgłoszenia. Jeżeli wniosek
  zostanie odrzucony, dochody trzeba opodatkować wstecznie na
  zasadach art. 19 (<LegalRef act="CIT" art="24d" paragraph="13" />).

## Kwalifikowany dochód [#kwalifikowany-dochód]

### Cztery tytuły dochodu - art. 24d ust. 7 [#cztery-tytuły-dochodu---art-24d-ust-7]

<LegalRef act="CIT" art="24d" paragraph="7" /> wyróżnia:

1. **Licencja** - opłaty / należności z umowy licencyjnej.
2. **Sprzedaż** kwalifikowanego IP - zbycie prawa.
3. **IP w cenie produktu lub usługi** - najczęstszy przypadek dla
   software: dochód z kwalifikowanego IP uwzględniony w cenie
   sprzedaży produktu lub usługi, w proporcji ustalonej zgodnie
   z art. 11c/11d (ceny transferowe).
4. **Odszkodowanie** za naruszenie praw IP, jeżeli zostało uzyskane
   w postępowaniu spornym (sąd / arbitraż).

Dla software "SaaS" dochód najczęściej spada do pkt 3 - kwalifikowane
IP (prawo do programu) jest uwzględnione w cenie licencji/subskrypcji
oprogramowania, a nie jest odrębnie licencjonowane.

### Wskaźnik nexus - art. 24d ust. 4 [#wskaźnik-nexus---art-24d-ust-4]

Nie cały dochód z kwalifikowanego IP jest "kwalifikowany" - musi być
przemnożony przez **wskaźnik nexus**:

```
         (a + b) × 1,3
nexus = ──────────────
        a + b + c + d
```

gdzie:

* `a` - koszty prowadzone **bezpośrednio przez podatnika** na B+R
  związaną z kwalifikowanym IP;
* `b` - koszty nabycia wyników prac B+R od **podmiotów
  niepowiązanych**;
* `c` - koszty nabycia wyników prac B+R od **podmiotów powiązanych**;
* `d` - koszty nabycia samego **kwalifikowanego IP** przez podatnika.

Jeżeli nexus > 1 → przyjmuje się `nexus = 1` (<LegalRef act="CIT" art="24d" paragraph="6" />).

**Intuicja:** im więcej B+R spółka wykonuje sama (lub kupuje od
niezależnych dostawców), tym wyższy wskaźnik. Outsourcing do podmiotu
powiązanego i zakup gotowego IP "rozcieńczają" preferencję.

### Koszty pominięte (art. 24d ust. 5) [#koszty-pominięte-art-24d-ust-5]

Do a/b/c/d **nie zalicza się** kosztów niebezpośrednio związanych
z kwalifikowanym IP - w szczególności odsetek, opłat finansowych
ani kosztów nieruchomości. Koszty pośrednie (biuro, księgowość,
marketing) pozostają na boku.

## Odliczenie ulgi B+R od dochodu z IP BOX - art. 24d ust. 9a [#odliczenie-ulgi-br-od-dochodu-z-ip-box---art-24d-ust-9a]

<LegalRef act="CIT" art="24d" paragraph="9a" /> pozwala podatnikowi
dodatkowo **odliczyć od dochodu z kwalifikowanego IP** koszty
kwalifikowane określone w art. 18d (ulga B+R) - doprowadzające do
wytworzenia/rozwinięcia/ulepszenia tego prawa.

Mechanizm łączący: jeden koszt można wykorzystać zarówno w uldze B+R
(odliczenie 100-200 % od podstawy z innych źródeł), jak i w IP BOX
(odliczenie od dochodu z kwalifikowanego IP) - ale z zastrzeżeniem,
że ten sam **konkretny** koszt nie zmniejsza podstawy dwukrotnie.

## Obowiązek ewidencyjny - art. 24e [#obowiązek-ewidencyjny---art-24e]

<LegalRef act="CIT" art="24e" paragraph="1" /> określa pięć wymogów
dla podatnika IP BOX:

1. **Wyodrębnić każde kwalifikowane IP** w ewidencji rachunkowej.
2. Prowadzić ewidencję w sposób zapewniający **ustalenie przychodów,
   kosztów uzyskania przychodów i dochodu/straty** dla każdego
   kwalifikowanego IP osobno.
3. Wyodrębnić koszty a/b/c/d **przypadające na każde kwalifikowane
   IP** (wskaźnik nexus per prawo).
4. Gdy niemożliwe jest wyliczenie per prawo - dopuszcza się zapisy
   zapewniające ustalenie **łącznego dochodu** z kwalifikowanych IP
   (pkt 4).
5. Gdy kwalifikowane IP jest wykorzystane w produkcie / usłudze /
   grupie produktów - zapisy zapewniające ustalenie dochodu **dla
   tego produktu lub usługi** (pkt 5).

<LegalRef act="CIT" art="24e" paragraph="2" />:

> W przypadku gdy na podstawie ewidencji rachunkowej **nie jest
> możliwe ustalenie dochodu (straty) z kwalifikowanych praw własności
> intelektualnej, podatnik jest obowiązany do zapłaty podatku zgodnie
> z art. 19**.

Brak odrębnej ewidencji = &#x2A;*bezwzględna utrata prawa do 5 %**.
Utrwalone orzecznictwo sądów administracyjnych konsekwentnie to
potwierdza — na zasadzie „brak ewidencji, brak ulgi”. Ewidencja
musi być prowadzona na bieżąco w trakcie roku; nie można jej
odtworzyć po zakończeniu roku w celu sporządzenia CIT-8.

## Implementacja w Numify - stan obecny [#implementacja-w-numify---stan-obecny]

**Numify nie posiada modułu IP BOX.** Brak:

* Rejestru kwalifikowanych praw własności intelektualnej.
* Tabeli kosztów a/b/c/d per prawo.
* Kalkulatora wskaźnika nexus.
* Załącznika CIT/IP.
* Automatycznego wyliczania dochodu z pkt 3 (IP w cenie produktu)
  z uwzględnieniem art. 11c/11d.

Rekomendowany workflow ręczny - **znacznie bardziej skomplikowany
niż dla B+R**:

1. **Klasyfikacja kwalifikowanego IP.** Podatnik (najczęściej ze
   wsparciem doradcy podatkowego) identyfikuje, które prawa kwalifikują
   się - w praktyce dla spółek software to zwykle wyniki prac
   rozwojowych stanowiące **autorskie prawo do programu komputerowego**.
2. **Plan kont rozbudowany** - konta analityczne per kwalifikowane IP
   dla: przychodów (`701-IP-X`), kosztów bezpośrednich (`404-IP-X`,
   `401-IP-X` itp.), ewentualnie per produkt.
3. **Ewidencja zewnętrzna kosztów a/b/c/d** - arkusz zbiorczy poza
   systemem księgowym, w którym dla każdego kwalifikowanego IP
   agregowane są cztery kategorie.
4. **Ustalenie proporcji dla art. 24d ust. 7 pkt 3** - analiza cen
   transferowych (nawet przy braku podmiotów powiązanych potrzebna
   jest metoda alokacji dochodu z IP do produktu/usługi).
5. **Roczne wyliczenie ręczne** - dochód × nexus × 5 %.
6. **Załącznik CIT/IP** wypełniany ręcznie.
7. **Interpretacja indywidualna** - z uwagi na złożoność i ryzyko
   kwestionowania, prawie każdy podatnik IP BOX występuje o
   interpretację indywidualną (KIS) przed rozpoczęciem stosowania
   preferencji.

**IP BOX wykracza daleko poza kompetencje Numify jako narzędzia
księgowego.** Obsługa wymaga kompetencji podatkowych i metodologii
cen transferowych - bez wsparcia doradcy podatkowego nie jest
rozsądna.

## Połączenie z ulgą B+R [#połączenie-z-ulgą-br]

| Element    | Ulga B+R (art. 18d)                             | IP BOX (art. 24d)                              |
| ---------- | ----------------------------------------------- | ---------------------------------------------- |
| Stawka     | 9 % lub 19 %                                    | **5 %**                                        |
| Co obniża  | Podstawę opodatkowania (dochód z innych źródeł) | Dochód z kwalifikowanego IP                    |
| Odliczenie | 200 % dla wynagrodzeń, 100 % dla pozostałych    | Nexus × dochód                                 |
| Ewidencja  | Koszty B+R wyodrębnione (art. 9 ust. 1b)        | Per każde IP (art. 24e) - znacznie rozbudowana |
| Załącznik  | CIT/BR                                          | CIT/IP                                         |

Połączenie obu (art. 24d ust. 9a) wymaga **osobnego śledzenia** każdego
wykorzystania kosztu - raz w uldze B+R, raz w IP BOX. W praktyce
prawidłowe prowadzenie obu preferencji naraz wymaga dedykowanego
systemu lub zaawansowanego arkusza z pełnym śladem alokacji.

## Typowe błędy [#typowe-błędy]

* **Rozpoczęcie IP BOX bez ewidencji prowadzonej od początku roku.**
  Art. 24e ust. 1 nie dopuszcza "dorabiania" ewidencji wstecz -
  musi być prowadzona w ciągu roku.
* **Ujęcie całego dochodu z software w 5 %.** Preferencja dotyczy
  **tylko** kwalifikowanego dochodu (nexus × kwalifikowany dochód z
  pkt 3). Pozostała część marży - na zasadach ogólnych.
* **Pominięcie kosztów pośrednich.** Nexus liczy tylko koszty
  **bezpośrednio** związane z kwalifikowanym IP (ust. 5). Biuro,
  sprzedaż, księgowość nie wchodzą - ale to nie znaczy, że są
  "za darmo" - redukują ogólny dochód, nie dochód kwalifikowany.
* **Brak interpretacji indywidualnej.** Każdy większy spór o IP BOX
  w postępowaniu kontrolnym → kwalifikacja działalności jako
  rozwojowej i kwalifikacja prawa są kluczowe. Interpretacja
  indywidualna chroni przed negatywnymi skutkami.
* **"Autorskie prawo do programu" vs "know-how".** Know-how nie
  figuruje w katalogu art. 24d ust. 2 - sama wiedza ekspercka bez
  skonkretyzowanego programu komputerowego **nie jest** kwalifikowanym IP.

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

* [Ulga B+R](/docs/zgodnosc-z-prawem/ustawa-o-cit/ulga-br) - warunek
  konieczny kwalifikowanego IP (art. 24d ust. 2 - ostatnie zdanie).
* [Stawki CIT](/docs/zgodnosc-z-prawem/ustawa-o-cit/stawki) - IP BOX
  jako osobna stawka obok 9/19 %.
* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) - załącznik
  CIT/IP dołączany do zeznania rocznego.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja - oparta na aktualnym tekście jednolitym ustawy
    o CIT (Dz.U. 2025 poz. 278). Zakres art. 24d i 24e bez zmian
    merytorycznych od wprowadzenia IP BOX w 2019 r., ostatnia
    istotna nowelizacja art. 24d ust. 9a (połączenie z B+R) -
    Dz.U. 2021 poz. 2105 ("Polski Ład").
  </ChangeEntry>
</ChangeHistory>


---

# Art. 9 CIT — Obowiązek prowadzenia ewidencji rachunkowej
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/art-9-ewidencja-rachunkowa
Description: Obowiązek prowadzenia ewidencji rachunkowej zgodnej z UoR w sposób zapewniający ustalenie dochodu, straty, podstawy opodatkowania i podatku. Obowiązkowe przesyłanie ksiąg w strukturze JPK (JPK_KR_PD) od 2025/2026 r. Wyodrębnienie kosztów B+R (ust. 1b) i środków trwałych z odpisami amortyzacyjnymi. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



Spółka z o.o. jest jednocześnie podatnikiem CIT i jednostką w
rozumieniu UoR — więc prowadzi **jedną** ewidencję spełniającą
wymagania **obu** ustaw. <LegalRef act="CIT" art="9" /> przepina UoR
do podatków i dokłada dwa dodatkowe wymagania: **ewidencję środków
trwałych z danymi do amortyzacji podatkowej** oraz **obowiązek
przesłania ksiąg w strukturze JPK** (JPK\_KR\_PD).

<ComplianceDisclaimer />

## Ewidencja zgodna z odrębnymi przepisami — ust. 1 [#ewidencja-zgodna-z-odrębnymi-przepisami--ust-1]

> Podatnicy są obowiązani do prowadzenia ewidencji rachunkowej,
> zgodnie z odrębnymi przepisami, w sposób zapewniający określenie
> wysokości dochodu (straty), podstawy opodatkowania i wysokości
> należnego podatku za rok podatkowy, a także do uwzględnienia w
> ewidencji środków trwałych oraz wartości niematerialnych i prawnych
> informacji niezbędnych do obliczenia wysokości odpisów
> amortyzacyjnych zgodnie z przepisami art. 16a–16m.

Trzy wymagania z jednego przepisu:

1. **Zgodność z odrębnymi przepisami** — dla sp. z o.o. odrębnymi
   przepisami jest **UoR**. Księgi prowadzone niezgodnie z UoR
   (błędny plan kont, brak śladu rewizyjnego, brak inwentaryzacji)
   są jednocześnie niezgodne z CIT.
2. **Ustalenie dochodu, straty, podstawy i podatku** — księgi muszą
   pozwolić **oddzielić** KUP od NKUP, przychody podatkowe od
   nieopodatkowanych, dochody z zysków kapitałowych od innych źródeł
   (zobacz [art. 7](/docs/zgodnosc-z-prawem/ustawa-o-cit/art-7-przedmiot-opodatkowania)).
3. **Ewidencja środków trwałych z danymi do amortyzacji podatkowej** —
   osobna lub zintegrowana, ale musi pozwalać wyliczyć odpisy według
   <LegalRef act="CIT" art="16a" /> – <LegalRef act="CIT" art="16m" />
   (zobacz [art. 16a–16m](/docs/zgodnosc-z-prawem/ustawa-o-cit/art-16a-16m-amortyzacja)).

### Wyodrębnienie kosztów B+R — ust. 1b [#wyodrębnienie-kosztów-br--ust-1b]

Podatnicy korzystający z **ulgi B+R** (<LegalRef act="CIT" art="18d" />)
muszą w ewidencji **wyodrębnić** koszty działalności badawczo-rozwojowej
— typowo przez:

* dedykowane konta zespołu 5 (`521-B+R`, `540-B+R`) lub analitykę na
  kontach kosztów rodzajowych (`401-BR`, `404-BR`),
* dodatkowy wymiar `projectCode` z kategorią `research`,
* metadane dokumentu źródłowego z flagą „koszt kwalifikowany B+R".

Bez wyodrębnienia **urząd skarbowy może zakwestionować** skorzystanie
z ulgi — co skutkuje zwrotem odliczonej kwoty z odsetkami.

## JPK\_KR\_PD — ust. 1c [#jpk_kr_pd--ust-1c]

> Podatnicy prowadzący księgi rachunkowe są obowiązani prowadzić te
> księgi przy użyciu programów komputerowych oraz przesyłać
> właściwemu naczelnikowi urzędu skarbowego te księgi po zakończeniu
> roku podatkowego, w terminie do dnia upływu terminu złożenia
> zeznania \[CIT-8], za pomocą środków komunikacji elektronicznej, w
> postaci elektronicznej odpowiadającej strukturze logicznej, o której
> mowa w art. 193a § 2 Ordynacji podatkowej.

Dwa obowiązki łącznie:

1. **Prowadzenie ksiąg przy użyciu programów komputerowych** —
   papierowe księgi są niedopuszczalne. UoR dopuszcza księgi
   komputerowe (<LegalRef act="UoR" art="13" paragraph="2" />) — CIT
   to wymusza.
2. **Przesłanie ksiąg po zakończeniu roku** — w strukturze logicznej
   **JPK\_KR\_PD** do naczelnika urzędu skarbowego w terminie złożenia
   CIT-8.

### Harmonogram wejścia w życie [#harmonogram-wejścia-w-życie]

Obowiązek JPK\_KR\_PD wprowadzany etapowo (<LegalRef act="JPK_KR_PD" art="1" />
— rozporządzenie MF):

| Kto                                                                       | Pierwszy rok podatkowy objęty |
| ------------------------------------------------------------------------- | ----------------------------- |
| Podatnicy CIT — duzi (podatkowe grupy kapitałowe, przychody > 50 mln EUR) | rozpoczęty po 31 XII 2024     |
| Pozostali podatnicy CIT                                                   | rozpoczęty po 31 XII 2025     |

Dla typowej sp. z o.o. z rokiem obrotowym pokrywającym się z kalendarzowym
pierwszy JPK\_KR\_PD obejmuje **rok 2026**, składany w marcu 2027 r.
razem z CIT-8.

### Struktura JPK\_KR\_PD [#struktura-jpk_kr_pd]

Schemat opublikowany na stronach MF obejmuje m.in.:

* nagłówek (dane podatnika, okres),
* plan kont,
* dziennik z wszystkimi zapisami,
* zapisy w podziale na konta,
* obroty i salda ZOiS,
* **kody znaczników**: `KSR` (klasyfikacja PKD), `KSeF` (ID faktur
  z KSeF), `POD` (klasyfikacja podatkowa KUP / NKUP), `RK` (różnice
  kursowe).

Znaczniki są **nowe** i wcześniejsze JPK\_KR (z lat 2016–2024) ich
nie zawierały. To właśnie dlatego obowiązek dotyczy ksiąg
&#x2A;*prowadzonych od 2025 r.**, a nie retroaktywnie.

Szczegóły wdrożenia w Numify —
[jpk-kr-pd](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd).

### Zwolnienia — ust. 1d [#zwolnienia--ust-1d]

Zwolnieni z obowiązku JPK\_KR\_PD są m.in.:

* podmioty zwolnione z CIT na podstawie <LegalRef act="CIT" art="6" />
  (z wyjątkiem fundacji rodzinnych),
* podatnicy składający zeznanie w postaci papierowej (tylko pewne
  jednostki bez osobowości prawnej — nie dotyczy sp. z o.o.),
* prowadzący uproszczoną ewidencję przychodów i kosztów (PKPiR —
  nie dotyczy sp. z o.o., która **musi** prowadzić księgi
  rachunkowe na podstawie <LegalRef act="UoR" art="2" paragraph="1" />).

**Dla sp. z o.o. obowiązek JPK\_KR\_PD jest bezwyjątkowy** (poza
fikcyjnym przypadkiem zwolnienia z CIT).

## Oszacowanie dochodu — ust. 2 [#oszacowanie-dochodu--ust-2]

> Jeżeli ustalenie dochodu (straty) w sposób określony w ust. 1 nie
> jest możliwe, dochód (stratę) ustala się w drodze oszacowania.

To „najgorszy przypadek" — konsekwencja niepełnej lub niewiarygodnej
ewidencji. Organ podatkowy może wtedy:

* zastosować wskaźnik dochodowości do branży,
* porównać z podobnymi podatnikami,
* dla nierezydentów — użyć wskaźników z ust. 2a (5 % handel hurtowy,
  10 % budownictwo, 60 % pośrednictwo, 80 % usługi adwokackie /
  rzeczoznawcze, 20 % pozostałe).

Oszacowanie **zwykle jest niekorzystne** dla podatnika — stąd
kluczowe znaczenie prawidłowej ewidencji.

## Ewidencja środków trwałych — ust. 1 in fine [#ewidencja-środków-trwałych--ust-1-in-fine]

Ewidencja środków trwałych musi zawierać dane niezbędne dla
amortyzacji podatkowej — w praktyce:

| Pole                       | Skąd                                                             |
| -------------------------- | ---------------------------------------------------------------- |
| Numer inwentarzowy         | nadany przy wprowadzeniu do ewidencji                            |
| Klasyfikacja KŚT           | klasyfikacja środków trwałych (rozporządzenie RM)                |
| Wartość początkowa         | <LegalRef act="CIT" art="16g" />                                 |
| Data przyjęcia do używania | dzień 1. odpisu miesięcznego (+1 miesiąc)                        |
| Metoda amortyzacji         | liniowa / degresywna / jednorazowa                               |
| Stawka roczna              | Wykaz stawek amortyzacyjnych lub indywidualna                    |
| Współczynnik               | 1,2 / 1,4 / 2,0 (<LegalRef act="CIT" art="16i" paragraph="2" />) |
| Suma odpisów dotychczas    | dla śladu historycznego                                          |

Rozróżnienie z art. 9 — ewidencja środków trwałych jest **niezależna
od UoR** w tym sensie, że amortyzacja bilansowa i podatkowa mogą się
różnić stawką i metodą. Numify prowadzi **dwa równoległe plany
amortyzacji** na jednym środku trwałym — zobacz
[fixed-assets](/docs/korzystanie-z-numify/fixed-assets) i
[art. 31–33 UoR](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-31-33-srodki-trwale).

## Realizacja w Numify [#realizacja-w-numify]

| Wymaganie CIT art. 9                                                    | Funkcja Numify                                                                                              |
| ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Księgi komputerowe (ust. 1c)                                            | Cała aplikacja — bez papierowych ksiąg                                                                      |
| Ustalenie dochodu / straty                                              | [cit-data](/docs/korzystanie-z-numify/cit-data) — raport „BO → PO"                                          |
| Ewidencja środków trwałych                                              | [fixed-assets](/docs/korzystanie-z-numify/fixed-assets) — wartość początkowa, metoda, stawka, współczynnik  |
| Dwa plany amortyzacji (bilansowy + podatkowy)                           | [fixed-assets](/docs/korzystanie-z-numify/fixed-assets) — pole `taxSchedule`                                |
| Wyodrębnienie kosztów B+R (ust. 1b)                                     | analityka na kontach zespołu 4 lub wymiar `projectCode`                                                     |
| Klasyfikacja podatkowa (KUP / NKUP)                                     | plan-kont — flaga `taxTreatment` per konto                                                                  |
| Generowanie JPK\_KR\_PD                                                 | [jpk-kr-pd](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd) + [exports](/docs/korzystanie-z-numify/exports) |
| Przechowywanie ksiąg (<LegalRef act="OrdPod" art="86" paragraph="1" />) | [art. 73–74 UoR](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-73-74-archiwizacja)                     |

### Uczciwe framing — stan implementacji JPK\_KR\_PD [#uczciwe-framing--stan-implementacji-jpk_kr_pd]

Numify generuje JPK\_KR\_PD w **strukturze logicznej MF**
obowiązującej od 2026 r. (po nowelizacji rozporządzenia z 15.12.2025).
Znaczniki KSR, POD i RK są wypełniane automatycznie z danych
planu kont i dokumentów; znacznik KSeF jest pobierany z pola
`KSeFReferenceNumber` dokumentu.

Pełna automatyzacja wymaga:

* ukończonej klasyfikacji wszystkich kont wg flag `taxTreatment`
  i `ksrCode`,
* zaimportowanych KSeF ID dla faktur wystawionych po 1 IV 2026 r.
* rozliczonych różnic kursowych (tagowanie RK na zapisach kont 750 / 755).

Weryfikacja pliku przed wysyłką — rekomendowana przez narzędzie MF
„Klient JPK\_KR\_PD" (walidacja schematu + kontrola spójności obrotów).

## Częste błędy [#częste-błędy]

* **Opóźnienie JPK\_KR\_PD** — termin = termin CIT-8. Spóźnienie to
  wykroczenie skarbowe (<LegalRef act="KKS" art="80" />).
* **Brak wyodrębnienia B+R** przed pierwszą ulgą — skutkuje
  zakwestionowaniem kwoty kwalifikowanej w kontroli.
* **Jedna stawka amortyzacji dla bilansu i podatku bez analizy** —
  naturalne, jeśli stawki są zgodne, ale błąd, jeśli księgowy
  zastosował stawkę podwyższoną bilansowo (ekonomicznie) bez
  spełnienia warunków art. 16i ust. 2.
* **Znacznik KSeF pomijany** — faktury z KSeF (obowiązkowo od 1 IV 2026
  r.) muszą być oznaczone w JPK\_KR\_PD swoim ID referencyjnym.
* **Zmiana planu kont w trakcie roku bez uzasadnienia w polityce
  rachunkowości** — narusza zarówno UoR (<LegalRef act="UoR" art="10" />)
  jak i CIT (ust. 1 — „zgodność z odrębnymi przepisami").
* **Luka w numeracji dziennika** — z JPK\_KR\_PD urząd od razu wykryje
  brakującą pozycję, co uruchamia kontrolę ksiąg.

## Checklist — przygotowanie do JPK\_KR\_PD [#checklist--przygotowanie-do-jpk_kr_pd]

* [ ] Wszystkie konta planu kont mają przypisany kod KSR
  (klasyfikacja PKD).
* [ ] Wszystkie konta kosztowe mają klasyfikację `taxTreatment`
  (KUP / NKUP / limit).
* [ ] Faktury 2026+ mają zarejestrowane KSeF ID (po 1 IV 2026 r.).
* [ ] Różnice kursowe zaksięgowane z prawidłowym typem (bilansowe /
  podatkowe — ust. 15a–15b CIT).
* [ ] Ewidencja środków trwałych z osobnym planem amortyzacji
  podatkowej.
* [ ] Koszty B+R wyodrębnione (jeśli dotyczy) przed pierwszą ulgą.
* [ ] JPK\_KR\_PD zwalidowany narzędziem „Klient JPK\_KR\_PD" MF.
* [ ] Wysyłka w terminie CIT-8 (3 miesiące od końca roku podatkowego).
* [ ] Urzędowe poświadczenie odbioru (UPO) zachowane przez 5 lat.


---

# Roczne zeznanie CIT-8 — art. 27
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8
Description: Zeznanie o wysokości dochodu (straty) sp. z o.o. za rok podatkowy. Termin do końca 3. miesiąca następnego roku (31 marca dla kalendarzowego), forma elektroniczna, załączniki (CIT-ST, CIT/IP, CIT/BR), obowiązek złożenia sprawozdania finansowego do Szefa KAS.
Review status: internal
Updated: 2026-04-16



**CIT-8** to roczne zeznanie spółki z o.o. o wysokości osiągniętego
dochodu (lub poniesionej straty) w roku podatkowym.
<LegalRef act="CIT" art="27" paragraph="1" /> zobowiązuje każdego
podatnika CIT (z wąskimi wyjątkami) do złożenia zeznania i zapłaty
podatku **w terminie do końca trzeciego miesiąca roku następnego**.

<ComplianceDisclaimer />

## Termin — do końca 3. miesiąca [#termin--do-końca-3-miesiąca]

<LegalRef act="CIT" art="27" paragraph="1" />:

> Podatnicy (…) są obowiązani (…) składać urzędom skarbowym
> zeznanie, według ustalonego wzoru, o wysokości dochodu osiągniętego
> (straty poniesionej) w roku podatkowym — **do końca trzeciego
> miesiąca roku następnego i w tym terminie wpłacić podatek należny
> albo różnicę** między podatkiem należnym od dochodu wykazanego
> w zeznaniu a sumą zapłaconych zaliczek za okres od początku roku.

Dla typowej sp. z o.o. z **rokiem kalendarzowym** termin = **31 marca**.

<DeadlineBadge type="cit-8" />

Dla roku obrotowego pokrywającego się np. z 1.07 → 30.06 — termin
30 września następnego roku.

### Sprzężenie z ostatnią zaliczką [#sprzężenie-z-ostatnią-zaliczką]

Zgodnie z <LegalRef act="CIT" art="25" paragraph="1a" /> zaliczka za
grudzień (lub IV kwartał — art. 25 ust. 1c) **nie jest wpłacana
osobno**, jeżeli przed 20 stycznia następnego roku spółka:

1. Złoży zeznanie CIT-8, i
2. Dokona zapłaty podatku na zasadach ogólnych.

W praktyce jest to furtka dla małych spółek, ale rzadko wykorzystywana
— CIT-8 musi być złożony z zamkniętym rokiem podatkowym (KUP/NKUP,
sprawozdanie finansowe), co zwykle nie jest gotowe do 20 stycznia.

## Forma zeznania — wyłącznie elektronicznie [#forma-zeznania--wyłącznie-elektronicznie]

<LegalRef act="CIT" art="27" paragraph="1c" />:

> Zeznanie (…) składa się za pomocą środków komunikacji
> elektronicznej zgodnie z przepisami Ordynacji podatkowej.

Papierowe CIT-8 są dostępne **wyłącznie** dla podatników wymienionych
w <LegalRef act="CIT" art="27a" /> (niewielka lista — typowej sp. z o.o.
nie dotyczy).

Kanały składania:

* **e-Deklaracje** (system ministerstwa finansów) — wymagany
  podpis elektroniczny lub kwalifikowany, profil zaufany, dane
  autoryzujące (dla osób fizycznych).
* **Oprogramowanie księgowe** z integracją e-Deklaracji.
* **Aplikacje biur rachunkowych** (np. Comarch, Sage, Symfonia).

**Numify nie generuje pliku CIT-8 XML.** Generowane są dane źródłowe
(zobacz sekcję poniżej), które użytkownik przenosi do e-Deklaracji
lub do oprogramowania składającego deklarację.

## Co zawiera CIT-8 — struktura formularza [#co-zawiera-cit-8--struktura-formularza]

Obowiązujący wzór CIT-8 jest publikowany rozporządzeniem Ministra Finansów i aktualizowany praktycznie co roku. Aktualną wersję formularza należy sprawdzić na [podatki.gov.pl](https://www.podatki.gov.pl/cit/e-deklaracje-cit/formularze-cit/). Formularz zawiera m.in.:

### Część podstawowa [#część-podstawowa]

| Pole | Zakres                                                             |
| ---- | ------------------------------------------------------------------ |
| A    | Dane identyfikacyjne i status podatnika                            |
| B    | Miesiąc rozpoczęcia / zakończenia działalności (jeśli krótszy rok) |
| C    | Przychody i koszty z zysków kapitałowych (art. 7b)                 |
| D    | Przychody i koszty z innych źródeł                                 |
| E    | Dochód do opodatkowania po odliczeniach                            |
| F    | Podstawa opodatkowania                                             |
| G    | Podatek i zaliczki — rozliczenie                                   |

### Kluczowe kwoty — skąd pochodzą [#kluczowe-kwoty--skąd-pochodzą]

| Pozycja CIT-8               | Źródło w księgach Numify                                                  |
| --------------------------- | ------------------------------------------------------------------------- |
| Przychody z innych źródeł   | obroty Ma kont Zespołu 7 (700, 701, 702, 711, 755, 765, 760)              |
| Koszty uzyskania przychodów | obroty Wn kont Zespołu 4 i 7 (400–409, 751, 761, 771) pomniejszone o NKUP |
| Wynik podatkowy             | dochód z innych źródeł − KUP (±korekty)                                   |
| Podatek należny             | dochód × 9 % lub 19 % (art. 19)                                           |
| Suma zaliczek wpłaconych    | suma obrotów Wn konta <AccountRef code="225" />                           |

## Obligatoryjne załączniki [#obligatoryjne-załączniki]

Niektóre załączniki dołącza się obowiązkowo, inne tylko przy
wystąpieniu określonych zdarzeń. Najczęściej spotykane:

| Załącznik   | Kiedy obowiązkowy                                                                               |
| ----------- | ----------------------------------------------------------------------------------------------- |
| **CIT-8/O** | Informacja o odliczeniach od dochodu i podatku (darowizny, ulga B+R, strata z lat ubiegłych)    |
| **CIT/BR**  | Ulga na działalność badawczo-rozwojową — zawsze gdy odlicza się koszty kwalifikowane z art. 18d |
| **CIT/IP**  | Rozliczenie dochodu z IP BOX (art. 24d)                                                         |
| **CIT-ST**  | Informacja o zakładach (oddziałach) w JST poza główną siedzibą                                  |
| **CIT/MIT** | Podatek od przychodów z budynków (art. 24b)                                                     |
| **CIT/NZI** | Niezrealizowane zyski (art. 24f)                                                                |
| **CIT/WZ**  | Ulga na złe długi (korekta z tytułu niezapłaconych należności/zobowiązań)                       |
| **CIT/KW**  | Korekta wstępna (estoński CIT — nie wspierany w Numify)                                         |

Szczegóły — zobacz wzory na stronie podatki.gov.pl.

## Obowiązek przekazania sprawozdania finansowego [#obowiązek-przekazania-sprawozdania-finansowego]

<LegalRef act="CIT" art="27" paragraph="2" />:

> Podatnicy obowiązani do sporządzenia sprawozdania finansowego
> przekazują, za pomocą środków komunikacji elektronicznej, Szefowi
> Krajowej Administracji Skarbowej sprawozdanie finansowe (…) wraz
> ze sprawozdaniem z badania, **w terminie 15 dni od dnia
> zatwierdzenia rocznego sprawozdania finansowego**.

Uwaga — to **odrębny** obowiązek od składania SF do KRS (zobacz:
[Złożenie do KRS](/docs/zgodnosc-z-prawem/sprawozdanie-finansowe/zlozenie-do-krs)).
Spółki, które mają obowiązek składania SF do KRS (wszystkie sp. z o.o.)
**nie** przesyłają go równolegle do KAS — wystarczy KRS. Obowiązek
z art. 27 ust. 2 dotyczy wyłącznie podmiotów, które do KRS nie
składają SF (np. podatkowe grupy kapitałowe, podatnicy CIT niebędący
spółkami handlowymi).

Format: &#x2A;*XML wg schemy `e-sprawozdania`** na bazie UoR, z podpisem
elektronicznym zarządu.

## Generacja danych źródłowych w Numify [#generacja-danych-źródłowych-w-numify]

<ServiceRef path="src/lib/services/cit-data.ts">generateCitData</ServiceRef>
zwraca strukturę `CitDataResult`:

```ts
{
  fiscalYear: number,
  companyId: string,
  citRate: 9 | 19,
  accountingRevenue: number,      // grosze
  accountingCosts: number,        // grosze
  accountingResult: number,       // grosze (revenue - costs)
  nonDeductibleCosts: number,     // grosze (suma NKUP)
  nkupItems: NkupItem[],          // lista NKUP po kontach
  taxableRevenue: number,         // grosze
  taxDeductibleCosts: number,     // grosze
  taxResult: number,              // grosze (dochód podatkowy)
  citDue: number,                 // grosze (podatek należny)
}
```

Wynik służy jako **nota podatkowa** — tabela pomocnicza dla księgowego
przenosząca wyliczenie do formularza CIT-8.

**Ograniczenia:**

1. Traktuje `accountingRevenue` jako `taxableRevenue` — **nie wydziela
   przychodów niepodatkowych** (np. umorzonych dotacji, odsetek
   z lat ubiegłych nieopodatkowanych, dywidend).
2. Nie stosuje mechanizmu z **art. 7b** (rozdzielenie zysków
   kapitałowych od innych źródeł) — wszystkie przychody trafiają do
   jednej kategorii.
3. Nie odlicza **strat z lat ubiegłych** (art. 7 ust. 5) — spółka z
   historyczną stratą musi uwzględnić to ręcznie.
4. Nie uwzględnia **odliczeń od podstawy** (ulga B+R, darowizny,
   art. 18, 18d).

Wynik jest **punktem wyjścia**, nie gotowym zeznaniem — ostateczne
rozliczenie wykonuje księgowy/doradca.

## Zamknięcie roku przed CIT-8 [#zamknięcie-roku-przed-cit-8]

Kolejność kroków:

1. **Zamknięcie 12 okresów miesięcznych** → <ServiceRef path="src/lib/services/fiscal-periods.ts">closePeriod</ServiceRef>
   per miesiąc. Okresy stają się **nieedytowalne**.
2. **Generowanie zapisów zamykających rok** → <ServiceRef path="src/lib/services/year-end-close.ts">previewYearEndClose</ServiceRef>
   / `executeYearEndClose`. Przeksięgowanie sald kont wynikowych
   (zespoły 4, 7, 8) na konto <AccountRef code="860" name="Wynik finansowy" />
   zgodnie z art. 12 ust. 2 UoR.
3. **Nota podatkowa KUP/NKUP** → <ServiceRef path="src/lib/services/cit-data.ts">generateCitData</ServiceRef>.
4. **Sprawozdanie finansowe** — bilans, RZiS, informacja dodatkowa
   ([Sprawozdanie finansowe](/docs/zgodnosc-z-prawem/sprawozdanie-finansowe)).
5. **Złożenie CIT-8** i zapłata podatku do 31 marca.
6. **Zgromadzenie wspólników** zatwierdzające SF — do 30 czerwca.
7. **Złożenie SF do KRS** — 15 dni od zatwierdzenia.

### Wchłonięcie ostatniej zaliczki [#wchłonięcie-ostatniej-zaliczki]

Po wyliczeniu `citDue` i sumie zaliczek wpłaconych w ciągu roku:

* Jeżeli `citDue > Σ zaliczek` — spółka dopłaca różnicę do 31 marca.
* Jeżeli `citDue < Σ zaliczek` — powstaje **nadpłata** (zwrot na
  wniosek lub zaliczenie na kolejne zobowiązanie).
* Jeżeli spółka miała stratę (`taxResult ≤ 0`) — `citDue = 0`, całość
  zaliczek podlega zwrotowi jako nadpłata.

## Typowe błędy [#typowe-błędy]

* **Pominięcie zysków kapitałowych.** Art. 7b przewiduje odrębne
  „koszyki" dochodów — dochód z zysków kapitałowych nie łączy się
  ze stratą z innych źródeł. Numify nie wydziela tego automatycznie.
* **Nieaktualny formularz CIT-8.** Wersje zmieniają się w zasadzie
  co rok. Przed złożeniem sprawdź aktualną wersję na
  [podatki.gov.pl](https://www.podatki.gov.pl/cit/e-deklaracje-cit/formularze-cit/).
* **Ignorowanie art. 27 ust. 2** przy PGK. Podatkowe grupy kapitałowe
  składają SF **do KAS**, nie do KRS.
* **Zapłata podatku po 31 marca.** Odsetki ustawowe za zwłokę liczone
  od dnia następującego po terminie.

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

* [Stawki CIT](/docs/zgodnosc-z-prawem/ustawa-o-cit/stawki) — 9 % / 19 %.
* [Zaliczki](/docs/zgodnosc-z-prawem/ustawa-o-cit/zaliczki) — zaliczki
  wchłaniane przez rozliczenie roczne.
* [KUP / NKUP](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup) —
  podstawa obliczenia dochodu podatkowego.
* [JPK\_KR\_PD](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd) — ksiąg
  rachunkowe przekazywane łącznie z CIT-8 (dla FY 2026+).
* [Sprawozdanie finansowe](/docs/zgodnosc-z-prawem/sprawozdanie-finansowe) —
  bilans i RZiS składane niezależnie do KRS.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja — oparta na art. 27 ustawy o CIT (Dz.U. 2025 poz. 278).
    Aktualną wersję formularza CIT-8 należy sprawdzać w rozporządzeniach
    Ministra Finansów publikowanych na podatki.gov.pl.
  </ChangeEntry>
</ChangeHistory>


---

# JPK_ST_KR — ewidencja środków trwałych
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-st-kr
Description: Struktura XML z ewidencji środków trwałych i wartości niematerialnych — składana łącznie z JPK_KR_PD przez podatników CIT. Rozporządzenie MF z 16.08.2024 (Dz.U. 2024 poz. 1314), pola KŚT, metoda amortyzacji, amortyzacja narastająca na BO/BZ, status środka (używany / zlikwidowany / w pełni zamortyzowany).
Review status: internal
Updated: 2026-04-16



**JPK\_ST\_KR** (Jednolity Plik Kontrolny — Środki Trwałe, Księgi
Rachunkowe) to druga struktura wprowadzona tym samym rozporządzeniem
co JPK\_KR\_PD. Zawiera **ewidencję środków trwałych** jednostki —
wartości początkowe, naliczoną amortyzację, statusy środków.

Składany **łącznie z JPK\_KR\_PD** — w tym samym terminie (art. 9
ust. 1c CIT), przez tę samą bramkę MF, za ten sam rok podatkowy.

<ComplianceDisclaimer />

## Podstawa prawna [#podstawa-prawna]

Obowiązek wynika z <LegalRef act="CIT" art="9" paragraph="1c" />
i Rozporządzenia MF z 16 sierpnia 2024 r. (Dz.U. 2024 poz. 1314) —
zob. [JPK\_KR\_PD](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd) dla
kalendarza wdrożenia. Rozporządzenie definiuje dwie struktury w
jednym akcie prawnym — JPK\_KR\_PD (księgi) i JPK\_ST\_KR (środki trwałe).

Aktualny namespace schemy: `http://jpk.mf.gov.pl/wzor/2024/08/16/08162/`.

## Zakres — które środki trafiają do JPK\_ST\_KR [#zakres--które-środki-trafiają-do-jpk_st_kr]

JPK\_ST\_KR obejmuje **środki trwałe oraz wartości niematerialne i
prawne**, które:

* Zostały **przyjęte do używania** przed końcem roku podatkowego
  (`acquisition_date ≤ 31.12`).
* Nie zostały **zlikwidowane/sprzedane przed początkiem** roku
  podatkowego (`disposal_date ≥ 01.01` lub brak).

Konsekwencje:

1. Środek nabyty w grudniu danego roku — **trafia** do JPK za ten rok,
   nawet jeśli amortyzacja dopiero się rozpocznie.
2. Środek sprzedany w styczniu — **trafia** do JPK za ten rok (był w
   użyciu przez część roku).
3. Środek sprzedany w grudniu roku poprzedniego — **nie trafia** do
   JPK\_ST\_KR tego roku.

## Struktura pliku [#struktura-pliku]

### Nagłówek i podmiot [#nagłówek-i-podmiot]

Analogicznie do JPK\_KR\_PD:

* `<Naglowek>` — `KodFormularza = "JPK_ST_KR (1)"`, `CelZlozenia`,
  daty `DataOd`/`DataDo`, kod urzędu, system źródłowy.
* `<Podmiot>` — NIP, REGON, nazwa, email.

### Element `<SrodekTrwaly>` — powtarzany dla każdego środka [#element-srodektrwaly--powtarzany-dla-każdego-środka]

| Pole XML                           | Źródło w Numify                                                                                  | Obowiązkowość                |
| ---------------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------- |
| `<LpST>`                           | kolejny numer od 1                                                                               | tak                          |
| `<NrInwentarzowy>`                 | `fixed_assets.inventoryNumber`                                                                   | warunkowo (jeżeli ustawiony) |
| `<NazwaST>`                        | `fixed_assets.name`                                                                              | tak                          |
| `<KodKST>`                         | `fixed_assets.classificationCode`                                                                | warunkowo (kod klasyfikacji) |
| `<DataPrzyjST>`                    | `fixed_assets.acquisitionDate`                                                                   | tak                          |
| `<WartoscPoczatkowa>`              | `fixed_assets.acquisitionValue`                                                                  | tak                          |
| `<Ulepszenia>`                     | `fixed_assets.improvementValue` (jeśli > 0)                                                      | warunkowo                    |
| `<MetodaAmortyzacji>`              | `linear` → „liniowa"; `degressive` → „degresywna"; `one_time` → „jednorazowa"                    | tak                          |
| `<StawkaAmortyzacji>`              | `fixed_assets.depreciationRate` (np. `20`)                                                       | tak                          |
| `<AmortyzacjaNarastajacoPoczatek>` | `accumulatedDepreciation − yearDepreciation`                                                     | tak                          |
| `<AmortyzacjaOkres>`               | Suma `depreciation_entries.amount` w roku                                                        | tak                          |
| `<AmortyzacjaNarastajaco>`         | `fixed_assets.accumulatedDepreciation` (na koniec roku)                                          | tak                          |
| `<WartoscNetto>`                   | `fixed_assets.netBookValue`                                                                      | tak                          |
| `<DataLikwidacji>`                 | `fixed_assets.disposalDate` (jeśli status `disposed`)                                            | warunkowo                    |
| `<WartoscLikwidacji>`              | `fixed_assets.disposalValue`                                                                     | warunkowo                    |
| `<StatusST>`                       | `active` → „używany"; `disposed` → „zlikwidowany"; `fully_depreciated` → „w pełni zamortyzowany" | tak                          |

### Blok kontrolny `<SrodekTrwalyCtrl>` [#blok-kontrolny-srodektrwalyctrl]

* `<LiczbaWierszyST>` — liczba środków w pliku.
* `<SumaWartosciPoczatkowych>` — suma wartości początkowych
  (z ulepszeniami).
* `<SumaAmortyzacjiOkres>` — suma amortyzacji za okres.

## Implementacja w Numify [#implementacja-w-numify]

<ServiceRef path="src/lib/services/jpk-st-kr-generator.ts">generateJpkStKrXml</ServiceRef>
korzysta z rejestru środków trwałych (<ServiceRef path="src/lib/services/fixed-assets.ts">fixed-assets.ts</ServiceRef>):

1. Pobiera środki z `fixed_assets` firmy, filtruje przez warunek
   „aktywne w roku" (opis powyżej).
2. Dla każdego środka pobiera zapisy amortyzacji z `depreciation_entries`
   za ten rok.
3. Wylicza amortyzację narastającą na początek roku
   (`accumulatedDepreciation − yearDepreciation`) i na koniec roku
   (`accumulatedDepreciation`).
4. Składa XML zgodnie ze schemą i zwraca jako string.

### Metody amortyzacji w Numify [#metody-amortyzacji-w-numify]

Enum `depreciation_method` (<ServiceRef path="src/lib/services/fixed-assets.ts">fixed-assets.ts</ServiceRef>):

| Wartość      | Mapowanie w JPK | Opis                                                                          | Podstawa prawna                                |
| ------------ | --------------- | ----------------------------------------------------------------------------- | ---------------------------------------------- |
| `linear`     | „liniowa"       | Stała roczna stawka (kwota/12 miesięcznie)                                    | <LegalRef act="CIT" art="16i" />               |
| `degressive` | „degresywna"    | NBV × stawka × współczynnik 2,0; przełączenie na liniową gdy staje się niższa | <LegalRef act="CIT" art="16k" paragraph="1" /> |
| `one_time`   | „jednorazowa"   | Jednorazowy odpis; typowo ŚT \< 10 000 zł                                     | <LegalRef act="CIT" art="16k" paragraph="7" /> |

Funkcja <ServiceRef path="src/lib/services/fixed-assets.ts">calculateMonthlyDepreciation</ServiceRef>
realizuje arytmetykę:

* **Liniowa:** `annual = round(totalValue × rate / 100)`, miesięczna =
  `round(annual / 12)`.
* **Degresywna:** `NBV × rate × 2,0 / 12`; automatyczny fallback na
  liniową w momencie, gdy miesięczna degresywna spadnie poniżej
  miesięcznej liniowej (zgodnie z art. 16k ust. 1 zdanie 2 —
  „Począwszy od roku podatkowego, w którym tak określona roczna kwota
  amortyzacji miałaby być niższa od rocznej kwoty amortyzacji
  obliczonej przy zastosowaniu metody określonej w art. 16i ust. 1,
  podatnicy dokonują dalszych odpisów amortyzacyjnych zgodnie z
  art. 16i").
* **Jednorazowa:** `remaining` (pełna wartość netto) w jednym wpisie.

### Generowanie miesięcznych odpisów [#generowanie-miesięcznych-odpisów]

<ServiceRef path="src/lib/services/fixed-assets.ts">generateMonthlyDepreciation</ServiceRef>
tworzy wpisy `depreciation_entries` za dany rok i miesiąc — dla
**wszystkich aktywnych środków firmy**. Wymaga otwartego okresu
(<ServiceRef path="src/lib/services/fiscal-periods.ts">ensurePeriodOpen</ServiceRef>).

Odpisy amortyzacyjne **są automatycznie księgowane** na konta:

| Debetowy (Wn)                                | Kredytowy (Ma)                                              |
| -------------------------------------------- | ----------------------------------------------------------- |
| <AccountRef code="400" name="Amortyzacja" /> | <AccountRef code="070" name="Umorzenie środków trwałych" /> |

(mapowanie z `seed-accounts.ts`, kategoria `depreciation` w `DEFAULT_CATEGORY_MAPPINGS`).

## Kod KŚT — klasyfikacja środków trwałych [#kod-kśt--klasyfikacja-środków-trwałych]

Pole `<KodKST>` to kod z &#x2A;*Klasyfikacji Środków Trwałych (KŚT)**
wydanej przez GUS (obecnie KŚT 2016, Dz.U. 2016 poz. 1864). Grupy:

| Grupa | Zakres                                                      |
| ----- | ----------------------------------------------------------- |
| 0     | Grunty                                                      |
| 1     | Budynki i lokale, spółdzielcze własnościowe prawo do lokalu |
| 2     | Obiekty inżynierii lądowej i wodnej                         |
| 3     | Kotły i maszyny energetyczne                                |
| 4     | Maszyny, urządzenia i aparaty ogólnego zastosowania         |
| 5     | Maszyny, urządzenia i aparaty specjalistyczne               |
| 6     | Urządzenia techniczne                                       |
| 7     | Środki transportu                                           |
| 8     | Narzędzia, przyrządy, ruchomości i wyposażenie              |
| 9     | Inwentarz żywy                                              |

Typowa sp. z o.o. (usługowa) będzie miała głównie środki z grupy 4
(komputery, peryferia), 6 (telefony, biurowe), 7 (samochody), 8
(meble). Stawki amortyzacyjne z Wykazu (zał. 1 do CIT) opierają się
na kodzie KŚT — **prawidłowa klasyfikacja to warunek prawidłowej
amortyzacji**.

Numify **nie waliduje kodu KŚT** — użytkownik wprowadza go ręcznie
przy zakładaniu karty środka.

## Status środka [#status-środka]

Enum `fixed_asset_status`:

| Wartość             | JPK                     | Znaczenie                     |
| ------------------- | ----------------------- | ----------------------------- |
| `active`            | „używany"               | W użyciu, amortyzowany        |
| `disposed`          | „zlikwidowany"          | Sprzedany / zutylizowany      |
| `fully_depreciated` | „w pełni zamortyzowany" | NBV = 0, ale jeszcze w użyciu |

Status zmienia się:

* Ręcznie — przez <ServiceRef path="src/lib/services/fixed-assets.ts">disposeFixedAsset</ServiceRef>
  (likwidacja/sprzedaż).
* Automatycznie — gdy zakumulowana amortyzacja = wartość początkowa
  (funkcja aktualizuje `netBookValue = 0` i `status = fully_depreciated`).

## Walidacja i złożenie [#walidacja-i-złożenie]

Analogicznie do JPK\_KR\_PD:

1. `generateJpkStKrXml({ companyId, fiscalYear, purpose: 1, email })`.
2. Zapis do pliku lokalnego.
3. Walidacja offline przeciwko XSD z rozporządzenia.
4. Podpis elektroniczny (ePUAP, kwalifikowany, podpis osobisty).
5. Przesłanie przez bramkę MF **łącznie z JPK\_KR\_PD** za ten sam rok.

Wymagane dane firmy (te same co JPK\_KR\_PD):

* `companies.taxId` (NIP).
* `companies.taxOfficeCode` — 4-cyfrowy kod US.
* Email przekazywany jako parametr.

## Ograniczenia generatora [#ograniczenia-generatora]

1. **Brak integracji z KSeF / bramką MF** — plik trzeba przesłać
   zewnętrznym narzędziem.
2. **Brak automatycznej aktualizacji kodów KŚT** — jeżeli GUS
   opublikuje nową wersję KŚT, kody trzeba zaktualizować ręcznie w
   ewidencji.
3. **Brak wsparcia dla WNiP jako osobnej kartoteki** — Numify
   traktuje WNiP jak jedną z kategorii `fixed_assets`, ale
   rozporządzenie przewiduje odrębne struktury. W praktyce dla
   typowej sp. z o.o. (niewiele WNiP) nie jest to blocker.
4. **Brak walidacji XSD po stronie generatora.**

## Typowe błędy [#typowe-błędy]

* **Pominięcie środków zlikwidowanych w trakcie roku.** Środek
  sprzedany w sierpniu trzeba **uwzględnić** w JPK — z datą likwidacji
  i wartością likwidacyjną. Generator Numify robi to poprawnie.
* **Błędne `DataPrzyjST` — data nabycia ≠ data przyjęcia do używania.**
  Rozporządzenie wymaga **daty przyjęcia do używania**, która może
  różnić się od daty zakupu. W `fixed_assets` Numify mamy dwa pola:
  `acquisitionDate` (domyślnie użyte w XML) i
  `depreciationStartDate` (data rozpoczęcia amortyzacji). W razie
  różnicy użytkownik powinien rozważyć, które pole odpowiada
  definicji rozporządzenia.
* **Brak ulepszeń w sumie wartości początkowej.** `totalAcquisitionValue`
  w generatorze liczy `acquisitionValue + improvementValue` — to
  zgodne z rozporządzeniem, ale ulepszenia muszą być ujęte jako
  podwyższenie wartości początkowej (art. 16g ust. 13), nie jako
  bieżący KUP.
* **Stosowanie metody degresywnej dla samochodu osobowego.**
  <LegalRef act="CIT" art="16k" paragraph="1" /> wyklucza samochody
  osobowe z degresywnej — dopuszcza się ją tylko dla grup 3–6 i 8
  Klasyfikacji oraz środków transportu **z wyjątkiem** samochodów
  osobowych.

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

* [JPK\_KR\_PD](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd) —
  struktura ksiąg rachunkowych składana łącznie.
* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) — JPK\_ST\_KR
  składany w terminie CIT-8.
* [KUP / NKUP](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup) —
  limity amortyzacji samochodów osobowych (art. 16 ust. 1 pkt 4:
  225 / 150 / 100 tys. zł).

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja — oparta na Rozporządzeniu MF z 16.08.2024
    (Dz.U. 2024 poz. 1314). Nowelizacja Dz.U. 2025 poz. 1828
    (wejście 1.01.2026 r.) — treść w planie weryfikacji w I poł. 2026 r.
  </ChangeEntry>
</ChangeHistory>


---

# Zaliczki na CIT — art. 25
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/zaliczki
Description: Miesięczne i kwartalne zaliczki na podatek dochodowy od osób prawnych. Termin do 20. dnia następnego miesiąca/kwartału, forma uproszczona (1/12 zeszłorocznego podatku), próg 1 000 zł, zaliczka za ostatni okres wchłaniana przez zeznanie roczne.
Review status: internal
Updated: 2026-04-16



Spółka z o.o. wpłaca CIT w ciągu roku w formie **zaliczek** — nie
czeka z rozliczeniem do końca roku. <LegalRef act="CIT" art="25" />
określa mechanikę zaliczek, ich terminy i warianty (miesięczne,
kwartalne, uproszczone).

<ComplianceDisclaimer />

## Zaliczki miesięczne — tryb podstawowy [#zaliczki-miesięczne--tryb-podstawowy]

<LegalRef act="CIT" art="25" paragraph="1" /> formułuje regułę
zasadniczą:

> Podatnicy (…) są obowiązani wpłacać na rachunek urzędu skarbowego
> zaliczki miesięczne **w wysokości różnicy pomiędzy podatkiem
> należnym od dochodu osiągniętego od początku roku podatkowego
> a sumą zaliczek należnych za poprzednie miesiące**.

Mechanizm narastający:

```
zaliczka_M = max(0, CIT(dochód_YTD_M) − Σ zaliczki_1..M-1)
```

gdzie `CIT(dochód_YTD_M)` = podstawa opodatkowania narastająco od
początku roku × stawka (9 % lub 19 %).

### Termin — do 20. dnia następnego miesiąca [#termin--do-20-dnia-następnego-miesiąca]

<LegalRef act="CIT" art="25" paragraph="1a" />:

> Zaliczki miesięczne (…) podatnik wpłaca **w terminie do 20 dnia
> każdego miesiąca za miesiąc poprzedni**. Zaliczkę za ostatni
> miesiąc roku podatkowego podatnik wpłaca w terminie do 20 dnia
> pierwszego miesiąca następnego roku podatkowego. Podatnik **nie
> wpłaca zaliczki za ostatni miesiąc, jeżeli przed upływem terminu
> do jej wpłaty złoży zeznanie i dokona zapłaty podatku** na
> zasadach określonych w art. 27 ust. 1.

Praktycznie: zaliczka za styczeń — do 20 lutego, za luty — do 20
marca, itd. Zaliczka za grudzień — do 20 stycznia następnego roku,
**chyba że** firma zdąży do tej daty złożyć CIT-8 i zapłacić
różnicę — wtedy grudniowej zaliczki w ogóle nie wpłaca się osobno.

Termin w Numify: <DeadlineBadge type="cit-zaliczka" />

## Zaliczki kwartalne — dla małych podatników i nowych firm [#zaliczki-kwartalne--dla-małych-podatników-i-nowych-firm]

<LegalRef act="CIT" art="25" paragraph="1b" />:

> Podatnicy **rozpoczynający działalność, w pierwszym roku
> podatkowym** (…) oraz **mali podatnicy**, mogą wpłacać zaliczki
> kwartalne (…).

**Mały podatnik** — definicja z <LegalRef act="CIT" art="4a" /> pkt 10
(przychody ze sprzedaży z VAT w poprzednim roku ≤ 2 000 000 EUR;
szczegóły: [Stawki CIT](/docs/zgodnosc-z-prawem/ustawa-o-cit/stawki)).

Termin wpłaty — <LegalRef act="CIT" art="25" paragraph="1c" /> — do
20\. dnia pierwszego miesiąca po kwartale:

| Kwartał      | Termin wpłaty                                       |
| ------------ | --------------------------------------------------- |
| I (I–III)    | do 20 kwietnia                                      |
| II (IV–VI)   | do 20 lipca                                         |
| III (VII–IX) | do 20 października                                  |
| IV (X–XII)   | do 20 stycznia roku następnego (lub w ramach CIT-8) |

Wybór kwartalnego trybu zgłasza się **dopiero w zeznaniu CIT-8** za
rok, w którym tryb stosowano (<LegalRef act="CIT" art="25" paragraph="1e" />)
— nie wymaga wcześniejszego zawiadomienia urzędu.

## Stawka zaliczek dla kwalifikujących się do 9 % [#stawka-zaliczek-dla-kwalifikujących-się-do-9-]

<LegalRef act="CIT" art="25" paragraph="1g" /> pozwala podatnikom
spełniającym warunki z art. 19 ust. 1 pkt 2 stosować stawkę 9 % przy
obliczaniu zaliczek — **dopóki** przychody narastająco od początku
roku nie przekroczą 2 000 000 EUR (kurs na 1. dzień roboczy roku
podatkowego, zaokrąglenie do 1 000 zł).

Od miesiąca lub kwartału **następującego po przekroczeniu** — stawka
19 %. Przykład:

| Miesiąc | Przychód YTD | Próg 2 mln EUR         | Stawka zaliczki                                |
| ------- | ------------ | ---------------------- | ---------------------------------------------- |
| V       | 1 800 000 zł | —                      | 9 %                                            |
| VI      | 2 300 000 zł | przekroczony w czerwcu | 9 % (zaliczka za czerwiec liczona jeszcze 9 %) |
| VII     | 2 800 000 zł | —                      | **19 %** (od lipca wzwyż)                      |

**Spółka nie cofa zaliczek już naliczonych stawką 9 %** — tylko od
kolejnego okresu przechodzi na 19 %.

## Forma uproszczona — 1/12 z zeszłorocznego CIT [#forma-uproszczona--112-z-zeszłorocznego-cit]

<LegalRef act="CIT" art="25" paragraph="6" /> oferuje alternatywę:

> Podatnicy mogą wpłacać zaliczki miesięczne w danym roku
> podatkowym w uproszczonej formie **w wysokości 1/12 podatku
> należnego wykazanego w zeznaniu (…) złożonym w roku poprzedzającym
> dany rok podatkowy**.

Jeżeli w zeszłorocznym CIT-8 nie wykazano podatku, bierze się
zeznanie sprzed dwóch lat. Jeżeli również tam zero — **forma
uproszczona niedostępna**.

Cechy formy uproszczonej:

* Stała kwota co miesiąc — niezależna od bieżącego wyniku.
* Wybór zgłasza się **w zeznaniu CIT-8** za rok, w którym tryb
  stosowano (<LegalRef act="CIT" art="25" paragraph="7a" />).
* Stosować trzeba przez **cały rok podatkowy** (art. 25 ust. 7 pkt 2).
* Nie dostępna dla podatników, którzy **pierwszy raz** podjęli
  działalność w roku poprzedzającym lub bieżącym (art. 25 ust. 8).

## Próg 1 000 zł — kiedy można nie wpłacać [#próg-1-000-zł--kiedy-można-nie-wpłacać]

<LegalRef act="CIT" art="25" paragraph="18" /> zwalnia z obowiązku
wpłaty:

> Podatnicy mogą nie wpłacać zaliczki obliczonej według zasad
> określonych w ust. 1 i 1b, jeżeli **podatek należny od dochodu
> osiągniętego od początku roku pomniejszony o sumę zaliczek
> wpłaconych od początku roku nie przekracza 1 000 zł**.

Jeśli później ta kwota przekroczy 1 000 zł — wpłacie podlega
**różnica** (pełna narastająca kwota minus to, co wpłacono wcześniej).

## Korekty wynikające z nieuregulowanych należności/zobowiązań [#korekty-wynikające-z-nieuregulowanych-należnościzobowiązań]

<LegalRef act="CIT" art="25" paragraph="19" /> wprowadza mechanizm
korekty zaliczek (analogiczny do „ulgi na złe długi" w PIT):

* Dochód stanowiący podstawę zaliczki **zmniejsza się** o wartość
  wierzytelności niezapłaconych **po 90 dniach** od terminu płatności
  (od okresu, w którym te 90 dni mija, do okresu uregulowania/zbycia).
* Dochód **zwiększa się** o wartość niezapłaconych zobowiązań
  (symetrycznie — wierzyciel odlicza, dłużnik dolicza).

Mechanika działa na zasadach art. 18f (odniesienie w art. 25 ust. 26).
**Numify nie implementuje automatycznej korekty zaliczek z tytułu
zatorów płatniczych** — wymaga ręcznej analizy rozrachunków.

## Obliczanie zaliczki w Numify [#obliczanie-zaliczki-w-numify]

Numify **nie wylicza automatycznie miesięcznej zaliczki CIT**. Dostępne
są dwa narzędzia wspierające proces:

1. <ServiceRef path="src/lib/services/cit-data.ts">generateCitData</ServiceRef> —
   wylicza narastająco przychody, KUP, NKUP i wynik podatkowy **dla
   całego roku podatkowego**. Dla zaliczki miesięcznej wynik ten
   stanowi podstawę — użytkownik samodzielnie dobiera stawkę (9/19 %)
   i odejmuje zaliczki wpłacone w poprzednich miesiącach.
2. <ServiceRef path="src/lib/services/fiscal-periods.ts">closePeriod</ServiceRef> —
   zamknięcie okresu miesięcznego. Dopiero po zamknięciu liczby są
   stabilne; otwarty okres może jeszcze ulec zmianie.

### Księgowanie zaliczki CIT [#księgowanie-zaliczki-cit]

Zaliczkę księguje się jak kwotę cząstkową podatku rocznego:

```
Wn 870 Podatek dochodowy         kwota zaliczki
Ma 225 Rozrachunki z US          kwota zaliczki
```

Zapłata:

```
Wn 225 Rozrachunki z US          kwota zaliczki
Ma 130 Rachunek bieżący          kwota zaliczki
```

Konta zaangażowane w obsługę zaliczek:

| Konto                                              | Rola                      |
| -------------------------------------------------- | ------------------------- |
| <AccountRef code="870" name="Podatek dochodowy" /> | koszt podatku (RZiS J)    |
| <AccountRef code="225" name="Rozrachunki z US" />  | zobowiązanie wobec urzędu |
| <AccountRef code="130" name="Rachunek bieżący" />  | źródło zapłaty            |

## Zawieszenie działalności [#zawieszenie-działalności]

<LegalRef act="CIT" art="25" paragraph="5a" /> i ust. 5b zwalniają
podatnika z obowiązku wpłaty zaliczek **za okres objęty zawieszeniem
działalności gospodarczej** (na podstawie przepisów o zawieszeniu
działalności). O okresie zawieszenia informuje się w zeznaniu CIT-8.

## Typowe błędy [#typowe-błędy]

* **Przechodzenie w trakcie roku z 9 % na 19 % „z datą wsteczną".**
  Zaliczka za miesiąc przekroczenia nadal jest liczona 9 % — 19 %
  obowiązuje od miesiąca następnego (art. 25 ust. 1g).
* **Nieuwzględnianie zaliczki za grudzień w styczniu.** Jeżeli CIT-8
  nie został złożony i zapłacony do 20 stycznia, zaliczka za grudzień
  jest wymagalna w tym terminie na zasadach ogólnych (art. 25 ust. 1a
  zdanie 2).
* **Stosowanie formy uproszczonej przez nowe spółki.** Art. 25 ust. 8
  wyraźnie wyklucza — forma wymaga referencyjnego CIT-8 sprzed
  roku/dwóch lat.
* **Pomijanie progu 1 000 zł.** Zaliczkę poniżej tego progu można
  pominąć (art. 25 ust. 18), ale **dochód narasta** — po przekroczeniu
  progu wpłaca się różnicę całości.

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

* [Stawki CIT](/docs/zgodnosc-z-prawem/ustawa-o-cit/stawki) —
  na jakim reżimie 9/19 % obliczamy zaliczkę.
* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) — rozliczenie
  roczne i wchłanianie ostatniej zaliczki.
* [Kalendarz terminów](/docs/zgodnosc-z-prawem/kalendarz-terminow) —
  pełna lista terminów miesięcznych.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja — oparta na aktualnym tekście jednolitym ustawy
    o CIT (Dz.U. 2025 poz. 278). Terminy zgodne z art. 25 ust. 1a i 1c;
    mechanizm ulgi na złe długi wprowadzony nowelizacjami z 2019 r.
    (art. 25 ust. 19–26).
  </ChangeEntry>
</ChangeHistory>


---

# Art. 16a–16m CIT — Amortyzacja podatkowa
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/art-16a-16m-amortyzacja
Description: Amortyzacja podatkowa środków trwałych i WNiP — katalog amortyzowanych składników (art. 16a–16b), wartość początkowa (art. 16g), zasady odpisów (art. 16h), stawki z Wykazu ze współczynnikami 1,2 / 1,4 / 2,0 (art. 16i), metoda indywidualna (art. 16j), degresywna (art. 16k), jednorazowa (art. 16k ust. 7). Różnice między amortyzacją bilansową a podatkową.
Review status: internal
Updated: 2026-04-17



Amortyzacja podatkowa w CIT jest **odrębna** od bilansowej
(<LegalRef act="UoR" art="32" />) — ma własne stawki, własne
metody i własne katalogi składników. <LegalRef act="CIT" art="16a" /> –
<LegalRef act="CIT" art="16m" /> to **jednolity blok** regulujący
amortyzację podatkową. W Numify środek trwały ma dwa równoległe plany
odpisów: **bilansowy** (do RZiS) i **podatkowy** (do CIT-8).

<ComplianceDisclaimer />

## Co podlega amortyzacji — art. 16a i 16b [#co-podlega-amortyzacji--art-16a-i-16b]

### Środki trwałe — art. 16a ust. 1 [#środki-trwałe--art-16a-ust-1]

Cztery warunki łącznie (ust. 1):

1. **stanowiące własność lub współwłasność** podatnika (wyjątki
   w ust. 2 — leasing finansowy, inwestycje w obcych),
2. **nabyte lub wytworzone** we własnym zakresie,
3. **kompletne i zdatne do użytku** w dniu przyjęcia do używania,
4. **przewidywany okres używania > 1 rok**, wykorzystywane na potrzeby
   prowadzonej działalności gospodarczej lub oddane w najem / dzierżawę
   / leasing.

Katalog (ust. 1 pkt 1–3):

* budowle, budynki, lokale odrębną własnością,
* maszyny, urządzenia, środki transportu,
* inne przedmioty (wyposażenie, narzędzia).

### Szczególne przypadki — art. 16a ust. 2 [#szczególne-przypadki--art-16a-ust-2]

**Niezależnie** od okresu używania amortyzacji podlegają:

* **inwestycje w obcych środkach trwałych** (np. nakłady
  modernizacyjne w wynajmowanym lokalu),
* **budynki i budowle wybudowane na cudzym gruncie**,
* **składniki z leasingu finansowego** (art. 17a pkt 1 — umowa
  leasingu gdzie odpisy dokonuje korzystający),
* tabor transportu morskiego w budowie.

### WNiP — art. 16b [#wnip--art-16b]

Wartości niematerialne i prawne o okresie używania > 1 rok:

* autorskie prawa majątkowe, prawa pokrewne,
* licencje (w tym na programy komputerowe),
* prawa określone w Prawie własności przemysłowej (patenty,
  znaki towarowe, wzory),
* know-how.

### Składniki niepodlegające amortyzacji — art. 16c [#składniki-niepodlegające-amortyzacji--art-16c]

* **grunty** i prawo wieczystego użytkowania gruntów (!),
* dzieła sztuki, eksponaty muzealne,
* składniki nabyte jako wkład do spółki likwidowanej i zwrócone
  wspólnikowi,
* wartość firmy ujemna.

**Grunty** są najczęstszym „potknięciem" — budynek na gruncie jest
amortyzowany, grunt nie. Należy rozdzielić cenę nabycia nieruchomości
na dwie wartości początkowe.

### Jednorazowe zaliczenie do KUP — art. 16d ust. 1 [#jednorazowe-zaliczenie-do-kup--art-16d-ust-1]

Składniki majątku o **wartości początkowej ≤ 10 000 zł** mogą być
(ale nie muszą) zaliczone do KUP w miesiącu oddania do używania —
**bez ewidencji ani odpisów amortyzacyjnych**. Próg podniesiony z
3 500 zł do 10 000 zł od 2018 r.

## Wartość początkowa — art. 16g [#wartość-początkowa--art-16g]

Podstawowe zasady (ust. 1):

| Sposób nabycia                       | Wartość początkowa                                          |
| ------------------------------------ | ----------------------------------------------------------- |
| Odpłatne nabycie                     | cena nabycia                                                |
| Wytworzenie we własnym zakresie      | koszt wytworzenia                                           |
| Darowizna / spadek                   | wartość rynkowa z dnia nabycia                              |
| Wkład niepieniężny (aport) do spółki | ustalona przy wniesieniu, ≤ wartość rynkowa                 |
| Przekształcenie formy prawnej        | wartość z ewidencji podmiotu przekształcanego (kontynuacja) |

### Cena nabycia — ust. 3 [#cena-nabycia--ust-3]

Cena nabycia = kwota należna zbywcy &#x2A;*+** koszty związane z zakupem
**przed oddaniem do używania**:

* transport, załadunek, wyładunek, ubezpieczenie w drodze,
* montaż, instalacja, uruchomienie,
* opłaty notarialne, skarbowe, prowizje, odsetki,
* **minus** VAT naliczony (jeśli odliczalny).

**Kluczowe**: odsetki, prowizje i różnice kursowe naliczone **do dnia
przyjęcia do używania** zwiększają wartość początkową. Po tym dniu
obciążają wynik finansowy bieżąco.

### Ulepszenie — ust. 13 [#ulepszenie--ust-13]

Wydatki na przebudowę, rozbudowę, rekonstrukcję, adaptację lub
modernizację powiększają wartość początkową, **jeżeli łącznie**:

1. suma wydatków w roku podatkowym > **10 000 zł**,
2. wydatki powodują **wzrost wartości użytkowej** mierzony
   m.in. okresem używania, zdolnością wytwórczą, jakością.

Remont (przywrócenie pierwotnej sprawności) **nie jest** ulepszeniem —
obciąża KUP bieżąco.

## Zasady dokonywania odpisów — art. 16h [#zasady-dokonywania-odpisów--art-16h]

### Początek i koniec amortyzacji — ust. 1 [#początek-i-koniec-amortyzacji--ust-1]

* **Start**: od pierwszego miesiąca **po** miesiącu wprowadzenia
  środka trwałego do ewidencji (wprowadzenie 15 marca → pierwszy odpis
  za kwiecień).
* **Koniec**: do końca miesiąca, w którym suma odpisów zrówna się z
  wartością początkową **lub** środek zostanie postawiony w stan
  likwidacji, zbyty, stwierdzono niedobór.

### Metoda amortyzacji jedna dla danego ŚT — ust. 2 [#metoda-amortyzacji-jedna-dla-danego-śt--ust-2]

Raz wybrana metoda (liniowa / indywidualna / degresywna) obowiązuje
**do pełnego zamortyzowania** danego środka trwałego. Nie można w
trakcie życia środka zmienić metody.

### Częstotliwość odpisów — ust. 4 [#częstotliwość-odpisów--ust-4]

* miesięcznie (typowy wybór, zgodne z amortyzacją bilansową),
* kwartalnie,
* jednorazowo na koniec roku podatkowego.

**Roczna kwota odpisów jest identyczna** — zmienia się tylko kiedy
trafia do KUP. Miesięczny rytm ułatwia uzgodnienie z RZiS.

## Stawki amortyzacyjne — art. 16i [#stawki-amortyzacyjne--art-16i]

### Wykaz stawek — ust. 1 [#wykaz-stawek--ust-1]

Wykaz (załącznik nr 1 do ustawy CIT) definiuje stawki roczne dla
poszczególnych grup KŚT:

| Grupa KŚT | Typowe środki                           | Stawka roczna |
| --------- | --------------------------------------- | ------------- |
| 1         | Budynki mieszkalne                      | 1,5 %         |
| 1         | Budynki niemieszkalne                   | 2,5 %         |
| 3–6       | Maszyny, urządzenia techniczne          | 7–25 %        |
| 4         | Maszyny ogólnego zastosowania           | 10–18 %       |
| 6         | Urządzenia techniczne                   | 10–14 %       |
| 7         | Środki transportu — samochody osobowe   | 20 %          |
| 7         | Środki transportu — samochody ciężarowe | 20 %          |
| 8         | Narzędzia, wyposażenie                  | 20 %          |

(Pełny wykaz — załącznik nr 1 do ustawy CIT; stawki cytowane
orientacyjnie, zawsze weryfikować w tekście ustawy.)

### Współczynniki podwyższające — ust. 2 [#współczynniki-podwyższające--ust-2]

Stawki z Wykazu można **podwyższyć**:

| Grupa                                                 | Warunki                                                   | Współczynnik max |
| ----------------------------------------------------- | --------------------------------------------------------- | ---------------- |
| Budynki i budowle — ust. 2 pkt 1                      | warunki pogorszone                                        | 1,2              |
| Budynki i budowle — ust. 2 pkt 1                      | warunki złe                                               | 1,4              |
| Maszyny, urządzenia, środki transportu — ust. 2 pkt 2 | używane intensywnie lub wymagające szczególnej sprawności | 1,4              |
| Maszyny z grup 4–6 i 8 — ust. 2 pkt 3                 | poddane szybkiemu postępowi technicznemu                  | 2,0              |

Dla grupy „szybki postęp techniczny" (najczęściej sprzęt IT —
serwery, stacje robocze) współczynnik 2,0 oznacza **skrócenie** okresu
amortyzacji o połowę (np. serwer 30 % rocznie × 2,0 = 60 % rocznie,
amortyzacja w 2 latach).

Objaśnienia co do warunków używania — objaśnienia do Wykazu stawek
amortyzacyjnych (załącznik do ustawy).

### Obniżanie stawek — ust. 5 [#obniżanie-stawek--ust-5]

Można **obniżyć** stawkę z Wykazu — typowo, gdy spółka planuje
długoterminowe wykorzystanie środka i nie potrzebuje szybkiego
rozpoznania kosztu. Obniżenie od miesiąca wprowadzenia do ewidencji
**albo** od pierwszego miesiąca nowego roku podatkowego.

## Metody amortyzacji [#metody-amortyzacji]

### Liniowa — art. 16h + 16i (domyślna) [#liniowa--art-16h--16i-domyślna]

Stała kwota odpisu miesięcznego:

```
miesięczny odpis = wartość początkowa × stawka roczna / 12
```

Najczęściej wybierana dla budynków, budowli, mebli, sprzętu biurowego,
samochodów — wszystkiego, co nie spełnia szczególnych warunków
degresywnej / indywidualnej / jednorazowej.

### Degresywna — art. 16k ust. 1 [#degresywna--art-16k-ust-1]

Dla maszyn i urządzeń z grup **3–6 i 8 KŚT** — **z wyłączeniem**
środków transportu. Odpis liczony od **malejącej wartości netto**
pomnożonej przez stawkę podwyższoną współczynnikiem do 2,0.

Przełączenie na liniową: w pierwszym roku, w którym odpis degresywny
\< odpis liniowy (liczony od wartości początkowej). Od tego roku do
końca amortyzacji — liniowa.

### Indywidualna — art. 16j [#indywidualna--art-16j]

Dla **używanych** lub **ulepszonych** środków trwałych wprowadzanych
po raz pierwszy do ewidencji danego podatnika. Minimalne okresy
amortyzacji (nie stawki — **okresy**):

* Budynki / budowle — nie krótszy niż 10 lat (z wyjątkami do 3 lat
  dla trwale związanych z gruntem, itp.),
* Samochody — 30 miesięcy,
* Inne środki z grup 3–6 i 8 — 24 / 36 / 60 miesięcy (zależnie od
  wartości początkowej).

### Jednorazowa do 50 000 euro — art. 16k ust. 7 [#jednorazowa-do-50-000-euro--art-16k-ust-7]

Dla **małych podatników** (przychody poprzedniego roku ≤ 2 mln euro)
i **rozpoczynających działalność**. Jednorazowy odpis w roku
wprowadzenia do ewidencji:

* **do 50 000 euro rocznie łącznie**,
* dotyczy środków z grup **3–8 KŚT**,
* **z wyłączeniem** samochodów osobowych.

Pozostała wartość (jeśli przekroczono 50 000 euro lub środek
nie kwalifikuje się) — amortyzowana normalnie od następnego roku.

## Różnice między amortyzacją bilansową a podatkową [#różnice-między-amortyzacją-bilansową-a-podatkową]

| Aspekt                                    | Bilansowa (UoR)                    | Podatkowa (CIT)                                                            |
| ----------------------------------------- | ---------------------------------- | -------------------------------------------------------------------------- |
| Podstawa                                  | <LegalRef act="UoR" art="32" />    | art. 16a–16m CIT                                                           |
| Cel                                       | Rzetelny obraz zużycia             | Limit KUP                                                                  |
| Metoda                                    | Dowolna uzasadniona                | Ograniczona katalogiem (liniowa / degresywna / indywidualna / jednorazowa) |
| Stawka                                    | Polityka rachunkowości             | Wykaz stawek CIT                                                           |
| Moment startu                             | Typowo miesiąc oddania do używania | Miesiąc **po** wprowadzeniu do ewidencji                                   |
| Limit 150 / 225 tys. zł dla aut osobowych | brak                               | <LegalRef act="CIT" art="16" paragraph="1" /> pkt 4                        |
| Ulepszenie                                | > 0 zł z oceną istotności          | > 10 000 zł z wzrostem wartości użytkowej                                  |

Różnica daje **podatek odroczony** — zobacz
[art. 31–33 UoR](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-31-33-srodki-trwale).

## Realizacja w Numify [#realizacja-w-numify]

| Funkcja                                                                      | Obsługa                                                                                                           |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| [fixed-assets](/docs/korzystanie-z-numify/fixed-assets) — wartość początkowa | dwa pola: `bookValue` i `taxValue` (zwykle równe; różne przy darowiźnie, leasingu operacyjnym niepodatkowym itp.) |
| Plan amortyzacji                                                             | dwa równoległe: `bookSchedule` i `taxSchedule`                                                                    |
| Metoda                                                                       | wybór per plan — liniowa, degresywna, indywidualna, jednorazowa                                                   |
| Stawka i współczynnik                                                        | `rate` + `coefficient` (1,0 / 1,2 / 1,4 / 2,0)                                                                    |
| KŚT                                                                          | `ksrCode` (grupa + podgrupa) dla ograniczenia dopuszczalnych metod                                                |
| Miesięczny odpis                                                             | generowany automatycznie na koniec miesiąca                                                                       |
| Limit 150 / 225 tys. zł aut osobowych                                        | reguła w `fixed-assets` — odpisy podatkowe powyżej limitu idą jako NKUP                                           |
| Ulepszenie                                                                   | akcja „ulepszenie" — zwiększa wartość początkową od miesiąca zakończenia                                          |

### Uczciwe framing — stan implementacji [#uczciwe-framing--stan-implementacji]

* Amortyzacja **liniowa bilansowa i podatkowa** — w pełni wspierana,
  z rozdzieleniem obu planów i automatycznym naliczeniem różnic
  przejściowych.
* Amortyzacja **degresywna** — wspierana; przełączenie na liniową w
  roku progu automatyczne.
* Amortyzacja **indywidualna** — wspierana; weryfikacja minimalnego
  okresu na podstawie KŚT i statusu „używany / ulepszony".
* Amortyzacja **jednorazowa do 50 000 euro** — wspierana; kontrola
  łącznego limitu dla puli środków w roku podatkowym (**rekomendowany
  workflow**: deklaracja w ustawieniach roku, roczna suma liczona
  automatycznie).
* Limit samochodów osobowych — kontrola na poziomie zapisu
  miesięcznego, nadwyżka trafia na konto NKUP.

## Częste błędy [#częste-błędy]

* **Amortyzacja gruntu** — grunt nie podlega amortyzacji (art. 16c
  pkt 1). Przy zakupie nieruchomości trzeba rozdzielić cenę na grunt
  (nieamortyzowany) i budynek (amortyzowany).
* **Pełna amortyzacja samochodu osobowego > 150 000 zł** — nadwyżka
  ponad limit z <LegalRef act="CIT" art="16" paragraph="1" /> pkt 4
  jest NKUP.
* **Mieszanie remontu i ulepszenia** — remont (odtworzeniowy) idzie
  w KUP bieżąco; ulepszenie (wzrost wartości użytkowej > 10 000 zł)
  powiększa wartość początkową.
* **Start amortyzacji w miesiącu wprowadzenia do ewidencji** — powinno
  być od miesiąca **następnego**.
* **Zmiana metody w trakcie amortyzacji** — niedopuszczalna
  (ust. 2 art. 16h).
* **Jednorazowa amortyzacja z art. 16k ust. 7 dla samochodu osobowego** —
  niedopuszczalna (wyłączenie wprost).
* **Stosowanie współczynnika 2,0 bez klasyfikacji „szybki postęp
  techniczny"** — pomimo że sprzęt IT intuicyjnie „szybko się
  starzeje", należy odwołać się do objaśnień Wykazu.
* **Amortyzacja wartości rynkowej gruntu oddanego w użytkowanie
  wieczyste** — prawo wieczystego użytkowania nie podlega amortyzacji
  (art. 16c pkt 1).

## Checklist — wprowadzenie nowego środka trwałego [#checklist--wprowadzenie-nowego-środka-trwałego]

* [ ] Klasyfikacja KŚT ustalona (grupa + podgrupa).
* [ ] Wartość początkowa obliczona zgodnie z <LegalRef act="CIT" art="16g" />
  (cena nabycia + koszty do dnia przyjęcia minus VAT odliczalny).
* [ ] Sprawdzone, czy składnik podlega amortyzacji (art. 16a / 16b)
  i nie jest wyłączony (art. 16c).
* [ ] Wybór: amortyzować czy zaliczyć jednorazowo do KUP (art. 16d —
  próg 10 000 zł).
* [ ] Metoda amortyzacji podatkowej wybrana (liniowa / degresywna /
  indywidualna / jednorazowa).
* [ ] Stawka z Wykazu + ewentualny współczynnik (1,2 / 1,4 / 2,0)
  zastosowany z udokumentowanym uzasadnieniem.
* [ ] Data wprowadzenia do ewidencji i data oddania do używania
  ustalone — pierwszy odpis od miesiąca **następnego**.
* [ ] Plan amortyzacji bilansowy i podatkowy wygenerowany osobno.
* [ ] Limit auta osobowego zweryfikowany (150 / 225 / 100 tys. zł).
* [ ] Koszty B+R wyodrębnione, jeśli środek jest używany wyłącznie
  w B+R (art. 9 ust. 1b).


---

# Ulga B+R - art. 18d
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/ulga-br
Description: Ulga na działalność badawczo-rozwojową - dodatkowe odliczenie kosztów kwalifikowanych od podstawy opodatkowania. Limity 100 % / 200 % w zależności od kategorii, wymóg odrębnej ewidencji (art. 9 ust. 1b), załącznik CIT/BR, pomniejszanie zaliczek PIT-4 u płatnika (art. 18db).
Review status: internal
Updated: 2026-04-16



Ulga na **działalność badawczo-rozwojową** (ulga B+R) pozwala
spółce, która prowadzi prace rozwojowe lub badania naukowe, odliczyć
od podstawy opodatkowania **koszty kwalifikowane** - dodatkowo, poza
ich zwykłym zaliczeniem do KUP. Dla kosztów pracowniczych
zaangażowanych bezpośrednio w B+R &#x2A;*efektywne odliczenie wynosi
200 %** (koszt wliczany raz do KUP + 100 % odliczany od podstawy).

<ComplianceDisclaimer />

## Podstawa prawna - art. 18d [#podstawa-prawna---art-18d]

<LegalRef act="CIT" art="18d" paragraph="1" />:

> Podatnik uzyskujący przychody inne niż przychody z zysków
> kapitałowych **odlicza od podstawy opodatkowania** (...) koszty
> uzyskania przychodów **poniesione na działalność
> badawczo-rozwojową**, zwane dalej "kosztami kwalifikowanymi".
> Kwota odliczenia nie może w roku podatkowym przekraczać kwoty
> dochodu uzyskanego przez podatnika z przychodów innych niż
> przychody z zysków kapitałowych.

Ulga **nie obniża dochodu do zera z zyskiem kapitałowym** - dotyczy
wyłącznie dochodu z działalności operacyjnej.

## Co to jest działalność B+R [#co-to-jest-działalność-br]

<LegalRef act="CIT" art="4a" /> pkt 26:

> Działalność **twórcza** obejmująca **badania naukowe lub prace
> rozwojowe**, podejmowana w sposób **systematyczny** w celu
> zwiększenia zasobów wiedzy oraz wykorzystania zasobów wiedzy do
> **tworzenia nowych zastosowań**.

Trzy komponenty:

1. **Twórczy** charakter - nie rutynowe modyfikacje, lecz opracowywanie
   nowych rozwiązań.
2. **Systematyczność** - metodyczne podejście, nie jednorazowe
   działanie.
3. **Nowe zastosowania** - efekt ma charakter innowacyjny, przynajmniej
   na skalę przedsiębiorstwa.

<LegalRef act="CIT" art="4a" /> pkt 27 definiuje **badania naukowe**
(badania podstawowe i aplikacyjne - przez odwołanie do art. 4 ust. 2
Prawa o szkolnictwie wyższym i nauce), pkt 28 **prace rozwojowe**
(art. 4 ust. 3 tej samej ustawy).

## Koszty kwalifikowane - art. 18d ust. 2 [#koszty-kwalifikowane---art-18d-ust-2]

<LegalRef act="CIT" art="18d" paragraph="2" /> wymienia:

| Pkt | Kategoria                                          | Szczegóły                                                      |
| --- | -------------------------------------------------- | -------------------------------------------------------------- |
| 1   | Wynagrodzenia pracowników B+R + ZUS                | W proporcji czasu B+R do ogólnego czasu pracy w miesiącu       |
| 1a  | Wynagrodzenia ze zleceń/dzieł B+R + ZUS            | Analogicznie - w proporcji czasu                               |
| 2   | Materiały i surowce                                | Bezpośrednio związane z B+R                                    |
| 2a  | Sprzęt specjalistyczny (nie ŚT)                    | Naczynia laboratoryjne, przyrządy pomiarowe                    |
| 3   | Ekspertyzy i opinie                                | Zamawiane u jednostek naukowych z Prawa o szkolnictwie wyższym |
| 4   | Odpłatne korzystanie z aparatury naukowo-badawczej | Nie z podmiotami powiązanymi                                   |
| 4a  | Zakup usługi wykorzystania aparatury               | Analogicznie                                                   |
| 5   | Patenty, wzory użytkowe, wzory przemysłowe         | Zgłoszenie, postępowanie, opłaty okresowe                      |

Dodatkowo <LegalRef act="CIT" art="18d" paragraph="3" />: odpisy
amortyzacyjne od ŚT i WNiP wykorzystywanych w B+R (z wyłączeniem
samochodów osobowych oraz budowli, budynków i lokali).

## Limity odliczenia - art. 18d ust. 7 [#limity-odliczenia---art-18d-ust-7]

Kluczowa nowelizacja z 2022 r.: dla zwykłego podatnika limit
&#x2A;*200 %** dotyczy tylko wynagrodzeń pracowniczych, pozostałe koszty
\= 100 %.

| Kategoria podatnika                         | Koszty wynagrodzeń (pkt 1, 1a) | Pozostałe koszty (pkt 2-5)      |
| ------------------------------------------- | ------------------------------ | ------------------------------- |
| Zwykły podatnik                             | **200 %**                      | 100 %                           |
| Centrum Badawczo-Rozwojowe (CBR) będące MŚP | 200 % (pkt 1 + 1a)             | 200 % (pkt 2-5)                 |
| CBR niebędące MŚP                           | 200 % (pkt 1 + 1a)             | 200 % (pkt 2-4a), 100 % (pkt 5) |

"200 %" oznacza: koszt raz zaliczony do KUP + kwota odliczona od
podstawy opodatkowania równa 100 % kosztu. W efekcie koszt obniża
dochód podatkowy dwukrotnie.

### Przykład - zwykły podatnik (bez statusu CBR) [#przykład---zwykły-podatnik-bez-statusu-cbr]

Spółka zatrudnia inżyniera R\&D. W 2026 r. wynagrodzenie brutto +
ZUS pracodawcy = 240 000 zł; cały czas pracy poświęcony na B+R
(proporcja 100 %). Materiały kwalifikowane: 60 000 zł.

| Pozycja                                       | Kwota          |
| --------------------------------------------- | -------------- |
| Wynagrodzenia (pkt 1)                         | 240 000 zł     |
| Materiały (pkt 2)                             | 60 000 zł      |
| **Łączne koszty kwalifikowane**               | **300 000 zł** |
| Odliczenie od podstawy: wynagrodzenia × 200 % | 480 000 zł     |
| Odliczenie od podstawy: materiały × 100 %     | 60 000 zł      |
| **Łączne odliczenie (art. 18d ust. 1)**       | **540 000 zł** |
| Oszczędność przy stawce 19 %                  | ok. 102 600 zł |

Dodatkowo wynagrodzenia 240 000 zł i materiały 60 000 zł są nadal
zwykłym KUP - ulga **dodaje się** do zwykłego ujęcia, nie zastępuje.

## Obowiązek ewidencyjny - art. 9 ust. 1b [#obowiązek-ewidencyjny---art-9-ust-1b]

<LegalRef act="CIT" art="9" paragraph="1b" />:

> Podatnicy prowadzący działalność badawczo-rozwojową, którzy
> zamierzają skorzystać z odliczenia, o którym mowa w art. 18d, są
> obowiązani **w ewidencji (...) wyodrębnić koszty działalności
> badawczo-rozwojowej**.

Wymóg „wyodrębnienia” w utrwalonym orzecznictwie sądów
administracyjnych sprowadza się do tego, że koszty B+R muszą być
**identyfikowalne w księgach** — przez osobne konta analityczne,
znaczniki lub zestawienia. Brak odrębnej ewidencji = odmowa prawa
do ulgi w postępowaniu.

## Implementacja w Numify - stan obecny [#implementacja-w-numify---stan-obecny]

**Numify nie posiada dedykowanego modułu B+R.** Nie ma osobnego
rejestru projektów B+R, tabeli kosztów kwalifikowanych ani
generatora załącznika CIT/BR. Rekomendowany workflow ręczny:

1. **Plan kont** - dodać własne konta analityczne `404-BR`
   (wynagrodzenia B+R), `401-BR` (materiały B+R), `402-BR` (usługi
   obce B+R). Numify pozwala na dowolne konta analityczne w
   `chart_accounts`.
2. **Klasyfikacja** - przy dekretowaniu wynagrodzeń/zakupów
   związanych z B+R księgować na kontach analitycznych `-BR`.
   Znacznik `taxClassification = KUP` (są to zwykłe koszty
   uzyskania przychodu - ulga to odliczenie **od podstawy**, nie
   zmiana klasyfikacji kosztu).
3. **Proporcja czasu pracy** - dla wynagrodzeń wymagana jest
   ewidencja czasu B+R vs ogólny czas pracy. Numify nie prowadzi
   ewidencji czasu pracy - należy utrzymywać arkusz zewnętrzny
   (np. Excel), w którym pracownicy potwierdzają procent czasu
   poświęconego na B+R w danym miesiącu.
4. **Zestawienie roczne** - na podstawie obrotów kont analitycznych
   `-BR` × proporcja czasu. Wynik trafia do **załącznika CIT/BR**
   wypełnianego ręcznie.
5. **CIT-8** - kwota odliczenia wpisywana w CIT-8/O (jako kwota
   odliczona od podstawy). Numify nie automatyzuje tego kroku.

**Świadome ograniczenie:** modul B+R/IP BOX jest poza zakresem
planu produktu - typowa sp. z o.o. prowadząca stabilną działalność
usługową nie korzysta z tych ulg. Dodanie modułu jest zagadnieniem
Phase 5+ planu rozwoju.

## Pomniejszanie zaliczek PIT-4 - art. 18db [#pomniejszanie-zaliczek-pit-4---art-18db]

<LegalRef act="CIT" art="18db" /> wprowadza "kredytowanie" ulgi B+R
dla spółek, które poniosły stratę lub nie miały dochodu dostatecznego
na pełne odliczenie:

> Podatnik (...), który poniósł za rok podatkowy stratę albo osiągnął
> dochód niższy od kwoty przysługującego w roku podatkowym
> odliczenia na podstawie art. 18d, **może pomniejszyć kwotę
> podlegających przekazaniu na rachunek urzędu skarbowego zaliczek
> na podatek dochodowy** (...) o iloczyn kwoty nieodliczonej i stawki
> podatku obowiązującej tego podatnika w danym roku podatkowym.

Mechanizm:

1. Nieodliczona kwota B+R (bo podstawa była zbyt mała) × stawka CIT
   (9 % lub 19 %) = **kwota do wykorzystania na zaliczki PIT-4**.
2. Zaliczki obejmują wynagrodzenia pracowników B+R zaangażowanych
   w działalność R\&D &#x2A;*co najmniej w 50 %** czasu pracy
   (art. 18db ust. 3).
3. Pomniejszenie można stosować **od miesiąca następującego po
   miesiącu złożenia CIT-8** do końca roku podatkowego.

Uwagi:

* Nie dotyczy zaliczek przekazywanych przez agencje zatrudnienia
  (art. 38 ust. 2-2c PIT).
* Podatnik z prawem do zwrotu bezpośredniego (art. 18da - nowe firmy)
  nie stosuje tego mechanizmu.

## Alternatywny zwrot - art. 18da dla nowych podatników [#alternatywny-zwrot---art-18da-dla-nowych-podatników]

Podatnicy **rozpoczynający działalność** mają alternatywę: zamiast
przenosić nieodliczoną kwotę B+R na kolejne 6 lat (art. 18d ust. 8),
mogą wystąpić o **bezpośredni zwrot gotówkowy** równy iloczynowi
nieodliczonej kwoty i stawki CIT. Warunki w art. 18da - nie są
przedmiotem szerszego omówienia w Numify, ponieważ wykraczają poza
typowy scenariusz.

## Typowe błędy [#typowe-błędy]

* **Brak ewidencji czasu pracy B+R.** Organy podatkowe wymagają
  udokumentowanej proporcji - "50 % czasu na B+R" bez karty
  ewidencji czasu pracy zostanie zakwestionowane.
* **Uwzględnianie wynagrodzeń przy bezczynnościach.** Linia orzecznicza
  NSA (m.in. II FSK 1038/19, II FSK 1049/19) traktuje okresy urlopu,
  choroby i inne usprawiedliwione nieobecności pracownika jako czas
  **nieprzeznaczony na B+R** - wynagrodzenia za te okresy są częściowo
  kwestionowane jako koszt kwalifikowany. Bezpiecznie jest prowadzić
  ewidencję czasu pracy wyłącznie z czasem rzeczywiście przeznaczonym
  na działalność badawczo-rozwojową.
* **Zaliczenie do pkt 3 ekspertyz od podmiotów komercyjnych.** Pkt 3
  dopuszcza **tylko** podmioty z art. 7 ust. 1 pkt 1, 2 i 4-8
  ustawy z 20 lipca 2018 r. - Prawo o szkolnictwie wyższym i nauce
  (uczelnie, PAN, instytuty badawcze, Centrum Łukasiewicz itp.).
  Faktura od zwykłej firmy konsultingowej się **nie kwalifikuje**
  (chyba że podatnik ma status CBR i stosuje ust. 3a).
* **Budynki i budowle jako pkt 3.** Wyłączone z amortyzacji
  kwalifikowanej (art. 18d ust. 3) poza podatnikami CBR (ust. 3a).
* **Brak limitu dochodowego.** Ulga nie może przekroczyć dochodu
  z innych niż zyski kapitałowe źródeł (art. 18d ust. 1, ostatnie
  zdanie).

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

* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) - załącznik
  CIT/BR jako załącznik do zeznania rocznego.
* [IP BOX](/docs/zgodnosc-z-prawem/ustawa-o-cit/ip-box) - B+R jest
  warunkiem uzyskania prawa do IP BOX (wytworzenie kwalifikowanego IP
  w ramach B+R).
* [KUP / NKUP](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup) -
  koszty B+R są zwykłym KUP; ulga to **dodatkowe** odliczenie od
  podstawy opodatkowania.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja - oparta na aktualnym tekście jednolitym ustawy
    o CIT (Dz.U. 2025 poz. 278). Limit 200 % dla kosztów pracowniczych
    obowiązuje od 1 stycznia 2022 r. (Dz.U. 2021 poz. 2105 - "Polski
    Ład").
  </ChangeEntry>
</ChangeHistory>


---

# Stawki CIT — 9 % i 19 % (art. 19)
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/stawki
Description: Dwie stawki podatku dochodowego od osób prawnych — podstawowa 19 % i obniżona 9 % dla małych podatników CIT. Zasady przeliczania progu 2 000 000 EUR, ograniczenia dla spółek przekształconych i dzielonych, status „małego podatnika" z art. 4a pkt 10.
Review status: internal
Updated: 2026-04-16



Podatek dochodowy od osób prawnych ma w 2026 r. w praktyce **dwie
stawki**: podstawową &#x2A;*19 %** i obniżoną &#x2A;*9 %**. Obniżona stawka
jest zarezerwowana dla nowych i małych firm — zależy jednocześnie od
**dwóch różnych progów** (nie od jednego).

<ComplianceDisclaimer />

## Stawka podstawowa — 19 % [#stawka-podstawowa--19-]

<LegalRef act="CIT" art="19" paragraph="1" /> pkt 1 ustala stawkę
**19 % podstawy opodatkowania**. Jest to stawka domyślna dla każdej
sp. z o.o. — obowiązuje zawsze, chyba że spółka spełnia jednocześnie
warunki art. 19 ust. 1 pkt 2 **i** ust. 1d.

Dla typowej sp. z o.o. (właścicielskiej, usługowej, o przychodach
powyżej kilku mln PLN) aktualną stawką jest 19 %.

## Stawka obniżona — 9 % [#stawka-obniżona--9-]

<LegalRef act="CIT" art="19" paragraph="1" /> pkt 2 pozwala na
stawkę **9 % podstawy opodatkowania — wyłącznie od przychodów innych
niż z zysków kapitałowych**, o ile spełnione są **dwa niezależne
warunki**:

### Warunek 1 — próg przychodów bieżącego roku (art. 19 ust. 1 pkt 2) [#warunek-1--próg-przychodów-bieżącego-roku-art-19-ust-1-pkt-2]

Przychody osiągnięte w **danym** roku podatkowym nie mogą przekroczyć
równowartości **2 000 000 EUR**. Kurs przeliczenia:

* Średni kurs EUR NBP na **pierwszy dzień roboczy roku podatkowego**
  (nie października poprzedniego roku!).
* Zaokrąglenie do 1 000 zł.
* Jeśli rok podatkowy był krótszy/dłuższy niż 12 miesięcy —
  proporcjonalnie (iloczyn 1/12 × liczba pełnych miesięcy).

### Warunek 2 — status małego podatnika (art. 19 ust. 1d → art. 4a pkt 10) [#warunek-2--status-małego-podatnika-art-19-ust-1d--art-4a-pkt-10]

Równolegle podatnik musi być &#x2A;*„małym podatnikiem"** w rozumieniu
<LegalRef act="CIT" art="4a" /> pkt 10:

> Wartość przychodu ze sprzedaży (wraz z kwotą należnego VAT) nie
> przekroczyła w **poprzednim** roku podatkowym równowartości
> **2 000 000 EUR**.

Tu kurs to średni EUR NBP na **pierwszy dzień roboczy października
roku poprzedzającego** rok podatkowy, również z zaokrągleniem do
1 000 zł.

### Dwa progi — jedna nazwa, różne przeliczenia [#dwa-progi--jedna-nazwa-różne-przeliczenia]

To najczęstsze źródło pomyłek:

| Próg            | Artykuł              | Co mierzy                                          | Rok bazowy | Data kursu NBP                                  |
| --------------- | -------------------- | -------------------------------------------------- | ---------- | ----------------------------------------------- |
| Próg roczny 9 % | art. 19 ust. 1 pkt 2 | Przychody w **tym** roku (bez VAT)                 | bieżący    | 1. dzień roboczy bieżącego roku                 |
| Mały podatnik   | art. 4a pkt 10       | Przychody ze sprzedaży **z VAT** w poprzednim roku | poprzedni  | 1. dzień roboczy października poprzedniego roku |

**Oba warunki muszą być spełnione równocześnie.** Jeżeli przychód
bieżącego roku przekroczy limit art. 19 ust. 1 pkt 2, od **kolejnego
miesiąca lub kwartału** (w zależności od trybu zaliczkowego) podatnik
przechodzi na stawkę 19 % (<LegalRef act="CIT" art="25" paragraph="1g" />).

## Wyłączenia ze stawki 9 % [#wyłączenia-ze-stawki-9-]

<LegalRef act="CIT" art="19" paragraph="1a" /> odbiera prawo do
stawki 9 % w roku utworzenia i roku bezpośrednio po nim następującym
dla:

1. Spółek powstałych z **przekształcenia, połączenia lub podziału**
   (z wyjątkiem przekształcenia spółki w inną spółkę).
2. Spółek powstałych z przekształcenia **przedsiębiorcy-osoby fizycznej**
   lub **spółki niebędącej osobą prawną**.
3. Spółek, do których wniesiono **przedsiębiorstwo lub jego
   zorganizowaną część** o wartości ≥ 10 000 EUR (kurs na 1. dzień
   roboczy października roku poprzedzającego rok wniesienia).
4. Spółek, do których wniesiono składniki z **likwidacji innych
   podatników**, jeżeli wnoszący posiadał udziały tych likwidowanych.

<LegalRef act="CIT" art="19" paragraph="1c" /> rozszerza wyłączenie na:

1. **Spółkę dzieloną** — w roku podziału i roku po nim.
2. Podatnika, który **wniósł wkład** do innego podmiotu w postaci
   przedsiębiorstwa / ZCP / składników o wartości ≥ 10 000 EUR — w roku
   wniesienia i roku po nim.

Dodatkowo <LegalRef act="CIT" art="19" paragraph="1b" /> w całości
wyklucza **podatkowe grupy kapitałowe** i **fundacje rodzinne** z
prawa do stawki 9 %.

### Podatnicy rozpoczynający działalność [#podatnicy-rozpoczynający-działalność]

Zgodnie z <LegalRef act="CIT" art="19" paragraph="1e" /> warunek
posiadania statusu małego podatnika (art. 19 ust. 1d) **nie dotyczy
podatników rozpoczynających działalność w roku rozpoczęcia tej
działalności** — z zastrzeżeniem wyłączeń z art. 19 ust. 1a i 1c.
Nowa sp. z o.o. od 0 zł może więc skorzystać ze stawki 9 %, o ile
nie powstała przez przekształcenie / wniesienie przedsiębiorstwa.

## Stawki specjalne — poza zakresem typowej sp. z o.o. [#stawki-specjalne--poza-zakresem-typowej-sp-z-oo]

Dla porządku: art. 19 ust. 1 wymienia jeszcze stawki dla banków i
instytucji finansowych (23 %, art. 19 ust. 1 pkt 3) oraz banków
spółdzielczych i SKOK (21 %, pkt 4). Typowej sp. z o.o. nie dotyczą
— Numify nie implementuje tych stawek.

Istnieją też odrębne formy opodatkowania CIT, do których nie stosuje
się art. 19 w standardowej postaci:

| Reżim                                     | Podstawa prawna                  | Stawka                      | Obsługa w Numify                                                                  |
| ----------------------------------------- | -------------------------------- | --------------------------- | --------------------------------------------------------------------------------- |
| Estoński CIT (ryczałt od dochodów spółek) | art. 28j–28t                     | 10 % lub 20 %               | **nie wspierany**                                                                 |
| IP BOX                                    | <LegalRef act="CIT" art="24d" /> | 5 % kwalifikowanego dochodu | opis w [IP BOX](/docs/zgodnosc-z-prawem/ustawa-o-cit/ip-box) — brak implementacji |
| Minimalny podatek CIT                     | art. 24ca                        | 10 %                        | **nie wspierany**                                                                 |
| Podatek od przychodów z budynków          | art. 24b                         | 0,035 %/miesiąc             | **nie wspierany**                                                                 |

## Wybór stawki w Numify [#wybór-stawki-w-numify]

Pole &#x2A;*`cit_rate`** na tabeli `companies` (enum `citRate`) przyjmuje
trzy wartości:

* `standard_19` — domyślna, stawka 19 %.
* `small_9` — stawka 9 % dla spółek spełniających oba warunki z art. 19.
* `estonian` — estoński CIT (**zastrzeżony, funkcja nie jest w pełni
  zaimplementowana**).

Wybór stawki odbywa się w ustawieniach firmy. <ServiceRef path="src/lib/services/cit-data.ts">generateCitData</ServiceRef>
odczytuje `companies.citRate` i wylicza zobowiązanie jako:

```
citDue = max(0, taxResult × citRatePercent / 100)
```

gdzie `citRatePercent = 9` jeśli `citRate === "small_9"`, w przeciwnym
razie `19`. Zaokrąglenie do pełnych groszy.

**Weryfikacja statusu „małego podatnika" i progu rocznego leży po
stronie użytkownika — Numify nie ostrzega o zbliżaniu się do progu
2 mln EUR ani nie automatycznie przełącza stawki w trakcie roku.**

## Księgowanie podatku dochodowego [#księgowanie-podatku-dochodowego]

Miesięczna/roczna zaliczka i ostateczne zobowiązanie CIT trafiają na:

| Konto                                                                          | Rola                                  |
| ------------------------------------------------------------------------------ | ------------------------------------- |
| <AccountRef code="870" name="Podatek dochodowy" />                             | Koszt podatku w RZiS (pnlTag `RZS_J`) |
| <AccountRef code="225" name="Rozrachunki z US z tytułu podatku dochodowego" /> | Zobowiązanie wobec urzędu skarbowego  |

Księgowanie zaliczki / ostatecznego CIT:

```
Wn 870 Podatek dochodowy         kwota CIT
Ma 225 Rozrachunki z US          kwota CIT
```

Zapłata zaliczki / CIT:

```
Wn 225 Rozrachunki z US          kwota CIT
Ma 130 Rachunek bieżący          kwota CIT
```

Konto 870 ma <PolishTerm pl="znacznik JPK" en="JPK marker">`jpkPdMarker`</PolishTerm>
`NKUP_RZS_J` — sam podatek dochodowy **nie jest kosztem uzyskania
przychodu** (<LegalRef act="CIT" art="16" paragraph="1" /> pkt 15).

## Typowe błędy [#typowe-błędy]

* **Utożsamianie dwóch progów 2 mln EUR.** Próg małego podatnika
  (art. 4a pkt 10) i próg rocznego przychodu dla 9 % (art. 19 ust. 1
  pkt 2) mają **różne daty kursu** i **różne rodzaje przychodu**
  (brutto vs netto, z VAT vs bez VAT). Spółka może być małym
  podatnikiem, ale w danym roku przekroczyć próg art. 19 — wtedy
  traci prawo do 9 % na ten rok.
* **Stosowanie 9 % w roku utworzenia spółki po przekształceniu.** Art. 19
  ust. 1a wyłącza stawkę przez dwa pierwsze lata — powszechny błąd
  przy przekształceniach JDG → sp. z o.o.
* **Stosowanie 9 % do przychodów z zysków kapitałowych.** Stawka 9 %
  dotyczy **wyłącznie** przychodów innych niż z zysków kapitałowych
  (art. 19 ust. 1 pkt 2). Dywidendy z udziałów, zbycie udziałów,
  odsetki od pożyczek — 19 % niezależnie od progów.
* **Pomijanie wyłączenia fundacji rodzinnych i PGK.** Art. 19 ust. 1b.

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

* [Zaliczki na CIT](/docs/zgodnosc-z-prawem/ustawa-o-cit/zaliczki) —
  jak wybór stawki wpływa na miesięczne/kwartalne zaliczki.
* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) — roczne
  zeznanie i rozliczenie stawki.
* [KUP / NKUP](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup) —
  koszty wpływające na podstawę opodatkowania.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja strony — oparta na aktualnym tekście jednolitym
    ustawy o CIT (Dz.U. 2025 poz. 278). Rozróżnienie dwóch progów
    2 mln EUR (art. 19 ust. 1 pkt 2 vs art. 4a pkt 10) oraz wyłączeń
    z art. 19 ust. 1a, 1b, 1c.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 7 CIT — Przedmiot opodatkowania
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/art-7-przedmiot-opodatkowania
Description: Dochód jako suma dochodu z zysków kapitałowych i z innych źródeł, strata ze źródła przychodów, wyłączenia z podstawy opodatkowania (przychody zwolnione, straty przekształcanych jednostek), rozliczanie straty w 5 kolejnych latach — dwa warianty (50 % / 5 mln zł). Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Dochód** jest przedmiotem opodatkowania CIT — nie obrót, nie
przychód, nie wynik bilansowy z RZiS.
<LegalRef act="CIT" art="7" /> definiuje **jak** powstaje dochód,
**jak** powstaje strata i **jak** rozlicza się stratę w kolejnych
latach. Dla typowej sp. z o.o. to jeden z najważniejszych przepisów
CIT.

<ComplianceDisclaimer />

## Dwa źródła przychodów — ust. 1 [#dwa-źródła-przychodów--ust-1]

> Przedmiotem opodatkowania podatkiem dochodowym jest dochód
> stanowiący sumę dochodu osiągniętego z zysków kapitałowych oraz
> dochodu osiągniętego z innych źródeł przychodów.

Od 2018 r. CIT rozróżnia **dwa źródła**:

| Źródło                       | Typowe pozycje dla sp. z o.o.                                                                                                                                                              | Konta przychodów                                         |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------- |
| **Zyski kapitałowe**         | dywidendy otrzymane, zbycie udziałów i akcji, wkłady niepieniężne, odsetki od pożyczek wewnątrz grupy (w niektórych przypadkach) — katalog w <LegalRef act="CIT" art="7b" paragraph="1" /> | 750 analityka „kapitałowe", 760 analityka „dywidendy"    |
| **Inne źródła** (operacyjne) | sprzedaż towarów i usług, pozostała działalność operacyjna, odsetki bankowe, różnice kursowe                                                                                               | 700, 730, 740, 760, 765, 766, 750 analityka „operacyjne" |

**Krytyczna zasada separacji**:

* Dochód z każdego źródła ustala się **odrębnie**.
* Strata z jednego źródła **nie pomniejsza** dochodu z drugiego źródła.
* Rozliczenie straty w kolejnych latach dotyczy **tylko tego samego
  źródła**, z którego strata powstała (ust. 5 — „obniżyć dochód
  uzyskany z tego źródła").

Wyjątki w zyskach z przychodów — sp. z o.o. bez działalności
inwestycyjnej w udziałach zwykle ma **zerowe przychody z zysków
kapitałowych** i liczy dochód tylko z „innych źródeł".

### Przychody opodatkowane ryczałtowo — art. 21, 22, 24b [#przychody-opodatkowane-ryczałtowo--art-21-22-24b]

<LegalRef act="CIT" art="21" /> (przychody nierezydentów), art. 22
(dywidendy wypłacane) i art. 24b (podatek od budynków) opodatkowane
są **ryczałtem** — nie wchodzą do ogólnej podstawy opodatkowania.
Ust. 1 ostatnie zdanie wyłącza te przychody z definicji „dochodu".

## Formuła dochodu — ust. 2 [#formuła-dochodu--ust-2]

> Dochodem ze źródła przychodów \[...] jest nadwyżka sumy przychodów
> uzyskanych z tego źródła przychodów nad kosztami ich uzyskania,
> osiągnięta w roku podatkowym. Jeżeli koszty uzyskania przychodów
> przekraczają sumę przychodów, różnica jest stratą ze źródła
> przychodów.

```
dochód podatkowy = Σ przychody podatkowe (art. 12)
                 − Σ koszty uzyskania przychodów (art. 15)
                 + dodania (art. 12 ust. 1, art. 7 ust. 3 — wyłączenia)
                 − odliczenia i ulgi
```

**Wynik podatkowy ≠ wynik rachunkowy**. Numify liczy oba niezależnie:

* **Wynik rachunkowy (RZiS, konto 860)** — według UoR, zobacz
  [art. 47](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-47-rzis).
* **Wynik podatkowy (CIT-8)** — według CIT, liczony z tych samych
  zapisów ale z klasyfikacją podatkową **KUP / NKUP / przychód
  podatkowy / przychód niepodlegający CIT**. Zobacz
  [cit-data](/docs/korzystanie-z-numify/cit-data) i
  [kup-nkup](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup).

Typowe różnice trwałe zwiększające wynik podatkowy vs bilansowy:

| Pozycja                                      | Wynik bilansowy | Wynik podatkowy                                                                                   |
| -------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------- |
| Reprezentacja — alkohol, upominki            | koszt księgowy  | NKUP (art. 16 ust. 1 pkt 28)                                                                      |
| Odsetki od zaległości podatkowych            | koszt księgowy  | NKUP (art. 16 ust. 1 pkt 21)                                                                      |
| Amortyzacja samochodu osobowego > 150 000 zł | pełna           | ograniczona — zobacz [art. 16a–16m](/docs/zgodnosc-z-prawem/ustawa-o-cit/art-16a-16m-amortyzacja) |
| Kary umowne z tytułu wad                     | koszt księgowy  | NKUP (art. 16 ust. 1 pkt 22)                                                                      |

Różnice przejściowe (np. amortyzacja bilansowa ≠ podatkowa) dają
**podatek odroczony** — księgowany na kontach 640 / 870.

## Wyłączenia z podstawy opodatkowania — ust. 3 [#wyłączenia-z-podstawy-opodatkowania--ust-3]

Do dochodu **nie wchodzą**:

1. przychody ze źródeł niepodlegających CIT lub zwolnionych,
2. przychody z art. 21, 22, 24b (opodatkowane ryczałtowo),
3. koszty uzyskania przychodów dotyczące pkt 1 i 2,
4. straty poniesione ze źródła przychodów (strata jest rozliczana
   w następnych latach — nie w roku jej powstania),
5. straty przedsiębiorców przekształcanych, łączonych, przejmowanych
   lub dzielonych — z wyjątkiem **przekształcenia spółki w inną
   spółkę**,
6. straty przedsiębiorstw państwowych przejmowanych na podstawie
   przepisów o prywatyzacji,
7. straty instytucji kredytowych związanych z oddziałem przejętym
   aportem.

Dla sp. z o.o. kontynuującej działalność (bez reorganizacji) znaczenie
ma głównie **pkt 1** (przychody zwolnione, np. z działalności
gospodarczej w SSE na podstawie odrębnej decyzji), **pkt 2**
(dywidendy wypłacane — od strony udziałowca, nie spółki) i **pkt 3**
(analogiczne koszty).

## Rozliczenie straty — ust. 5 [#rozliczenie-straty--ust-5]

> O wysokość straty ze źródła przychodów, poniesionej w roku
> podatkowym, podatnik może:
>
> 1. obniżyć dochód uzyskany z tego źródła w najbliższych kolejno po
>    sobie następujących pięciu latach podatkowych, z tym że kwota
>    obniżenia w którymkolwiek z tych lat nie może przekroczyć 50 %
>    wysokości tej straty, **albo**
>
> 2. obniżyć jednorazowo dochód uzyskany z tego źródła w jednym z
>    najbliższych kolejno po sobie następujących pięciu lat
>    podatkowych o kwotę nieprzekraczającą 5 000 000 zł, nieodliczona
>    kwota podlega rozliczeniu w pozostałych latach tego pięcioletniego
>    okresu, z tym że kwota obniżenia w którymkolwiek z tych lat nie
>    może przekroczyć 50 % wysokości tej straty.

### Dwa warianty rozliczenia straty [#dwa-warianty-rozliczenia-straty]

| Wariant               | Maksymalnie rocznie                                | Typowy przypadek                               |
| --------------------- | -------------------------------------------------- | ---------------------------------------------- |
| **1 — klasyczny**     | 50 % wysokości straty                              | straty > 10 mln zł (rozkłada się równomiernie) |
| **2 — przyspieszony** | 5 000 000 zł w 1 roku **lub** 50 % w pozostałych 4 | strata ≤ 5 mln zł — cała kwota w 1 roku        |

Wybór dokonywany **dla każdej straty osobno** w momencie rozliczania —
nie trzeba deklarować z góry. Część podatników wybiera wariant 1, jeśli
prognozuje kolejne straty i woli nie „zużyć" całej puli w jednym
przyszłym zyskownym roku.

### Przykład — strata 4 mln zł w 2024 [#przykład--strata-4-mln-zł-w-2024]

Rok 2024: strata 4 000 000 zł ze źródła „inne źródła".
Rok 2025: dochód 3 000 000 zł.

* **Wariant 1**: max odliczenie 50 % × 4 000 000 = 2 000 000 zł.
  Do opodatkowania zostaje 1 000 000 zł. Pozostałe 2 000 000 zł straty
  czeka na lata 2026–2029.
* **Wariant 2**: jednorazowo można odliczyć max 4 000 000 zł (cała
  strata ≤ 5 mln zł). Wynik po odliczeniu — 0 zł do opodatkowania.
  Strata rozliczona w całości.

### 5-letni okres — liczymy od roku straty [#5-letni-okres--liczymy-od-roku-straty]

Okres 5 lat liczy się **kolejno po sobie następujących**, zaczynając
od roku po roku poniesienia straty. Strata z 2024 r. rozliczana w
latach 2025–2029. Po 2029 r. nieodliczona część **przepada**.

### Straty z walut wirtualnych — ust. 6 [#straty-z-walut-wirtualnych--ust-6]

Strata ze zbycia walut wirtualnych **nie podlega** rozliczeniu z ust. 5
— jest tracona bezpowrotnie. Dotyczy wąskiej grupy podatników.

### Odliczenie straty a ryczałt od dochodów spółek — ust. 7–8 [#odliczenie-straty-a-ryczałt-od-dochodów-spółek--ust-78]

Przejście na **estoński CIT** (ryczałt) wymaga rozstrzygnięcia losu
nierozliczonych strat — dwuetapowe obniżenie dochodu w 2 latach
bezpośrednio poprzedzających ryczałt lub utrata prawa do odliczenia.
Dla sp. z o.o. rozważającej estoński CIT po latach strat — warto to
skonsultować ze doradcą przed decyzją.

## Realizacja w Numify [#realizacja-w-numify]

| Krok                                        | Funkcja Numify                                                                    | Efekt                                             |
| ------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------- |
| Klasyfikacja podatkowa kont                 | plan-kont (flaga `taxTreatment`)                                                  | każde konto kosztowe oznaczone KUP / NKUP / limit |
| Liczenie przychodów i kosztów podatkowych   | [cit-data](/docs/korzystanie-z-numify/cit-data)                                   | agregacja obrotów kont po klasyfikacji            |
| Oddzielne źródła (kapitałowe vs operacyjne) | wymiar `citSource` na koncie / wymiar analityczny                                 | dochód i strata per źródło                        |
| Rozliczanie straty w CIT-8                  | [cit-data](/docs/korzystanie-z-numify/cit-data) — sekcja „straty z lat ubiegłych" | podpowiada dopuszczalne odliczenie wg wariantu    |
| Różnice trwałe i przejściowe                | [cit-data](/docs/korzystanie-z-numify/cit-data) — raport BO → PO                  | wynik podatkowy z podpowiedzią korekt             |
| Eksport CIT-8                               | [exports](/docs/korzystanie-z-numify/exports)                                     | XML CIT-8 zgodny ze schemą MF                     |

### Uczciwe framing — dwa źródła [#uczciwe-framing--dwa-źródła]

Rozdzielanie dochodu na **zyski kapitałowe** vs **inne źródła**
w Numify wymaga **oznaczenia na koncie** lub na wymiarze analityki
(`citSource = 'capital' | 'other'`). Domyślnie wszystkie konta
przychodów / kosztów są w źródle „inne" (operacyjne). Jednostki
prowadzące regularne operacje kapitałowe (inwestowanie w udziały,
obrót instrumentami finansowymi) muszą **jawnie** przypisać konta.
Bez tego Numify zaliczy przychody kapitałowe do źródła operacyjnego,
zafałszowując dochód per źródło.

## Częste błędy [#częste-błędy]

* **Mieszanie dwóch źródeł** — odliczenie straty z „innych źródeł"
  od dochodu z „zysków kapitałowych" lub odwrotnie. Każde źródło
  rozliczane odrębnie.
* **Odliczenie > 50 % straty w wariancie 1** — niedopuszczalne.
* **Odliczenie > 5 000 000 zł w 1 roku w wariancie 2** — niedopuszczalne.
* **Próba rozliczenia straty po 5 latach** — strata przepada.
* **Ujęcie przychodu z dywidend w „innych źródłach"** — dywidendy
  otrzymane to zyski kapitałowe (<LegalRef act="CIT" art="7b" paragraph="1" />),
  a dywidendy wypłacane przez spółkę pomniejszają zysk do podziału,
  ale są odrębnie opodatkowane u udziałowca (<LegalRef act="CIT" art="22" />).
* **Ujęcie zaliczek na dywidendę jako koszt** — nie jest kosztem
  podatkowym.
* **Wynik podatkowy = wynik bilansowy** — pomija różnice trwałe
  i przejściowe, zafałszowując podstawę CIT-8.
* **Nierozliczenie podatku odroczonego** — różnice przejściowe
  (typowo amortyzacja) muszą być odzwierciedlone w aktywach i
  rezerwach z tytułu podatku odroczonego.

## Checklist — liczenie dochodu / straty [#checklist--liczenie-dochodu--straty]

* [ ] Wszystkie przychody roku podatkowego zaksięgowane.
* [ ] Wszystkie koszty roku podatkowego zaksięgowane i zdekretowane.
* [ ] Klasyfikacja KUP / NKUP zweryfikowana
  ([kup-nkup](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup)).
* [ ] Podział na źródła (zyski kapitałowe vs inne) ustalony.
* [ ] Dochód / strata z każdego źródła policzona odrębnie.
* [ ] Straty z lat poprzednich do rozliczenia — sprawdzone 5-letnie okno.
* [ ] Wybór wariantu odliczenia (1 klasyczny / 2 przyspieszony).
* [ ] Dochód po odliczeniu strat × stawka CIT → podatek należny.
* [ ] CIT-8 wygenerowany, porównany ze stanem zaliczek.
* [ ] Podatek odroczony z tytułu różnic przejściowych zaksięgowany.


---

# JPK_KR_PD — księgi rachunkowe w strukturze JPK
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd
Description: Obowiązkowe przekazywanie ksiąg rachunkowych w strukturze JPK wraz z znacznikami podatkowymi — art. 9 ust. 1c ustawy o CIT, Rozp. MF z 16.08.2024 (Dz.U. 2024 poz. 1314) znowelizowane Dz.U. 2025 poz. 1828. Pierwsza deklaracja za FY 2026 dla typowej sp. z o.o., struktura JPK_KR_PD(1), znaczniki `KodZapisuKR` i `OpisZapisuKR`.
Review status: internal
Updated: 2026-04-16



**JPK\_KR\_PD** (Jednolity Plik Kontrolny — Księgi Rachunkowe z Danymi
Podatkowymi) to nowy obowiązek dla podatników CIT: przekazywanie
prowadzonych ksiąg rachunkowych w **strukturze XML** wraz ze
znacznikami podatkowymi. Obowiązek wynika z <LegalRef act="CIT" art="9" paragraph="1c" />
i Rozporządzenia MF z 16 sierpnia 2024 r.

Typowa sp. z o.o. (rozliczająca VAT miesięcznie) składa pierwszy
plik **za rok 2026** — w terminie CIT-8, czyli do **31 marca 2027**.

<ComplianceDisclaimer />

## Podstawa prawna — art. 9 ust. 1c [#podstawa-prawna--art-9-ust-1c]

<LegalRef act="CIT" art="9" paragraph="1c" />:

> Podatnicy prowadzący księgi rachunkowe są obowiązani prowadzić
> te księgi przy użyciu programów komputerowych oraz **przesyłać
> właściwemu naczelnikowi urzędu skarbowego te księgi po zakończeniu
> roku podatkowego, w terminie do dnia upływu terminu złożenia
> zeznania**, o którym mowa w art. 27 ust. 1 (…), **za pomocą
> środków komunikacji elektronicznej, w postaci elektronicznej
> odpowiadającej strukturze logicznej**, o której mowa w art. 193a
> § 2 Ordynacji podatkowej (…).

Struktura logiczna publikowana jest na stronach MF w ramach schem
XSD — aktualna dla 2026 r. to &#x2A;*JPK\_KR\_PD(1)** (namespace
`http://jpk.mf.gov.pl/wzor/2024/08/16/08161/`).

## Zakres obowiązku — kto i kiedy [#zakres-obowiązku--kto-i-kiedy]

### Zwolnienia podmiotowe (art. 9 ust. 1d) [#zwolnienia-podmiotowe-art-9-ust-1d]

Obowiązek **nie dotyczy**:

1. Podatników zwolnionych podmiotowo (<LegalRef act="CIT" art="6" paragraph="1" />) —
   z wyjątkiem fundacji rodzinnych.
2. Podatników składających CIT-8 w postaci papierowej (<LegalRef act="CIT" art="27a" />) —
   wąski katalog.
3. Prowadzących uproszczoną ewidencję przychodów i kosztów (nie
   dotyczy sp. z o.o. — spółki handlowe muszą prowadzić pełne księgi).

### Rozporządzenie zwalniające — Dz.U. 2024 poz. 1861 [#rozporządzenie-zwalniające--dzu-2024-poz-1861]

<LegalRef act="JPK_KR_PD" href="https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20240001861">Rozporządzenie MF z 13.12.2024</LegalRef>
wyłącza z obowiązku przesyłania **dwa elementy księgi** — struktury
ZOiS (Zestawienie Obrotów i Sald) oraz Dziennik — dla podatników,
którzy spełniają szczegółowe warunki (np. pierwsze lata obowiązku).
W praktyce dla sp. z o.o. w 2026/2027 — **podstawowy zakres
przesłania obejmuje pełen JPK\_KR\_PD** (łącznie z ZOiS i KontoZapis).

### Kalendarz wdrożenia [#kalendarz-wdrożenia]

Rozporządzenie MF z 16 sierpnia 2024 r. (Dz.U. 2024 poz. 1314)
wprowadza obowiązek etapami — **daty pierwszej deklaracji zależą od
kadencji rozliczania VAT**:

| Grupa podatników                                    | Pierwsza deklaracja JPK\_KR\_PD | Termin pierwszego złożenia      |
| --------------------------------------------------- | ------------------------------- | ------------------------------- |
| Duzi podatnicy CIT (przychód > 50 mln EUR) oraz PGK | za rok 2025                     | **31 marca 2026** — już za nami |
| Podatnicy VAT **miesięczni** (JPK\_V7M)             | za rok **2026**                 | **31 marca 2027**               |
| Podatnicy VAT **kwartalni** (JPK\_V7K) i pozostali  | za rok **2027**                 | **31 marca 2028**               |

**Dla typowej sp. z o.o. rozliczającej VAT miesięcznie pierwsze
złożenie to 31.03.2027 r. za FY 2026.** Nie jest prawdą, że „wszyscy
od 2026" — pierwsza deklaracja zależy od harmonogramu w rozporządzeniu
i od grupy podatnika.

### Nowelizacja Dz.U. 2025 poz. 1828 [#nowelizacja-dzu-2025-poz-1828]

<LegalRef act="JPK_KR_PD" href="https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20250001828">Rozporządzenie MF z 15.12.2025</LegalRef>
zmieniające rozporządzenie wyjściowe, &#x2A;*wchodzi w życie 1 stycznia
2026 r.**. Zmiany techniczne dotyczą głównie zakresu obowiązku i
dat — treść jest w planie weryfikowana w pierwszej połowie 2026 r.
Szczegóły: [ISAP — karta aktu](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20250001828).

## Struktura JPK\_KR\_PD — cztery sekcje [#struktura-jpk_kr_pd--cztery-sekcje]

| Sekcja         | Zawartość                                                                                                                                                                |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Nagłówek**   | Metadane — kod formularza, cel złożenia, okres, kod US, system źródłowy                                                                                                  |
| **Podmiot**    | NIP, REGON, nazwa, email                                                                                                                                                 |
| **ZOiS**       | Zestawienie Obrotów i Sald — konto po koncie: BO, obroty okresu, obroty narastające, saldo końcowe                                                                       |
| **Dziennik**   | Chronologiczne ujęcie zapisów — numer, data, opis operacji, kwota                                                                                                        |
| **KontoZapis** | Dekretacja — każda linia zapisu z numerem zapisu, kontem, kwotami Wn/Ma, opcjonalnie `KodZapisuKR` (znacznik podatkowy), `OpisZapisuKR` (klasyfikacja), `NIPKontrahenta` |

Oraz dwa „bloki kontrolne":

* **DziennikCtrl** — liczba wierszy i suma kwot operacji w Dzienniku.
* **KontoZapisCtrl** — liczba wierszy KontoZapis i sumy Wn/Ma.

## Znaczniki podatkowe — `KodZapisuKR` i `OpisZapisuKR` [#znaczniki-podatkowe--kodzapisukr-i-opiszapisukr]

Dwa pola XML **w elemencie KontoZapis** realizują najważniejszy
element rozporządzenia — powiązanie zapisu księgowego z jego
klasyfikacją podatkową.

### `KodZapisuKR` — znacznik konta (`jpkPdMarker`) [#kodzapisukr--znacznik-konta-jpkpdmarker]

Wynika z **planu kont** — każdemu kontu syntetycznemu przypisuje się
znacznik JPK z listy rozporządzenia (np. `AKT_A_II` dla środków
trwałych, `KUP_RZS_B_V` dla wynagrodzeń, `NKUP_RZS_J` dla podatku
dochodowego). Znacznik jednoznacznie łączy konto z pozycją bilansową
(AKT/PAS) lub z pozycją RZiS (RZS\_\*) oraz z klasyfikacją podatkową
(KUP / NKUP / PRZYCHOD\_POD / PRZYCHOD\_NPOD / NEUTRALNE).

Pełna lista znaczników w Numify jest w `chart_accounts.jpkPdMarker` —
zobacz domyślny plan kont w <ServiceRef path="src/db/seed-accounts.ts">seed-accounts.ts</ServiceRef>.

### `OpisZapisuKR` — klasyfikacja podatkowa per zapis [#opiszapisukr--klasyfikacja-podatkowa-per-zapis]

Pozwala na **nadpisanie domyślnej klasyfikacji** konta dla
konkretnego zapisu. W schema enum `taxClassification`:

| Wartość         | Znaczenie                                |
| --------------- | ---------------------------------------- |
| `KUP`           | Koszt uzyskania przychodu                |
| `NKUP`          | Niestanowiący kosztu uzyskania przychodu |
| `PRZYCHOD_POD`  | Przychód podatkowy                       |
| `PRZYCHOD_NPOD` | Przychód niepodatkowy                    |
| `NEUTRALNE`     | Neutralny podatkowo                      |

Przykład: konto <AccountRef code="402" name="Usługi obce" /> ma
domyślny znacznik `KUP_RZS_B_III`. Jeżeli jeden konkretny wpis jest
NKUP (np. reprezentacja art. 16 ust. 1 pkt 28), na linii zapisu
ustawia się `taxClassification = NKUP` — w JPK\_KR\_PD zostanie
przekazane jako `<OpisZapisuKR>NKUP</OpisZapisuKR>` przy zachowaniu
znacznika konta `KUP_RZS_B_III` w `<KodZapisuKR>`. Organ podatkowy
widzi: konto normalnie kosztowe, ale ten konkretny dekret — NKUP.

### Logika wyznaczania `OpisZapisuKR` [#logika-wyznaczania-opiszapisukr]

Implementacja w <ServiceRef path="src/lib/services/jpk-kr-pd-generator.ts">generateJpkKrPdXml</ServiceRef>:

1. Jeżeli `journal_lines.taxClassification` jest ustawione → użyj tego.
2. W przeciwnym razie — `deriveTaxClassification(account, isTaxDeductible)`:
   * Konto typu `expense` + `isTaxDeductible = true` → `KUP`.
   * Konto typu `expense` + `isTaxDeductible = false` → `NKUP`.
   * Konto typu `revenue` → `PRZYCHOD_POD` (o ile brak odrębnego flagi).
   * Pozostałe konta (asset, liability, equity) → `NEUTRALNE`.

Użytkownik widzi i edytuje flagę `isTaxDeductible` oraz opcjonalnie
`taxClassification` na poziomie dekretu. Domyślne wartości są zgodne
z `chart_accounts.jpkPdMarker`.

## Dane kontrahenta — `NIPKontrahenta` [#dane-kontrahenta--nipkontrahenta]

Dla każdego zapisu może być dołączony NIP kontrahenta — jeżeli pole
`journal_lines.contractorId` wskazuje na pozycję w `contractors`.
Numify automatycznie pobiera `contractors.taxId` i wstawia do pola
XML. **Brak NIP-u nie blokuje generacji** — pole jest opcjonalne dla
operacji, które nie mają kontrahenta (np. przeksięgowania wewnętrzne,
odpisy amortyzacyjne, korekty).

## Wymagania dotyczące danych firmy [#wymagania-dotyczące-danych-firmy]

<ServiceRef path="src/lib/services/jpk-kr-pd-generator.ts">generateJpkKrPdXml</ServiceRef>
wymusza walidację przed generacją:

1. **NIP** — `companies.taxId` jest obowiązkowy.
2. **Kod urzędu skarbowego** — `companies.taxOfficeCode` musi być
   **4-cyfrowym kodem TKodUS** (enumeracja ministerstwa — pełna lista
   \~400 kodów w schemach JPK). Walidacja wyrażeniem regularnym
   `/^\d{4}$/`.
3. **Email** — przekazywany jako parametr funkcji; wymagany przez
   schemę.

Brak któregokolwiek → `Error: Missing or invalid tax office code`
(lub odpowiednio NIP).

## Walidacja i złożenie [#walidacja-i-złożenie]

Numify **generuje plik XML** — nie podpisuje go i nie przesyła
bezpośrednio do KAS. Workflow użytkownika:

1. `generateJpkKrPdXml({ companyId, fiscalYear, purpose: 1, email })` → string XML.
2. Pobranie pliku (UI dostępne z poziomu strony „Rozliczenie roku").
3. **Walidacja XSD** — zalecane offline przed złożeniem (np. Notepad++
   z wtyczką XML, lub walidator MF).
4. **Podpisanie** kwalifikowanym podpisem elektronicznym lub profilem
   zaufanym (e-Urząd Skarbowy).
5. **Przesłanie** — przez dedykowaną bramkę JPK ministerstwa finansów
   lub zewnętrzne narzędzie (e-mikrofirma, programy księgowe).

Pole `<CelZlozenia>`:

* `1` — pierwotne złożenie (domyślne w Numify).
* `2` — korekta (można wygenerować ponownie, parametr `purpose: 2`).

## Ograniczenia generatora [#ograniczenia-generatora]

Znane ograniczenia <ServiceRef path="src/lib/services/jpk-kr-pd-generator.ts">generateJpkKrPdXml</ServiceRef>
aktualnej wersji:

1. **Ręczne przełączenie trybu korekty** — użytkownik musi sam
   zdecydować, że generuje korektę (`purpose: 2`). System nie ma
   rejestru wcześniejszych złożeń.
2. **Brak walidacji przeciwko XSD** — generator konstruuje XML
   zgodnie ze schemą, ale **nie waliduje** wyniku wobec pliku XSD
   ministerstwa. Zalecane zewnętrzne narzędzie walidacji przed
   złożeniem.
3. **Księgi pomocnicze (subsidiary ledgers)** — generator nie
   emituje odrębnych struktur analitycznych (KsiegaGlowna + kartoteki
   subkont). Działa na poziomie syntetyki + analityki kontrahentów.
4. **Złożenie elektroniczne** — poza zakresem Numify; integracja z
   bramką MF jest planowana w kolejnych etapach.

## Typowe błędy [#typowe-błędy]

* **Przekazanie JPK\_KR\_PD za zbyt wczesny rok.** Typowa sp. z o.o.
  rozliczająca VAT miesięcznie **nie składa** JPK\_KR\_PD za FY 2025 —
  pierwsze obowiązkowe to FY 2026.
* **Brak wypełnionego kodu urzędu (`taxOfficeCode`).** Plik nie
  wygeneruje się bez czterocyfrowego kodu z TKodUS.
* **Niezgodność `KodZapisuKR` między ZOiS a KontoZapis dla tego
  samego konta.** Znacznik konta w obu sekcjach musi być identyczny.
  Numify zapewnia zgodność przez wspólne źródło (`chart_accounts.jpkPdMarker`).
* **Błędne sumowania kontrolne.** Wartości `DziennikCtrl` i
  `KontoZapisCtrl` muszą zgadzać się z faktycznymi sumami — generator
  Numify zlicza automatycznie. Przy ręcznym edytowaniu pliku łatwo
  złamać spójność.
* **Stosowanie poprzedniej wersji schemy.** Schemat JPK\_KR\_PD(1)
  używa namespace `http://jpk.mf.gov.pl/wzor/2024/08/16/08161/`.
  Nowelizacja z 2025 r. (Dz.U. 2025 poz. 1828) może wprowadzić nową
  wersję — sprawdź aktualny namespace w schematach MF.

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

* [JPK\_ST\_KR](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-st-kr) —
  osobna struktura dla ewidencji środków trwałych.
* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) — JPK\_KR\_PD
  składany wraz z zeznaniem rocznym.
* [KUP / NKUP](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup) —
  klasyfikacja podatkowa zapisu przekłada się na `OpisZapisuKR`.
* [Art. 18 UoR — Trial Balance](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-18-trial-balance) —
  sekcja ZOiS w JPK\_KR\_PD = zestawienie obrotów i sald zgodne z
  art. 18 UoR.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja — oparta na Rozporządzeniu MF z 16.08.2024
    (Dz.U. 2024 poz. 1314) i nowelizacji Dz.U. 2025 poz. 1828.
    Obowiązek wprowadzony przez art. 9 ust. 1c ustawy o CIT
    (Dz.U. 2025 poz. 278).
  </ChangeEntry>
</ChangeHistory>


---

# KUP i NKUP — art. 15 i 16
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup
Description: Koszty uzyskania przychodu (art. 15) i katalog wyłączeń (art. 16) w CIT. Ogólna definicja KUP, kluczowe wyłączenia (reprezentacja, kary, odsetki od zaległości, PFRON, limity samochodowe 150/225 tys. zł), klasyfikacja podatkowa w Numify.
Review status: internal
Updated: 2026-04-16



**KUP (koszty uzyskania przychodów)** i &#x2A;*NKUP (niestanowiące KUP)**
to najważniejsza oś rozliczenia podatkowego sp. z o.o. Wynik
rachunkowy z księgi głównej **nie jest tożsamy** z wynikiem
podatkowym — różnicę tworzą pozycje z art. 16 ust. 1 (oraz drobniejsze
kategorie z art. 15).

<ComplianceDisclaimer />

## Definicja ogólna — art. 15 ust. 1 [#definicja-ogólna--art-15-ust-1]

<LegalRef act="CIT" art="15" paragraph="1" />:

> Kosztami uzyskania przychodów są koszty **poniesione w celu
> osiągnięcia przychodów ze źródła przychodów lub w celu zachowania
> albo zabezpieczenia źródła przychodów**, z wyjątkiem kosztów
> wymienionych w art. 16 ust. 1.

Trzy warunki KUP:

1. **Koszt został poniesiony** — jest udokumentowany fakturą,
   rachunkiem lub innym dowodem księgowym (<LegalRef act="CIT" art="15" paragraph="4e" /> —
   dzień poniesienia = dzień ujęcia w księgach).
2. **Cel** — osiągnięcie przychodu albo zachowanie/zabezpieczenie
   źródła. Wystarczy pośredni związek.
3. **Nie jest wymieniony w art. 16 ust. 1** — katalog NKUP ma
   charakter zamknięty, ale obszerny.

Orzecznictwo NSA wielokrotnie podkreślało, że związek z przychodem
może być **pośredni** — wydatki na reklamę, szkolenia pracowników,
doradztwo nie muszą generować konkretnych przychodów, żeby były KUP.

## Moment potrącenia — koszty bezpośrednie vs pośrednie [#moment-potrącenia--koszty-bezpośrednie-vs-pośrednie]

### Bezpośrednie (art. 15 ust. 4) [#bezpośrednie-art-15-ust-4]

> Koszty uzyskania przychodów **bezpośrednio związane z przychodami**
> (…) są potrącalne w tym roku podatkowym, w którym osiągnięte
> zostały odpowiadające im przychody.

Przykład: towar handlowy — jego zakup jest kosztem w momencie
sprzedaży, nie w momencie zakupu.

### Pośrednie (art. 15 ust. 4d) [#pośrednie-art-15-ust-4d]

> Koszty uzyskania przychodów, **inne niż koszty bezpośrednio
> związane z przychodami, są potrącalne w dacie ich poniesienia**.
> Jeżeli koszty te dotyczą okresu przekraczającego rok podatkowy
> (…), stanowią koszty uzyskania przychodów **proporcjonalnie do
> długości okresu**, którego dotyczą.

Przykład: polisa ubezpieczeniowa za 18 miesięcy — rozlicza się
proporcjonalnie między dwa lata podatkowe.

### Dzień poniesienia (art. 15 ust. 4e) [#dzień-poniesienia-art-15-ust-4e]

> Dzień, na który ujęto koszt w księgach rachunkowych (zaksięgowano)
> na podstawie otrzymanej faktury (rachunku), albo dzień, na który
> ujęto koszt na podstawie innego dowodu (…), z wyjątkiem sytuacji
> gdy dotyczyłoby to ujętych jako koszty **rezerw** albo **biernych
> rozliczeń międzyokresowych** kosztów.

Krótko: moment podatkowy = moment księgowy, ale rezerwy i bierne RMK
nie są KUP, dopóki nie staną się faktycznym kosztem (fakturą).

## Katalog NKUP — art. 16 ust. 1 [#katalog-nkup--art-16-ust-1]

<LegalRef act="CIT" art="16" paragraph="1" /> liczy 70+ punktów.
Najważniejsze dla typowej sp. z o.o.:

### Wydatki na aktywa trwałe — pkt 1 [#wydatki-na-aktywa-trwałe--pkt-1]

Wydatki na nabycie gruntów, środków trwałych, WNiP oraz ulepszenia
**nie są KUP bezpośrednio** — stają się KUP przez odpisy amortyzacyjne
(art. 15 ust. 6, art. 16a–16m) albo przy odpłatnym zbyciu.

### Limity samochodów osobowych — pkt 4 [#limity-samochodów-osobowych--pkt-4]

Odpisy amortyzacyjne samochodów osobowych są KUP tylko do wartości
początkowej:

| Wartość limitu | Warunek                                                                      |
| -------------- | ---------------------------------------------------------------------------- |
| 225 000 zł     | Pojazd elektryczny lub napędzany wodorem (art. 2 ustawy o elektromobilności) |
| 150 000 zł     | Emisja CO₂ \< 50 g/km                                                        |
| 100 000 zł     | Emisja CO₂ ≥ 50 g/km                                                         |

Ponad limit — NKUP. Analogiczny limit dla kosztów **leasingu
operacyjnego** samochodu (pkt 49a) i dla **składek ubezpieczenia**
(pkt 49).

### 25 % kosztów używania samochodu osobowego „mieszanego" — pkt 51 [#25--kosztów-używania-samochodu-osobowego-mieszanego--pkt-51]

Jeżeli samochód jest używany **także prywatnie** (brak ewidencji
przebiegu VAT-26), **25 % wydatków z tytułu kosztów używania** jest
NKUP. Praktycznie oznacza to zaliczanie do KUP tylko 75 % wydatków
eksploatacyjnych (paliwo, serwis, myjnia).

### Odsetki od zaległości podatkowych — pkt 21 [#odsetki-od-zaległości-podatkowych--pkt-21]

> Odsetki za zwłokę z tytułu nieterminowych wpłat należności
> budżetowych i innych należności, do których stosuje się przepisy
> Ordynacji podatkowej.

Typowy NKUP — odsetki od zaległości CIT, VAT, ZUS, składek zdrowotnych.

### Kary umowne z tytułu wad — pkt 22 [#kary-umowne-z-tytułu-wad--pkt-22]

> Kar umownych i odszkodowań z tytułu **wad dostarczonych towarów,
> wykonanych robót i usług** oraz zwłoki w dostarczeniu towaru
> wolnego od wad albo zwłoki w usunięciu wad.

**Ważne rozróżnienie:** kary za **niewykonanie / wadliwe wykonanie
świadczenia** = NKUP. Kary za opóźnienie w zapłacie (odsetki
handlowe), odszkodowania za wypowiedzenie kontraktu czy kary z tytułu
braku przeciwdziałania nadmiernym opóźnieniom — **nie są
w katalogu** i zasadniczo mogą być KUP, o ile spełnią art. 15 ust. 1.

### Grzywny i kary z postępowań — pkt 18 [#grzywny-i-kary-z-postępowań--pkt-18]

Grzywny karne, karnoskarbowe, administracyjne i w sprawach
o wykroczenia wraz z odsetkami — NKUP.

### Reprezentacja — pkt 28 [#reprezentacja--pkt-28]

> Kosztów reprezentacji, w szczególności poniesionych na **usługi
> gastronomiczne, zakup żywności oraz napojów, w tym alkoholowych**.

Granica reprezentacja / reklama wywołuje liczne spory. Utrwalona
linia orzecznicza NSA kieruje się **celem wydatku** — reprezentacja
to działanie nastawione na wywołanie korzystnego wrażenia o firmie
u konkretnego odbiorcy. Imprezy dla klientów, kolacje biznesowe,
drogie prezenty z logo — zwykle reprezentacja. Ulotki, gadżety
reklamowe małej wartości skierowane do szerszego kręgu,
catering na otwartą konferencję — zwykle reklama, KUP.

### Wpłaty PFRON — pkt 36 [#wpłaty-pfron--pkt-36]

> Wpłat, o których mowa w art. 21 ust. 1 i w art. 23 ustawy (…)
> o rehabilitacji zawodowej i społecznej oraz zatrudnianiu osób
> niepełnosprawnych.

Comiesięczna wpłata na PFRON (pracodawcy zatrudniający ≥ 25 osób,
którzy nie osiągnęli 6 % wskaźnika zatrudnienia osób
niepełnosprawnych) — NKUP w całości.

### Niewypłacone wynagrodzenia i składki ZUS — pkt 57 i 57a [#niewypłacone-wynagrodzenia-i-składki-zus--pkt-57-i-57a]

Wynagrodzenia z umowy o pracę, zlecenia i składki ZUS od nich
**nie są KUP, dopóki nie zostały faktycznie wypłacone / opłacone
w terminie**. Wyjątek — art. 15 ust. 4g i 4h: jeżeli zostały
wypłacone/opłacone w terminie wynikającym z prawa pracy, są KUP
**w miesiącu, za który są należne** (a nie w miesiącu zapłaty).

### Samochód poza ewidencją — pkt 50 [#samochód-poza-ewidencją--pkt-50]

Straty w wyniku utraty lub likwidacji samochodów oraz koszty
remontów powypadkowych, jeśli **samochód nie był objęty
ubezpieczeniem dobrowolnym** — NKUP.

### Podatek dochodowy własny — pkt 15 [#podatek-dochodowy-własny--pkt-15]

Sam CIT i wpłaty z zysku **nie są KUP** — stąd `jpkPdMarker` konta
<AccountRef code="870" /> to `NKUP_RZS_J`.

### Rezerwy i bierne RMK — pkt 27 [#rezerwy-i-bierne-rmk--pkt-27]

Rezerwy tworzone zgodnie z UoR są NKUP (z wyjątkami dla banków,
ubezpieczycieli). Stają się KUP dopiero przy rozwiązaniu lub
rzeczywistym poniesieniu kosztu.

## Podstawowe narzędzie — klasyfikacja na linii PK [#podstawowe-narzędzie--klasyfikacja-na-linii-pk]

W Numify każda pozycja zapisu księgowego (`journal_lines&#x60;) ma pole
&#x2A;*`isTaxDeductible`** (boolean, domyślnie `true&#x60;) oraz opcjonalne
&#x2A;*`nkupReason`** (krótki opis dlaczego NKUP). Dodatkowo:

**`taxClassification`** (enum `taxClassification`):

| Wartość         | Znaczenie                                                  |
| --------------- | ---------------------------------------------------------- |
| `KUP`           | Koszt uzyskania przychodu (tax-deductible)                 |
| `NKUP`          | Niestanowiący kosztu uzyskania przychodu                   |
| `PRZYCHOD_POD`  | Przychód podatkowy                                         |
| `PRZYCHOD_NPOD` | Przychód niepodatkowy (np. dywidenda otrzymana)            |
| `NEUTRALNE`     | Neutralny podatkowo (np. ruchy bilansowe, rozliczenia VAT) |

Dodatkowo plan kont (`chart_accounts&#x60;) nosi domyślny znacznik
&#x2A;*`jpkPdMarker`** — podpowiedź zarówno dla użytkownika, jak i dla
generatora JPK\_KR\_PD. Dla kosztów ogólnych Zespołu 4 znaczniki to
`KUP_RZS_B_…`; dla podatku dochodowego — `NKUP_RZS_J`; dla wyniku
finansowego — `PAS_A_VIII`.

## Wyliczenie NKUP w rozliczeniu rocznym [#wyliczenie-nkup-w-rozliczeniu-rocznym]

<ServiceRef path="src/lib/services/cit-data.ts">generateCitData</ServiceRef>
wylicza:

```
accountingRevenue     — suma obrotów kont przychodowych
accountingCosts       — suma obrotów kont kosztowych
nonDeductibleCosts    — suma linii z isTaxDeductible = false na kontach kosztowych
taxDeductibleCosts    — accountingCosts − nonDeductibleCosts
taxResult             — accountingRevenue − taxDeductibleCosts
citDue                — max(0, taxResult × 9 % lub 19 %)
```

Wynik zawiera listę `nkupItems` — pozycje NKUP zgrupowane po kontach,
z `nkupReason` jako wyjaśnieniem. Użytkownik otrzymuje więc
&#x2A;*uzgodnienie (recon)** wyniku księgowego z wynikiem podatkowym
dokładnie na podstawie flag `isTaxDeductible` ustawionych na
poziomie zapisu.

**Ograniczenia implementacji:**

* `generateCitData` **nie odzwierciedla różnic przejściowych**
  (np. amortyzacja bilansowa ≠ amortyzacja podatkowa). Zakłada
  zgodność amortyzacji bilansowej i podatkowej.
* Nie wykrywa automatycznie **limitów** (np. 150 tys. dla samochodów)
  — klasyfikację NKUP na przekroczonej części ustawia użytkownik
  ręcznie na poziomie dekretu.
* Nie implementuje mechanizmu z art. 15c (koszty finansowania
  dłużnego) ani art. 15e (sztywny limit usług od podmiotów
  powiązanych — uchylony od 2022 r.).

## Typowe błędy [#typowe-błędy]

* **Traktowanie reprezentacji jak reklamy.** Posiłki z klientami =
  reprezentacja (NKUP). Kalkulatory firmowe z logo = reklama (KUP).
* **Ujęcie odsetek od zaległości ZUS jako KUP.** Art. 16 ust. 1
  pkt 21 łapie wszelkie „odsetki za zwłokę z tytułu nieterminowych
  wpłat należności budżetowych". Odsetki od zaległości VAT, CIT,
  ZUS, NFZ — NKUP.
* **Pełne zaliczenie wydatków samochodu osobowego „mieszanego".**
  Brak ewidencji przebiegu VAT-26 = 25 % wydatków z art. 16 ust. 5f
  jest NKUP.
* **Zaliczenie do KUP kary umownej od kontrahenta za wadliwe
  świadczenie.** Pkt 22 wymienia wprost.
* **Zaliczenie do KUP wynagrodzenia niewypłaconego w terminie.** Pkt 57
  — do momentu faktycznej wypłaty jest NKUP.

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

* [CIT-8](/docs/zgodnosc-z-prawem/ustawa-o-cit/cit-8) — jak
  uzgodnienie KUP/NKUP trafia do zeznania rocznego.
* [Zaliczki](/docs/zgodnosc-z-prawem/ustawa-o-cit/zaliczki) — NKUP
  wpływa na podstawę zaliczki miesięcznej.
* [JPK\_KR\_PD](/docs/zgodnosc-z-prawem/ustawa-o-cit/jpk-kr-pd) —
  znaczniki podatkowe przekazywane w pliku JPK.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3c">
    Pierwsza wersja — katalog NKUP oparty na aktualnym tekście
    jednolitym ustawy o CIT (Dz.U. 2025 poz. 278). Limity samochodów
    (pkt 4 lit. a/b/c: 225/150/100 tys. zł) zgodne z nowelizacją
    Dz.U. 2018 poz. 2159 z późn. zm.
  </ChangeEntry>
</ChangeHistory>


---

# Ustawa o VAT — przegląd
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat
Description: Mapa najważniejszych przepisów Ustawy o podatku od towarów i usług z 11 marca 2004 r. dla spółki z o.o. — stawki, JPK_V7M, faktury, transakcje UE (WNT/WDT), mechanizm podzielonej płatności, biała lista.
Review status: internal
Updated: 2026-04-16



**Ustawa o podatku od towarów i usług** (dalej: ustawa o VAT) z 11
marca 2004 r. reguluje opodatkowanie obrotu towarami i usługami
w Polsce. Dla sp. z o.o. jest to — obok UoR — najważniejszy akt
prawa podatkowego: reguluje zarówno ewidencję sprzedaży i zakupów
(poprzez JPK\_V7M), jak i codzienne fakturowanie.

<ComplianceDisclaimer />

## Zakres opodatkowania — art. 5 [#zakres-opodatkowania--art-5]

<LegalRef act="VAT" art="5" paragraph="1" /> wymienia pięć typów
czynności podlegających VAT:

| pkt | Czynność                                                                  | Gdzie dokumentujemy                                 |
| --- | ------------------------------------------------------------------------- | --------------------------------------------------- |
| 1   | Odpłatna dostawa towarów i odpłatne świadczenie usług na terytorium kraju | Faktura sprzedaży krajowej                          |
| 2   | Eksport towarów                                                           | Faktura z <VatRate rate="0" />, art. 41 ust. 4      |
| 3   | Import towarów na terytorium kraju                                        | Dokument celny + JPK\_V7M                           |
| 4   | Wewnątrzwspólnotowe nabycie towarów za wynagrodzeniem na terytorium kraju | [WNT](/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt) |
| 5   | Wewnątrzwspólnotowa dostawa towarów                                       | [WDT](/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt) |

Dodatkowo ustawa opodatkowuje **import usług** (art. 17 ust. 1 pkt 4)
jako samodzielne podatnictwo nabywcy — zobacz [odwrotne obciążenie](/docs/zgodnosc-z-prawem/ustawa-o-vat/odwrotne-obciazenie).

## Stawki aktualne w 2026 r. [#stawki-aktualne-w-2026-r]

Stawka podstawowa wynosi &#x2A;*22 %** (<LegalRef act="VAT" art="41" paragraph="1" />),
obniżona do &#x2A;*23 %** przez <LegalRef act="VAT" art="146ef" /> (tzw.
stawka podwyższona na okres wydatków obronnych > 3 % PKB). Obniżona
stawka art. 41 ust. 2 = &#x2A;*7 %**, w okresie ustawy o obronie Ojczyzny
podwyższona do &#x2A;*8 %**.

| Stawka                | Zakres                                                                         | Podstawa prawna                                                                                        |
| --------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| <VatRate rate="23" /> | Podstawowa (22 % + podwyżka z art. 146ef)                                      | <LegalRef act="VAT" art="41" paragraph="1" /> + <LegalRef act="VAT" art="146ef" paragraph="1" /> pkt 1 |
| <VatRate rate="8" />  | Załącznik 3 (7 % + podwyżka z art. 146ef)                                      | <LegalRef act="VAT" art="41" paragraph="2" /> + <LegalRef act="VAT" art="146ef" paragraph="1" /> pkt 2 |
| <VatRate rate="5" />  | Załącznik 10 (żywność podstawowa, książki, prasa)                              | <LegalRef act="VAT" art="41" paragraph="2a" />                                                         |
| <VatRate rate="0" />  | WDT, eksport, usługi międzynarodowe                                            | <LegalRef act="VAT" art="41" paragraph="3" /> + <LegalRef act="VAT" art="83" />                        |
| <VatRate rate="zw" /> | Zwolnienia przedmiotowe (usługi medyczne, finansowe, edukacyjne...)            | <LegalRef act="VAT" art="43" paragraph="1" />                                                          |
| <VatRate rate="np" /> | Czynności poza zakresem VAT (np. usługi B2B z miejscem świadczenia za granicą) | <LegalRef act="VAT" art="28b" /> (dla usług)                                                           |

Szczegóły: [Stawki VAT](/docs/zgodnosc-z-prawem/ustawa-o-vat/stawki).

## Co dokumentujemy w tej sekcji [#co-dokumentujemy-w-tej-sekcji]

<Cards>
  <Card title="Stawki VAT" description="23/8/5/0/zw/np — zakresy, mechanika art. 41 i art. 146ef, załączniki 3 i 10, zwolnienia art. 43." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/stawki" />

  <Card title="JPK_V7M — art. 99" description="Miesięczna deklaracja łączona z ewidencją: pola K_10–K_47, znaczniki GTU i procedur, NrKSeF/OFF, terminy do 25. dnia następnego miesiąca." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/jpk-v7m" />

  <Card title="Odwrotne obciążenie — art. 28b, 17" description="Import usług B2B z UE i spoza UE — mechanizm self-assessment, podwójny wpis w JPK_V7M (sprzedaż + zakup)." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/odwrotne-obciazenie" />

  <Card title="WNT i WDT — art. 9, 13" description="Wewnątrzwspólnotowe nabycie i dostawa towarów — stawka 0% dla WDT pod warunkami art. 42, pola K_21/K_23/K_24 w JPK." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt" />

  <Card title="VAT-UE — art. 100" description="Informacja podsumowująca o transakcjach UE (WDT/WNT/usługi art. 28b/procedura uproszczona) — miesięcznie do 25. dnia." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue" />

  <Card title="MPP split payment — art. 108a" description="Mechanizm podzielonej płatności — obowiązkowy powyżej 15 000 zł dla towarów z Załącznika 15, dobrowolny dla wszystkich faktur." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/mpp-split-payment" />

  <Card title="Biała lista — art. 96b + OrdPod art. 117ba" description="Wykaz podatników VAT — weryfikacja rachunku kontrahenta, solidarna odpowiedzialność za VAT spoza wykazu, ZAW-NR jako ścieżka obronna." href="/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista" />
</Cards>

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

* **KSeF** — obowiązek wystawiania faktur przez Krajowy System
  e-Faktur od 1 lutego 2026 r. (duzi podatnicy) / 1 kwietnia 2026 r.
  (pozostali). Wszystkie faktury objęte przez ustawę o VAT
  (<LegalRef act="VAT" art="106e" />) muszą mieć formę FA(3).
  Szczegóły: [Sekcja KSeF](/docs/zgodnosc-z-prawem/ksef/).
* **Kalendarz terminów** — terminy składania JPK\_V7M, VAT-UE,
  zaliczek CIT: [Kalendarz terminów](/docs/zgodnosc-z-prawem/kalendarz-terminow).

## Co nie jest w zakresie tej sekcji [#co-nie-jest-w-zakresie-tej-sekcji]

* **Procedury szczególne** (marża biur podróży, marża towarów
  używanych, OSS, IOSS, rolnik ryczałtowy) — Numify nie wspiera tych
  procedur.
* **Obowiązek podatkowy** (art. 19a) — omówiony w granicznym zakresie
  przy konkretnych artykułach (JPK, WNT/WDT, odwrotne obciążenie).
* **VAT w obrocie nieruchomościami** (art. 43 ust. 1 pkt 9–10a) —
  poza zakresem typowej operacyjnej sp. z o.o.

## Źródło tekstu ustawy [#źródło-tekstu-ustawy]

Tekst jednolity obowiązuje na podstawie **Dz.U. 2025 poz. 775**
(obwieszczenie Marszałka Sejmu z 6 czerwca 2025 r.), z późniejszymi
zmianami — w tym pakietem KSeF (Dz.U. 2023 poz. 1598, kluczowe
przepisy wejdą w życie 1 lutego i 1 kwietnia 2026 r.). Cytowania
w tej sekcji odsyłają do [ISAP — karta aktu](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20250000775)
przez komponent `<LegalRef>`.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja sekcji artykuł-po-artykule. Struktura oparta na
    aktualnym tekście jednolitym ustawy o VAT (Dz.U. 2025 poz. 775),
    z uwzględnieniem art. 146ef jako aktualnej podstawy prawnej
    stawek 23/8/4 %.
  </ChangeEntry>
</ChangeHistory>


---

# VAT-UE — informacja podsumowująca — art. 100
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue
Description: Zbiorcza informacja o transakcjach wewnątrzwspólnotowych — zakres (WDT, WNT, usługi art. 28b, procedura uproszczona 136, call-off stock), termin do 25. dnia następnego miesiąca, wyłącznie elektronicznie.
Review status: internal
Updated: 2026-04-16



**VAT-UE** (informacja podsumowująca) to miesięczne zbiorcze
zestawienie transakcji wewnątrzwspólnotowych, w którym polski
podatnik raportuje — per kontrahent — łączne kwoty WDT, WNT,
usług art. 28b oraz innych transakcji UE za miniony miesiąc.

VAT-UE jest **narzędziem kontrolnym systemu VIES** — dane z informacji
wszystkich państw UE łączą się wzajemnie, umożliwiając porównanie
„co Polska firma wykazała jako WDT do Niemiec" z „co niemiecka firma
wykazała jako WNT z Polski". Rozbieżność uruchamia kontrolę.

<ComplianceDisclaimer />

## Kto składa VAT-UE [#kto-składa-vat-ue]

<LegalRef act="VAT" art="100" paragraph="1" /> obowiązuje:

> Podatnicy, o których mowa w art. 15, zarejestrowani jako podatnicy
> VAT UE, są obowiązani składać w urzędzie skarbowym zbiorcze
> informacje (...).

Warunek: **rejestracja jako podatnik VAT UE** (identyfikator PL + NIP).
Rejestracja odbywa się przez VAT-R (pole E.1) lub oddzielne zgłoszenie
VAT-R przed pierwszą transakcją wewnątrzwspólnotową.

Spółka niezarejestrowana jako VAT UE **nie może** legalnie wystawić
faktury WDT ze stawką 0 % (art. 42 ust. 1 pkt 3 — jeden z trzech
warunków), więc w praktyce rejestracja VAT UE jest bezwarunkowa dla
firm prowadzących handel UE.

## Zakres VAT-UE — art. 100 ust. 1 [#zakres-vat-ue--art-100-ust-1]

Pięć kategorii transakcji:

| pkt | Zakres                                                                                                | Podstawa prawna                                                                 | Odpowiednie pola JPK\_V7M |
| --- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------- |
| 1   | WDT do kontrahentów VAT UE                                                                            | <LegalRef act="VAT" art="13" /> + <LegalRef act="VAT" art="42" paragraph="1" /> | K\_21                     |
| 2   | WNT od kontrahentów VAT UE                                                                            | <LegalRef act="VAT" art="9" /> + <LegalRef act="VAT" art="11" />                | K\_23 / K\_24             |
| 3   | Dostawa w procedurze uproszczonej (transakcja trójstronna)                                            | <LegalRef act="VAT" art="136" />                                                | K\_21 z adnotacją         |
| 4   | **Usługi art. 28b** świadczone na rzecz podatników VAT UE, dla których zobowiązanym jest usługobiorca | <LegalRef act="VAT" art="28b" />                                                | K\_11 + K\_12             |
| 5   | Przemieszczenia w procedurze magazynu typu call-off stock                                             | Dział II, rozdz. 3b                                                             | Ewidencja odrębna         |

### Świadczenie usług B2B dla kontrahenta UE — często pomijane [#świadczenie-usług-b2b-dla-kontrahenta-ue--często-pomijane]

Najczęściej niedocenianym przypadkiem jest **punkt 4** — gdy polska
sp. z o.o. **świadczy** usługę (np. konsulting, usługi IT,
marketing) dla klienta firmowego z innego państwa UE, usługa nie
podlega polskiemu VAT (miejsce świadczenia = kraj nabywcy,
<LegalRef act="VAT" art="28b" paragraph="1" />), ale **podlega
wykazaniu w VAT-UE**.

Niewykazanie takiej usługi jest bardzo typowym błędem firm
usługowych, które kojarzą VAT-UE wyłącznie z handlem towarami.

## Zakres danych — art. 100 ust. 8 [#zakres-danych--art-100-ust-8]

Na każdą transakcję wykazywaną w VAT-UE wymagane są:

| Dane                                                                          | Źródło                     |
| ----------------------------------------------------------------------------- | -------------------------- |
| Nazwa i NIP składającego (z kodem kraju PL)                                   | Rejestr VAT UE             |
| Numer identyfikacyjny kontrahenta z kodem kraju (np. `DE123456789`)           | Weryfikacja VIES           |
| Łączna wartość transakcji per kontrahent                                      | Suma wpisów VAT za miesiąc |
| Dla transakcji trójstronnych (art. 136) — adnotacja o procedurze uproszczonej | Ewidencja                  |
| Dla call-off stock — numer identyfikacyjny PC docelowego                      | Ewidencja odrębna          |

Dane są **zbiorcze per kontrahent, nie per faktura**. Jeśli polska
spółka wystawiła w kwietniu dwanaście faktur WDT do niemieckiego
klienta, w VAT-UE pojawia się jeden wiersz z sumą dwunastu faktur.

## Termin — art. 100 ust. 3 [#termin--art-100-ust-3]

> Informacje podsumowujące składa się za okresy miesięczne, za pomocą
> środków komunikacji elektronicznej, w terminie do 25. dnia miesiąca
> następującego po miesiącu, w którym:
>
> 1. powstał obowiązek podatkowy z tytułu dokonania transakcji,
>    o których mowa w ust. 1 pkt 1–4;
> 2. dokonano przemieszczenia towarów (...) w procedurze call-off
>    stock.

<DeadlineBadge type="vat-ue" />

Termin zbieżny z JPK\_V7M — obie informacje za ten sam miesiąc
składane są do 25. dnia następnego miesiąca. Format — **wyłącznie
elektronicznie** (art. 100 ust. 3).

## Skutki braku lub błędnej VAT-UE [#skutki-braku-lub-błędnej-vat-ue]

### Utrata stawki 0% dla WDT [#utrata-stawki-0-dla-wdt]

<LegalRef act="VAT" art="42" paragraph="1a" /> jednoznacznie
stanowi:

> Stawka podatku, o której mowa w ust. 1, nie ma zastosowania, jeżeli:
>
> 1. podatnik nie dopełnił obowiązku, o którym mowa w art. 100
>    ust. 1 pkt 1 lub ust. 3 pkt 1 (...).

Niewykazanie WDT w VAT-UE lub brak informacji za miesiąc = WDT
opodatkowana stawką krajową (zwykle <VatRate rate="23" />). Jedynym
wyjściem jest **pisemne wyjaśnienie uchybienia** naczelnikowi US.
Akceptowalne są sytuacje losowe (awaria systemu, błędna weryfikacja
kontrahenta); niedbałe pominięcie — raczej nie.

### Brak odliczenia WNT [#brak-odliczenia-wnt]

Dla WNT brak VAT-UE nie powoduje bezpośredniej sankcji, ale tworzy
rozbieżność w VIES między polskim nabywcą a zagranicznym dostawcą.
Typowa konsekwencja — wezwanie US do wyjaśnienia.

## Weryfikacja VAT UE kontrahenta — dowód należytej staranności [#weryfikacja-vat-ue-kontrahenta--dowód-należytej-staranności]

Podstawowym obowiązkiem przed wystawieniem faktury WDT ze stawką 0 %
jest sprawdzenie ważności numeru VAT UE kontrahenta w systemie VIES
(europejska baza). Wynik weryfikacji (data, status, nazwa firmy)
stanowi dowód dochowania należytej staranności w razie kontroli.

Numify automatyzuje weryfikację VIES w
<ServiceRef path="src/lib/services/vies-validation.ts">vies-validation.ts</ServiceRef>
— funkcja `validateVatNumber` wysyła zapytanie SOAP do punktu
końcowego komisji i zapisuje wynik w bazie (pola `isValid`,
`companyName`, `companyAddress`, `requestDate`). Dane przechowywane
są jako dowód na 10 lat.

## Jak Numify generuje VAT-UE [#jak-numify-generuje-vat-ue]

Moduł
<ServiceRef path="src/lib/services/vat-ue.ts">vat-ue.ts</ServiceRef>
generuje plik XML VAT-UE na podstawie wpisów z tabeli `vat_entries`
filtrowanych po:

* Kontrahentach z UE (na podstawie pola `counterpartyCountry`).
* Typie transakcji — sprzedaż WDT, zakup WNT, sprzedaż usług art. 28b
  (reverse charge z polskim dostawcą).

Struktura XML zawiera trzy grupy kontrahentów (pole `type`):

| Wartość   | Zakres                                             |
| --------- | -------------------------------------------------- |
| `towary`  | WNT — nabycie towarów                              |
| `dostawa` | WDT — dostawa towarów                              |
| `uslugi`  | Usługi art. 28b świadczone na rzecz kontrahenta UE |

Wynik funkcji `generateVatUe` to obiekt z polami `hasTransactions`,
`counterparties` i `xml`. Brak transakcji UE za miesiąc oznacza
**brak obowiązku złożenia** (informacja zerowa nie jest wymagana
w obecnym stanie prawnym).

## Korekta VAT-UE [#korekta-vat-ue]

Korekta polega na złożeniu **nowej** informacji podsumowującej za
ten sam okres z oznaczeniem `CelZlozenia = 2` (korekta). Plik zawiera
tylko te pozycje, które są zmieniane (wartość, NIP, kwota) — nie
cały komplet wszystkich transakcji miesiąca.

Numify nie implementuje automatycznego różnicowego trybu korekty —
generuje pełny plik; korekty są realizowane przez edycję i ponowne
generowanie.

## Typowe błędy [#typowe-błędy]

* **Pominięcie usług B2B dla kontrahenta UE** — usługowa sp. z o.o.
  wystawia fakturę „reverse charge" niemieckiemu klientowi i uważa
  sprawę za zakończoną. Transakcja **musi** trafić do VAT-UE
  (art. 100 ust. 1 pkt 4), inaczej grozi zaleganie z obowiązkiem.
* **Brak weryfikacji VAT UE przed fakturą** — opieranie się wyłącznie
  na numerze podanym przez kontrahenta, bez sprawdzenia w VIES. Jeżeli
  numer okaże się nieważny, stawka 0 % jest niedozwolona i US
  doliczy VAT 23 %.
* **Wykazywanie WDT mimo braku dowodów wywozu** — zgodnie z art. 42
  ust. 12 transakcja bez dowodów nie jest wykazywana w ewidencji
  tego okresu; pojawia się w późniejszym okresie stawce krajowej.
  Błędne wcześniejsze pokazanie w VAT-UE generuje rozbieżność
  z sąsiednim VIES.
* **Składanie „zerowej" VAT-UE za każdy miesiąc** — nie ma takiego
  obowiązku. Jeśli w miesiącu nie było transakcji wewnątrzwspólnotowych,
  informacja nie jest wymagana.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 100 ustawy o VAT (Dz.U. 2025
    poz. 775 t.j.) oraz implementacji `vat-ue.ts` i `vies-validation.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Mechanizm podzielonej płatności (MPP) — art. 108a
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/mpp-split-payment
Description: Split payment w Polsce — obowiązkowy dla faktur powyżej 15 000 zł dla towarów i usług z Załącznika 15 VAT, dobrowolny dla wszystkich innych faktur, komunikat przelewu i rachunek VAT.
Review status: internal
Updated: 2026-04-16



**Mechanizm podzielonej płatności** (ang. *split payment*, dalej:
MPP) dzieli płatność faktury VAT na dwa strumienie:

* Kwota **netto** idzie na zwykły rachunek rozliczeniowy dostawcy.
* Kwota **VAT** idzie na specjalny **rachunek VAT** dostawcy, którym
  ten może dysponować wyłącznie w wąskim zakresie (zapłata VAT do
  US, zapłata VAT do innego dostawcy w MPP, wybrane podatki).

Celem jest ograniczenie wyłudzeń VAT w łańcuchach dostaw — środek
oznaczony jako VAT nie może zostać „zniknięty" przez nieuczciwego
dostawcę.

<ComplianceDisclaimer />

## Dwa reżimy MPP — dobrowolny i obowiązkowy [#dwa-reżimy-mpp--dobrowolny-i-obowiązkowy]

### Dobrowolny — art. 108a ust. 1 [#dobrowolny--art-108a-ust-1]

<LegalRef act="VAT" art="108a" paragraph="1" /> umożliwia **każdemu**
nabywcy towaru lub usługi od polskiego podatnika VAT czynnego
zastosowanie MPP — niezależnie od wartości faktury i rodzaju
transakcji.

Dlaczego korzystać dobrowolnie? Trzy korzyści:

1. **Solidarna odpowiedzialność za VAT sprzedawcy jest wyłączona**
   dla kwoty zapłaconej w MPP (ochrona w razie, gdy sprzedawca okaże
   się nieuczciwy).
2. **Płatność MPP zwalnia z konsekwencji braku weryfikacji białej
   listy** — zobacz [Biała lista](/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista).
3. **Szybszy zwrot VAT** (25 dni zamiast 60 dni, jeżeli wniosek o
   zwrot złożono na rachunek VAT).

### Obowiązkowy — art. 108a ust. 1a [#obowiązkowy--art-108a-ust-1a]

<LegalRef act="VAT" art="108a" paragraph="1a" /> narzuca MPP:

> Przy dokonywaniu płatności za nabyte towary lub usługi wymienione
> w załączniku nr 15 do ustawy, udokumentowane fakturą, w której
> kwota należności ogółem przekracza kwotę 15 000 zł lub jej
> równowartość wyrażoną w walucie obcej, podatnicy są obowiązani
> zastosować mechanizm podzielonej płatności.

Dwa warunki łączne:

1. Kwota brutto faktury > &#x2A;*<Grosze value="1500000" />** (15 000 zł).
2. Faktura obejmuje towary lub usługi z **Załącznika 15** do ustawy.

Jeśli oba są spełnione — MPP **obowiązkowy**, niezależnie od woli
stron.

## Załącznik 15 — towary i usługi objęte obowiązkiem [#załącznik-15--towary-i-usługi-objęte-obowiązkiem]

Załącznik 15 zawiera \~150 pozycji. Najczęściej spotykane grupy:

| Grupa                                      | Przykłady                                             |
| ------------------------------------------ | ----------------------------------------------------- |
| Elektronika                                | Komputery, smartfony, konsole, podzespoły komputerowe |
| Wyroby metalowe                            | Stal, aluminium, miedź, wyroby ze złota               |
| Paliwa i oleje                             | Benzyna, olej napędowy, oleje smarowe                 |
| Usługi budowlane                           | Roboty ogólnobudowlane, montaż, wykończenie wnętrz    |
| Części samochodowe                         | Silniki, elementy podwozia, akumulatory               |
| Usługi najmu i dzierżawy w dla budownictwa | Wynajem dźwigów, rusztowań                            |
| Odpady                                     | Złom, odpady metalowe, papierowe, szklane             |
| Węgiel, koks                               | Węgiel kamienny, brunatny, koks                       |

**Uwaga:** Załącznik 15 jest precyzyjny — nie „komputery ogółem", ale
konkretne pozycje z PKWiU. W wątpliwych przypadkach należy
skonsultować konkretną pozycję z klasyfikacją PKWiU i Załącznikiem 15.

Dla typowej usługowej sp. z o.o. (konsulting, IT) Załącznik 15
dotyczy zwykle zakupów elektroniki (laptopy, monitory) i samochodów
służbowych — rzadko sprzedaży.

## Mechanika — art. 108a ust. 2 i 3 [#mechanika--art-108a-ust-2-i-3]

<LegalRef act="VAT" art="108a" paragraph="2" /> definiuje mechanikę:

> Zastosowanie mechanizmu podzielonej płatności polega na tym, że:
>
> 1. zapłata kwoty odpowiadającej całości albo części kwoty podatku
>    wynikającej z otrzymanej faktury jest dokonywana na rachunek VAT;
>
> 2. zapłata całości albo części kwoty odpowiadającej wartości
>    sprzedaży netto (...) jest dokonywana na rachunek bankowy (...).

Zapłata odbywa się **jednym przelewem** z podwójnym zapisem —
komunikat przelewu MPP (<LegalRef act="VAT" art="108a" paragraph="3" />)
zawiera:

| Pole          | Wartość                                                      |
| ------------- | ------------------------------------------------------------ |
| Kwota VAT     | Kwota do zapłaty na rachunek VAT                             |
| Kwota brutto  | Kwota netto + VAT (obie trafią do dostawcy, ale rozdzielnie) |
| Numer faktury | Identyfikator dokumentu (dla faktury KSeF — `NrKSeF`)        |
| NIP dostawcy  | Numer dostawcy                                               |

Bank w komunikacie MPP automatycznie rozdziela środki — VAT trafia
na rachunek VAT powiązany z rachunkiem rozliczeniowym dostawcy.

### Rachunek VAT — czym jest [#rachunek-vat--czym-jest]

Każdy podatnik VAT w Polsce ma automatycznie **rachunek VAT** —
techniczny rachunek powiązany z rachunkiem rozliczeniowym. Bank
otwiera go z urzędu przy zakładaniu rachunku firmowego (ustawa Prawo
bankowe, art. 62a). Środki na rachunku VAT mogą być wykorzystane
wyłącznie na:

* Zapłatę VAT, CIT, PIT, ZUS i wybranych akcyzy.
* Zapłatę VAT do innego dostawcy w MPP.
* Przelew na własny rachunek rozliczeniowy za zgodą US (art. 108b).

## Obowiązek oznaczania faktury — art. 106e ust. 1 pkt 18a [#obowiązek-oznaczania-faktury--art-106e-ust-1-pkt-18a]

<LegalRef act="VAT" art="106e" paragraph="1" /&#x3E; pkt 18a wymaga
dodania wyrazów &#x2A;*„mechanizm podzielonej płatności"** na fakturach:

> w przypadku faktur, w których kwota należności ogółem przekracza
> kwotę 15 000 zł lub jej równowartość wyrażoną w walucie obcej,
> obejmujących dokonaną na rzecz podatnika dostawę towarów lub
> świadczenie usług, o których mowa w załączniku nr 15 do ustawy —
> wyrazy „mechanizm podzielonej płatności".

Na fakturze XML FA(3) odpowiada to atrybutowi `MPP = 1`. Dla faktur
poza KSeF — literalne wyrażenie „mechanizm podzielonej płatności"
w treści dokumentu.

W JPK\_V7M — oznaczenie `<MPP>1</MPP>` w wierszu ewidencji.

## Sankcje za naruszenie [#sankcje-za-naruszenie]

### Brak oznaczenia na fakturze — art. 106e ust. 12 [#brak-oznaczenia-na-fakturze--art-106e-ust-12]

Sprzedawca, który wystawia fakturę objętą obowiązkiem MPP (kwota > 15 000 zł
z Załącznika 15) &#x2A;*bez adnotacji „mechanizm podzielonej płatności"**,
podlega dodatkowemu zobowiązaniu podatkowemu w wysokości **30 %
kwoty podatku** od tej dostawy / usługi:

> (...) naczelnik urzędu skarbowego (...) ustala dodatkowe zobowiązanie
> podatkowe w wysokości odpowiadającej 30% kwoty podatku przypadającej
> na dostawę towarów lub świadczenie usług wymienionych w załączniku
> nr 15 do ustawy, wykazanej na tej fakturze.

Wyjątek (<LegalRef act="VAT" art="106e" paragraph="13" />) — jeżeli
nabywca zapłacił fakturę z zastosowaniem MPP mimo braku adnotacji,
sankcja nie jest nakładana.

### Brak MPP przy płatności obowiązkowej — art. 108a ust. 7 [#brak-mpp-przy-płatności-obowiązkowej--art-108a-ust-7]

Nabywca, który dostaje fakturę z adnotacją „mechanizm podzielonej
płatności" i **płaci bez MPP**, podlega sankcji **30 % kwoty VAT**:

> (...) naczelnik urzędu skarbowego (...) ustala dodatkowe zobowiązanie
> podatkowe w wysokości odpowiadającej 30% kwoty podatku (...).

Wyjątek (<LegalRef act="VAT" art="108a" paragraph="8" />) —
sprzedawca rozliczył całą kwotę VAT. Nie chroni to jednak przed
konsekwencjami w CIT — <LegalRef act="CIT" art="15d" paragraph="1" />
pkt 3 wyłącza zapłatę bez MPP (mimo oznaczenia faktury) z kosztów
uzyskania przychodów.

### Solidarna odpowiedzialność — art. 108a ust. 5 [#solidarna-odpowiedzialność--art-108a-ust-5]

Jeśli płatność MPP zostanie skierowana na rachunek innego podatnika
niż wskazany na fakturze (np. przez błąd lub cesję wierzytelności),
otrzymujący płatność odpowiada **solidarnie** za nierozliczony VAT
dostawcy — do wysokości kwoty otrzymanej na rachunek VAT.

## Kwoty w walucie obcej — art. 108a ust. 1a [#kwoty-w-walucie-obcej--art-108a-ust-1a]

Dla faktur walutowych > 15 000 zł kwotę brutto przelicza się na PLN
**według zasad stosowanych do określenia podstawy opodatkowania**
(czyli średni kurs NBP z dnia poprzedzającego powstanie obowiązku
podatkowego). MPP jest **zawsze wykonywany w złotych polskich**
(<LegalRef act="VAT" art="108a" paragraph="3" />) — nie można
zapłacić MPP w EUR.

Polski nabywca towaru o wartości 3 500 EUR × kurs 4,30 = 15 050 zł
brutto → MPP obowiązkowy (jeśli towar z Załącznika 15).

## Zbiorczy MPP — art. 108a ust. 3a [#zbiorczy-mpp--art-108a-ust-3a]

Dla wielu faktur od tego samego dostawcy w okresie od 1 dnia do
1 miesiąca można stosować **zbiorczy MPP** — jeden komunikat przelewu
obejmujący wszystkie faktury (ust. 3a i 3b). Dla faktur z KSeF
komunikat może dotyczyć dowolnych faktur w okresie, dla faktur poza
KSeF — wszystkich faktur w okresie.

Numify nie implementuje automatycznych zbiorczych MPP — użytkownik
opłaca każdą fakturę osobno.

## Księgowanie MPP [#księgowanie-mpp]

MPP nie zmienia księgowania VAT — nie tworzy odrębnych kont. Z
punktu widzenia księgi, płatność MPP to zwykły przelew, tylko
technicznie rozdzielony przez bank. Saldo rachunku VAT nie ma
odzwierciedlenia w księgach; widoczne jest w wyciągu bankowym.

## Typowe błędy [#typowe-błędy]

* **Pominięcie adnotacji „mechanizm podzielonej płatności"** przez
  wystawcę — grzywna 30 % VAT (<LegalRef act="VAT" art="106e" paragraph="12" />).
  Numify sprawdza kwotę brutto > 15 000 zł i obecność pozycji
  z Załącznika 15 w momencie tworzenia faktury, i dodaje adnotację
  automatycznie.
* **Zapłata bez MPP przy obowiązku** — sankcja 30 % VAT
  (<LegalRef act="VAT" art="108a" paragraph="7" />) + NKUP
  (<LegalRef act="CIT" art="15d" paragraph="1" /> pkt 3).
* **Dobrowolny MPP dla rachunku spoza białej listy** — MPP
  wyłącza solidarną odpowiedzialność wg <LegalRef act="OrdPod" art="117ba" paragraph="3" />
  pkt 4, ale **nie wyłącza** NKUP z CIT przy rachunku spoza białej listy —
  ochronę zapewnia dopiero ZAW-NR (CIT art. 15d ust. 4 pkt 1) albo
  MPP (CIT art. 15d ust. 4 pkt 3). W praktyce MPP zwykle wystarczy.
* **MPP w walucie obcej** — komunikat MPP musi być w PLN. Niektóre
  banki odrzucają MPP dla rachunków walutowych; wtedy podatnik
  przewalutowuje środki i wykonuje MPP w PLN.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 108a, 106e ustawy o VAT
    (Dz.U. 2025 poz. 775 t.j.) oraz art. 15d CIT jako podstawa NKUP
    przy pominięciu MPP.
  </ChangeEntry>
</ChangeHistory>


---

# JPK_V7M — art. 99
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/jpk-v7m
Description: Jednolity Plik Kontrolny VAT z deklaracją — struktura pliku XML, pola K_10 do K_47, znaczniki GTU i procedur, oznaczenia NrKSeF/OFF/BFK/DI, termin do 25. dnia następnego miesiąca.
Review status: internal
Updated: 2026-04-16



**JPK\_V7M** to ustrukturyzowany plik XML, w którym sp. z o.o.
rozliczająca się miesięcznie z VAT składa **jednocześnie**
deklarację podatkową i ewidencję sprzedaży oraz zakupów.
Odpowiednikiem dla małych podatników rozliczających się kwartalnie
jest **JPK\_V7K**.

Podstawą prawną jest <LegalRef act="VAT" art="99" paragraph="11c" />,
który wymaga, aby deklaracja VAT była sporządzana „zgodnie z wzorem
dokumentu elektronicznego (...), który obejmuje deklarację
i ewidencję, o której mowa w art. 109 ust. 3". Szczegółową strukturę
określa <LegalRef act="Rozp_JPK_V7M" /> (Dz.U. 2019 poz. 1988 ze zm.).

<ComplianceDisclaimer />

## Terminy składania — art. 99 [#terminy-składania--art-99]

<LegalRef act="VAT" art="99" paragraph="1" /> określa termin
miesięcznej deklaracji:

> (...) są obowiązani składać w urzędzie skarbowym deklaracje
> podatkowe za okresy miesięczne w terminie do 25. dnia miesiąca
> następującego po każdym kolejnym miesiącu (...).

<DeadlineBadge type="jpk-v7m" />

Dla małych podatników rozliczających się kwartalnie
(<LegalRef act="VAT" art="99" paragraph="2" />) termin to 25. dnia
miesiąca po każdym kwartale. &#x2A;*Uwaga:** ograniczenia w korzystaniu
z rozliczenia kwartalnego nakłada <LegalRef act="VAT" art="99" paragraph="3a" />
— wyłączenie w okresie 12 miesięcy od rejestracji oraz przy sprzedaży
towarów z Załącznika 15 powyżej 50 000 zł miesięcznie.

<LegalRef act="VAT" art="99" paragraph="11b" /> wymaga, aby wszystkie
deklaracje składane były wyłącznie elektronicznie.

## Dwa bloki danych — deklaracja + ewidencja [#dwa-bloki-danych--deklaracja--ewidencja]

Plik XML JPK\_V7M zawiera dwie sekcje:

| Sekcja         | Zakres                                                                                       | Odpowiednik „papierowy" |
| -------------- | -------------------------------------------------------------------------------------------- | ----------------------- |
| **Deklaracja** | Pozycje P\_10 – P\_68 — podsumowanie rozliczenia za okres                                    | VAT-7(23)               |
| **Ewidencja**  | Zbiór wierszy sprzedaży (SprzedazWiersz) i zakupów (ZakupWiersz) z pojedynczymi polami K\_xx | Rejestr VAT             |

Dane deklaracji są **wyliczane z ewidencji** — nie należy ich
wpisywać ręcznie. Numify generuje plik w
<ServiceRef path="src/lib/services/jpk-vat-generator.ts" tests="22">jpk-vat-generator.ts</ServiceRef>
na podstawie wpisów z tabeli `vat_entries`.

## Pola K\_xx — klasyfikacja sprzedaży i zakupów [#pola-k_xx--klasyfikacja-sprzedaży-i-zakupów]

### Sprzedaż (K\_10 – K\_36) [#sprzedaż-k_10--k_36]

| Pole          | Zakres                                                            | Podstawa prawna                                                                    |
| ------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| K\_10         | Sprzedaż zwolniona z VAT                                          | <LegalRef act="VAT" art="43" />                                                    |
| K\_11         | Sprzedaż poza terytorium kraju                                    | <LegalRef act="VAT" art="28b" /> (usługi)                                          |
| K\_12         | Usługi art. 28b świadczone na rzecz kontrahentów UE (część K\_11) | <LegalRef act="VAT" art="100" paragraph="1" /> pkt 4                               |
| K\_13         | Sprzedaż krajowa ze stawką <VatRate rate="0" />                   | <LegalRef act="VAT" art="83" />                                                    |
| K\_15 / K\_16 | Netto / VAT przy stawce <VatRate rate="5" />                      | <LegalRef act="VAT" art="41" paragraph="2a" />                                     |
| K\_17 / K\_18 | Netto / VAT przy stawce <VatRate rate="8" />                      | <LegalRef act="VAT" art="41" paragraph="2" /> + <LegalRef act="VAT" art="146ef" /> |
| K\_19 / K\_20 | Netto / VAT przy stawce <VatRate rate="23" />                     | <LegalRef act="VAT" art="41" paragraph="1" /> + <LegalRef act="VAT" art="146ef" /> |
| K\_21         | WDT — wewnątrzwspólnotowa dostawa towarów (<VatRate rate="0" />)  | <LegalRef act="VAT" art="13" /> + <LegalRef act="VAT" art="42" />                  |
| K\_22         | Eksport towarów (<VatRate rate="0" />)                            | <LegalRef act="VAT" art="41" paragraph="4" />                                      |
| K\_23 / K\_24 | Netto / VAT przy WNT                                              | <LegalRef act="VAT" art="9" />                                                     |
| K\_29 / K\_30 | Netto / VAT przy imporcie usług art. 28b                          | <LegalRef act="VAT" art="17" paragraph="1" /> pkt 4                                |

### Zakupy (K\_40 – K\_47) [#zakupy-k_40--k_47]

| Pole          | Zakres                                                       |
| ------------- | ------------------------------------------------------------ |
| K\_40 / K\_41 | Netto / VAT naliczony od nabycia środków trwałych            |
| K\_42 / K\_43 | Netto / VAT naliczony od nabycia pozostałych towarów i usług |
| K\_44 – K\_47 | Korekty i zwroty (m.in. korekta rocznej proporcji)           |

Numify klasyfikuje wpis VAT do odpowiedniej kategorii w funkcji
`classifySale` w
<ServiceRef path="src/lib/services/jpk-vat-generator.ts" tests="22">jpk-vat-generator.ts</ServiceRef>
— na podstawie kraju kontrahenta (UE/poza UE/PL) i stawki VAT
z pozycji faktury.

## Znaczniki GTU — kody towarów i usług [#znaczniki-gtu--kody-towarów-i-usług]

Znaczniki GTU\_01 – GTU\_13 oznaczają **grupy towarów i usług
wrażliwe** z perspektywy ryzyka podatkowego. Muszą być ujawnione
w wierszu ewidencji dla sprzedawcy.

| Kod     | Zakres                                                                     |
| ------- | -------------------------------------------------------------------------- |
| GTU\_01 | Napoje alkoholowe                                                          |
| GTU\_02 | Paliwa                                                                     |
| GTU\_03 | Oleje opałowe, oleje smarowe                                               |
| GTU\_04 | Wyroby tytoniowe                                                           |
| GTU\_05 | Odpady                                                                     |
| GTU\_06 | Urządzenia elektroniczne, telefony, konsole                                |
| GTU\_07 | Pojazdy                                                                    |
| GTU\_08 | Metale szlachetne i nieszlachetne                                          |
| GTU\_09 | Leki i wyroby medyczne                                                     |
| GTU\_10 | Budynki, budowle i grunty                                                  |
| GTU\_11 | Prawa do emisji CO2                                                        |
| GTU\_12 | Usługi niematerialne (doradztwo, księgowość, prawne, zarządcze, marketing) |
| GTU\_13 | Usługi transportowe i gospodarki magazynowej                               |

Dla typowej usługowej sp. z o.o. relewantny jest głównie **GTU\_12**
(konsulting, księgowość, usługi prawne, marketing). Numify przechowuje
znaczniki w polu `gtuCodes` w tabeli `vat_entries` (wartości oddzielone
przecinkami, np. `GTU_12,GTU_13`).

## Oznaczenia procedur — MPP, TP, WEW, FP, RO... [#oznaczenia-procedur--mpp-tp-wew-fp-ro]

Oddzielną grupę znaczników stanowią **oznaczenia procedur**:

| Kod                                                  | Zakres                                                                                                              |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| MPP                                                  | Transakcja objęta obowiązkowym mechanizmem podzielonej płatności (<LegalRef act="VAT" art="108a" paragraph="1a" />) |
| TP                                                   | Transakcja z podmiotem powiązanym                                                                                   |
| WEW                                                  | Dokument wewnętrzny (np. dowód na czynności nieodpłatne, korekta podstawy)                                          |
| FP                                                   | Faktura do paragonu fiskalnego                                                                                      |
| RO                                                   | Zbiorcza informacja o sprzedaży paragonowej                                                                         |
| B\_SPV / B\_MPV / B\_SPV\_DOSTAWA / B\_MPV\_PROWIZJA | Bony jednego / różnego przeznaczenia                                                                                |

Numify przechowuje oznaczenia w polu `procedureMarkers` w tabeli
`vat_entries`. Generator JPK emituje je jako pojedyncze elementy XML
w wierszu ewidencji (np. `<MPP>1</MPP>`).

## KSeF w JPK\_V7M — NrKSeF / OFF / BFK / DI [#ksef-w-jpk_v7m--nrksef--off--bfk--di]

Od 1 lutego 2026 r. (duzi) / 1 kwietnia 2026 r. (wszyscy) każda
faktura wystawiana przez sp. z o.o. musi przechodzić przez KSeF.
Struktura JPK\_V7M(3) przewiduje cztery wzajemnie wyłączne warianty
oznaczenia faktury w wierszu sprzedaży:

| Element        | Znaczenie                                                                                                        |
| -------------- | ---------------------------------------------------------------------------------------------------------------- |
| `<NrKSeF>`     | Identyfikator faktury nadany przez KSeF (faktura ustrukturyzowana)                                               |
| `<OFF>1</OFF>` | Faktura wystawiona w trybie offline24 (<LegalRef act="VAT" art="106nf" />)                                       |
| `<BFK>1</BFK>` | Faktura elektroniczna lub papierowa wystawiona poza KSeF (w okresie przejściowym lub przy wyjątkach z obowiązku) |
| `<DI>1</DI>`   | Dokument inny niż faktura (np. paragon fiskalny)                                                                 |

Zgodnie ze schematem XSD elementy te muszą znaleźć się **przed**
znacznikami GTU i polami K\_xx. Walidację wymusza generator w
`jpk-vat-generator.ts` (switch na polu `ksefFlag` w rekordzie
`VatEntry`).

Szczegóły struktury KSeF i FA(3) — [KSeF format FA(3)](/docs/zgodnosc-z-prawem/ksef/format-fa3).

## Cel złożenia — oryginał czy korekta [#cel-złożenia--oryginał-czy-korekta]

<LegalRef act="VAT" art="99" paragraph="11c" /> odsyła do wzoru
dokumentu elektronicznego. W JPK\_V7M pole `CelZlozenia` przyjmuje:

* `1` — złożenie oryginalne.
* `2` — korekta.

Numify przekazuje cel jako parametr `purpose` w input dla
`generateJpkVatXml`. Korekta JPK\_V7M = pełne, ponowne sporządzenie
pliku z zaktualizowaną ewidencją (nie same różnice).

## Jak Numify generuje JPK\_V7M [#jak-numify-generuje-jpk_v7m]

Funkcja `generateJpkVatXml` w `jpk-vat-generator.ts`:

1. Pobiera wpisy VAT (`vat_entries`) za wybrany okres dla spółki.
2. Rozdziela wpisy na sprzedaż (sprzedaz) i zakup (zakup).
3. Klasyfikuje każdy wpis sprzedaży do kategorii K\_xx na podstawie
   stawki, kraju kontrahenta i typu transakcji.
4. Agreguje kwoty — deklaracja (P\_10 ... P\_38) + pola kontrolne
   (SprzedazCtrl, ZakupCtrl).
5. Buduje XML zgodny ze schematem MF — struktura `Naglowek`,
   `Podmiot1`, `Deklaracja`, `Ewidencja`.

Wpisy VAT są tworzone automatycznie przez
<ServiceRef path="src/lib/services/vat-register.ts">vat-register.ts</ServiceRef>
w momencie weryfikacji (zatwierdzenia) faktury. Dla transakcji
odwrotnego obciążenia tworzone są dwa wpisy — sprzedaż (VAT należny)

* zakup (VAT naliczony), co daje zero efektywnego VAT, ale obie
  pozycje pojawiają się w pliku zgodnie z wymogiem.

## Typowe błędy [#typowe-błędy]

* **Pominięcie znaczników MPP** — faktura > 15 000 zł zawierająca
  towary/usługi z Załącznika 15 musi mieć `<MPP>1</MPP>`. Brak
  oznaczenia skutkuje sankcją 30 % (<LegalRef act="VAT" art="106e" paragraph="12" />).
* **Niewykazanie importu usług art. 28b** — transakcja reverse charge
  musi trafić do K\_29/K\_30 (sprzedaż — VAT należny) **oraz** K\_42/K\_43
  (zakup — VAT naliczony). Pominięcie którejkolwiek strony = błędna
  deklaracja.
* **Brak NrKSeF dla faktur objętych obowiązkiem KSeF** — od terminu
  obowiązkowego KSeF każda faktura B2B musi mieć NrKSeF (lub OFF dla
  trybu awaryjnego). Sama `BFK` dopuszczalna wyłącznie dla wyjątków
  ustawowych.
* **Korekta przez sam wpis różnicowy** — korekta JPK\_V7M polega na
  złożeniu **pełnego, nowego pliku** z oznaczeniem `CelZlozenia = 2`,
  nie dodawaniu różnicy do kolejnego okresu.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 99 ustawy o VAT (Dz.U. 2025
    poz. 775 t.j.) oraz rozporządzeniu JPK\_V7M (Dz.U. 2019 poz. 1988
    ze zm.). Struktura K\_xx, GTU i procedur zgodna z bieżącym
    schematem JPK\_V7M(3) oraz implementacją `jpk-vat-generator.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 113 VAT — Zwolnienie podmiotowe (limit 240 000 zł)
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/art-113-zwolnienie-podmiotowe
Description: Zwolnienie od VAT ze względu na wartość sprzedaży — limit 240 000 zł rocznie (od 2026 r.), co wchodzi do limitu i co nie, proporcjonalny limit dla rozpoczynających, utrata zwolnienia po przekroczeniu, wyłączenia branżowe (doradztwo prawnicze, jubilerskie, e-commerce sprzętem elektronicznym), roczna karencja przed ponownym zwolnieniem. Dla typowej sp. z o.o. i sytuacje, gdy rezygnacja / utrata jest korzystna.
Review status: internal
Updated: 2026-04-17



**Zwolnienie podmiotowe** z VAT-u to ścieżka dla drobnych podatników —
zwalnia ze wszystkich obowiązków VAT (deklaracja, JPK\_V7M, rejestry,
faktury VAT) w zamian za **brak prawa do odliczenia naliczonego**.
<LegalRef act="VAT" art="113" /> określa limit roczny, wyłączenia
branżowe i zasady utraty / odzyskania zwolnienia.

Dla typowej sp. z o.o. zwolnienie jest **rzadko wybierane** — większość
transakcji z kontrahentami B2B wymaga faktury VAT i oczekuje prawa
do odliczenia po drugiej stronie. Ale na początku działalności lub dla
bardzo małych spółek jednoosobowych — może być ekonomicznie uzasadnione.

<ComplianceDisclaimer />

## Limit 240 000 zł — ust. 1 [#limit-240-000-zł--ust-1]

> Zwalnia się od podatku sprzedaż dokonywaną przez podatnika
> posiadającego siedzibę działalności gospodarczej na terytorium kraju,
> u którego wartość sprzedaży, z wyłączeniem podatku, nie przekroczyła
> w poprzednim ani bieżącym roku podatkowym kwoty 240 000 zł.

**Próg podniesiony z 200 000 zł do 240 000 zł od 1 stycznia 2026 r.**

Zwolnienie przysługuje „automatycznie" — bez składania wniosku —
dopóki:

* siedziba działalności gospodarczej **na terytorium kraju**,
* wartość sprzedaży (netto, bez VAT) **w poprzednim roku** nie
  przekroczyła 240 000 zł,
* wartość sprzedaży **w bieżącym roku** nie przekroczyła 240 000 zł.

Pierwszy rok działalności — stosuje się limit **proporcjonalny** z
ust. 9.

### Co to znaczy „wartość sprzedaży" [#co-to-znaczy-wartość-sprzedaży]

Kwoty **netto** (bez VAT) sprzedaży opodatkowanej — zarówno krajowej,
jak i zagranicznej (dostawy, usługi). Sprzedaż **zwolniona**
przedmiotowo na podstawie <LegalRef act="VAT" art="43" paragraph="1" />
do limitu **nie wchodzi** (ust. 2 pkt 2) — z wyjątkiem
niektórych transakcji, m.in. związanych z nieruchomościami.

## Co NIE wchodzi do limitu — ust. 2 [#co-nie-wchodzi-do-limitu--ust-2]

Do wartości 240 000 zł **nie wlicza się**:

1. **WNT na odległość** niepodlegającej opodatkowaniu w Polsce
   (ust. 2 pkt 1),
2. **Sprzedaży na odległość towarów importowanych** niepodlegającej
   opodatkowaniu w Polsce (pkt 1a),
3. **Sprzedaży zwolnionej przedmiotowo** na podstawie art. 43 ust. 1
   lub art. 82 ust. 3 — **z wyjątkami**:
   * transakcji związanych z nieruchomościami (ust. 2 pkt 2 lit. a),
   * usług finansowych z art. 43 ust. 1 pkt 7, 12 i 38–41 (lit. b),
   * usług ubezpieczeniowych i reasekuracyjnych (lit. c),
   * chyba że są to „transakcje pomocnicze" — wtedy są wyłączone
     także z tych wyjątków,
4. **Odpłatnej dostawy środków trwałych i WNiP** amortyzowanych
   (pkt 3).

W praktyce sp. z o.o. prowadząca normalną działalność nie ma
transakcji z ust. 2 — całość sprzedaży wchodzi do limitu.

## Rezygnacja ze zwolnienia — ust. 4 [#rezygnacja-ze-zwolnienia--ust-4]

> Podatnicy, o których mowa w ust. 1 i 9, mogą zrezygnować ze
> zwolnienia określonego w ust. 1 i 9 pod warunkiem zawiadomienia na
> piśmie o tym zamiarze naczelnika urzędu skarbowego **przed
> początkiem miesiąca, w którym rezygnują ze zwolnienia**.

Dla rozpoczynających w trakcie roku — przed dniem wykonania
pierwszej czynności.

### Formalność rezygnacji [#formalność-rezygnacji]

Formularz **VAT-R** (zgłoszenie rejestracyjne) z zaznaczeniem:

* rezygnacja z art. 113 ust. 1 / 9,
* data rezygnacji,
* wybór rozliczania (miesięcznie / kwartalnie).

Po rejestracji podatnik staje się **czynnym podatnikiem VAT** z
wszystkimi obowiązkami — deklaracje JPK\_V7M (zobacz
[art. 109](/docs/zgodnosc-z-prawem/ustawa-o-vat/art-109-ewidencja-vat)),
faktury VAT, prawo do odliczenia (zobacz
[art. 86](/docs/zgodnosc-z-prawem/ustawa-o-vat/art-86-odliczenie-vat)).

### Kiedy warto zrezygnować [#kiedy-warto-zrezygnować]

Kalkulacja opłacalności rezygnacji:

| Sytuacja                                          | Rezygnacja warto                                                                     |
| ------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Sprzedaż do klientów **B2B** (podatników VAT)     | tak — odbiorca odliczy VAT, cena brutto bez znaczenia; spółka odlicza VAT od zakupów |
| Sprzedaż do **konsumentów** (B2C)                 | nie — VAT to koszt ekonomiczny, spółka zostaje droższa o 23 %                        |
| Duża inwestycja początkowa (zakupy ze sporym VAT) | tak — odliczenie naliczonego na starcie                                              |
| Usługi mało-materiałochłonne, sprzedaż B2C        | nie — mały VAT naliczony, duży VAT należny                                           |

## Utrata zwolnienia — ust. 5 i 10 [#utrata-zwolnienia--ust-5-i-10]

### Przekroczenie limitu — ust. 5 [#przekroczenie-limitu--ust-5]

> Jeżeli wartość sprzedaży zwolnionej od podatku na podstawie ust. 1
> przekroczy kwotę, o której mowa w ust. 1, zwolnienie traci moc
> **począwszy od czynności, którą przekroczono tę kwotę**.

Kluczowe: utrata zwolnienia jest **natychmiastowa** — od konkretnej
transakcji, nie od początku miesiąca / następnego roku.

### Przykład [#przykład]

Rok 2026, sprzedaż kumulatywna do 10 listopada: 235 000 zł.
Faktura 15 listopada — 8 000 zł (netto).

* Po tej fakturze kumulatywna sprzedaż: 243 000 zł, próg 240 000 zł
  przekroczony.
* **Ta faktura musi być wystawiona z VAT** (stawka właściwa dla
  sprzedaży).
* Od tego momentu spółka jest **czynnym podatnikiem VAT** — obowiązek
  rejestracji VAT-R, faktur z VAT, JPK\_V7M.
* Należy złożyć VAT-R do 7 dni po przekroczeniu limitu.

### Proporcjonalny limit dla rozpoczynających — ust. 9 i 10 [#proporcjonalny-limit-dla-rozpoczynających--ust-9-i-10]

Spółka rozpoczynająca działalność w trakcie roku — limit liczony
proporcjonalnie:

```
limit proporcjonalny = 240 000 zł × (dni od rozpoczęcia do 31 XII) / 365
```

Spółka zarejestrowana 1 lipca — limit proporcjonalny na 2026:
240 000 × 184 / 365 ≈ **120 986 zł**.

Utrata tego proporcjonalnego zwolnienia — analogicznie do ust. 5 —
od czynności przekraczającej limit (ust. 10).

## Roczna karencja — ust. 11 [#roczna-karencja--ust-11]

> Podatnik, który utracił prawo do zwolnienia sprzedaży od podatku
> lub zrezygnował z tego zwolnienia, może, **nie wcześniej niż po
> upływie roku**, licząc od końca roku, w którym utracił prawo do
> zwolnienia lub zrezygnował z tego zwolnienia, ponownie skorzystać
> ze zwolnienia określonego w ust. 1.

Karencja = **co najmniej rok kalendarzowy** po roku, w którym
zwolnienie odpadło.

### Przykład [#przykład-1]

Spółka zrezygnowała ze zwolnienia 1 III 2024. Najwcześniejszy powrót
do zwolnienia:

* koniec roku 2024 + 1 rok = **1 I 2026**.

Oczywiście — tylko jeśli w międzyczasie spółka **nie przekroczyła**
240 000 zł w 2025 ani w pierwszych miesiącach 2026.

## Wyłączenia branżowe — ust. 13 [#wyłączenia-branżowe--ust-13]

Zwolnienia z ust. 1 i 9 **nie stosuje się** do podatników
dokonujących określonych dostaw / świadczących określone usługi —
nawet jeśli sprzedaż \< 240 000 zł.

### Wyłączone dostawy — ust. 13 pkt 1 [#wyłączone-dostawy--ust-13-pkt-1]

* **towary z załącznika nr 12** (metale szlachetne, biżuteria,
  dzieła sztuki),
* **towary akcyzowe** — z wyjątkiem energii elektrycznej (CN 2716),
  wyrobów tytoniowych, samochodów osobowych zaliczanych do środków
  trwałych,
* **budynki, budowle, ich części** w przypadkach art. 43 ust. 1
  pkt 10 lit. a i b (sprzedaż przed upływem 2 lat od pierwszego
  zasiedlenia),
* **tereny budowlane**,
* **nowe środki transportu**,
* **sprzedaż na odległość** (bez fizycznej obecności stron):
  * preparaty kosmetyczne (PKWiU 20.42.1),
  * komputery, wyroby elektroniczne, optyczne (PKWiU 26),
  * urządzenia elektryczne (PKWiU 27),
  * maszyny (PKWiU 28),
* **hurtowe i detaliczne części do pojazdów** (PKWiU 45.3, 45.4).

### Wyłączone usługi — ust. 13 pkt 2 [#wyłączone-usługi--ust-13-pkt-2]

* **usługi prawnicze**,
* **usługi doradcze** (z wyjątkiem doradztwa rolniczego),
* **usługi jubilerskie**,
* **usługi ściągania długów**, w tym factoring.

### Co to oznacza praktycznie [#co-to-oznacza-praktycznie]

Spółka **doradcza** (konsulting, IT consulting, marketing strategiczny)
— **zawsze** jest czynnym podatnikiem VAT, niezależnie od obrotów.
Limit 240 000 zł jej nie dotyczy.

Spółka **e-commerce** sprzedająca elektronikę online — analogicznie.

Spółka **prawnicza / kancelaria radcowska** w formie sp. z o.o.
(w zakresie dopuszczonym przepisami korporacyjnymi) — analogicznie.

## Realizacja w Numify [#realizacja-w-numify]

| Funkcja                                            | Obsługa                                                                                                             |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Status podatnika VAT                               | [ustawienia](/docs/korzystanie-z-numify/settings) — `vatStatus = 'zwolniony' / 'czynny' / 'zwolniony-rolnik'`       |
| Faktury bez VAT (podatnik zwolniony)               | [faktury](/docs/korzystanie-z-numify/faktury) — pozycja z adnotacją „zwolnienie z VAT na podstawie art. 113 ust. 1" |
| Ewidencja sprzedaży (uproszczona, ust. 1 art. 109) | [vat-register](/docs/korzystanie-z-numify/vat-register) — widok „zwolniony"                                         |
| Monitoring limitu 240 000 zł                       | dashboard — licznik skumulowanej sprzedaży netto w roku + progress bar + ostrzeżenie przy 90 %                      |
| Pełny VAT po rezygnacji / przekroczeniu            | automatyczne przełączenie dostępne funkcji (JPK\_V7M, GTU, znaczniki) po zmianie `vatStatus`                        |
| Formularz VAT-R                                    | rekomendowany workflow ręczny — link do druku MF                                                                    |

### Uczciwe framing — VAT-R [#uczciwe-framing--vat-r]

Numify **nie składa** formularza VAT-R do urzędu skarbowego
automatycznie. Monitoring limitu i podpowiedzi („do limitu zostało
X zł") są wbudowane, ale **decyzja i formalność rejestracji** —
rekomendowany workflow ręczny: wygenerować dane, pobrać druk VAT-R
z MF, podpisać, wysłać przez e-Deklaracje albo pocztą do urzędu.

## Częste błędy [#częste-błędy]

* **Wliczanie do limitu wartości brutto** zamiast netto — limit dotyczy
  kwot **bez VAT**.
* **Wliczanie sprzedaży zwolnionej przedmiotowo** (np. usług
  medycznych) — ust. 2 pkt 2 wyłącza.
* **Brak rejestracji VAT-R po przekroczeniu limitu** — 7 dni od
  pierwszej czynności po przekroczeniu; zaniechanie to wykroczenie
  skarbowe i powstaje dług VAT od pominiętych faktur.
* **Wystawianie „faktur VAT" jako podatnik zwolniony** — zwolnieni
  wystawiają **faktury bez VAT**, z adnotacją podstawy zwolnienia.
  Wystawienie z VAT przy statusie zwolnionym = art. 108 VAT (obowiązek
  zapłaty wykazanego VAT, bez prawa do odliczenia).
* **Powrót do zwolnienia przed upływem roku karencji** — narusza
  ust. 11.
* **Rezygnacja ze zwolnienia po rozpoczęciu miesiąca** — zawiadomienie
  musi trafić do US **przed** 1. dniem miesiąca rezygnacji.
* **Spółka doradcza / prawnicza / jubilerska korzystająca ze
  zwolnienia** — wyłączone z ust. 13, bez względu na obroty.

## Checklist — pozostawanie zwolnionym podatnikiem VAT [#checklist--pozostawanie-zwolnionym-podatnikiem-vat]

* [ ] Działalność nie jest na liście wyłączeń z ust. 13 (doradztwo,
  prawnicze, jubilerskie, e-commerce określoną elektroniką).
* [ ] Monitoring skumulowanej sprzedaży netto od 1 stycznia roku
  (dashboard Numify).
* [ ] Oszacowanie na koniec każdego miesiąca: czy prognoza rocznej
  sprzedaży ≤ 240 000 zł.
* [ ] Faktury sprzedaży wystawiane **bez VAT**, z adnotacją podstawy
  zwolnienia („zwolnienie z VAT na podstawie art. 113 ust. 1
  ustawy o VAT").
* [ ] Ewidencja uproszczona sprzedaży prowadzona codziennie (ust. 1
  art. 109).
* [ ] W razie przekroczenia limitu:
  * [ ] Pierwsza faktura przekraczająca limit — wystawiona z VAT.
  * [ ] VAT-R do urzędu skarbowego w 7 dni.
  * [ ] Przełączenie Numify na tryb czynnego podatnika VAT.
  * [ ] Pierwsza deklaracja JPK\_V7M za miesiąc przekroczenia limitu
    złożona do 25. dnia miesiąca następnego.


---

# Odwrotne obciążenie (import usług) — art. 28b, art. 17
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/odwrotne-obciazenie
Description: Reverse charge dla usług kupowanych od kontrahentów zagranicznych — miejsce świadczenia art. 28b, samoopodatkowanie nabywcy art. 17 ust. 1 pkt 4, podwójny wpis w JPK_V7M (K_29/K_30 + K_42/K_43).
Review status: internal
Updated: 2026-04-16



**Odwrotne obciążenie** (ang. *reverse charge*) to mechanizm, w
którym **nabywca usługi lub towaru rozlicza VAT zamiast sprzedawcy**.
Dla typowej sp. z o.o. najczęstszy przypadek to **import usług** od
kontrahenta z UE lub spoza UE — np. subskrypcja SaaS (AWS, Google,
Stripe), reklama (Facebook, LinkedIn Ads), usługi marketingowe
międzynarodowe.

Nie należy go mylić z WNT — WNT dotyczy **towarów** (art. 9 VAT),
odwrotne obciążenie usług — **usług** (art. 28b + art. 17 ust. 1
pkt 4). Obie transakcje opierają się na self-assessment, ale mechanika
i pola JPK są różne.

<ComplianceDisclaimer />

## Miejsce świadczenia usług B2B — art. 28b [#miejsce-świadczenia-usług-b2b--art-28b]

<LegalRef act="VAT" art="28b" paragraph="1" /> ustanawia zasadę
ogólną:

> Miejscem świadczenia usług w przypadku świadczenia usług na rzecz
> podatnika jest miejsce, w którym podatnik będący usługobiorcą
> posiada siedzibę działalności gospodarczej (...).

Innymi słowy — usługa B2B jest opodatkowana **tam, gdzie znajduje
się nabywca**. Polska sp. z o.o. kupująca usługę od firmy niemieckiej:
miejscem świadczenia jest Polska → VAT polski (23 %) rozliczany przez
polskiego nabywcę.

Wyjątki od zasady ogólnej określone są w art. 28b ust. 2–4 oraz
art. 28e–28n:

* Usługi związane z nieruchomościami — miejsce położenia nieruchomości
  (<LegalRef act="VAT" art="28e" />).
* Transport pasażerski — miejsce rozpoczęcia transportu (<LegalRef act="VAT" art="28f" />).
* Usługi restauracyjne i cateringowe — miejsce faktycznego wykonania.
* Wstęp na imprezy kulturalne, sportowe, naukowe — miejsce
  organizacji (<LegalRef act="VAT" art="28g" />).
* Krótkoterminowy najem środków transportu — miejsce wydania
  (<LegalRef act="VAT" art="28j" />).

**Dla typowej usługowej sp. z o.o.:** zakup SaaS, reklamy cyfrowej,
usług programistycznych, konsultingu — **zawsze art. 28b ust. 1**,
miejsce świadczenia = Polska, reverse charge.

## Kto jest podatnikiem — art. 17 ust. 1 pkt 4 [#kto-jest-podatnikiem--art-17-ust-1-pkt-4]

<LegalRef act="VAT" art="17" paragraph="1" /> pkt 4 ustanawia nabywcę
jako podatnika, gdy:

> a) usługodawcą jest podatnik nieposiadający siedziby działalności
> gospodarczej oraz stałego miejsca prowadzenia działalności
> gospodarczej na terytorium kraju (...);
>
> b) usługobiorcą jest (...) podatnik, o którym mowa w art. 15 (...).

Warunki łączne — obydwa muszą być spełnione:

1. **Usługodawca** nie ma siedziby ani stałego miejsca działalności
   w Polsce (np. Google LLC w USA, AWS w Luksemburgu).
2. **Usługobiorca** jest polskim podatnikiem VAT (typowa sp. z o.o.
   czynnym podatnikiem).

Przy spełnieniu warunków:

* Usługodawca wystawia fakturę **bez VAT** (stawka "reverse charge"
  lub zerowa).
* Nabywca wystawia sobie **VAT należny** po stawce polskiej
  (zwykle <VatRate rate="23" />) i jednocześnie **odlicza VAT
  naliczony** (jeżeli usługa służy działalności opodatkowanej).

<LegalRef act="VAT" art="17" paragraph="2" /> potwierdza:
„usługodawca (...) nie rozlicza podatku należnego" — obowiązek
w całości przechodzi na nabywcę.

## Efekt netto — zerowy wpływ na zobowiązanie VAT [#efekt-netto--zerowy-wpływ-na-zobowiązanie-vat]

W typowym scenariuszu polski nabywca używa nabytej usługi do
czynności opodatkowanych → pełne prawo do odliczenia. Dla np. usługi
za 1 000 EUR:

| Pozycja                     | Kwota netto                 | Kwota VAT | Efekt                 |
| --------------------------- | --------------------------- | --------- | --------------------- |
| VAT należny (K\_29/K\_30)   | 1 000 EUR (przeliczone PLN) | 23 %      | Zwiększa VAT należny  |
| VAT naliczony (K\_42/K\_43) | 1 000 EUR (przeliczone PLN) | 23 %      | Zmniejsza VAT należny |
| **Netto**                   | —                           | **0 zł**  | Transakcja neutralna  |

**Uwaga:** neutralność wymaga, aby nabywca:

* Był podatnikiem VAT czynnym.
* Nabywał usługę do czynności opodatkowanych (<LegalRef act="VAT" art="86" paragraph="1" />).
* Rozliczył VAT należny w deklaracji, w której wykazuje odliczenie
  (<LegalRef act="VAT" art="86" paragraph="10b" /> pkt 3).

Jednostka świadcząca wyłącznie czynności zwolnione z VAT (art. 43)
**nie odlicza** VAT naliczonego — transakcja reverse charge staje
się wówczas rzeczywistym kosztem (23 % dodane do faktury w PLN).

## Podwójny wpis w JPK\_V7M [#podwójny-wpis-w-jpk_v7m]

W JPK\_V7M transakcja reverse charge powoduje **dwa wpisy**:

### Wpis sprzedaży (VAT należny) [#wpis-sprzedaży-vat-należny]

| Pole  | Wartość                        |
| ----- | ------------------------------ |
| K\_29 | Podstawa (netto PLN)           |
| K\_30 | VAT należny (23 % × netto PLN) |

Jeśli dostawca jest z UE, dodatkowo wartość trafia do pola K\_11
i K\_12 (usługi art. 28b na rzecz podatnika VAT UE — zobacz [VAT-UE](/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue)).

### Wpis zakupu (VAT naliczony) [#wpis-zakupu-vat-naliczony]

| Pole  | Wartość                          |
| ----- | -------------------------------- |
| K\_42 | Podstawa (netto PLN)             |
| K\_43 | VAT naliczony (23 % × netto PLN) |

Numify automatyzuje ten podwójny wpis w
<ServiceRef path="src/lib/services/vat-register.ts">vat-register.ts</ServiceRef>.
Dla faktury zakupu z kraju UE i typu usługi (nie towaru) funkcja
tworzy **dwa rekordy VatEntry**:

1. Wpis z `registerType = "sprzedaz"`, K\_29/K\_30 (dodatkowo K\_12 jeśli UE).
2. Wpis z `registerType = "zakup"`, K\_42/K\_43.

Oba wpisy mają tę samą kwotę netto i VAT — wynik neutralny, ale obie
pozycje trafiają do JPK zgodnie z wymogiem ewidencji.

## Przeliczenie waluty obcej [#przeliczenie-waluty-obcej]

Kwota z faktury zagranicznej (najczęściej EUR lub USD) musi być
przeliczona na PLN **dla celów VAT**:

* Data przeliczenia = data powstania obowiązku podatkowego
  (<LegalRef act="VAT" art="19a" />).
* Kurs = **średni NBP z dnia poprzedzającego** powstanie obowiązku
  podatkowego (<LegalRef act="UoR" art="30" paragraph="2" />).

Numify używa funkcji `getNbpRate` w
<ServiceRef path="src/lib/services/nbp-exchange-rates.ts">nbp-exchange-rates.ts</ServiceRef>
— szczegóły w [art. 30 UoR](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut).

## Różnice wobec WNT — kluczowa matryca [#różnice-wobec-wnt--kluczowa-matryca]

| Aspekt                     | Import usług (art. 28b + 17)                    | WNT (art. 9)                                                                            |
| -------------------------- | ----------------------------------------------- | --------------------------------------------------------------------------------------- |
| Przedmiot                  | **Usługi**                                      | **Towary**                                                                              |
| Miejsce opodatkowania      | Kraj nabywcy (art. 28b)                         | Kraj zakończenia wysyłki (art. 25)                                                      |
| Podstawa samoopodatkowania | Art. 17 ust. 1 pkt 4                            | Art. 17 ust. 1 pkt 3                                                                    |
| Pola JPK sprzedaż          | K\_29 / K\_30                                   | K\_23 / K\_24                                                                           |
| VAT-UE                     | Tak — „usługi" (art. 100 ust. 1 pkt 4)          | Tak — „towary" (art. 100 ust. 1 pkt 2)                                                  |
| Data obowiązku podatkowego | Data wykonania usługi / data otrzymania faktury | 15. dnia miesiąca następującego po dostawie / data otrzymania faktury (jeśli wcześniej) |

Szczegóły WNT: [WNT / WDT](/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt).

## Księgowanie [#księgowanie]

Typowy schemat księgowy dla reverse charge na usługę o wartości
4 300 zł netto (równowartość 1 000 EUR × 4,3):

```
Dt 402 Usługi obce     4 300,00 zł
Dt 221 VAT naliczony     989,00 zł
    Ct 201 Rozrachunki z dostawcą UE  4 300,00 zł
    Ct 220 VAT należny                  989,00 zł
```

Konto <AccountRef code="402" name="Usługi obce" /> przyjmuje netto,
<AccountRef code="201" /> ewidencjonuje zobowiązanie wobec kontrahenta
zagranicznego, a VAT 23 % jednocześnie trafia na
<AccountRef code="221" name="VAT naliczony" /> i <AccountRef code="220" name="VAT należny" />
— salda te kompensują się w bieżącym JPK\_V7M.

## Typowe błędy [#typowe-błędy]

* **Księgowanie faktury zagranicznej jak krajowej** — dodanie VAT na
  fakturze, której usługodawca nie ma siedziby w Polsce. Jeśli
  faktura zawiera VAT zagraniczny (np. niemiecki 19 %), **nie
  odlicza się go w polskim JPK** — to błąd księgowy i podatkowy.
* **Pominięcie VAT-UE** — import usług art. 28b od kontrahenta UE
  wymaga **zawsze** zgłoszenia w informacji podsumowującej VAT-UE.
  Numify automatycznie wykrywa to przy generowaniu VAT-UE w
  <ServiceRef path="src/lib/services/vat-ue.ts">vat-ue.ts</ServiceRef>.
* **Brak weryfikacji VAT UE kontrahenta** — transakcja reverse charge
  z „podmiotem" nieposiadającym ważnego numeru VAT UE jest wysoce
  ryzykowna. Numify udostępnia walidację VIES w
  <ServiceRef path="src/lib/services/vies-validation.ts">vies-validation.ts</ServiceRef>.
* **Mylenie reverse charge usług z WNT towarów** — oba mechanizmy
  polegają na self-assessment, ale podstawa prawna, pola JPK i moment
  obowiązku podatkowego są różne.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 28b, 17, 86 ustawy o VAT
    (Dz.U. 2025 poz. 775 t.j.) i implementacji `vat-register.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Stawki VAT — art. 41, 43, 146ef
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/stawki
Description: Stawki VAT obowiązujące w Polsce — 22% / 7% jako stawka ustawowa, 23% / 8% / 5% / 0% / zw / np w praktyce 2026 r., stawka 4% dla taksówek (art. 114 + art. 146ef).
Review status: internal
Updated: 2026-04-16



Mechanika stawek VAT w Polsce ma podwójną warstwę: **ustawowa
podstawa** (22 % / 7 %) i **aktualnie obowiązująca podwyżka czasowa**
(23 % / 8 % / 4 %). Przyczyną jest <LegalRef act="VAT" art="146ef" />
— przepis przejściowy, który od 1 stycznia 2024 r. utrzymuje
podwyższone stawki przez okres, w którym wydatki obronne RP
przekraczają 3 % PKB.

W praktyce oznacza to, że **stawki 23 % / 8 % / 4 % są stawkami
roboczymi** — z nimi wystawia się faktury, te wpisuje się w JPK\_V7M,
tych używa się w systemach księgowych. Pierwotne stawki art. 41 są
odniesieniem formalnym.

<ComplianceDisclaimer />

## Mechanika dwupoziomowa — art. 41 + art. 146ef [#mechanika-dwupoziomowa--art-41--art-146ef]

<LegalRef act="VAT" art="41" paragraph="1" /> w pełnym brzmieniu
zaczyna się od:

> Stawka podatku wynosi 22 %, z zastrzeżeniem ust. 2-12c, art. 83,
> art. 119 ust. 7, art. 120 ust. 2 i 3, art. 122 i art. 129 ust. 1.

Uwaga redakcyjna obok przepisu: „Zgodnie z <LegalRef act="VAT" art="146ef" paragraph="1" />
pkt 1 stawka podatku wynosi 23 %".

<LegalRef act="VAT" art="146ef" paragraph="1" /> podwyższa cztery
stawki na okres, w którym suma wydatków wymienionych w ustawie o
obronie Ojczyzny przekracza 3 % PKB:

| pkt | Stawka ustawowa                                                                           | Stawka aktualna | Zakres                  |
| --- | ----------------------------------------------------------------------------------------- | --------------- | ----------------------- |
| 1   | 22 % (art. 41 ust. 1 i 13, art. 109 ust. 2, art. 110, art. 120 ust. 3a, art. 138i ust. 4) | **23 %**        | Stawka podstawowa       |
| 2   | 7 % (art. 41 ust. 2, art. 120 ust. 2 i 3, Załącznik 3)                                    | **8 %**         | Obniżona — Załącznik 3  |
| 3   | 6 % (art. 115 ust. 2 — zryczałtowany zwrot dla rolników)                                  | **7 %**         | Zryczałtowany zwrot     |
| 4   | 3 % (art. 114 ust. 1 — ryczałt taksówki)                                                  | **4 %**         | Ryczałt dla taksówkarzy |

<LegalRef act="VAT" art="146ef" paragraph="2" /> przewiduje, że Minister
Finansów ogłosi koniec okresu stawek podwyższonych obwieszczeniem
w „Monitorze Polskim", do 31 października roku, dla którego
spełnione zostaną warunki. **Do dnia ostatniej weryfikacji
(16 kwietnia 2026 r.) obwieszczenia nie wydano** — stawki 23 / 8 %
pozostają aktualne.

### Co to oznacza dla praktyki [#co-to-oznacza-dla-praktyki]

* Faktury wystawiamy z <VatRate rate="23" /> i <VatRate rate="8" />.
* Konto <AccountRef code="220" name="VAT należny" /> i
  <AccountRef code="221" name="VAT naliczony" /> ewidencjonuje kwoty
  wg stawki 23 / 8 %.
* W JPK\_V7M pola K\_19/K\_20 (stawka podstawowa) i K\_17/K\_18
  (stawka obniżona) odzwierciedlają 23 / 8 %.

## Stawka 5% — art. 41 ust. 2a + Załącznik 10 [#stawka-5--art-41-ust-2a--załącznik-10]

Dotyczy pozycji oznaczanej na fakturze jako <VatRate rate="5" />.

<LegalRef act="VAT" art="41" paragraph="2a" /> wprowadza stawkę 5 %
dla towarów wymienionych w Załączniku 10 do ustawy. Stawka ta
**nie podlega podwyżce z art. 146ef**. Obejmuje m.in.:

* Podstawowe produkty spożywcze (chleb, nabiał, mięso, owoce, warzywa).
* Książki drukowane i e-booki (objęte zakresem Załącznika 10).
* Prasę drukowaną i elektroniczną (w określonym zakresie).
* Produkty farmaceutyczne.

Stawka 5 % jest szczególnie istotna dla firm handlujących żywnością,
książkami i prasą — dla typowej usługowej sp. z o.o. rzadko stosowana.

## Stawka 0% — art. 41 ust. 3 i art. 83 [#stawka-0--art-41-ust-3-i-art-83]

Na fakturze oznaczana jako <VatRate rate="0" />.

Stawkę 0 % stosuje się w dwóch głównych grupach przypadków:

### WDT — wewnątrzwspólnotowa dostawa towarów [#wdt--wewnątrzwspólnotowa-dostawa-towarów]

<LegalRef act="VAT" art="41" paragraph="3" /> przewiduje stawkę 0 %
dla WDT, pod warunkami określonymi w <LegalRef act="VAT" art="42" paragraph="1" />:

1. Nabywca posiada ważny numer VAT UE w innym państwie członkowskim.
2. Sprzedawca posiada dowody wywozu towaru z Polski przed upływem
   terminu złożenia deklaracji.
3. Sprzedawca jest zarejestrowany jako podatnik VAT UE.

Szczegóły: [WNT / WDT](/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt).

### Eksport i usługi międzynarodowe — art. 83 [#eksport-i-usługi-międzynarodowe--art-83]

<LegalRef act="VAT" art="83" /> wymienia szereg sytuacji, w których
stosuje się stawkę 0 % — m.in. dostawa towarów do krajów trzecich
(eksport), usługi transportu międzynarodowego, dostawa środków
transportu morskiego i lotniczego.

## Zwolnienia przedmiotowe — art. 43 (oznaczenie „zw”) [#zwolnienia-przedmiotowe--art-43-oznaczenie-zw]

Na fakturze stosowane jest oznaczenie <VatRate rate="zw" />.

<LegalRef act="VAT" art="43" paragraph="1" /> wymienia ponad 40
kategorii czynności **zwolnionych z VAT**. Najważniejsze dla
sp. z o.o.:

| pkt    | Zakres                                                      | Typowe sytuacje                          |
| ------ | ----------------------------------------------------------- | ---------------------------------------- |
| 18–19a | Usługi opieki medycznej                                     | Lekarze, podmioty lecznicze              |
| 26–29  | Usługi edukacyjne i szkoleniowe                             | Szkoły, kształcenie zawodowe             |
| 36     | Wynajem nieruchomości mieszkalnych na cele mieszkaniowe     | Wynajem mieszkań dla najemców osobistych |
| 37     | Usługi ubezpieczeniowe                                      | Ubezpieczyciele, pośrednicy              |
| 38–41  | Usługi finansowe — kredyty, depozyty, instrumenty finansowe | Banki, SKOK, firmy inwestycyjne          |

**Istotne:** podatnik świadczący **wyłącznie** usługi zwolnione
z art. 43 nie ma prawa do odliczenia VAT naliczonego od zakupów
(<LegalRef act="VAT" art="86" paragraph="1" /> — zakres „wykonywania
czynności opodatkowanych" nie obejmuje zwolnionych). Jeśli firma
świadczy zarówno czynności opodatkowane, jak i zwolnione — stosuje
**proporcję odliczenia** (art. 90).

## Czynności poza zakresem VAT (oznaczenie „np”) [#czynności-poza-zakresem-vat-oznaczenie-np]

Na fakturze oznaczane jako <VatRate rate="np" />.

„Np" oznacza **czynność niepodlegającą opodatkowaniu w Polsce** —
nie ma polskiego VAT, ale też nie jest to zwolnienie przedmiotowe.
Typowa sytuacja:

* Usługa B2B z miejscem świadczenia w innym państwie UE
  (<LegalRef act="VAT" art="28b" paragraph="1" /> — miejsce świadczenia
  \= siedziba nabywcy). Polski dostawca wystawia fakturę z adnotacją
  „odwrotne obciążenie" / „reverse charge", a VAT rozlicza nabywca
  w swoim kraju.

W JPK\_V7M usługa taka trafia do pola K\_11 (sprzedaż poza terytorium
kraju) oraz K\_12 (usługi art. 28b do kontrahentów UE). Trafia też do
informacji podsumowującej [VAT-UE](/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue).

## Stawka 4% — taksówki [#stawka-4--taksówki]

<LegalRef act="VAT" art="114" paragraph="1" /> pozwala podatnikowi
świadczącemu usługi taksówek osobowych wybrać &#x2A;*ryczałt 3 %**,
podwyższony przez <LegalRef act="VAT" art="146ef" paragraph="1" />
pkt 4 do &#x2A;*4 %**. Przy tym ryczałcie nabywca usług nie odlicza VAT
naliczonego (<LegalRef act="VAT" art="114" paragraph="2" />).

Ryczałt 4 % jest bez znaczenia dla typowej sp. z o.o. — dotyczy
wyłącznie podatników świadczących usługi taksówek. Numify nie
implementuje procedury ryczałtowej.

## Wybór stawki w Numify [#wybór-stawki-w-numify]

Numify obsługuje stawki `23`, `8`, `5`, `0`, `zw`, `np` — pole
`vatRate` na pozycji faktury (tabela `transaction_line_items`). Dla
każdej pozycji wyliczane są:

* `amountNetPln` — kwota netto w groszach PLN.
* `amountVatPln` — kwota VAT w groszach PLN (dla stawki `zw` / `np`
  równa 0).
* `amountGrossPln` — suma netto + VAT.

Odniesienie do kont VAT:

| Stawka       | Konto należnego VAT (sprzedaż)                               | Konto naliczonego VAT (zakup) |
| ------------ | ------------------------------------------------------------ | ----------------------------- |
| 23 / 8 / 5 % | <AccountRef code="220" />                                    | <AccountRef code="221" />     |
| 0 %          | <AccountRef code="220" /> (kwota = 0, ale obrót w podstawie) | <AccountRef code="221" />     |
| zw / np      | nie księguje się VAT, wpis tylko na koncie sprzedaży/zakupu  | —                             |

## Stawka na fakturze wystawianej przez KSeF [#stawka-na-fakturze-wystawianej-przez-ksef]

Od 1 lutego 2026 r. (duzi podatnicy) / 1 kwietnia 2026 r. (wszyscy)
faktury muszą być wystawiane przez KSeF w formacie FA(3). Stawka
VAT jest obowiązkowym polem XML (element `StawkaPodatku` w
`Podsumowanie`). Format schematu — zobacz [KSeF — format FA(3)](/docs/zgodnosc-z-prawem/ksef/format-fa3).

## Typowe błędy [#typowe-błędy]

* **Stosowanie stawki z art. 41 ust. 1 (22 %) zamiast 23 %** —
  naruszenie przepisów przejściowych. Do momentu obwieszczenia
  Ministra Finansów o końcu okresu (art. 146ef ust. 2) obowiązują
  stawki podwyższone.
* **Pomylenie <VatRate rate="zw" /> z <VatRate rate="np" />** —
  inne konsekwencje dla JPK\_V7M i prawa do odliczenia. Zwolnienie
  (art. 43) = brak prawa do odliczenia; „np" (miejsce świadczenia
  za granicą) = prawo do odliczenia zachowane na zasadzie
  <LegalRef act="VAT" art="86" paragraph="8" /> pkt 1.
* **Stosowanie 8 % do produktów spoza Załącznika 3** — stawka 8 %
  dotyczy ściśle wyliczonych towarów i usług. Dla każdego produktu
  w wątpliwej sytuacji należy sprawdzić konkretną pozycję w
  Załączniku 3.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 41, 43, 114, 146ef (Dz.U. 2025
    poz. 775 t.j.). Stawki 23 / 8 / 4 % w okresie wydatków obronnych

    > 3 % PKB — podstawa prawna art. 146ef, nie historyczny art.
    > 146a / 146aa.
  </ChangeEntry>
</ChangeHistory>


---

# WNT i WDT — art. 9, 13, 25, 42
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt
Description: Wewnątrzwspólnotowe nabycie (WNT) i dostawa (WDT) towarów — definicje, miejsce opodatkowania, stawka 0% dla WDT pod warunkami art. 42, obowiązkowa rejestracja jako podatnik VAT UE.
Review status: internal
Updated: 2026-04-16



**WNT** (wewnątrzwspólnotowe nabycie towarów) i **WDT**
(wewnątrzwspólnotowa dostawa towarów) to dwa lustrzane mechanizmy
opodatkowania transakcji towarowych między polskim podatnikiem
a podatnikiem z innego państwa członkowskiego UE. Różnią się od
importu/eksportu — te ostatnie dotyczą wymiany z krajami spoza UE.

Dla typowej sp. z o.o. kupującej towary w Niemczech, Czechach czy
Holandii, lub sprzedającej towary do klienta firmowego w innym
państwie UE, WNT/WDT to **podstawowy mechanizm rozliczeń**.

<ComplianceDisclaimer />

## Definicje — art. 9 (WNT) i art. 13 (WDT) [#definicje--art-9-wnt-i-art-13-wdt]

### WNT — art. 9 ust. 1 [#wnt--art-9-ust-1]

<LegalRef act="VAT" art="9" paragraph="1" /> definiuje WNT jako:

> nabycie prawa do rozporządzania jak właściciel towarami, które
> w wyniku dokonanej dostawy są wysyłane lub transportowane na
> terytorium państwa członkowskiego inne niż terytorium państwa
> członkowskiego rozpoczęcia wysyłki lub transportu (...).

Trzy elementy:

1. **Nabycie prawa do rozporządzania** — przeniesienie ekonomicznej
   własności, nie samo wydanie.
2. **Wysyłka lub transport** — towar faktycznie przemieszcza się
   fizycznie.
3. **Między różnymi państwami członkowskimi** — nadawca w PC-A,
   odbiorca w PC-B.

Dodatkowe warunki z art. 9 ust. 2: nabywca jest podatnikiem VAT (lub
osobą prawną niebędącą podatnikiem) i nabywa towary na potrzeby
działalności gospodarczej, a dostawca jest podatnikiem VAT.

### WDT — art. 13 ust. 1 [#wdt--art-13-ust-1]

<LegalRef act="VAT" art="13" paragraph="1" /> definiuje WDT jako
lustro WNT:

> wywóz towarów z terytorium kraju w wykonaniu czynności określonych
> w art. 7 na terytorium państwa członkowskiego inne niż terytorium
> kraju (...).

Warunek z art. 13 ust. 2: nabywca ma ważny numer VAT UE w innym
państwie członkowskim i jest zarejestrowany na potrzeby transakcji
wewnątrzwspólnotowych.

<LegalRef act="VAT" art="13" paragraph="3" /> rozszerza definicję
o **przemieszczenia własnych towarów** — jeśli polska sp. z o.o.
przemieszcza swoje towary z Polski do własnego magazynu w Niemczech,
to również WDT (z WNT po stronie niemieckiej). Zastrzeżenia z ust. 4
— m.in. towary czasowo używane za granicą, materiały do obróbki
zleconej.

## Miejsce opodatkowania WNT — art. 25 [#miejsce-opodatkowania-wnt--art-25]

<LegalRef act="VAT" art="25" paragraph="1" /> określa:

> Wewnątrzwspólnotowe nabycie towarów uznaje się za dokonane na
> terytorium państwa członkowskiego, na którym towary znajdują się
> w momencie zakończenia ich wysyłki lub transportu.

Dla polskiej sp. z o.o. nabywającej towary z innego PC — miejscem
opodatkowania jest **Polska**, nabywca wylicza i odprowadza polski
VAT 23 % od wartości zakupu.

Wyjątek — art. 25 ust. 2: jeśli nabywca poda NIP z kraju innego niż
kraj zakończenia wysyłki, WNT jest uznawane za dokonane **także** w
państwie NIP-u, chyba że nabywca udowodni, że opodatkował transakcję
we właściwym kraju. To przepis zapobiegający nadużyciom.

## Samoopodatkowanie nabywcy WNT — art. 17 ust. 1 pkt 3 [#samoopodatkowanie-nabywcy-wnt--art-17-ust-1-pkt-3]

<LegalRef act="VAT" art="17" paragraph="1" /> pkt 3 wskazuje nabywcę
jako podatnika:

> Podatnikami są również osoby prawne (...) dokonujące
> wewnątrzwspólnotowego nabycia towarów (...).

Mechanika zbliżona do reverse charge usług, ale odmienne pola JPK
i moment obowiązku podatkowego. Polski nabywca:

1. Wylicza VAT należny od kwoty netto faktury zagranicznej (stawka
   właściwa dla tego towaru w PL — zwykle <VatRate rate="23" />).
2. Odlicza VAT naliczony w tej samej deklaracji (pod warunkiem
   z art. 86 ust. 10b pkt 2 — uwzględnienie kwoty należnej).

Efekt netto dla transakcji typowo produkcyjnej (towary do dalszej
odsprzedaży) = 0 zł. Ale — WNT musi być wykazana w JPK\_V7M i VAT-UE.

## WDT ze stawką 0% — warunki art. 42 [#wdt-ze-stawką-0--warunki-art-42]

<LegalRef act="VAT" art="41" paragraph="3" /> ustanawia stawkę 0 %
dla WDT, ale <LegalRef act="VAT" art="42" paragraph="1" /> wprowadza
**trzy warunki łączne**:

> 1. podatnik dokonał dostawy na rzecz nabywcy posiadającego
>    właściwy i ważny numer identyfikacyjny dla transakcji
>    wewnątrzwspólnotowych (...);
>
> 2. podatnik przed upływem terminu do złożenia deklaracji podatkowej
>    za dany okres rozliczeniowy, posiada w swojej dokumentacji dowody,
>    że towary (...) zostały wywiezione z terytorium kraju i dostarczone
>    do nabywcy (...);
>
> 3. podatnik składając deklarację podatkową, w której wykazuje tę
>    dostawę towarów, jest zarejestrowany jako podatnik VAT UE.

### Warunek 1 — ważny VAT UE nabywcy [#warunek-1--ważny-vat-ue-nabywcy]

Numer VAT UE nabywcy musi być sprawdzony w momencie transakcji
w systemie **VIES** (europejska baza VAT). Sama weryfikacja wraz
z datą i wynikiem stanowi dowód dochowania należytej staranności.

Numify wykonuje walidację przez SOAP API VIES w
<ServiceRef path="src/lib/services/vies-validation.ts">vies-validation.ts</ServiceRef>.
Wynik (sukces + nazwa firmy) zapisywany jest jako dowód.

### Warunek 2 — dowody wywozu [#warunek-2--dowody-wywozu]

<LegalRef act="VAT" art="42" paragraph="3" /> wylicza dokumenty
wywozowe:

| Dokument                                  | Wymóg                                 |
| ----------------------------------------- | ------------------------------------- |
| Dokumenty przewozowe od spedytora (CMR)   | Jeśli transport zlecany przewoźnikowi |
| Specyfikacja poszczególnych sztuk ładunku | Zawsze wymagana                       |

<LegalRef act="VAT" art="42" paragraph="4" /> określa dodatkowe
warunki, gdy wywóz jest własnym transportem podatnika lub nabywcy —
dokument z adresem dostawy, ilością, potwierdzeniem odbioru, numerem
rejestracyjnym pojazdu lub lotu.

<LegalRef act="VAT" art="42" paragraph="11" /> dopuszcza **inne
dokumenty** potwierdzające wywóz, gdy podstawowe nie są jednoznaczne
— m.in. korespondencja handlowa, dokumenty ubezpieczenia i frachtu,
dokument potwierdzający zapłatę.

### Warunek 3 — rejestracja jako VAT UE [#warunek-3--rejestracja-jako-vat-ue]

Polski sprzedawca musi być zarejestrowany jako **podatnik VAT UE** —
oddzielna rejestracja poza zwykłym zgłoszeniem VAT-R (dokonywana
przez VAT-R z zaznaczonym polem E.1 lub osobnym zgłoszeniem).

## Obowiązek podatkowy — moment rozliczenia [#obowiązek-podatkowy--moment-rozliczenia]

| Transakcja           | Moment powstania obowiązku                                                                                         |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ |
| WNT (art. 20 ust. 5) | **15. dnia** miesiąca następującego po dostawie, lub **wcześniej** — w momencie wystawienia faktury przez dostawcę |
| WDT (art. 20 ust. 1) | Z chwilą wystawienia faktury — nie później niż 15. dnia miesiąca następującego po dostawie                         |

Numify stosuje datę wystawienia faktury jako moment obowiązku dla
WNT (z zastrzeżeniem korekty, gdy faktura nie wpłynie w terminie).
Dla WDT obowiązek pokrywa się z datą sprzedaży.

## Utrata prawa do stawki 0% — art. 42 ust. 1a i 12 [#utrata-prawa-do-stawki-0--art-42-ust-1a-i-12]

### Brak informacji VAT-UE [#brak-informacji-vat-ue]

<LegalRef act="VAT" art="42" paragraph="1a" /> pozbawia stawki 0%,
jeżeli:

> 1. podatnik nie dopełnił obowiązku, o którym mowa w art. 100
>    ust. 1 pkt 1 lub ust. 3 pkt 1, lub
>
> 2. złożona informacja podsumowująca nie zawiera prawidłowych
>    danych dotyczących wewnątrzwspólnotowych dostaw towarów (...)

Jedynym wyjściem jest **pisemne wyjaśnienie uchybienia** naczelnikowi
urzędu skarbowego. Brak VAT-UE lub złe dane = stawka krajowa
(zwykle 23 %).

### Brak dowodów wywozu w terminie — art. 42 ust. 12 [#brak-dowodów-wywozu-w-terminie--art-42-ust-12]

Jeśli przed upływem terminu deklaracji sprzedawca nie ma dowodów
wywozu, WDT **nie jest wykazywana w tym okresie**. Dla miesięcznego
rozlicznia dostawa trafia do ewidencji dopiero w drugim kolejnym
okresie (art. 42 ust. 12 pkt 2), **ze stawką krajową**. Otrzymanie
dowodów później (art. 42 ust. 12a) umożliwia korektę z powrotem do
stawki 0 %.

## Pola JPK\_V7M [#pola-jpk_v7m]

| Transakcja                   | Pola w JPK\_V7M                                                                          |
| ---------------------------- | ---------------------------------------------------------------------------------------- |
| WDT (sprzedaż)               | K\_21 (netto, stawka 0%)                                                                 |
| WNT (zakup, self-assessment) | K\_23 (netto), K\_24 (VAT należny), jednocześnie K\_42 / K\_43 (VAT naliczony odliczany) |

Dodatkowo dane trafiają do informacji podsumowującej
[VAT-UE](/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue) — oddzielna
informacja zbiorcza.

## Księgowanie — przykład WNT [#księgowanie--przykład-wnt]

Sp. z o.o. kupuje towary z Niemiec za 10 000 EUR × kurs 4,30 =
43 000 zł netto:

```
Dt 330 Towary             43 000,00 zł
Dt 221 VAT naliczony       9 890,00 zł
    Ct 201 Rozrachunki UE  43 000,00 zł
    Ct 220 VAT należny      9 890,00 zł
```

<AccountRef code="330" /> przyjmuje zapas towarów w cenie netto,
<AccountRef code="221" /> i <AccountRef code="220" /> — lustrzane
wpisy VAT 23 %.

## Rejestracja jako podatnik VAT UE [#rejestracja-jako-podatnik-vat-ue]

Bezwarunkowy warunek jakichkolwiek WNT/WDT — rejestracja VAT UE
(VAT-R, pole E.1 lub oddzielne zgłoszenie). Nadawany jest identyfikator
`PL + NIP` (np. `PL1234567890`). Ten numer pojawia się na:

* Fakturach WDT wystawianych przez polskiego sprzedawcę.
* Fakturach WNT wystawianych na polskiego nabywcę przez zagranicznego
  dostawcę (jako identyfikator nabywcy w jego wewnętrznym systemie VAT).

Rejestracja jest **bezpłatna** i trwała do wyrejestrowania.

## Wyłączenia — art. 10 [#wyłączenia--art-10]

<LegalRef act="VAT" art="10" paragraph="1" /> wymienia sytuacje,
w których **WNT nie występuje** — m.in. nabycie towarów używanych
opodatkowanych w kraju nabywcy wg procedury marży, nabycie przez
podmiot korzystający ze zwolnienia podmiotowego przy limicie
50 000 zł rocznie. Dla typowej operacyjnej sp. z o.o. wyłączenia te
rzadko mają zastosowanie.

## Typowe błędy [#typowe-błędy]

* **Stosowanie stawki <VatRate rate="0" /> do WDT bez ważnego VAT UE
  nabywcy** — narusza warunek 1 z art. 42 ust. 1. Stawka wraca do
  krajowej <VatRate rate="23" />.
* **Brak dokumentów wywozu** — faktura z 0 % bez CMR, potwierdzeń
  dostawy, korespondencji handlowej. W razie kontroli US może
  zdyskwalifikować stawkę 0 %.
* **Mylenie WNT (towary) z importem usług art. 28b (usługi)** —
  różna podstawa prawna (art. 9 vs art. 28b), różne pola JPK
  (K\_23/K\_24 vs K\_29/K\_30), różny moment obowiązku podatkowego.
* **Pomijanie przemieszczenia własnych towarów** — art. 13 ust. 3
  traktuje przewiezienie własnych zapasów z Polski do własnego
  magazynu za granicą jako WDT. Wymaga faktury wewnętrznej
  i zgłoszenia w VAT-UE.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 9, 13, 25, 42 ustawy o VAT
    (Dz.U. 2025 poz. 775 t.j.). Klasyfikacja WNT/WDT oraz implementacja
    walidacji VIES w `vies-validation.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 109 VAT — Ewidencja VAT i JPK_V7M
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/art-109-ewidencja-vat
Description: Obowiązek prowadzenia ewidencji VAT w postaci elektronicznej — zakres danych (rodzaj sprzedaży, stawki, VAT należny i naliczony, kontrahenci, dokumenty), przesyłanie JPK_V7M miesięcznie lub kwartalnie, korekta w 14 dni, kara 500 zł za błąd po wezwaniu. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**JPK\_V7M** to jednolity plik kontrolny łączący **ewidencję VAT**
z **deklaracją VAT**. Od 1 października 2020 r. zastąpił dwa osobne
obowiązki (JPK\_VAT + VAT-7) i stał się jedynym dopuszczalnym
sposobem rozliczenia VAT przez sp. z o.o.
<LegalRef act="VAT" art="109" /> reguluje obowiązek ewidencji i jej
elektronicznego przekazywania.

<ComplianceDisclaimer />

## Zakres ewidencji — ust. 3 [#zakres-ewidencji--ust-3]

> Podatnicy, z wyjątkiem \[zwolnionych na podstawie art. 43 ust. 1,
> art. 82 ust. 3, art. 113 ust. 1 i 9, art. 113a ust. 1], są
> obowiązani prowadzić ewidencję zawierającą dane pozwalające na
> prawidłowe rozliczenie podatku i sporządzenie informacji
> podsumowującej, w szczególności dane dotyczące:
>
> 1. rodzaju sprzedaży i podstawy opodatkowania, wysokości kwoty
>    podatku należnego, w tym korekty podatku należnego, z podziałem
>    na stawki podatku;
> 2. kwoty podatku naliczonego obniżającego kwotę podatku należnego,
>    w tym korekty podatku naliczonego;
> 3. kontrahentów;
> 4. dowodów sprzedaży i zakupów.

Cztery kategorie danych:

| Kategoria             | Konkretnie                                            | Przykład z JPK\_V7M                            |
| --------------------- | ----------------------------------------------------- | ---------------------------------------------- |
| Rodzaj sprzedaży      | stawka 23 / 8 / 5 / 0 %, zwolniona, OSS, WDT, eksport | pola K\_10–K\_21                               |
| Kwota VAT naliczonego | nabycia krajowe + zagraniczne + środki trwałe + inne  | pola K\_40–K\_50                               |
| Kontrahenci           | NIP, nazwa, adres nabywcy / sprzedawcy                | pola w sekcji `SprzedazWiersz` i `ZakupWiersz` |
| Dowody                | numer faktury, data wystawienia, data sprzedaży       | pole `DowodSprzedazy` / `DowodZakupu`          |

### Kody GTU — rozporządzenie MF (JPK\_V7M) [#kody-gtu--rozporządzenie-mf-jpk_v7m]

Obok danych z ust. 3, rozporządzenie MFIR wymaga oznaczenia faktur
sprzedaży **kodami GTU** dla 13 grup towarów i usług szczególnie
podatnych na oszustwa VAT:

| GTU     | Grupa                                                            |
| ------- | ---------------------------------------------------------------- |
| GTU\_01 | napoje alkoholowe                                                |
| GTU\_02 | paliwa                                                           |
| GTU\_03 | olej opałowy, smary                                              |
| GTU\_04 | wyroby tytoniowe                                                 |
| GTU\_05 | odpady                                                           |
| GTU\_06 | urządzenia elektroniczne (telefony, komputery, konsole)          |
| GTU\_07 | pojazdy i części                                                 |
| GTU\_08 | metale szlachetne                                                |
| GTU\_09 | leki objęte zakazem wywozu                                       |
| GTU\_10 | nieruchomości                                                    |
| GTU\_11 | usługi przenoszenia praw do emisji gazów                         |
| GTU\_12 | usługi niematerialne (doradztwo, reklama, księgowość, prawnicze) |
| GTU\_13 | usługi transportowe i magazynowe                                 |

Kody ustala się na poziomie **pozycji faktury** — jedna faktura może
mieć wiele kodów. Brak lub błędny kod GTU = typowy tytuł do wezwania
z ust. 3f.

### Procedury szczególne i znaczniki [#procedury-szczególne-i-znaczniki]

Rozporządzenie wymaga oznaczenia znacznikami m.in.:

* **SW** — sprzedaż wysyłkowa z terytorium kraju,
* **EE** — świadczenie usług telekomunikacyjnych, nadawczych,
  elektronicznych,
* **TP** — transakcje z podmiotami powiązanymi,
* **MPP** — mechanizm podzielonej płatności (zobacz
  [MPP](/docs/zgodnosc-z-prawem/ustawa-o-vat/mpp-split-payment)),
* **WEW** — dowód wewnętrzny (brak faktury),
* **RO** — raport z kasy fiskalnej.

## Kto jest zwolniony z prowadzenia ewidencji — ust. 3 (wyłączenia) [#kto-jest-zwolniony-z-prowadzenia-ewidencji--ust-3-wyłączenia]

* podatnicy wykonujący **wyłącznie** czynności zwolnione na podstawie
  <LegalRef act="VAT" art="43" paragraph="1" /> (np. usługi medyczne,
  edukacyjne),
* podatnicy zwolnieni podmiotowo na podstawie
  [art. 113 ust. 1 i 9](/docs/zgodnosc-z-prawem/ustawa-o-vat/art-113-zwolnienie-podmiotowe)
  (limit 240 000 zł),
* zwolnieni na podstawie przepisów wydanych na podstawie art. 82 ust. 3
  (organizacje międzynarodowe).

**Dla typowej sp. z o.o. prowadzącej działalność opodatkowaną —
obowiązek ewidencji VAT jest bezwyjątkowy.** Podatnicy zwolnieni
z ust. 1 (art. 113) prowadzą **uproszczoną** ewidencję sprzedaży
(ust. 1).

## Terminy przesyłania — ust. 3b i 3c [#terminy-przesyłania--ust-3b-i-3c]

### Rozliczenia miesięczne — ust. 3b [#rozliczenia-miesięczne--ust-3b]

Ewidencja (JPK\_V7M) **łącznie z deklaracją** za każdy miesiąc, do
**25. dnia miesiąca następującego** po miesiącu rozliczeniowym.
Deklaracja i ewidencja są w jednym pliku JPK\_V7M.

| Miesiąc       | Termin JPK\_V7M |
| ------------- | --------------- |
| Styczeń 2026  | 25 II 2026      |
| Grudzień 2026 | 25 I 2027       |

### Rozliczenia kwartalne — ust. 3c (JPK\_V7K) [#rozliczenia-kwartalne--ust-3c-jpk_v7k]

Podatnicy z art. 99 ust. 2 i 3 (przychody ≤ 4 mln euro, bez
wyłączeń z ust. 3a) składają deklarację **kwartalnie**, ale
ewidencję **miesięcznie**:

| Miesiąc kwartału | Termin                       | Zawartość                            |
| ---------------- | ---------------------------- | ------------------------------------ |
| I miesiąc        | 25. dnia miesiąca następnego | ewidencja (część E JPK\_V7K)         |
| II miesiąc       | 25. dnia miesiąca następnego | ewidencja (część E JPK\_V7K)         |
| III miesiąc      | 25. dnia miesiąca następnego | ewidencja + deklaracja (część D + E) |

Dla typowej sp. z o.o. miesięcznej wystarczy jeden plik JPK\_V7M na
miesiąc — kwartalny model jest opcjonalny i zwykle wybierany przez
małych podatników.

## Korekta ewidencji — ust. 3e [#korekta-ewidencji--ust-3e]

> W terminie 14 dni od dnia stwierdzenia przez podatnika, że przesłana
> ewidencja zawiera błędy \[...] lub zmiany danych zawartych w
> przesłanej ewidencji — podatnik jest obowiązany przesłać korektę
> ewidencji.

14 dni liczy się od **stwierdzenia błędu przez podatnika** — nie od
otrzymania wezwania z urzędu.

Typowe przyczyny korekty:

* faktura korygująca zmniejszająca lub zwiększająca,
* faktura pierwotnie ujęta w błędnym miesiącu,
* zmiana NIP kontrahenta po wysłaniu,
* poprawka kodu GTU.

Korektę przesyła się w **tym samym formacie** (JPK\_V7M lub JPK\_V7K) z
polem `cel zlozenia` ustawionym na 2 (korekta).

## Wezwanie od naczelnika US — ust. 3f i 3h [#wezwanie-od-naczelnika-us--ust-3f-i-3h]

### Wezwanie — ust. 3f [#wezwanie--ust-3f]

Jeżeli naczelnik US stwierdzi w przesłanej ewidencji błędy
uniemożliwiające weryfikację prawidłowości transakcji — **wzywa
podatnika** do skorygowania, wskazując konkretne błędy.

### Termin odpowiedzi — ust. 3g [#termin-odpowiedzi--ust-3g]

**14 dni od doręczenia wezwania** — albo:

1. skorygowana ewidencja (JPK\_V7M z celem 2),
2. wyjaśnienia wskazujące, że ewidencja nie zawiera błędów.

### Kara 500 zł za błąd — ust. 3h [#kara-500-zł-za-błąd--ust-3h]

> Jeżeli podatnik, wbrew obowiązkowi określonemu w ust. 3g:
>
> 1. nie prześle ewidencji skorygowanej \[...] ani nie złoży wyjaśnień,
>    albo zrobi to po terminie,
> 2. w złożonych wyjaśnieniach nie wykaże, że ewidencja nie zawiera
>    błędów — naczelnik urzędu skarbowego może nałożyć, w drodze
>    decyzji, na tego podatnika karę pieniężną w wysokości 500 zł za
>    każdy błąd.

500 zł **za każdy błąd** — kumuluje się. Przy 20 błędach w jednym
JPK\_V7M kara może wynieść **10 000 zł**. Kara uiszczana bez wezwania
w 14 dni od doręczenia decyzji (ust. 3k).

### Wyjątek — osoby fizyczne na ryzyku karno-skarbowym — ust. 3i [#wyjątek--osoby-fizyczne-na-ryzyku-karno-skarbowym--ust-3i]

Kary 500 zł nie stosuje się do osoby fizycznej, która za ten sam czyn
ponosi odpowiedzialność karno-skarbową. **Dla sp. z o.o. — ten
wyjątek nie ma zastosowania**, sp. z o.o. zawsze odpowiada
administracyjnie.

## Postać elektroniczna — ust. 8a [#postać-elektroniczna--ust-8a]

> Ewidencja, o której mowa w ust. 3, prowadzona jest w postaci
> elektronicznej przy użyciu programów komputerowych.

Papierowa ewidencja VAT jest **niedopuszczalna** od 2018 r. Plik
JPK\_V7M musi być przesłany przez MF Gateway (bramkę Ministerstwa
Finansów) z UPO (Urzędowym Poświadczeniem Odbioru) — zachowywanym
przez 5 lat.

## Realizacja w Numify [#realizacja-w-numify]

| Wymaganie art. 109                        | Funkcja Numify                                                                                    |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------- |
| Ewidencja sprzedaży z podziałem na stawki | [faktury](/docs/korzystanie-z-numify/faktury) — pozycja faktury z kodem stawki VAT                |
| Ewidencja zakupów                         | [dokumenty](/docs/korzystanie-z-numify/dokumenty) / [faktury](/docs/korzystanie-z-numify/faktury) |
| Kody GTU                                  | pole `gtuCodes` na pozycji faktury sprzedaży                                                      |
| Znaczniki (TP, MPP, EE, SW, WEW, RO)      | flaga per faktura — `vatMarkers`                                                                  |
| Dane kontrahenta                          | [kontrahenci](/docs/korzystanie-z-numify/kontrahenci) — NIP, nazwa, adres                         |
| Generowanie JPK\_V7M                      | [exports](/docs/korzystanie-z-numify/exports) — sekcja „JPK"                                      |
| Walidacja schematu przed wysyłką          | wbudowana — blokuje eksport jeśli brakują obowiązkowe pola                                        |
| Korekta ewidencji (ust. 3e)               | ponowne wygenerowanie JPK\_V7M z `celZlozenia = 2` po poprawkach                                  |
| Rejestr JPK wysłanych + UPO               | [exports](/docs/korzystanie-z-numify/exports) — historia z UPO                                    |

### Uczciwe framing — wysyłka JPK [#uczciwe-framing--wysyłka-jpk]

Numify **generuje** plik JPK\_V7M w formacie akceptowanym przez bramkę
MF. **Wysyłka** do bramki MF wymaga albo podpisu kwalifikowanego,
albo dedykowanego klienta do podpisu. Rekomendowany workflow:

1. Numify → eksport JPK\_V7M (plik XML).
2. Zewnętrzny klient MF (np. „Klient JPK\_WEB") lub biuro rachunkowe
   — podpis + wysyłka.
3. UPO zapisywane z powrotem w Numify jako dowód wywiązania.

Pełna integracja z bramką MF (automatyczny podpis i wysyłka) jest
**zaplanowana**; obecnie workflow jest częściowo ręczny w ostatnim
kroku.

## Częste błędy [#częste-błędy]

* **Pominięcie kodu GTU** dla sprzedaży np. sprzętu elektronicznego
  (GTU\_06) — typowy tytuł wezwania 3f i kary 500 zł.
* **Brak znacznika TP** dla transakcji z podmiotami powiązanymi —
  nawet jeśli transakcja jest po cenach rynkowych, obowiązek
  znacznika pozostaje.
* **Ujęcie faktury w JPK bez faktycznej dostawy** — faktura pusta;
  sankcje z art. 108 VAT + NKUP.
* **Korekta po 14 dniach od wykrycia** — naruszenie ust. 3e,
  może być podstawą do wezwania.
* **Brak odpowiedzi na wezwanie 3f w 14 dni** — automatycznie
  kara 500 zł za każdy błąd.
* **Wysyłka JPK\_V7M z celem 1 (pierwsza deklaracja)** zamiast
  &#x2A;*celem 2 (korekta)** — powoduje zduplikowanie ewidencji w
  systemie MF, a nie zastąpienie.
* **Korekta deklaracji VAT bez korekty ewidencji JPK** — obie
  muszą być w parze.

## Checklist — wysyłka miesięcznego JPK\_V7M [#checklist--wysyłka-miesięcznego-jpk_v7m]

* [ ] Wszystkie faktury sprzedaży miesiąca zarejestrowane.
* [ ] Wszystkie faktury zakupu z otrzymaniem w miesiącu zarejestrowane.
* [ ] Kody GTU przypisane do pozycji objętych obowiązkiem.
* [ ] Znaczniki (TP, MPP, EE, SW, WEW, RO) sprawdzone.
* [ ] NIP kontrahenta weryfikowany wobec białej listy MF —
  [biała lista](/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista).
* [ ] VAT należny per stawka policzony i uzgodniony z sumą faktur.
* [ ] VAT naliczony z nabyć krajowych, WNT, odwrotnego obciążenia
  policzony.
* [ ] Plik JPK\_V7M wygenerowany i zwalidowany schematem XSD.
* [ ] Plik podpisany kwalifikowanym podpisem elektronicznym / profilem
  zaufanym / podpisem osobistym.
* [ ] Plik wysłany do bramki MF do 25. dnia miesiąca następnego.
* [ ] UPO zapisane w archiwum elektronicznym (min. 5 lat).


---

# Biała lista podatników VAT — art. 96b VAT + art. 117ba OrdPod
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista
Description: Wykaz podatników VAT prowadzony przez Szefa KAS — weryfikacja rachunku kontrahenta, solidarna odpowiedzialność za VAT spoza wykazu (art. 117ba OrdPod), NKUP przy przelewie spoza białej listy (art. 15d CIT), zawiadomienie ZAW-NR.
Review status: internal
Updated: 2026-04-16



**Biała lista podatników VAT** to publiczny wykaz prowadzony przez
Szefa Krajowej Administracji Skarbowej — zawiera dane identyfikacyjne
każdego zarejestrowanego lub wykreślonego podatnika VAT oraz — co
najważniejsze dla nabywców — **numery rachunków rozliczeniowych
zgłoszone przez podatnika i potwierdzone w systemie STIR**.

Sam wykaz to narzędzie informacyjne; konsekwencje prawne płatności
na rachunek spoza wykazu reguluje **nie ustawa o VAT, lecz Ordynacja
podatkowa** (art. 117ba — solidarna odpowiedzialność za VAT) i
**ustawa o CIT** (art. 15d — wyłączenie z kosztów uzyskania
przychodów).

<ComplianceDisclaimer />

## Biała lista — art. 96b ustawy o VAT [#biała-lista--art-96b-ustawy-o-vat]

<LegalRef act="VAT" art="96b" paragraph="1" /> ustanawia obowiązek
prowadzenia wykazu:

> Szef Krajowej Administracji Skarbowej prowadzi w postaci
> elektronicznej wykaz podmiotów:
>
> 1. w odniesieniu do których naczelnik urzędu skarbowego nie
>    dokonał rejestracji albo które wykreślił z rejestru jako
>    podatników VAT;
> 2. zarejestrowanych jako podatnicy VAT, w tym podmiotów, których
>    rejestracja jako podatników VAT została przywrócona.

Wykaz jest **publiczny** — dostępny w Biuletynie Informacji Publicznej
MF, przez CEIDG i Punkt Informacji dla Przedsiębiorcy.

### Zakres danych — art. 96b ust. 3 [#zakres-danych--art-96b-ust-3]

Na każdego podatnika wykaz zawiera:

| Dane                                                          | Źródło                                |
| ------------------------------------------------------------- | ------------------------------------- |
| Nazwa lub imię i nazwisko                                     | Zgłoszenie identyfikacyjne            |
| NIP                                                           | Zgłoszenie identyfikacyjne            |
| Status (czynny / zwolniony / wykreślony / nie zarejestrowany) | Decyzje naczelnika US                 |
| REGON, KRS                                                    | CEIDG / KRS                           |
| Adres siedziby / prowadzenia działalności                     | Zgłoszenie                            |
| Imiona i nazwiska członków zarządu / wspólników + ich NIP     | KRS / CEIDG                           |
| Daty rejestracji, wykreślenia, przywrócenia                   | Rejestr US                            |
| **Numery rachunków rozliczeniowych**                          | Zgłoszenie + potwierdzenie w **STIR** |

Kluczowe dla konsekwencji podatkowych są ostatnie trzy pozycje —
rachunki rozliczeniowe. Rachunki:

1. Muszą być zgłoszone przez podatnika w zgłoszeniu identyfikacyjnym
   lub aktualizacyjnym (NIP-8 / VAT-R).
2. Muszą być **potwierdzone przez bank** za pośrednictwem STIR
   (System Teleinformatyczny Izby Rozliczeniowej) — tylko potwierdzone
   numery są widoczne w wykazie.

Wykaz jest **aktualizowany raz na dobę w dni robocze**
(<LegalRef act="VAT" art="96b" paragraph="8" />).

## Sankcje — nie w ustawie o VAT [#sankcje--nie-w-ustawie-o-vat]

Sama ustawa o VAT nie przewiduje sankcji za płatność na rachunek
spoza wykazu. Sankcje ustanawiają dwa inne akty prawne:

### Solidarna odpowiedzialność — art. 117ba Ordynacji podatkowej [#solidarna-odpowiedzialność--art-117ba-ordynacji-podatkowej]

<LegalRef act="OrdPod" art="117ba" paragraph="1" /> wprowadza
solidarną odpowiedzialność:

> Podatnik (...), na rzecz którego dokonano dostawy towarów lub
> świadczenia usług, odpowiada solidarnie całym swoim majątkiem wraz
> z dostawcą towarów lub usługodawcą zarejestrowanym na potrzeby
> podatku od towarów i usług jako podatnik VAT czynny, za jego
> zaległości podatkowe w części podatku od towarów i usług
> proporcjonalnie przypadającej na tę dostawę towarów lub to
> świadczenie usług, jeżeli zapłata należności (...) została
> dokonana przelewem na rachunek inny niż zawarty na dzień zlecenia
> przelewu w wykazie (...).

**Kluczowe:** odpowiedzialność dotyczy **VAT**, nie kwoty brutto
faktury. Nabywca może zostać zobowiązany do zapłaty części VAT
sprzedawcy, jeśli sprzedawca nie wpłacił tego VAT do US.

### NKUP — art. 15d ustawy o CIT [#nkup--art-15d-ustawy-o-cit]

<LegalRef act="CIT" art="15d" paragraph="1" /> pkt 2 wyłącza z KUP:

> (...) płatność (...) została dokonana przelewem na rachunek inny
> niż zawarty na dzień zlecenia przelewu w wykazie (...) — w
> przypadku dostawy towarów lub świadczenia usług, potwierdzonych
> fakturą, dokonanych przez dostawcę towarów lub usługodawcę
> zarejestrowanego na potrzeby podatku od towarów i usług jako
> podatnik VAT czynny (...).

Dla sp. z o.o. oznacza to, że **cała kwota faktury zapłaconej
niepoprawnie** nie stanowi kosztu uzyskania przychodów — zwiększa
podstawę opodatkowania CIT.

## Zakres — kiedy weryfikacja jest obowiązkowa [#zakres--kiedy-weryfikacja-jest-obowiązkowa]

Oba reżimy (art. 117ba OrdPod + art. 15d CIT) stosuje się **łącznie**
do transakcji:

1. Zawartej z **polskim podatnikiem VAT czynnym** (rola kontrahenta
   w wykazie).
2. Potwierdzonej **fakturą** (nie rachunek, paragon).
3. Wymagającej zapłaty przez rachunek płatniczy (<LegalRef act="VAT" art="108a" /> — odsyłacz
   do art. 19 Prawa przedsiębiorców — transakcja B2B > 15 000 zł).

Dla transakcji poniżej 15 000 zł brutto weryfikacja białej listy
**nie jest obowiązkowa** — można legalnie zapłacić gotówką lub
przelewem na rachunek spoza wykazu.

## Wyłączenia solidarnej odpowiedzialności — art. 117ba § 3 [#wyłączenia-solidarnej-odpowiedzialności--art-117ba--3]

<LegalRef act="OrdPod" art="117ba" paragraph="3" /> wymienia pięć
sytuacji, w których sankcja **nie jest stosowana**:

### 1. Transakcja nieobjęta obowiązkiem rachunku płatniczego (pkt 1) [#1-transakcja-nieobjęta-obowiązkiem-rachunku-płatniczego-pkt-1]

Jeśli transakcja nie spełnia warunków z art. 19 Prawa przedsiębiorców
(B2B > 15 000 zł brutto), wyłączenie działa automatycznie.

### 2. Zawiadomienie ZAW-NR (pkt 2) [#2-zawiadomienie-zaw-nr-pkt-2]

Najważniejsze wyłączenie w praktyce. Jeśli nabywca zorientuje się,
że zapłacił na rachunek spoza wykazu, może złożyć **zawiadomienie
ZAW-NR** do naczelnika US **w ciągu 7 dni** od zlecenia przelewu.
Zawiadomienie musi zawierać dane określone w <LegalRef act="OrdPod" art="117ba" paragraph="4" />:

| Dane                                             | Opis                     |
| ------------------------------------------------ | ------------------------ |
| Dane identyfikacyjne nabywcy (NIP, firma, adres) | Składający zawiadomienie |
| Dane wystawcy faktury                            | Z faktury                |
| Numer rachunku, na który dokonano zapłaty        | Ten spoza wykazu         |
| Kwota należności                                 | Kwota przelana           |
| Dzień zlecenia przelewu                          | Data dyspozycji          |

Zawiadomienie składa się **tylko przy pierwszej zapłacie** na dany
rachunek — kolejne płatności na ten sam rachunek nie wymagają
ponowienia zawiadomienia.

**Uwaga terminowa:** do 30 czerwca 2020 r. termin wynosił 3 dni;
od 1 lipca 2020 r. jest **7 dni** (aktualne brzmienie art. 117ba § 3
pkt 2 OrdPod).

### 3. Rachunek cesyjny / faktoringowy / własny banku (pkt 3) [#3-rachunek-cesyjny--faktoringowy--własny-banku-pkt-3]

Jeśli rachunek należy do banku lub SKOK i służy do obsługi cesji
wierzytelności lub pobierania należności w imieniu dostawcy — nie
jest zgłaszany do białej listy, ale nie wyzwala sankcji. Warunek:
bank lub wystawca faktury informują nabywcę o charakterze rachunku.

### 4. Płatność z MPP (pkt 4) [#4-płatność-z-mpp-pkt-4]

Zapłata z zastosowaniem [mechanizmu podzielonej płatności](/docs/zgodnosc-z-prawem/ustawa-o-vat/mpp-split-payment)
wyłącza solidarną odpowiedzialność, nawet jeśli rachunek nie jest
w wykazie.

### 5. Reverse charge / import / WNT (pkt 5) [#5-reverse-charge--import--wnt-pkt-5]

Jeśli faktura dokumentuje WNT, import towarów, import usług lub
dostawę rozliczaną przez nabywcę (odwrotne obciążenie) — rachunek
nie ma znaczenia (VAT rozlicza nabywca samodzielnie).

## Wyłączenia NKUP w CIT — art. 15d ust. 4 [#wyłączenia-nkup-w-cit--art-15d-ust-4]

<LegalRef act="CIT" art="15d" paragraph="4" /> ma identyczne
wyłączenia wobec NKUP:

* Złożenie zawiadomienia **ZAW-NR** do naczelnika US w 7 dni
  (pkt 1 — literalne powtórzenie art. 117ba § 3 pkt 2 OrdPod).
* Rachunek cesyjny / faktoringowy / własny banku (pkt 2).
* Płatność z MPP (pkt 3).
* Faktura dokumentująca WNT, import towarów / usług, reverse charge
  (pkt 4).

**Identyczne wyłączenia** w VAT i CIT — oznacza to, że jedno ZAW-NR
chroni przed oboma konsekwencjami jednocześnie.

## Jak Numify weryfikuje rachunek [#jak-numify-weryfikuje-rachunek]

Moduł
<ServiceRef path="src/lib/services/white-list.ts">white-list.ts</ServiceRef>
integruje się z API Ministerstwa Finansów
(`https://wl-api.mf.gov.pl/`). Udostępnione funkcje:

| Funkcja                                      | Zakres                                                                                    |
| -------------------------------------------- | ----------------------------------------------------------------------------------------- |
| `verifyBankAccount(nip, bankAccount, date?)` | Weryfikacja, czy dany rachunek znajduje się w wykazie dla danego NIP na wybrany dzień     |
| `lookupByNip(nip, date?)`                    | Pobranie pełnych danych podmiotu z wykazu — wszystkie zarejestrowane rachunki, status VAT |

Wynik `WhiteListResult` zawiera m.in.:

* `verified` — boolean (czy rachunek jest w wykazie dla tego NIP-u).
* `companyName` — nazwa podmiotu z wykazu.
* `vatStatus` — `czynny` / `zwolniony` / `niezarejestrowany`.
* `requestId` — identyfikator zapytania z API MF (dowód weryfikacji).

Weryfikacja jest wykonywana w momencie zatwierdzania przelewu.
`requestId` zapisywany w bazie stanowi dowód dochowania należytej
staranności — w razie kontroli US można go przywołać.

## Dowód weryfikacji — dlaczego ma znaczenie [#dowód-weryfikacji--dlaczego-ma-znaczenie]

Sam fakt, że rachunek **był** w wykazie w dniu zlecenia przelewu,
ma znaczenie prawne — <LegalRef act="OrdPod" art="117ba" paragraph="1" />
odnosi się do stanu wykazu „na dzień zlecenia przelewu". Jeżeli
rachunek został usunięty z wykazu np. tydzień po przelewie,
to nie wpływa na ochronę podatnika.

Dlatego **zapisanie dowodu weryfikacji** (data, wynik, `requestId`)
jest krytyczne. Numify automatycznie to robi — w razie kontroli
można z logu eksportować dowód.

## Typowe błędy [#typowe-błędy]

* **Oparcie się wyłącznie na rachunku z faktury** — kontrahent może
  zmienić rachunek, a faktura zawiera stary numer. Weryfikacja
  **zawsze** aktualnym stanem wykazu eliminuje to ryzyko.
* **Pominięcie ZAW-NR w 7 dni** — jeśli nabywca zauważy po tygodniu,
  że zapłacił na niewłaściwy rachunek, okienko na zawiadomienie
  przeminęło. W takiej sytuacji pozostaje tylko zapłata ponowna
  z MPP (nie cofnie NKUP) lub akceptacja konsekwencji.
* **Mylenie art. 117ba Ordynacji z nieistniejącym „art. 117ba
  ustawy o VAT"** — wiele źródeł błędnie cytuje ten przepis. Jest
  to **Ordynacja podatkowa**, rozdział 15 „Odpowiedzialność
  podatkowa osób trzecich".
* **Płatność gotówką > 15 000 zł** — narusza art. 19 Prawa
  przedsiębiorców + wyłącza wydatek z KUP (<LegalRef act="CIT" art="15d" paragraph="1" />
  pkt 1). Biała lista to kolejna warstwa po obowiązku rachunkowym.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3b">
    Pierwsza wersja — oparta na art. 96b ustawy o VAT (Dz.U. 2025
    poz. 775), art. 117ba Ordynacji podatkowej (Dz.U. 2025 poz. 111)
    oraz art. 15d ustawy o CIT. Implementacja weryfikacji w
    `white-list.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 86 VAT — Odliczenie podatku naliczonego
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-vat/art-86-odliczenie-vat
Description: Prawo do obniżenia VAT należnego o VAT naliczony — zakres (związek z czynnościami opodatkowanymi), kwota naliczonego (faktury, import, WNT, odwrotne obciążenie), moment powstania prawa (obowiązek podatkowy u dostawcy + otrzymanie faktury), okna czasowe (3 następne okresy + korekta do 5 lat), prewspółczynnik dla działalności mieszanej. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



Prawo do **odliczenia VAT** — obniżenia VAT należnego o VAT naliczony
— to kluczowy mechanizm ekonomiczny VAT-u jako podatku obciążającego
**wartość dodaną**, nie obrót.
<LegalRef act="VAT" art="86" /> określa **kiedy** to prawo powstaje,
**co** wchodzi do kwoty naliczonego, **jaki okres** okno się otwiera i
**co** jeśli go się spóźni.

<ComplianceDisclaimer />

## Podstawowa zasada — ust. 1 [#podstawowa-zasada--ust-1]

> W zakresie, w jakim towary i usługi są wykorzystywane do wykonywania
> czynności opodatkowanych, podatnikowi, o którym mowa w art. 15,
> przysługuje prawo do obniżenia kwoty podatku należnego o kwotę
> podatku naliczonego.

Trzy warunki łącznie:

1. **Podatnik VAT** w rozumieniu <LegalRef act="VAT" art="15" /> —
   sp. z o.o. zarejestrowana jako podatnik czynny VAT.
2. **Nabycie jest wykorzystywane do czynności opodatkowanych** —
   sprzedaży ze stawką 23 %, 8 %, 5 %, 0 % lub eksportu / WDT. Zakup
   dla celów prywatnych, nieodpłatnych, zwolnionych = brak
   odliczenia.
3. **Fakt odliczenia wynika z przepisów** — nie ma wyłączeń z
   <LegalRef act="VAT" art="88" /> (faktury pustosowe, usługi
   gastronomiczne i hotelowe z wyjątkami, nabycia od podmiotu
   nieistniejącego itd.).

### „Związek z czynnościami opodatkowanymi" [#związek-z-czynnościami-opodatkowanymi]

Nie musi być bezpośredni. Koszt ogólny (najem biura, księgowość,
energia elektryczna) jest „związany" z całością działalności
opodatkowanej — cały VAT jest naliczony. Problem pojawia się przy
działalności **mieszanej**:

* część sprzedaży zwolnionej (np. usługi finansowe <LegalRef act="VAT" art="43" />),
* część sprzedaży niegospodarczej (np. działalność statutowa
  fundacji),

— wtedy stosuje się odliczenie **proporcjonalne** (współczynnik z
art. 90) lub **prewspółczynnik** (ust. 2a).

## Co jest VAT naliczonym — ust. 2 [#co-jest-vat-naliczonym--ust-2]

Cztery główne źródła:

| Źródło                                                            | Typowy dokument                                               | Uwagi                                            |
| ----------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------ |
| Nabycie towarów i usług                                           | faktura VAT od dostawcy                                       | najczęstszy przypadek                            |
| Import towarów                                                    | dokument celny SAD, decyzja celna                             | lub procedura uproszczona (art. 33a)             |
| WNT                                                               | faktura zagranicznego dostawcy + własne wyliczenie            | VAT naliczony = VAT należny (**reverse charge**) |
| Odwrotne obciążenie / usługi z zagranicy (art. 17 ust. 1 pkt 4–5) | faktura bez VAT od zagranicznego dostawcy + własne wyliczenie | VAT naliczony = VAT należny                      |

### Szczególny przypadek: zaliczki — ust. 2 pkt 1 lit. b [#szczególny-przypadek-zaliczki--ust-2-pkt-1-lit-b]

Zapłata zaliczki przed dostawą — jeśli dostawca wystawił fakturę
zaliczkową, VAT z tej faktury jest naliczonym już w miesiącu zapłaty.

## Prewspółczynnik — ust. 2a–2h [#prewspółczynnik--ust-2a2h]

Dla działalności **mieszanej** (gospodarcza + niegospodarcza) —
jeśli nie da się przypisać zakupu do jednej z kategorii — VAT
naliczony liczy się **proporcjonalnie**.

### Metody ustalania proporcji — ust. 2c [#metody-ustalania-proporcji--ust-2c]

Dopuszczalne bazy:

1. **liczba osób** — etaty związane z działalnością gospodarczą
   w ogólnej liczbie etatów,
2. **godziny robocze** — godziny pracy przy działalności
   gospodarczej / ogółem,
3. **obrót** — obrót z działalności gospodarczej / obrót + dotacje
   i przychody z działalności niegospodarczej,
4. **powierzchnia** — powierzchnia wykorzystywana do działalności
   gospodarczej / ogółem.

Dla typowej sp. z o.o. **prowadzącej wyłącznie działalność
gospodarczą** prewspółczynnik **nie ma zastosowania** — odliczenie
pełne.

### Dane wyjściowe — ust. 2d [#dane-wyjściowe--ust-2d]

Proporcję liczy się na podstawie danych **poprzedniego roku
podatkowego**. Dla rozpoczynających — szacunkowo (ust. 2e) z
obowiązkiem zawiadomienia naczelnika US.

## Moment powstania prawa — ust. 10 i 10b [#moment-powstania-prawa--ust-10-i-10b]

### Zasada ogólna — ust. 10 [#zasada-ogólna--ust-10]

> Prawo do obniżenia kwoty podatku należnego o kwotę podatku
> naliczonego powstaje w rozliczeniu za okres, w którym w odniesieniu
> do nabytych lub importowanych przez podatnika towarów i usług
> powstał obowiązek podatkowy.

Obowiązek podatkowy u **dostawcy** (<LegalRef act="VAT" art="19a" />) —
nie data faktury, nie data zapłaty, nie data wprowadzenia do ksiąg.

### Dodatkowy warunek — ust. 10b [#dodatkowy-warunek--ust-10b]

Dla faktur i dokumentów celnych — prawo powstaje **nie wcześniej niż
w rozliczeniu za okres, w którym podatnik otrzymał fakturę**.

Efekt: prawo do odliczenia VAT z faktury powstaje w okresie
**późniejszym** z dwóch:

1. miesiąca powstania obowiązku podatkowego u dostawcy,
2. miesiąca otrzymania faktury.

### Przykład [#przykład]

Dostawa towarów 28 marca, faktura wystawiona 2 kwietnia, otrzymana
5 kwietnia.

* Obowiązek podatkowy u dostawcy: marzec (ust. 10 — data dostawy).
* Otrzymanie faktury: kwiecień.
* **Prawo do odliczenia**: rozliczenie za kwiecień.

Jeśli ta sama faktura dotarła 31 marca:

* Obowiązek podatkowy: marzec.
* Otrzymanie: marzec.
* Prawo do odliczenia: rozliczenie za marzec.

### WNT i odwrotne obciążenie — ust. 10b pkt 2–3 [#wnt-i-odwrotne-obciążenie--ust-10b-pkt-23]

Dla WNT (ust. 2 pkt 4 lit. c) i usług z zagranicy / odwrotnego
obciążenia (ust. 2 pkt 4 lit. a, b, d) — warunkiem jest **wykazanie
VAT należnego** w deklaracji za ten sam okres. Brak wykazania należnego
\= brak prawa do naliczonego.

Jest to mechanizm „bezgotówkowy" — VAT należny równy VAT naliczonemu
— ale tylko, jeśli obie kwoty pojawią się w tej samej deklaracji.

## Okna czasowe — ust. 11 i 13 [#okna-czasowe--ust-11-i-13]

### Trzy dodatkowe okresy — ust. 11 [#trzy-dodatkowe-okresy--ust-11]

> Jeżeli podatnik nie dokonał obniżenia kwoty podatku należnego w
> terminach określonych w ust. 10, 10d i 10e, może obniżyć kwotę
> podatku należnego w deklaracji podatkowej za jeden z trzech
> następnych okresów rozliczeniowych.

Czyli VAT z faktury marcowej można jeszcze odliczyć w kwietniu, maju
lub czerwcu (dla rozliczeń miesięcznych). Po trzech okresach —
potrzebna korekta deklaracji (ust. 13).

Dla rozliczeń **kwartalnych** — dwa następne kwartały.

### Korekta deklaracji — ust. 13 [#korekta-deklaracji--ust-13]

> Jeżeli podatnik nie dokonał obniżenia w terminach z ust. 10, 10d,
> 10e i 11, może obniżyć kwotę podatku należnego przez dokonanie
> korekty deklaracji podatkowej \[...] nie później jednak niż w
> ciągu 5 lat, licząc od początku roku, w którym powstało prawo do
> obniżenia.

Okno 5 lat na korektę — długoterminowa granica prawa do odliczenia.
Po tych 5 latach VAT **przepada** definitywnie.

### Korekta wsteczna — dwa tryby [#korekta-wsteczna--dwa-tryby]

1. Korekta za okres, **w którym powstało prawo** (miesiąc marzec z
   powyższego przykładu).
2. Korekta za **jeden z trzech następnych okresów** po okresie
   powstania prawa.

Różnica ma znaczenie przy odsetkach — korekta wsteczna do „dawnego"
okresu może wygenerować zwrot, ale zwykle nie generuje odsetek na
korzyść podatnika.

## Korekty VAT naliczonego — ust. 19a i 19c [#korekty-vat-naliczonego--ust-19a-i-19c]

Gdy dostawca wystawia **fakturę korygującą** zmniejszającą kwotę —
nabywca ma obowiązek **zmniejszyć VAT naliczony** w rozliczeniu za
okres **otrzymania faktury korygującej**.

Jeżeli VAT pierwotny **nie został jeszcze odliczony** — korekta
uwzględniana jest w rozliczeniu, w którym nabywca dokona tego
odliczenia.

Korekta musi nastąpić **z odpowiadającą po stronie dostawcy** (typowo
potwierdzenie otrzymania faktury korygującej — zobacz <LegalRef act="VAT" art="29a" paragraph="13" />).

## Realizacja w Numify [#realizacja-w-numify]

| Krok                          | Funkcja Numify                                                                                    | Efekt                                                                                          |
| ----------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Rejestracja faktury zakupu    | [faktury](/docs/korzystanie-z-numify/faktury) / [dokumenty](/docs/korzystanie-z-numify/dokumenty) | VAT naliczony z podziałem na stawki (23 / 8 / 5 / 0)                                           |
| Wyznaczenie okresu odliczenia | pole `vatDeductionPeriod` dokumentu                                                               | późniejszy z: miesiąc obowiązku podatkowego u dostawcy i miesiąc otrzymania faktury            |
| Zapis w ewidencji zakupu      | [vat-register](/docs/korzystanie-z-numify/vat-register)                                           | pozycja w rejestrze VAT miesięcznym                                                            |
| Generowanie JPK\_V7M          | [exports](/docs/korzystanie-z-numify/exports)                                                     | pola K\_40–K\_44 (nabycia krajowe), K\_45–K\_50 (nabycia związane z WNT), odpowiednie kody GTU |
| Prewspółczynnik               | ustawienia jednostki → `prewspolczynnik`                                                          | mnoży VAT naliczony przez proporcję                                                            |
| Okna czasowe                  | [vat-register](/docs/korzystanie-z-numify/vat-register) — widok „faktury do zaksięgowania"        | pokazuje faktury zakupu, dla których okno jeszcze otwarte                                      |
| Korekty VAT naliczonego       | powiązanie faktury korygującej z pierwotną                                                        | automatyczna zmiana w rejestrze za miesiąc otrzymania korekty                                  |

### Uczciwe framing — kontrola okna 3 okresów [#uczciwe-framing--kontrola-okna-3-okresów]

Numify śledzi okno 3 następnych okresów z ust. 11 na poziomie
każdej faktury zakupu. Ostrzeżenie pojawia się, gdy faktura pozostaje
niezaksięgowana dłużej niż okno pozwala na bieżące odliczenie —
z podpowiedzią, że dalsze odliczenie wymaga korekty deklaracji za
miesiąc powstania prawa (ust. 13).

Kontrola 5-letniego okna korekty (ust. 13 in fine) jest
**rekomendowanym workflow ręcznym** — dokumenty starsze niż 4 lata
kalendarzowe są zawsze flagowane, z rekomendacją przejrzenia przed
końcem roku.

## Częste błędy [#częste-błędy]

* **Odliczenie VAT z faktury przed jej otrzymaniem** — narusza
  ust. 10b. Kluczowa jest data **otrzymania** (doręczenia), nie
  wystawienia.
* **Odliczenie VAT z faktury od podmiotu niezarejestrowanego** —
  art. 88 ust. 3a pkt 1. Weryfikacja w białej liście MF to
  **ważny element due diligence** — zobacz [biała lista](/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista).
* **Odliczenie pełnego VAT od samochodu osobowego bez VAT-26** —
  <LegalRef act="VAT" art="86a" /> dopuszcza tylko 50 % odliczenia
  bez zgłoszenia użytku wyłącznie służbowego.
* **Odliczenie VAT od gastronomii i hoteli** — art. 88 ust. 1 pkt 4
  wyłącza (z wyjątkiem usług turystycznych dla dalszej sprzedaży).
* **Pominięcie warunku ujęcia VAT należnego** przy WNT /
  odwrotnym obciążeniu — brak wpisu należnego = brak prawa
  do naliczonego.
* **Odliczenie VAT z faktury pustosowej** (wystawionej bez
  rzeczywistej transakcji) — art. 88 ust. 3a pkt 4. To jeden z
  najczęstszych tytułów sankcji karno-skarbowych.
* **Odliczenie proporcjonalne bez prewspółczynnika, mimo mieszanej
  działalności** — jeśli spółka ma przychody z działalności
  niegospodarczej, musi stosować ust. 2a.

## Checklist — odliczenie VAT z faktury zakupu [#checklist--odliczenie-vat-z-faktury-zakupu]

* [ ] Dostawca jest zarejestrowany jako podatnik czynny VAT (sprawdź
  białą listę MF).
* [ ] Faktura spełnia wymogi <LegalRef act="VAT" art="106e" /> —
  wszystkie obowiązkowe pola.
* [ ] Nabycie jest wykorzystywane do czynności opodatkowanych.
* [ ] Brak wyłączenia z <LegalRef act="VAT" art="88" />.
* [ ] Obowiązek podatkowy u dostawcy powstał (typowo data dostawy /
  wykonania usługi).
* [ ] Faktura została **otrzymana** (zarejestrowana data otrzymania).
* [ ] Zapis w ewidencji zakupu w okresie = późniejszy z (obowiązek,
  otrzymanie).
* [ ] Dla faktur „na granicy" miesiąca — sprawdzone okno 3 następnych
  okresów (ust. 11).
* [ ] Dla starszych faktur — okno 5-letnie na korektę (ust. 13)
  nie upłynęło.
* [ ] Jeśli dotyczy samochodu osobowego — kontrola limitu 50 / 100 %
  (<LegalRef act="VAT" art="86a" />).
* [ ] Jeśli WNT / odwrotne obciążenie — VAT należny również ujęty
  w deklaracji za ten sam okres.


---

# Art. 45 UoR — Sprawozdanie finansowe
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-45-sprawozdanie-finansowe
Description: Zasady sporządzania sprawozdania finansowego — dzień bilansowy, trzy obligatoryjne elementy (bilans, RZiS, informacja dodatkowa), postać elektroniczna i struktura logiczna e-Sprawozdania dla KRS, kwalifikowany podpis elektroniczny, język polski i waluta polska. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Sprawozdanie finansowe** (dalej: SF) to końcowy rezultat całego roku
prowadzenia ksiąg rachunkowych. <LegalRef act="UoR" art="45" /> określa
ogólne zasady jego sporządzania — kiedy, z czego się składa, w jakiej
postaci i w jakim języku. Szczegółową strukturę bilansu i RZiS
regulują <LegalRef act="UoR" art="46" /> i <LegalRef act="UoR" art="47" />,
a wzory pozycji — załączniki 1 (jednostki inne) i 5 (jednostki małe).

<ComplianceDisclaimer />

## Dzień bilansowy — ust. 1 [#dzień-bilansowy--ust-1]

> Sprawozdanie finansowe sporządza się na dzień zamknięcia ksiąg
> rachunkowych, o którym mowa w art. 12 ust. 2, oraz na inny dzień
> bilansowy, stosując odpowiednio, z zastrzeżeniem ust. 1a–1ba,
> zasady wyceny aktywów i pasywów oraz ustalania wyniku finansowego,
> określone w rozdziale 4.

**Dzień bilansowy** to dzień, na który sporządza się SF. Dla typowej
sp. z o.o. kontynuującej działalność jest to **dzień kończący rok
obrotowy** (domyślnie 31 grudnia) — zobacz
[Art. 12 ust. 2](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-12-otwarcie-zamkniecie-ksiag).

Inne dni bilansowe — przy zakończeniu działalności, zmianie formy
prawnej, podziale, postawieniu w stan likwidacji — dotyczą wyjątków.

SF nie jest osobną ewidencją — jest **wycinkiem zamkniętych ksiąg**
na dzień bilansowy, zaprezentowanym w ustawowym układzie. Dlatego
warunkiem prawidłowego SF jest prawidłowe zamknięcie ksiąg i wycena
zgodna z rozdziałem 4 UoR (m.in. <LegalRef act="UoR" art="28" /> —
metody wyceny aktywów i pasywów, <LegalRef act="UoR" art="30" /> —
kursy walut).

### MSR zamiast UoR — ust. 1a–1e [#msr-zamiast-uor--ust-1a1e]

Emitenci na rynku regulowanym, spółki zależne w grupach kapitałowych
stosujących MSR oraz podatnicy podatku wyrównawczego mogą sporządzać
SF zgodnie z **Międzynarodowymi Standardami Rachunkowości**.

Dla typowej sp. z o.o. spoza grupy kapitałowej i bez papierów
wartościowych na rynku regulowanym — MSR nie mają zastosowania. Numify
wspiera wyłącznie SF według **polskich zasad** (UoR + załączniki 1 i 5).

## Postać elektroniczna — ust. 1f i 1g [#postać-elektroniczna--ust-1f-i-1g]

> 1f. Sprawozdanie finansowe sporządza się w postaci elektronicznej
> oraz opatruje się kwalifikowanym podpisem elektronicznym, podpisem
> zaufanym albo podpisem osobistym.
>
> 1g. Sprawozdania finansowe jednostek wpisanych do rejestru
> przedsiębiorców Krajowego Rejestru Sądowego sporządza się w
> strukturze logicznej oraz formacie udostępnianych w Biuletynie
> Informacji Publicznej na stronie podmiotowej urzędu obsługującego
> ministra właściwego do spraw finansów publicznych.

### Co to znaczy w praktyce dla sp. z o.o. [#co-to-znaczy-w-praktyce-dla-sp-z-oo]

Sp. z o.o. jako jednostka wpisana do rejestru przedsiębiorców KRS
**ma obowiązek** sporządzić SF jako plik **XML** o strukturze
logicznej publikowanej przez Ministerstwo Finansów
(e-Sprawozdanie Finansowe). Papierowa forma SF od 2018 r. **nie jest
prawnie sporządzonym SF**.

Aktualne schematy XSD: serwis BIP MF → Krajowe Standardy Rachunkowości →
Struktury logiczne sprawozdań finansowych. Od 2022 r. dostępne są
warianty dla jednostek innych, małych, mikro, OPP oraz zgodne z MSR.

### Podpis elektroniczny — ust. 1f [#podpis-elektroniczny--ust-1f]

SF muszą podpisać **wszyscy członkowie zarządu** oraz osoba, której
powierzono prowadzenie ksiąg. Dopuszczalne rodzaje podpisu:

| Rodzaj                             | Dostarczyciel                           | Typowy użytkownik                 |
| ---------------------------------- | --------------------------------------- | --------------------------------- |
| Kwalifikowany podpis elektroniczny | certyfikowane CA (np. Certum, EuroCert) | księgowy, członek zarządu z kartą |
| Podpis zaufany                     | profil zaufany ePUAP                    | członek zarządu bez certyfikatu   |
| Podpis osobisty                    | e-dowód                                 | członek zarządu mający e-dowód    |

Od 2022 r. — przepis <LegalRef act="UoR" art="52" paragraph="2" />
dopuszcza podpisanie SF **przez jedną osobę** (kierownika jednostki)
pod warunkiem złożenia przez pozostałych członków zarządu **oświadczeń**
o zgodności SF z księgami, również w formie elektronicznej.

## Trzy obligatoryjne elementy — ust. 2 [#trzy-obligatoryjne-elementy--ust-2]

> Sprawozdanie finansowe składa się z:
>
> 1. bilansu;
> 2. rachunku zysków i strat;
> 3. informacji dodatkowej, obejmującej wprowadzenie do sprawozdania
>    finansowego oraz dodatkowe informacje i objaśnienia.

| Element                 | Regulacja                                                                   | Realizacja w Numify                                            |
| ----------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Bilans                  | [Art. 46 UoR](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-46-bilans) | [reports → bilans](/docs/korzystanie-z-numify/balance-sheet)   |
| Rachunek zysków i strat | [Art. 47 UoR](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-47-rzis)   | [reports → RZiS](/docs/korzystanie-z-numify/profit-loss)       |
| Informacja dodatkowa    | Załączniki 1 / 5 — pozycje 1–…, noty 1–…                                    | [exports → e-Sprawozdanie](/docs/korzystanie-z-numify/exports) |

Brak któregokolwiek z trzech elementów oznacza, że SF **nie zostało
sporządzone** w rozumieniu ustawy. Dotyczy to również jednostek
małych i mikro korzystających z uproszczonych wzorów — pozycje są
krótsze, ale trzy elementy muszą wystąpić.

### Kiedy dodatkowo zestawienie zmian w kapitale i rachunek przepływów — ust. 3 [#kiedy-dodatkowo-zestawienie-zmian-w-kapitale-i-rachunek-przepływów--ust-3]

Jednostki **inne niż mikro i małe** (a także wybrane jednostki sektora
finansów publicznych) dołączają:

* zestawienie zmian w kapitale (funduszu) własnym,
* rachunek przepływów pieniężnych.

Progi wielkości jednostki — zobacz <LegalRef act="UoR" art="3" paragraph="1c" />
(jednostki małe) i <LegalRef act="UoR" art="3" paragraph="1a" />
(jednostki mikro). Sp. z o.o. przekraczająca progi jednostki małej
(łączny bilans > 33 mln zł, przychody > 66 mln zł, zatrudnienie >
50 osób — dwa z trzech w dwóch kolejnych latach) wpada w obowiązek
tych dwóch dodatkowych elementów.

## Sprawozdanie z działalności — ust. 4 [#sprawozdanie-z-działalności--ust-4]

> Do rocznego sprawozdania finansowego dołącza się sprawozdanie z
> działalności jednostki, jeżeli obowiązek jego sporządzania wynika
> z ustawy lub odrębnych przepisów.

Dla sp. z o.o. obowiązek wynika z <LegalRef act="UoR" art="49" />
oraz <LegalRef act="KSH" art="231" paragraph="2" />. Sprawozdanie z
działalności zarządu jest **osobnym dokumentem** — nie jest częścią SF
w rozumieniu ust. 2, ale **dołącza się** je razem ze zgłoszeniem SF
do KRS.

Numify nie generuje sprawozdania z działalności automatycznie — jest
to dokument narracyjny opisujący rok z perspektywy zarządu.
Rekomendowany workflow: przygotowanie poza Numify, podpisanie tymi
samymi podpisami co SF, złożenie razem w KRS.

## Język polski i waluta polska — ust. 5 [#język-polski-i-waluta-polska--ust-5]

> Sprawozdanie finansowe oraz sprawozdanie z działalności jednostki
> sporządza się w języku polskim i w walucie polskiej. Dane liczbowe
> można wykazywać w zaokrągleniu do tysięcy złotych, jeżeli nie
> zniekształca to obrazu jednostki zawartego w sprawozdaniu
> finansowym oraz w sprawozdaniu z działalności.

* Walutą SF jest **zawsze PLN**, niezależnie od waluty faktur i
  transakcji w ciągu roku. Kwoty w walutach obcych są przeliczane na
  PLN według zasad <LegalRef act="UoR" art="30" /> — zobacz
  [kursy walut](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut).
* Zaokrąglanie do tysięcy jest **fakultatywne** — wymaga deklaracji
  w informacji dodatkowej i konsekwentnego stosowania we wszystkich
  pozycjach. Numify domyślnie prezentuje SF w groszach / pełnych
  złotych; opcja zaokrąglenia do tysięcy jest w `accounting-policy`
  (zobacz [ustawienia](/docs/korzystanie-z-numify/settings)).

## Terminy — art. 52 i art. 53 [#terminy--art-52-i-art-53]

Trzy twarde terminy przypinające się do dnia bilansowego:

| Termin                                         | Podstawa prawna                                                         | Dla dnia bilansowego 31 XII 2025          |
| ---------------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------- |
| Sporządzenie SF                                | <LegalRef act="UoR" art="52" paragraph="1" /> — 3 miesiące              | 31 III 2026                               |
| Zatwierdzenie SF przez zgromadzenie wspólników | <LegalRef act="UoR" art="53" paragraph="1" /> — 6 miesięcy              | 30 VI 2026                                |
| Ostateczne zamknięcie ksiąg                    | <LegalRef act="UoR" art="12" paragraph="4" /> — 15 dni od zatwierdzenia | do 15 VII 2026 (jeśli zatwierdzono 30 VI) |

Po sporządzeniu SF ale **przed** jego zatwierdzeniem obowiązkowo
następuje **badanie** przez biegłego rewidenta (jeśli jednostka
podlega obowiązkowi badania — <LegalRef act="UoR" art="64" />).

### Złożenie SF do KRS [#złożenie-sf-do-krs]

W ciągu **15 dni od dnia zatwierdzenia** SF, zarząd sp. z o.o.
składa komplet dokumentów do KRS przez system
[eKRS](https://ekrs.ms.gov.pl):

* SF w formacie XML (e-Sprawozdanie),
* sprawozdanie z działalności (PDF lub XML),
* uchwała o zatwierdzeniu SF,
* uchwała o podziale zysku / pokryciu straty,
* sprawozdanie biegłego rewidenta (jeśli dotyczy).

Podstawa — <LegalRef act="UoR" art="69" paragraph="1" />. Dla SF
roku 2025 (dzień bilansowy 31 XII 2025, zatwierdzenie do 30 VI 2026)
ostatni dzień złożenia to **15 VII 2026**.

## Realizacja w Numify [#realizacja-w-numify]

| Krok                        | Funkcja Numify                                                 | Efekt                                                   |
| --------------------------- | -------------------------------------------------------------- | ------------------------------------------------------- |
| Sporządzenie bilansu        | [balance-sheet](/docs/korzystanie-z-numify/balance-sheet)      | Bilans A/P wg załącznika 1 lub 5                        |
| Sporządzenie RZiS           | [profit-loss](/docs/korzystanie-z-numify/profit-loss)          | RZiS wariant porównawczy lub kalkulacyjny               |
| Noty i informacja dodatkowa | [exports → e-sprawozdanie](/docs/korzystanie-z-numify/exports) | Szkielet XML z agregatami kont                          |
| Eksport XML e-Sprawozdanie  | [exports](/docs/korzystanie-z-numify/exports)                  | Plik XML zgodny ze strukturą MF                         |
| Zamknięcie roku             | [fiscal-periods](/docs/korzystanie-z-numify/fiscal-periods)    | `locked` dla wszystkich 12 miesięcy po zatwierdzeniu SF |

### Uczciwe framing — stan implementacji [#uczciwe-framing--stan-implementacji]

Numify generuje **szkielet** e-Sprawozdania XML z agregatów kont
(bilans, RZiS). Uzupełnienie **informacji dodatkowej** — wprowadzenie,
noty 1–…, polityka rachunkowości w części opisowej — pozostaje
**rekomendowanym workflow ręcznym**: wygenerowany XML otwiera się w
zewnętrznym narzędziu (np. aplikacja e-Sprawozdania MF, `e-Sprawozdania`
od KIR), uzupełnia pozycje opisowe, podpisuje elektronicznie i składa
do KRS.

Pełna automatyzacja informacji dodatkowej jest **zaplanowana** — wymaga
mapowania kolejnych not na strukturę logiczną MF.

## Częste błędy [#częste-błędy]

* **Pominięcie informacji dodatkowej** — SF to trzy elementy, nie dwa.
  Bilans + RZiS bez noty = SF nie zostało sporządzone.
* **Podpis papierowy / skan podpisu** — SF wymaga kwalifikowanego
  podpisu elektronicznego, zaufanego lub osobistego. Skan odręcznego
  podpisu **nie jest** podpisem w rozumieniu ust. 1f.
* **Brak podpisu jednego z członków zarządu** — wymaga oświadczenia
  pozostałych o zgodności SF z księgami (art. 52 ust. 2).
* **Złożenie PDF zamiast XML do KRS** — PDF nie spełnia wymogu
  struktury logicznej z ust. 1g.
* **Waluta inna niż PLN** — SF **zawsze** w PLN, nawet jeśli większość
  faktur była w EUR / USD.
* **Zaokrąglenie do tysięcy bez deklaracji** — trzeba ujawnić w
  informacji dodatkowej i stosować konsekwentnie.
* **Termin 3 miesięcy liczony od końca stycznia zamiast od dnia
  bilansowego** — dla 31 XII ostatni dzień sporządzenia to 31 III,
  nie 31 I + 3 miesiące.

## Checklist — sporządzenie rocznego SF [#checklist--sporządzenie-rocznego-sf]

* [ ] Księgi zamknięte technicznie (`close` dla grudnia) — zobacz
  [art. 12](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-12-otwarcie-zamkniecie-ksiag).
* [ ] Inwentaryzacja przeprowadzona i rozliczona
  (<LegalRef act="UoR" art="26" />).
* [ ] Wycena aktywów i pasywów na dzień bilansowy zgodna z rozdziałem 4.
* [ ] Różnice kursowe naliczone (<LegalRef act="UoR" art="30" />).
* [ ] Amortyzacja grudniowa wygenerowana
  (zobacz [art. 31–33](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-31-33-srodki-trwale)).
* [ ] Bilans wygenerowany wg załącznika 1 lub 5.
* [ ] RZiS wygenerowany w wybranym wariancie.
* [ ] Informacja dodatkowa — wprowadzenie + noty — uzupełniona.
* [ ] XML e-Sprawozdania wygenerowany i zweryfikowany schematem XSD.
* [ ] Podpisy elektroniczne wszystkich członków zarządu + księgowego.
* [ ] SF sporządzone w terminie 3 miesięcy od dnia bilansowego.
* [ ] SF zatwierdzone uchwałą zgromadzenia wspólników w terminie 6 miesięcy.
* [ ] Komplet dokumentów złożony do KRS w terminie 15 dni od zatwierdzenia.
* [ ] Księgi `locked` w Numify dla wszystkich 12 miesięcy — art. 12 ust. 4.


---

# Art. 23 UoR — Zapis księgowy
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-23-zapis-ksiegowy
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.
Review status: internal
Updated: 2026-04-17



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

<ComplianceDisclaimer />

## 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 &#x2A;*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 <LegalRef act="UoR" art="14" paragraph="4" />) 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 (<LegalRef act="UoR" art="15" paragraph="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 [#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 (<LegalRef act="UoR" art="14" paragraph="2" />)
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 (<LegalRef act="CIT" art="9" paragraph="1c" />).

### 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 <LegalRef act="UoR" art="25" />.
* **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.


---

# Art. 10 UoR — plan kont i polityka rachunkowości
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-10-plan-kont
Description: Obowiązkowy dokument opisujący przyjęte przez jednostkę zasady (politykę) rachunkowości — zakładowy plan kont, metody wyceny, sposób prowadzenia ksiąg, opis systemu informatycznego. Podstawa prawna i realizacja w Numify.
Review status: internal
Updated: 2026-04-16



Każda jednostka zobowiązana do prowadzenia ksiąg rachunkowych — w tym
każda sp. z o.o. — musi posiadać **pisemną dokumentację opisującą
przyjęte zasady (politykę) rachunkowości**. Obowiązek jest bezwarunkowy
(<LegalRef act="UoR" art="10" paragraph="1" />), a za jego brak
odpowiada kierownik jednostki (zarząd spółki).

<ComplianceDisclaimer />

## Obowiązkowy zakres polityki rachunkowości [#obowiązkowy-zakres-polityki-rachunkowości]

Ustawa wymienia w <LegalRef act="UoR" art="10" paragraph="1" /> cztery
obszary, które muszą być opisane:

| Punkt | Obszar                                                            | Zakres wymaganego opisu                                                          |
| ----- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| 1     | Rok obrotowy i okresy sprawozdawcze                               | Definicja roku obrotowego (zwykle kalendarzowy), okresy miesięczne do sprawozdań |
| 2     | Metody wyceny aktywów i pasywów oraz ustalania wyniku finansowego | Wycena środków trwałych, należności, zapasów, walut obcych                       |
| 3     | Sposób prowadzenia ksiąg rachunkowych                             | Plan kont, wykaz zbiorów danych, opis systemu informatycznego                    |
| 4     | System ochrony danych i dowodów księgowych                        | Zabezpieczenia, kopie zapasowe, dostęp                                           |

Punkt 3 jest rozbity na trzy literki — szczegóły poniżej.

## Sposób prowadzenia ksiąg (art. 10 ust. 1 pkt 3) [#sposób-prowadzenia-ksiąg-art-10-ust-1-pkt-3]

To najbardziej rozbudowana część polityki. Obejmuje:

### a) Zakładowy plan kont [#a-zakładowy-plan-kont]

Wykaz kont księgi głównej wraz z:

* Zasadami klasyfikacji zdarzeń (np. co idzie na konto 402 „Usługi
  obce" a co na 403 „Podatki i opłaty").
* Zasadami prowadzenia kont ksiąg pomocniczych.
* Sposobem powiązania kont analitycznych z syntetycznymi (np. konta
  analityczne `200-01`, `200-02`, ... rozbijają syntetyczne 200).

Numify domyślnie seeduje polski plan kont oparty na zespołach 0–8 —
patrz [Art. 15 — księga główna](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-15-ksiega-glowna).
Implementacja:
<ServiceRef path="src/lib/services/seed-company-accounts.ts">seed-company-accounts.ts</ServiceRef>,
pełna tabela definicji w
<ServiceRef path="src/db/seed-accounts.ts">src/db/seed-accounts.ts</ServiceRef>.

### b) Wykaz ksiąg rachunkowych / zbiorów danych [#b-wykaz-ksiąg-rachunkowych--zbiorów-danych]

Przy prowadzeniu ksiąg na komputerze — wykaz **zbiorów danych tworzących
księgi rachunkowe na informatycznych nośnikach danych**, z określeniem
ich struktury, powiązań i funkcji.

W praktyce: lista tabel bazodanowych, które tworzą księgi — u nas
`journal_entries`, `journal_lines`, `chart_accounts`, `contractors`,
`fixed_assets`, `exchange_rates` itd. Schemat jest definiowany w
[`src/db/schema.ts`](https://github.com/kacperkwapisz/numifyai/blob/master/src/db/schema.ts).

### c) Opis systemu informatycznego [#c-opis-systemu-informatycznego]

Przy prowadzeniu ksiąg komputerem — **wykaz programów, procedur lub
funkcji** wraz z opisem:

* Algorytmów i parametrów.
* Programowych zasad ochrony danych (uwierzytelnianie, autoryzacja,
  szyfrowanie).
* Wersji oprogramowania i daty rozpoczęcia eksploatacji.

Numify udostępnia generator wstępnego dokumentu polityki rachunkowości,
który wypełnia ten opis na podstawie wersji aplikacji i konfiguracji
spółki — zobacz sekcję [Generowanie polityki rachunkowości w Numify](#generowanie-polityki-rachunkowosci-w-numify)
poniżej.

## Metody wyceny (art. 10 ust. 1 pkt 2) [#metody-wyceny-art-10-ust-1-pkt-2]

Polityka musi opisywać zasady wyceny. Najczęstsze decyzje dla sp. z o.o.:

| Grupa                           | Typowy wybór                                        | Odniesienie UoR                               |
| ------------------------------- | --------------------------------------------------- | --------------------------------------------- |
| Środki trwałe                   | Cena nabycia pomniejszona o amortyzację             | <LegalRef act="UoR" art="28" />               |
| Wartości niematerialne i prawne | Cena nabycia pomniejszona o amortyzację             | <LegalRef act="UoR" art="28" />               |
| Materiały, towary               | Cena nabycia lub koszt wytworzenia                  | <LegalRef act="UoR" art="28" />               |
| Należności                      | Kwota wymaganej zapłaty, z odpisami aktualizującymi | <LegalRef act="UoR" art="28" />               |
| Zobowiązania                    | Kwota wymagająca zapłaty                            | <LegalRef act="UoR" art="28" />               |
| Operacje w walutach obcych      | Średni kurs NBP z dnia poprzedzającego operację     | <LegalRef act="UoR" art="30" paragraph="2" /> |

Szczegóły wyceny walutowej — zobacz [Art. 30 — kursy walut](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut).

## System ochrony danych (art. 10 ust. 1 pkt 4) [#system-ochrony-danych-art-10-ust-1-pkt-4]

Polityka musi opisywać **system służący ochronie danych i ich zbiorów,
w tym dowodów księgowych, ksiąg rachunkowych i innych dokumentów**. W
praktyce to opis:

* Kopii zapasowych (częstotliwość, miejsce przechowywania, test
  odtworzenia).
* Uwierzytelniania użytkowników (hasła, 2FA, SSO).
* Kontroli dostępu (role, uprawnienia).
* Szyfrowania (w spoczynku, w transmisji).
* Retencji dokumentów zgodnie z <LegalRef act="UoR" art="74" />.

Numify: kopie R2 + Postgres, szyfrowanie dokumentów R2 przez SSE-S3,
wrażliwe pola (np. certyfikaty KSeF) szyfrowane AES-256-CBC w bazie.

## Forma, zatwierdzenie, aktualizacja [#forma-zatwierdzenie-aktualizacja]

<LegalRef act="UoR" art="10" paragraph="2" /> nakłada trzy wymogi na
dokument polityki:

* **Forma pisemna** — może być elektroniczna, ale musi być utrwalona
  w sposób czytelny i odtwarzalny.
* **Ustalenie przez kierownika jednostki** — dla sp. z o.o. oznacza to
  zarząd. W praktyce potrzebna jest uchwała zarządu przyjmująca
  politykę.
* **Aktualizacja** — polityka musi być aktualizowana przy zmianach
  operacyjnych, prawnych lub systemu informatycznego.

Zmiana polityki obowiązuje co do zasady **od początku nowego roku
obrotowego** — zmiany w ciągu roku są dozwolone tylko wyjątkowo
(np. zmiana przepisów wymuszająca inny sposób wyceny).

## Krajowe standardy rachunkowości i MSR [#krajowe-standardy-rachunkowości-i-msr]

<LegalRef act="UoR" art="10" paragraph="3" /> pozwala:

* W sprawach nieuregulowanych ustawą — stosować **Krajowe Standardy
  Rachunkowości** (KSR) wydawane przez Komitet Standardów Rachunkowości
  przy Ministrze Finansów.
* W razie braku KSR — stosować **Międzynarodowe Standardy Rachunkowości**
  (MSR/MSSF), o ile jednostka nie jest objęta obligatoryjnym MSR (banki,
  podmioty publiczne).

Typowa sp. z o.o. najczęściej odwołuje się do KSR nr 7 (zmiany zasad
rachunkowości), KSR nr 11 (środki trwałe) i KSR nr 13 (koszt
wytworzenia).

## Generowanie polityki rachunkowości w Numify [#generowanie-polityki-rachunkowości-w-numify]

Numify dostarcza **wstępny projekt polityki rachunkowości** generowany
na podstawie danych spółki (forma prawna, status VAT, stawka CIT, rok
obrotowy) oraz bieżącej konfiguracji (liczba kont w planie kont, liczba
środków trwałych). Dokument jest dostępny pod `/accounting-policy` w
aplikacji — implementacja:
<ServiceRef path="src/lib/services/accounting-policy.ts">accounting-policy.ts</ServiceRef>.

Generator wypełnia 12 sekcji wymaganych przez art. 10 (postanowienia
ogólne, dane identyfikacyjne, rok obrotowy, miejsce prowadzenia ksiąg,
plan kont, metody wyceny, metody amortyzacji, ewidencja kosztów,
sprawozdawczość, JPK/KSeF, przechowywanie dokumentów, postanowienia
końcowe).

> **Ważne:** wygenerowany dokument to **projekt wymagający akceptacji
> przez Zarząd** — nie jest to gotowy dokument przyjęty automatycznie.
> Przed podpisaniem polityki należy:
>
> 1. Zweryfikować treść z księgowym lub doradcą podatkowym.
> 2. Dostosować sekcję metod wyceny do faktycznie stosowanych w spółce.
> 3. Przyjąć uchwałą zarządu.
> 4. Podpisać i archiwizować (min. okres prowadzenia ksiąg).

Przy zmianie przepisów (np. wyższe progi amortyzacji jednorazowej,
nowe obowiązki JPK) generator aktualizuje szablon — ale **aktualizacja
przyjętej polityki wymaga osobnej uchwały zarządu** zgodnie z
<LegalRef act="UoR" art="10" paragraph="2" />.

## Dlaczego to ma znaczenie [#dlaczego-to-ma-znaczenie]

Brak polityki rachunkowości albo jej niespójność z faktyczną praktyką
księgową to jeden z najczęstszych zarzutów przy kontroli skarbowej. W
skrajnym przypadku może skutkować:

* Zakwestionowaniem poprawności ksiąg i oszacowaniem podstawy
  opodatkowania przez organ podatkowy.
* Odpowiedzialnością karną członków zarządu z <LegalRef act="UoR" art="77" /> —
  grzywną albo karą pozbawienia wolności do lat 2 (albo obiema
  karami łącznie) za dopuszczenie do nieprowadzenia ksiąg, prowadzenia
  ich wbrew przepisom lub podawania w nich nierzetelnych danych.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnym tekście art. 10 UoR (tekst
    jednolity Dz.U. 2023 poz. 120) oraz na implementacji generatora
    polityki w `src/lib/services/accounting-policy.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Ustawa o rachunkowości — przegląd
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci
Description: Mapa najważniejszych przepisów Ustawy o rachunkowości z 29 września 1994 r. dla spółki z o.o. — księgi rachunkowe, polityka rachunkowości, zapis dwustronny, audit trail, waluty obce, sprawozdanie finansowe.
Review status: internal
Updated: 2026-04-16



**Ustawa o rachunkowości** (dalej: UoR) z 29 września 1994 r. jest
głównym aktem regulującym zasady prowadzenia ksiąg rachunkowych,
sporządzania sprawozdań finansowych oraz badania i ogłaszania tych
sprawozdań przez jednostki mające siedzibę w Polsce. Dla sp. z o.o.
obowiązek prowadzenia pełnej księgowości wynika bezpośrednio z
<LegalRef act="UoR" art="2" paragraph="1" /> — nie zależy od progu
przychodów ani wielkości spółki.

<ComplianceDisclaimer />

## Struktura ustawy [#struktura-ustawy]

Ustawa dzieli się na 9 rozdziałów i 6 załączników:

| Rozdział | Zakres                                                                                    | Kluczowe artykuły |
| -------- | ----------------------------------------------------------------------------------------- | ----------------- |
| 1        | Przepisy ogólne                                                                           | 1–8               |
| 2        | Prowadzenie ksiąg rachunkowych                                                            | 9–25              |
| 3        | Inwentaryzacja                                                                            | 26–27             |
| 4        | Wycena aktywów i pasywów, ustalanie wyniku finansowego                                    | 28–44             |
| 5        | Sprawozdania finansowe jednostki                                                          | 45–54             |
| 6        | Skonsolidowane sprawozdania finansowe grup kapitałowych                                   | 55–63d            |
| 7        | Badanie, składanie do właściwego rejestru sądowego, udostępnianie i ogłaszanie sprawozdań | 64–70             |
| 8        | Ochrona danych                                                                            | 71–76             |
| 9        | Odpowiedzialność karna                                                                    | 77–79             |

| Załącznik | Zakres                                                       |
| --------- | ------------------------------------------------------------ |
| 1         | Pełny zakres SF dla jednostek innych niż banki/ubezpieczenia |
| 2         | SF banków                                                    |
| 3         | SF zakładów ubezpieczeń i reasekuracji                       |
| 4         | Uproszczone SF jednostki mikro                               |
| 5         | Uproszczone SF jednostki małej                               |
| 6         | SF jednostek NGO (działalność pożytku publicznego)           |

Typowa sp. z o.o. stosuje **Załącznik 1** (domyślnie) lub **Załącznik 5**
(jeśli spełnia progi jednostki małej, <LegalRef act="UoR" art="3" paragraph="1" />
pkt 1b).

## Co dokumentujemy w tej sekcji [#co-dokumentujemy-w-tej-sekcji]

Ta sekcja zawiera artykuł-po-artykule opisy tych przepisów UoR, które
Numify realizuje w kodzie lub od których zależy codzienna praca
użytkownika. Pozostałe przepisy (np. skonsolidowane SF, badanie przez
biegłego rewidenta) nie są objęte dokumentacją — dotyczą scenariuszy
poza zakresem Numify.

<Cards>
  <Card title="Art. 10 — Plan kont i polityka rachunkowości" description="Dokumentacja opisująca przyjęte zasady rachunkowości, zakładowy plan kont, wykaz zbiorów danych, opis systemu informatycznego." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-10-plan-kont" />

  <Card title="Art. 14 — Dziennik" description="Chronologiczne ujęcie zdarzeń, kolejna numeracja zapisów, ciągłość obrotów, automatyczny numer pozycji przy prowadzeniu ksiąg komputerem." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik" />

  <Card title="Art. 15 — Księga główna" description="Zapis systematyczny na kontach syntetycznych, zasada podwójnego zapisu, kolejność chronologiczna." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-15-ksiega-glowna" />

  <Card title="Art. 16–17 — Księgi pomocnicze" description="Konta analityczne uszczegółowiające księgę główną — kontrahenci, środki trwałe, rozrachunki z pracownikami, operacje sprzedaży i zakupu." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-16-ksiegi-pomocnicze" />

  <Card title="Art. 18 — Zestawienie obrotów i sald" description="Miesięczne zestawienie obrotów i sald, zgodność z obrotami dziennika, zestawienie sald kont ksiąg pomocniczych na dzień zamknięcia." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-18-trial-balance" />

  <Card title="Art. 25 — Poprawianie błędów (audit trail)" description="Zakaz usuwania zapisów, korekta wyłącznie przez storno (zapisy dodatnie lub ujemne) przy prowadzeniu ksiąg komputerem." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny" />

  <Card title="Art. 30 — Kursy walut obcych" description="Średni kurs NBP z dnia poprzedzającego operację, dzień bilansowy, różnice kursowe jako przychody/koszty finansowe." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut" />

  <Card title="Załącznik 1 — Pełna struktura SF" description="Bilans (aktywa A–E, pasywa A–D), rachunek zysków i strat (wariant kalkulacyjny albo porównawczy), informacja dodatkowa." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1" />

  <Card title="Załącznik 5 — Jednostka mała" description="Progi 33 mln / 66 mln / 50 osób, uproszczona struktura bilansu i RZiS, dostępne uproszczenia ewidencyjne." href="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-5" />
</Cards>

## Co nie jest w zakresie tej sekcji [#co-nie-jest-w-zakresie-tej-sekcji]

* **Inwentaryzacja** (art. 26–27) — obsługiwana tylko częściowo w
  Numify (subsidiary ledger dla środków trwałych). Dokumentacja procedur
  inwentaryzacyjnych — poza zakresem.
* **Skonsolidowane sprawozdania grup kapitałowych** (art. 55–63d) — Numify
  jest projektowany pod pojedynczą jednostkę, nie pod grupę.
* **Badanie przez biegłego rewidenta** (art. 64–70) — obowiązek badania
  dotyczy jednostek przekraczających określone progi; proces badania jest
  poza systemem.
* **MSR/MSSF** — Numify wspiera jedynie polski plan kont na podstawie
  UoR; jednostki stosujące MSR mają odmienną strukturę ksiąg.

## Terminologia aktu prawnego [#terminologia-aktu-prawnego]

Niektóre pojęcia UoR nie tłumaczą się bezpośrednio na terminy angielskie
— tabela pomocnicza (pełny słownik: [Słownik pojęć](/docs/referencje/slownik)):

| Polski termin                                                                    | Angielski odpowiednik | Uwaga                  |
| -------------------------------------------------------------------------------- | --------------------- | ---------------------- |
| <PolishTerm pl="Księga główna" en="General ledger" />                            | General ledger        | Konta syntetyczne      |
| <PolishTerm pl="Księgi pomocnicze" en="Subsidiary ledgers" />                    | Subsidiary ledgers    | Analityka              |
| <PolishTerm pl="Dziennik" en="Journal" />                                        | Journal               | Zapis chronologiczny   |
| <PolishTerm pl="Zestawienie obrotów i sald" en="Trial balance">ZOiS</PolishTerm> | Trial balance         | Synteza księgi głównej |
| <PolishTerm pl="Polityka rachunkowości" en="Accounting policy" />                | Accounting policy     | Dokument wewnętrzny    |

## Źródło tekstu ustawy [#źródło-tekstu-ustawy]

Tekst jednolity obowiązuje na podstawie Dz.U. 2023 poz. 120, z
późniejszymi zmianami. Cytowania w tej sekcji odsyłają do
[ISAP — karta aktu](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20230000120)
przez komponent `<LegalRef>`.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja sekcji artykuł-po-artykule. Struktura oparta na
    aktualnym tekście jednolitym UoR (Dz.U. 2023 poz. 120), z uwzględnieniem
    nowelizacji Dz.U. 2024 poz. 1863 zmieniającej definicje wielkości
    jednostek (art. 3 ust. 1 pkt 1a–1e).
  </ChangeEntry>
</ChangeHistory>


---

# Art. 14 UoR — Dziennik
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-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.
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>


---

# Art. 16–17 UoR — Księgi pomocnicze
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-16-ksiegi-pomocnicze
Description: Konta analityczne uszczegóławiające księgę główną — per kontrahent, per środek trwały, per pracownik, per operacje sprzedaży i zakupu. Podstawa prawna (art. 16 + art. 17) i realizacja w Numify.
Review status: internal
Updated: 2026-04-16



<PolishTerm pl="Księgi pomocnicze" en="Subsidiary ledgers">Księgi
pomocnicze</PolishTerm> (inaczej: analityka) to drugi poziom ewidencji.
Konto syntetyczne w księdze głównej (np. 202 „Rozrachunki z dostawcami")
mówi, że spółka ma 48 500 zł do zapłaty — ale **komu konkretnie**,
wynika dopiero z konta pomocniczego rozbijającego 202 na poszczególnych
dostawców.

Dwa artykuły UoR regulują temat: **art. 16** (ogólna rola ksiąg
pomocniczych) i **art. 17** (konkretny wykaz obszarów, dla których
prowadzenie ewidencji pomocniczej jest obligatoryjne).

<ComplianceDisclaimer />

## Art. 16 — funkcja i sposób prowadzenia [#art-16--funkcja-i-sposób-prowadzenia]

### Ust. 1 — uszczegółowienie i uzgodnienie z księgą główną [#ust-1--uszczegółowienie-i-uzgodnienie-z-księgą-główną]

> Konta ksiąg pomocniczych zawierają zapisy będące uszczegółowieniem i
> uzupełnieniem zapisów kont księgi głównej. Prowadzi się je w ujęciu
> systematycznym jako wyodrębniony system ksiąg, kartotek (zbiorów
> kont), komputerowych zbiorów danych, uzgodniony z saldami i zapisami
> na kontach księgi głównej.

Dwa kluczowe wymogi:

1. **Uszczegółowienie i uzupełnienie** — konta pomocnicze rozbijają
   konto syntetyczne na analityczne pozycje (np. 202 na 202-ACME,
   202-BETA), ale nie zmieniają kwoty sumarycznej na koncie
   syntetycznym.
2. **Uzgodnienie z saldami i zapisami księgi głównej** — suma sald
   wszystkich kont pomocniczych w ramach danego konta syntetycznego
   musi być równa saldu konta syntetycznego. Jest to zasada
   **dwupoziomowej kontroli**: błąd w analityce lub w syntetyce
   ujawnia się jako rozjazd między tymi dwiema wartościami.

### Ust. 2 — jednostki naturalne [#ust-2--jednostki-naturalne]

Na kontach pomocniczych można stosować jednostki naturalne
(kilogramy, sztuki) obok lub zamiast jednostek pieniężnych — ale
**na koniec okresu sprawozdawczego** trzeba sporządzić zestawienie
tych zapisów i ustalić ich wartość w PLN. Dotyczy to głównie kart
magazynowych towarów i materiałów.

W Numify rzeczowe aktywa obrotowe (zespół 3) są domyślnie w PLN —
nie prowadzimy ewidencji magazynowej w sztukach. Dla spółek
prowadzących detaliczny obrót towarami jest to uproszczenie, które
wymaga świadomej decyzji w polityce rachunkowości.

## Art. 17 — obszary wymagające ksiąg pomocniczych [#art-17--obszary-wymagające-ksiąg-pomocniczych]

<LegalRef act="UoR" art="17" paragraph="1" /> wymienia siedem kategorii,
w których prowadzenie kont analitycznych jest **obligatoryjne**:

| Pkt | Obszar                                                     | Typowa analityka                                |
| --- | ---------------------------------------------------------- | ----------------------------------------------- |
| 1   | Środki trwałe, WNiP, odpisy amortyzacyjne                  | Karta ewidencyjna per środek trwały             |
| 2   | Rozrachunki z kontrahentami                                | Konto per dostawca, per odbiorca                |
| 3   | Rozrachunki z pracownikami (imienna ewidencja wynagrodzeń) | Karta wynagrodzeń per pracownik                 |
| 4   | Operacje sprzedaży                                         | Rejestr faktur własnych z numerami              |
| 5   | Operacje zakupu                                            | Rejestr faktur obcych                           |
| 6   | Koszty i istotne składniki aktywów                         | Analityka kosztów (miejsce powstawania, rodzaj) |
| 7   | Operacje gotówkowe (przy prowadzeniu kasy)                 | Raport kasowy                                   |

> **Uwaga:** słowo „w szczególności" w art. 17 ust. 1 oznacza katalog
> otwarty — obligatoryjne są co najmniej te siedem, ale jednostka może
> prowadzić analitykę także dla innych obszarów (np. budżetowe centra
> kosztów).

### Metody ewidencji rzeczowych aktywów obrotowych (ust. 2) [#metody-ewidencji-rzeczowych-aktywów-obrotowych-ust-2]

Dla towarów, materiałów i produktów gotowych <LegalRef act="UoR" art="17" paragraph="2" />
dopuszcza cztery metody, z których wybór należy do kierownika jednostki:

1. **Ilościowo-wartościowa** — dla każdego składnika: stany i obroty
   w jednostkach naturalnych i pieniężnych. Najpełniejsza kontrola,
   ale też najbardziej pracochłonna.
2. **Ilościowa** — tylko w jednostkach naturalnych; wycena stanu
   przynajmniej na koniec okresu sprawozdawczego do rozliczeń
   podatkowych.
3. **Wartościowa** — tylko w jednostkach pieniężnych; stosowana w
   detalicznym obrocie, gdzie zapisem jest przychód, rozchód i stan
   całego zapasu.
4. **Odpisywanie w koszty w momencie zakupu / wytworzenia** — z
   korektą kosztów o wartość stanu na dzień bilansowy (tzw. „koszt
   100%"). Najprostsza, ale wymaga inwentaryzacji na koniec roku.

## Jak Numify realizuje art. 16–17 [#jak-numify-realizuje-art-1617]

Numify prowadzi księgi pomocnicze automatycznie dla następujących
obszarów:

### Rozrachunki z kontrahentami (art. 17 ust. 1 pkt 2) [#rozrachunki-z-kontrahentami-art-17-ust-1-pkt-2]

Każda faktura ma przypisanego `contractorId` — przy księgowaniu zapis
w `journal_lines` otrzymuje kolumnę `contractorId`, co daje możliwość
zapytania „jakie są salda per kontrahent". Realizacja:
`getContractorLedger` w
<ServiceRef path="src/lib/services/subsidiary-ledger.ts">subsidiary-ledger.ts</ServiceRef>.

Ekran `/contractors/{id}` pokazuje:

* Salda Dt/Ct per kontrahent (saldo dodatnie = należność, ujemne =
  zobowiązanie).
* Historię dokumentów (faktury, płatności).
* Suma rozrachunków zgodna z kontem syntetycznym 201/202.

### Środki trwałe (art. 17 ust. 1 pkt 1) [#środki-trwałe-art-17-ust-1-pkt-1]

Każdy środek trwały ma osobną kartę w tabeli `fixed_assets` zawierającą:

* Wartość początkową, metodę i stawkę amortyzacji.
* Historię odpisów amortyzacyjnych (`depreciation_entries`).
* Numer inwentarzowy, klasyfikację KŚT.

Wygenerowanie odpisu amortyzacyjnego tworzy zapis w dzienniku
(`journal_entries.source = 'auto_depreciation'`) i odnośnik do karty.
Realizacja w
<ServiceRef path="src/lib/services/fixed-assets.ts">fixed-assets.ts</ServiceRef>,
zapytanie analityczne — `getFixedAssetLedger` w
<ServiceRef path="src/lib/services/subsidiary-ledger.ts">subsidiary-ledger.ts</ServiceRef>.

### Operacje sprzedaży i zakupu (art. 17 ust. 1 pkt 4 i 5) [#operacje-sprzedaży-i-zakupu-art-17-ust-1-pkt-4-i-5]

* **Faktury sprzedaży** mają kolejną numerację własną (wzorzec
  konfigurowalny w ustawieniach spółki) — rejestrowane w tabeli
  `invoices`.
* **Faktury zakupu** trafiają do tabeli `documents` / `transactions` z
  numerem KSeF (od 1 kwietnia 2026 r.) albo numerem dostawcy przed tą
  datą.

Oba rejestry są podstawą do generowania JPK\_V7M (patrz
<ServiceRef path="src/lib/services/jpk-vat-generator.ts">jpk-vat-generator.ts</ServiceRef>).

### Koszty (art. 17 ust. 1 pkt 6) [#koszty-art-17-ust-1-pkt-6]

Numify prowadzi ewidencję kosztów w układzie rodzajowym (zespół 4 —
<AccountRef code="401" name="Zużycie materiałów" />,
<AccountRef code="402" name="Usługi obce" />,
<AccountRef code="403" name="Podatki i opłaty" /> itd.), z możliwością
dodania analityki per projekt / centrum kosztów (ręcznie w planie
kont).

### Czego Numify nie prowadzi [#czego-numify-nie-prowadzi]

* **Imienna ewidencja wynagrodzeń** (art. 17 ust. 1 pkt 3) — Numify
  nie obsługuje płac, wynagrodzenia księgowane są zbiorczo. Prowadzenie
  imiennej ewidencji wymaga osobnego systemu kadrowo-płacowego.
* **Raport kasowy** (art. 17 ust. 1 pkt 7) — jeśli spółka prowadzi
  kasę, obecnie wymaga to wyodrębnienia analityki w planie kont
  ręcznie. Automatyczny moduł kasowy nie jest zaimplementowany.

## Uzgodnienie analityki z syntetyką [#uzgodnienie-analityki-z-syntetyką]

Sprawdzenie uzgodnienia jest wbudowane:

* Na ekranie `/chart-of-accounts/{code}` pokazywane jest saldo konta
  syntetycznego oraz suma sald analityki.
* Różnica (powinna być zerem) jest wyświetlana jako ostrzeżenie, jeśli
  przekracza 1 grosz — co wynika z <LegalRef act="UoR" art="16" paragraph="1" />
  (wymóg uzgodnienia).

Dla konkretnego konta rozrachunkowego można też zbudować zestawienie
sald wszystkich kontrahentów na koniec okresu — realizuje to
`getContractorLedgerSummary` w
<ServiceRef path="src/lib/services/subsidiary-ledger.ts">subsidiary-ledger.ts</ServiceRef>,
dostępne z widoku `/contractors` oraz w eksportach `/reports`.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnych tekstach art. 16 i art. 17
    UoR (Dz.U. 2023 poz. 120). Rozbudowano zakres w stosunku do
    wcześniejszych wersji dokumentacji, które łączyły oba artykuły pod
    hasłem „art. 16" — uszczegółowienie katalogu siedmiu obszarów
    (art. 17 ust. 1) oraz metod ewidencji (art. 17 ust. 2).
  </ChangeEntry>
</ChangeHistory>


---

# Art. 46 UoR — Bilans
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-46-bilans
Description: Struktura bilansu — aktywa i pasywa na dzień bilansowy, wartości księgowe skorygowane o odpisy amortyzacyjne, umorzeniowe i aktualizujące, kompensata aktywów i zobowiązań finansowych, załączniki 1 i 5 jako wzorce pozycji, aktywa trwałe i obrotowe, kapitał własny i zobowiązania. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Bilans** to zestawienie **aktywów** i **pasywów** jednostki na dzień
bilansowy — pierwszy z trzech obligatoryjnych elementów SF
(zobacz [art. 45 ust. 2](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-45-sprawozdanie-finansowe)).
<LegalRef act="UoR" art="46" /> określa, jak prezentować salda kont
bilansowych w układzie A/P oraz jakie wzory (załączniki 1–6) stosować.

<ComplianceDisclaimer />

## Stany na dwa dni bilansowe — ust. 1 i 1a [#stany-na-dwa-dni-bilansowe--ust-1-i-1a]

> 1. W bilansie wykazuje się stany aktywów i pasywów na dzień
>    kończący bieżący i poprzedni rok obrotowy.
>
> 1a. W przypadku sporządzania bilansu na inny dzień bilansowy niż
> określony w ust. 1, w bilansie wykazuje się stany aktywów i
> pasywów na ten dzień oraz na dzień kończący rok obrotowy
> bezpośrednio poprzedzający ten dzień bilansowy.

Bilans **zawsze** prezentuje **dwie kolumny**:

| Kolumna                            | Dzień                                                 | Źródło                                   |
| ---------------------------------- | ----------------------------------------------------- | ---------------------------------------- |
| Stan na koniec bieżącego okresu    | dzień bilansowy (typowo 31 XII RRRR)                  | salda kont po zamknięciu ksiąg roku RRRR |
| Stan na koniec poprzedniego okresu | dzień kończący poprzedni rok obrotowy (31 XII RRRR-1) | bilans zamknięcia poprzedniego roku      |

Dane porównawcze są **obowiązkowe** — pomagają użytkownikowi SF
ocenić kierunek zmian (wzrost, spadek). Pierwszy bilans po rozpoczęciu
działalności wyjątkowo prezentuje tylko kolumnę bieżącą (brak okresu
poprzedniego).

### Zachowanie ciągłości z bilansem zamknięcia poprzedniego roku [#zachowanie-ciągłości-z-bilansem-zamknięcia-poprzedniego-roku]

Kolumna „poprzedni okres" musi **dokładnie** odpowiadać zatwierdzonemu
bilansowi poprzedniego roku. Różnica naruszałaby zasadę ciągłości
bilansowej — zobacz <LegalRef act="UoR" art="5" paragraph="1" /> i
[bilans otwarcia](/docs/korzystanie-z-numify/opening-balance).

## Wycena aktywów — ust. 2 i 2a [#wycena-aktywów--ust-2-i-2a]

> Wykazana w aktywach bilansu wartość poszczególnych grup składników
> aktywów wynika z ich wartości księgowej, skorygowanej o:
>
> 1. dotychczas dokonane odpisy amortyzacyjne lub umorzeniowe oraz
>    odpisy aktualizujące, w tym również z tytułu trwałej utraty
>    wartości składników aktywów trwałych;
> 2. odpisy aktualizujące wartość rzeczowych składników aktywów
>    obrotowych;
> 3. odpisy aktualizujące wartość należności.

Formuła wartości bilansowej aktywu:

```
wartość bilansowa = wartość księgowa (cena nabycia / koszt wytworzenia)
                  − umorzenie (środki trwałe, WNiP)
                  − odpisy aktualizujące (trwała utrata, aktywa
                    obrotowe, należności wątpliwe)
```

Przykłady:

* **Środek trwały**: cena nabycia 100 000 zł − umorzenie 40 000 zł =
  wartość bilansowa 60 000 zł. Szczegóły —
  [art. 31–33](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-31-33-srodki-trwale).
* **Należność wątpliwa**: wartość nominalna 10 000 zł − odpis
  aktualizujący 10 000 zł = wartość bilansowa 0 zł. Należność nie
  znika z ksiąg (pozostaje na koncie 201), ale w bilansie po
  skorygowaniu o odpis prezentuje się jako zero.

### Kompensata aktywów i zobowiązań finansowych — ust. 2a [#kompensata-aktywów-i-zobowiązań-finansowych--ust-2a]

> Aktywa finansowe i zobowiązania finansowe wykazuje się w bilansie w
> kwocie netto po kompensacie, jeżeli jednostka ma bezwarunkowe
> prawo do kompensaty aktywów i zobowiązań danego rodzaju i zamierza
> je rozliczyć w kwocie netto albo jednocześnie wydać składnik aktywów
> finansowych i rozliczyć zobowiązanie finansowe.

Kompensata wymaga **dwóch warunków łącznie**:

1. bezwarunkowe prawo do kompensaty (np. umowa nettingowa, przepis),
2. zamiar rozliczenia netto (deklaracja w polityce rachunkowości lub
   umowie).

Typowy przypadek: rachunek bieżący w banku (saldo debetowe jednego
dnia, kredytowe następnego) — w bilansie wykazuje się **saldo netto**
konta bankowego.

### Odpisy z wyniku w ciągu roku — ust. 3 [#odpisy-z-wyniku-w-ciągu-roku--ust-3]

Odpisy z zysku netto dokonywane w ciągu roku (zaliczki na dywidendę,
inne) wykazuje się **ze znakiem ujemnym** w pasywach, w pozycji
„Kapitał (fundusz) własny" — „Odpisy z zysku netto w ciągu roku
obrotowego (wielkość ujemna)".

## Wzory bilansu — ust. 5 [#wzory-bilansu--ust-5]

> Bilans powinien zawierać informacje w zakresie ustalonym:
>
> 1. dla jednostek innych niż banki, zakłady ubezpieczeń i zakłady
>    reasekuracji — w załączniku nr 1 do ustawy;
> 2. dla banków — w załączniku nr 2 do ustawy;
> 3. dla zakładów ubezpieczeń i zakładów reasekuracji — w załączniku
>    nr 3 do ustawy;
> 4. dla jednostek mikro sporządzających uproszczony bilans — w
>    załączniku nr 4 do ustawy;
> 5. dla jednostek małych sporządzających uproszczony bilans — w
>    załączniku nr 5 do ustawy;
> 6. dla OPP — w załączniku nr 6 do ustawy.

Dla typowej sp. z o.o. istotne są **dwa** warianty:

| Wzór                                                                         | Adresat                                                                      | Liczba pozycji (szacunkowo) |
| ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------- |
| [Załącznik nr 1](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1) | jednostki inne — domyślny wariant                                            | ok. 90 pozycji bilansu      |
| [Załącznik nr 5](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-5) | jednostki małe (<LegalRef act="UoR" art="3" paragraph="1c" />) — uproszczony | ok. 30 pozycji bilansu      |

Przejście na uproszczony wariant wymaga uchwały organu zatwierdzającego
— nie jest automatyczne z samego spełnienia progów.

## Struktura bilansu — załącznik 1 [#struktura-bilansu--załącznik-1]

### Aktywa [#aktywa]

Aktywa w bilansie załącznika 1 są pogrupowane w **dwie główne grupy**:

| Grupa           | Kod | Zawartość — przykładowe pozycje                                                                                                                          |
| --------------- | --- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Aktywa trwałe   | A   | wartości niematerialne i prawne, rzeczowe aktywa trwałe, należności długoterminowe, inwestycje długoterminowe, długoterminowe rozliczenia międzyokresowe |
| Aktywa obrotowe | B   | zapasy, należności krótkoterminowe, inwestycje krótkoterminowe (w tym środki pieniężne), krótkoterminowe rozliczenia międzyokresowe                      |

Szczegółowy podział aktywów trwałych A:

| Pozycja | Tytuł                                     | Typowe konta            |
| ------- | ----------------------------------------- | ----------------------- |
| A.I     | Wartości niematerialne i prawne           | 020, 070                |
| A.II    | Rzeczowe aktywa trwałe                    | 010, 030, 080 minus 070 |
| A.III   | Należności długoterminowe                 | 241 (>12 mies.)         |
| A.IV    | Inwestycje długoterminowe                 | 030, 140 długoterminowe |
| A.V     | Długoterminowe rozliczenia międzyokresowe | 650 długoterminowe      |

Aktywa obrotowe B:

| Pozycja | Tytuł                                      | Typowe konta                       |
| ------- | ------------------------------------------ | ---------------------------------- |
| B.I     | Zapasy                                     | 300, 310, 330, 601                 |
| B.II    | Należności krótkoterminowe                 | 201, 221, 229, 241 (≤12 mies.)     |
| B.III   | Inwestycje krótkoterminowe                 | 130, 131, 135, 140 krótkoterminowe |
| B.IV    | Krótkoterminowe rozliczenia międzyokresowe | 650 krótkoterminowe                |

### Pasywa [#pasywa]

Pasywa są pogrupowane w:

| Grupa                                  | Kod | Zawartość                                                                                                                           |
| -------------------------------------- | --- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Kapitał (fundusz) własny               | A   | kapitał zakładowy, zapasowy, z aktualizacji wyceny, zysk / strata z lat ubiegłych, zysk / strata netto, odpisy z zysku w ciągu roku |
| Zobowiązania i rezerwy na zobowiązania | B   | rezerwy, zobowiązania długoterminowe, zobowiązania krótkoterminowe, rozliczenia międzyokresowe                                      |

Kapitał własny A (szczegółowo):

| Pozycja | Tytuł                                      | Typowe konta |
| ------- | ------------------------------------------ | ------------ |
| A.I     | Kapitał (fundusz) podstawowy               | 800          |
| A.II    | Kapitał zapasowy                           | 810          |
| A.III   | Kapitał z aktualizacji wyceny              | 811          |
| A.IV    | Pozostałe kapitały rezerwowe               | 813          |
| A.V     | Zysk / strata z lat ubiegłych              | 820          |
| A.VI    | Zysk / strata netto                        | saldo 860    |
| A.VII   | Odpisy z zysku netto w ciągu roku (ujemna) | 822          |

Zobowiązania B:

| Pozycja | Tytuł                        | Kluczowa cecha                                                              |
| ------- | ---------------------------- | --------------------------------------------------------------------------- |
| B.I     | Rezerwy na zobowiązania      | niepewna kwota lub termin                                                   |
| B.II    | Zobowiązania długoterminowe  | termin wymagalności > 12 mies.                                              |
| B.III   | Zobowiązania krótkoterminowe | termin wymagalności ≤ 12 mies. — tu większość zobowiązań typowej sp. z o.o. |
| B.IV    | Rozliczenia międzyokresowe   | bierne RMK, dotacje rozliczane w czasie                                     |

## Realizacja w Numify [#realizacja-w-numify]

| Krok                              | Funkcja Numify                                                                        | Efekt                                                      |
| --------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Mapowanie kont na pozycje bilansu | plan-kont (flagi `balancePosition`)                                                   | każde konto ma przypisaną pozycję A.I–B.IV lub A–B pasywów |
| Generowanie bilansu z sald        | [balance-sheet](/docs/korzystanie-z-numify/balance-sheet)                             | suma sald kont według mapowania                            |
| Dane porównawcze                  | [balance-sheet](/docs/korzystanie-z-numify/balance-sheet) — kolumna „poprzedni okres" | z zamkniętego poprzedniego roku obrotowego                 |
| Wzór załącznika                   | ustawienia jednostki                                                                  | `balanceSheetTemplate = 'zal1'` lub `'zal5'`               |
| Eksport XML                       | [exports](/docs/korzystanie-z-numify/exports)                                         | bilans wbudowany w e-Sprawozdanie                          |

### Uczciwe framing — mapowanie kont [#uczciwe-framing--mapowanie-kont]

Mapowanie kont księgi głównej na pozycje bilansu jest **kluczowym
krokiem** konfiguracyjnym — błąd w mapowaniu = błąd w bilansie. Numify
dostarcza **domyślne mapowanie** dla wzorcowego planu kont (zobacz
[plan kont](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-10-plan-kont)),
ale każda jednostka z indywidualnymi kontami musi **zweryfikować
mapowanie ręcznie** przy pierwszym bilansie.

## Wartość ogólna — równanie bilansowe [#wartość-ogólna--równanie-bilansowe]

Aktywa (A + B) = Pasywa (A + B). Nierówność o jakąkolwiek kwotę
oznacza błąd w księgach. Typowe przyczyny:

* Zapis z niezbilansowaną stroną Wn ≠ Ma (nie powinien powstać w
  systemie podwójnego zapisu — zobacz
  [art. 23](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-23-zapis-ksiegowy)).
* Błędne mapowanie konta — konto wynikowe zaksięgowane w bilansie lub
  odwrotnie.
* Różnice kursowe nie zamknięte na koniec roku — saldo konta 750 / 755
  zasila wynik netto przez RZiS, który trafia do kapitału własnego
  (pozycja A.VI).

Numify blokuje eksport XML e-Sprawozdania, jeśli bilans nie bilansuje
na kwotę > 0,01 zł — chroni przed złożeniem wadliwego SF do KRS.

## Częste błędy [#częste-błędy]

* **Bilans nie bilansuje** — typowo błędne mapowanie konta wynikowego
  na pozycję bilansu.
* **Dane porównawcze z ręcznie wpisanego bilansu, nie z zamkniętych
  ksiąg poprzedniego roku** — narusza ciągłość (<LegalRef act="UoR" art="5" paragraph="1" />).
* **Pominięcie odpisów aktualizujących** — należności wątpliwe
  prezentowane w pełnej wartości nominalnej.
* **Brak kompensaty salda rachunku bankowego** — prezentacja brutto
  mimo spełnienia warunków ust. 2a.
* **Środki trwałe prezentowane w wartości początkowej** — pomija
  umorzenie, narusza ust. 2 pkt 1.
* **Używanie załącznika 5 bez uchwały o statusie jednostki małej** —
  sam fakt spełnienia progów nie wystarczy.
* **Zysk netto w dwóch miejscach** — raz na koncie 860, raz przepisany
  do pasywów jako A.VI; bilans zaczyna podwójnie liczyć wynik.

## Checklist — sporządzenie bilansu [#checklist--sporządzenie-bilansu]

* [ ] Księgi zamknięte technicznie na dzień bilansowy (status `closed`).
* [ ] Inwentaryzacja przeprowadzona, różnice rozliczone.
* [ ] Wycena aktywów i pasywów zgodna z <LegalRef act="UoR" art="28" />.
* [ ] Odpisy amortyzacyjne za grudzień wygenerowane.
* [ ] Odpisy aktualizujące należności wątpliwe zaksięgowane.
* [ ] Różnice kursowe z konta 751 / 755 naliczone i zaksięgowane.
* [ ] Mapowanie kont na pozycje bilansu zweryfikowane.
* [ ] Bilans wygenerowany — kolumna bieżąca + porównawcza.
* [ ] Kolumna porównawcza zgodna z bilansem zamknięcia poprzedniego roku.
* [ ] Bilans bilansuje (Aktywa = Pasywa, tolerancja ≤ 0,01 zł).
* [ ] Wariant wzoru (załącznik 1 lub 5) zgodny z polityką rachunkowości.


---

# Załącznik 1 UoR - Pełna struktura SF
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1
Description: Struktura pełnego sprawozdania finansowego dla sp. z o.o. - Bilans (aktywa A-E, pasywa A-D), Rachunek zysków i strat (wariant kalkulacyjny albo porównawczy), Informacja dodatkowa. Mapowanie na plan kont Numify.
Review status: internal
Updated: 2026-04-16



Załącznik 1 do UoR określa **pełną strukturę sprawozdania finansowego**
dla jednostek innych niż banki, zakłady ubezpieczeń i NGO. Jest to
domyślny format dla sp. z o.o. - stosuje się go zawsze, chyba że
spółka spełnia progi jednostki małej lub mikro i zdecyduje się na
Załącznik 5 / 4. Struktura jest wiążąca - wszystkie nagłówki pozycji
muszą się pojawić w sprawozdaniu (ale pozycje bez ruchu można pominąć,
<LegalRef act="UoR" art="50" paragraph="3" />).

<ComplianceDisclaimer />

## Kiedy Załącznik 1 jest obowiązkowy [#kiedy-załącznik-1-jest-obowiązkowy]

Załącznik 1 stosują jednostki, które **nie kwalifikują się** do
uproszczeń:

* Nie są jednostką mikro (progi: 2 mln aktywów / 4 mln przychodów /
  10 osób).
* Nie są jednostką małą (progi: 33 mln / 66 mln / 50 osób -
  <LegalRef act="UoR" art="3" paragraph="1" /> pkt 1b).
* Albo są mikro/małe, ale kierownik jednostki nie zdecydował o
  stosowaniu uproszczeń.

Dla rosnącej sp. z o.o. Załącznik 1 jest typowym "docelowym" formatem,
do którego przechodzi się po przekroczeniu progów z Załącznika 5.

## Bilans - struktura aktywów [#bilans---struktura-aktywów]

<LegalRef act="UoR" art="46" paragraph="5" /> pkt 1 określa, że bilans
dla jednostek standardowych ma strukturę z Załącznika 1. Aktywa dzielą
się na pięć głównych grup oznaczonych literami A-E:

| Pozycja                                     | Opis                                           | Konta Numify (tag `balanceSheetTag`)                                                                                                         |
| ------------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **A. Aktywa trwałe**                        | Długoterminowe aktywa (powyżej 12 miesięcy)    | Zespół 0                                                                                                                                     |
| Wartości niematerialne i prawne (A.I)       |                                                | <AccountRef code="020" />, <AccountRef code="075" name="Umorzenie WNiP" />                                                                   |
| Rzeczowe aktywa trwałe (A.II)               |                                                | <AccountRef code="010" name="Środki trwałe" />, <AccountRef code="070" name="Umorzenie ŚT" />, <AccountRef code="080" name="ŚT w budowie" /> |
| Inwestycje długoterminowe (A.IV)            |                                                | <AccountRef code="030" />                                                                                                                    |
| **B. Aktywa obrotowe**                      | Krótkoterminowe aktywa                         | Zespoły 1, 2, 3                                                                                                                              |
| Zapasy (B.I)                                |                                                | <AccountRef code="300" />, <AccountRef code="310" name="Materiały" />, <AccountRef code="330" name="Towary" />                               |
| Należności handlowe (B.II.1)                |                                                | <AccountRef code="201" name="Odbiorcy" />                                                                                                    |
| Inne należności (B.II.2)                    | VAT naliczony, rozrach. z pracownikami         | <AccountRef code="221" />, <AccountRef code="234" />, <AccountRef code="240" />                                                              |
| Inwestycje krótkoterminowe (B.III)          | Kasa, bank, krótkoterm. aktywa finansowe       | <AccountRef code="100" />, <AccountRef code="130" />, <AccountRef code="135" />, <AccountRef code="140" />                                   |
| Rozliczenia międzyokresowe czynne (B.IV)    |                                                | <AccountRef code="640" />                                                                                                                    |
| **C. Należne wpłaty na kapitał podstawowy** | Pozycja rzadka — brak konta w domyślnym planie | —                                                                                                                                            |
| **D. Udziały (akcje) własne**               | Pozycja rzadka                                 | —                                                                                                                                            |

Załącznik 1 rozbudowuje powyższe grupy do trzech poziomów szczegółowości
(I → 1 → a), np. pozycja A.II dzieli się na „środki trwałe” (z dalszym
rozbiciem na budynki, maszyny, środki transportu, inne) oraz „środki
trwałe w budowie”. W Numify te podpozycje są oznaczane przez
szczegółowe tagi w `balanceSheetTag` (np. `AKT_B_III_1b` dla rachunków
bankowych).

> **Mapowanie kont na pozycje bilansu** w Numify realizuje pole
> `balanceSheetTag` w tabeli `chart_accounts` (np. `AKT_A_II`,
> `AKT_B_II`). Generowanie bilansu:
> <ServiceRef path="src/lib/services/balance-sheet.ts">balance-sheet.ts</ServiceRef>.

## Bilans - struktura pasywów [#bilans---struktura-pasywów]

Pasywa dzielą się wg Załącznika 1 na dwie główne grupy - **A. Kapitał
własny** i **B. Zobowiązania i rezerwy na zobowiązania** (plus dwie
rzadkie pozycje C/D dla niektórych jednostek). Domyślne mapowanie kont
Numify:

| Pozycja                                       | Opis                                 | Konta Numify (tag `balanceSheetTag`)                                                                                                  |
| --------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| **A. Kapitał (fundusz) własny**               | Wkłady wspólników i zatrzymane zyski | Zespół 8                                                                                                                              |
| Kapitał podstawowy (A.I)                      |                                      | <AccountRef code="800" name="Kapitał zakładowy" />                                                                                    |
| Kapitał z aktualizacji wyceny (A.III)         |                                      | <AccountRef code="804" name="Kapitał z aktualizacji wyceny" />                                                                        |
| Kapitał zapasowy (A.IV)                       |                                      | <AccountRef code="801" name="Kapitał zapasowy" />                                                                                     |
| Pozostałe kapitały rezerwowe (A.V)            |                                      | <AccountRef code="802" name="Kapitał rezerwowy" />                                                                                    |
| Zysk/strata z lat ubiegłych (A.VII)           |                                      | <AccountRef code="820" />                                                                                                             |
| Zysk/strata netto (A.VIII)                    |                                      | <AccountRef code="860" name="Wynik finansowy" />                                                                                      |
| **B. Zobowiązania i rezerwy na zobowiązania** |                                      |                                                                                                                                       |
| Rezerwy (B.I)                                 |                                      | <AccountRef code="840" name="Rezerwy" />, <AccountRef code="845" name="Rezerwa na odroczony CIT" />                                   |
| Zobowiązania handlowe (B.III.1)               | Dostawcy                             | <AccountRef code="202" />                                                                                                             |
| Zobowiązania publicznoprawne (B.III.3g)       | VAT, CIT, ZUS                        | <AccountRef code="220" />, <AccountRef code="223" />, <AccountRef code="225" />, <AccountRef code="229" />, <AccountRef code="231" /> |
| Zobowiązania z tytułu wynagrodzeń (B.III.3h)  |                                      | <AccountRef code="230" />                                                                                                             |
| Fundusze specjalne (B.IV)                     | ZFŚS i in.                           | <AccountRef code="851" />, <AccountRef code="852" />                                                                                  |
| Rozliczenia międzyokresowe bierne             |                                      | <AccountRef code="642" />                                                                                                             |

> **Uwaga:** mapowania `balanceSheetTag` w planie kont Numify są
> dostosowane do struktury Załącznika 1 z uwzględnieniem znaczników
> JPK\_KR\_PD. Pełną listę tagów wraz z kodami PL/EN zawiera
> <ServiceRef path="src/db/seed-accounts.ts">src/db/seed-accounts.ts</ServiceRef>.

<LegalRef act="UoR" art="46" paragraph="3" /> nakazuje wykazywać
odpisy z wyniku finansowego bieżącego roku (np. dywidendy zaliczkowe)
ze znakiem ujemnym jako osobną pozycję pasywów "Odpisy z zysku netto
w ciągu roku obrotowego".

## Rachunek zysków i strat (RZiS) [#rachunek-zysków-i-strat-rzis]

<LegalRef act="UoR" art="47" paragraph="4" /> pkt 1 pozwala sp. z o.o.
wybrać **jeden z dwóch wariantów RZiS**:

### Wariant kalkulacyjny [#wariant-kalkulacyjny]

Koszty grupowane według typów działalności (zespół 5 - wydział
produkcyjny, dział handlowy, zarząd). Stosowany przez jednostki
produkcyjne z rozbudowaną kalkulacją kosztów wytworzenia.

Struktura skrócona:

```
Przychody netto ze sprzedaży produktów, towarów i materiałów
 - Koszt sprzedanych produktów, towarów, materiałów
 = Zysk ze sprzedaży
 - Koszty sprzedaży
 - Koszty ogólnego zarządu
 = Zysk z działalności operacyjnej
 + Pozostałe przychody/koszty operacyjne
 = Zysk z działalności gospodarczej
 + Przychody/koszty finansowe
 = Zysk brutto
 - Podatek dochodowy
 = Zysk netto
```

### Wariant porównawczy [#wariant-porównawczy]

Koszty grupowane według rodzaju (zespół 4 - zużycie materiałów, usługi
obce, wynagrodzenia, amortyzacja). Domyślny wybór dla większości
handlowych i usługowych sp. z o.o., bo pasuje bezpośrednio do planu
kont zespołu 4.

Struktura skrócona:

```
Przychody netto ze sprzedaży
 + Zmiana stanu produktów
 + Koszt wytworzenia produktów na potrzeby własne jednostki
 - Koszty działalności operacyjnej (zużycie materiałów, usługi obce,
    podatki i opłaty, wynagrodzenia, ZUS, amortyzacja, pozostałe)
 = Zysk ze sprzedaży
 (dalej identycznie jak w kalkulacyjnym)
```

> Numify domyślnie generuje wariant porównawczy - <ServiceRef path="src/lib/services/profit-loss.ts">profit-loss.ts</ServiceRef>.
> Mapowanie kont z zespołu 4/7 na pozycje RZiS - przez pole
> `pnlTag` w planie kont.

Wybór wariantu jest decyzją kierownika jednostki - zapisaną w
polityce rachunkowości (<LegalRef act="UoR" art="10" paragraph="1" />).
Raz przyjęty wariant stosuje się zasadniczo w kolejnych latach
(zasada ciągłości).

## Informacja dodatkowa - art. 48 [#informacja-dodatkowa---art-48]

<LegalRef act="UoR" art="48" /> nakłada obowiązek sporządzenia
**Informacji dodatkowej** - trzeciej obowiązkowej części sprawozdania
finansowego (obok bilansu i RZiS). Zawartość określa Załącznik 1,
punkt II.

Kluczowe bloki Informacji dodatkowej:

* Omówienie przyjętych zasad rachunkowości.
* Uzupełniające dane o aktywach i pasywach (ruchy ŚT, WNiP, rezerwy).
* Uzupełniające dane o przychodach i kosztach.
* Informacje o zmianach kapitału własnego.
* Zatrudnienie, wynagrodzenia zarządu, transakcje z członkami zarządu.
* Istotne zdarzenia po dacie bilansu.

Numify generuje szkielet Informacji dodatkowej na podstawie danych
spółki - implementacja:
<ServiceRef path="src/lib/services/informacja-dodatkowa.ts">informacja-dodatkowa.ts</ServiceRef>.
Tak jak w przypadku polityki rachunkowości, jest to **projekt
wymagający weryfikacji przez księgowego**.

## Terminy sporządzenia, zatwierdzenia, złożenia [#terminy-sporządzenia-zatwierdzenia-złożenia]

| Etap                    | Termin                                                    | Podstawa                        |
| ----------------------- | --------------------------------------------------------- | ------------------------------- |
| Sporządzenie SF         | 3 miesiące od końca roku obrotowego                       | <LegalRef act="UoR" art="52" /> |
| Zatwierdzenie przez ZZW | 6 miesięcy od końca roku obrotowego                       | <LegalRef act="UoR" art="53" /> |
| Złożenie w eKRS         | 15 dni od zatwierdzenia (<DeadlineBadge type="sf-krs" />) | <LegalRef act="UoR" art="69" /> |

Pełny kalendarz terminów - [Kalendarz terminów](/docs/zgodnosc-z-prawem/kalendarz-terminow).

## Format złożenia - e-sprawozdanie [#format-złożenia---e-sprawozdanie]

Od 2019 r. sprawozdanie finansowe sp. z o.o. składa się wyłącznie
elektronicznie w strukturze XSD opublikowanej przez MF:
**e-Sprawozdanie Finansowe** (eSF). Plik XML musi być podpisany
kwalifikowanym podpisem członka zarządu.

Numify generuje eSF w strukturze zgodnej ze schematem MF -
implementacja <ServiceRef path="src/lib/services/e-sprawozdanie.ts">e-sprawozdanie.ts</ServiceRef>.
Złożenie w eKRS wymaga zalogowania się w Portalu Rejestrów Sądowych -
jest to czynność ręczna, nie jest objęta automatyzacją w Numify.

## Powiązane moduły w Numify [#powiązane-moduły-w-numify]

| Dokument             | Ekran            | Serwis                                                                                           |
| -------------------- | ---------------- | ------------------------------------------------------------------------------------------------ |
| Bilans               | `/balance-sheet` | <ServiceRef path="src/lib/services/balance-sheet.ts">balance-sheet.ts</ServiceRef>               |
| RZiS                 | `/profit-loss`   | <ServiceRef path="src/lib/services/profit-loss.ts">profit-loss.ts</ServiceRef>                   |
| Informacja dodatkowa | `/reports`       | <ServiceRef path="src/lib/services/informacja-dodatkowa.ts">informacja-dodatkowa.ts</ServiceRef> |
| e-Sprawozdanie XML   | `/reports`       | <ServiceRef path="src/lib/services/e-sprawozdanie.ts">e-sprawozdanie.ts</ServiceRef>             |

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja - oparta na aktualnych tekstach art. 46, 47, 48, 50
    UoR (Dz.U. 2023 poz. 120) oraz na definicjach `balanceSheetTag` i
    `pnlTag` w `src/db/seed-accounts.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 20–21 UoR — Dowody księgowe
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-20-21-dowody-ksiegowe
Description: Trzy kategorie dowodów źródłowych (zewnętrzne obce, zewnętrzne własne, wewnętrzne), cztery kategorie dowodów własnych jednostki (zbiorcze, korygujące, zastępcze, rozliczeniowe), sześć obligatoryjnych elementów dowodu (art. 21 ust. 1), cztery wymogi dla ksiąg prowadzonych komputerowo (art. 20 ust. 5). Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Dowód księgowy** to podstawa każdego zapisu w księgach rachunkowych
(<LegalRef act="UoR" art="20" paragraph="2" />). Bez prawidłowego
dowodu źródłowego zapis w dzienniku jest pusty z punktu widzenia UoR —
nawet gdy technicznie został dokonany.

<ComplianceDisclaimer />

## Zasada — każde zdarzenie idzie do ksiąg [#zasada--każde-zdarzenie-idzie-do-ksiąg]

<LegalRef act="UoR" art="20" paragraph="1" />:

> Do ksiąg rachunkowych okresu sprawozdawczego należy wprowadzić, w
> postaci zapisu, każde zdarzenie, które nastąpiło w tym okresie
> sprawozdawczym.

**Każde zdarzenie** — nie próbki, nie wybrane, nie te powyżej
istotności. Zasada kompletności jest bezwzględna (granicą jest
definicja „zdarzenia gospodarczego", nie jego kwota).

## Trzy kategorie dowodów źródłowych — ust. 2 [#trzy-kategorie-dowodów-źródłowych--ust-2]

> Podstawą zapisów w księgach rachunkowych są dowody księgowe
> stwierdzające dokonanie operacji gospodarczej, zwane dalej
> „dowodami źródłowymi":
>
> 1. zewnętrzne obce — otrzymane od kontrahentów;
> 2. zewnętrzne własne — przekazywane w oryginale kontrahentom;
> 3. wewnętrzne — dotyczące operacji wewnątrz jednostki.

### Zewnętrzne obce [#zewnętrzne-obce]

Typowe przykłady:

* Faktura zakupowa otrzymana od dostawcy.
* Nota odsetkowa z banku.
* Polisa ubezpieczeniowa.
* Decyzja urzędu skarbowego o zwrocie VAT.

W Numify są to dokumenty wgrywane przez użytkownika do
[dokumentów](/docs/korzystanie-z-numify/dokumenty) (PDF / skan) oraz
faktury pobrane automatycznie z
[KSeF](/docs/korzystanie-z-numify/ksef) (XML FA(3)).

### Zewnętrzne własne [#zewnętrzne-własne]

Typowe przykłady:

* Faktura sprzedaży wystawiona nabywcy.
* Nota odsetkowa wysłana dłużnikowi.
* Nota korygująca.

W Numify generowane na ekranie
[faktur](/docs/korzystanie-z-numify/faktury) i wysyłane do
[KSeF](/docs/korzystanie-z-numify/ksef) jako faktury ustrukturyzowane.

### Wewnętrzne [#wewnętrzne]

Operacje bez zewnętrznego kontrahenta:

* Polecenie księgowania (PK) — przeksięgowanie między kontami.
* Protokoły inwentaryzacji.
* Rozchód materiału z magazynu na produkcję.
* Dokumenty naliczeń (lista płac, miesięczne odpisy amortyzacyjne).

W Numify: zapisy w dzienniku z `source = 'manual'` oraz automatyczne
polecenia księgowania (np. amortyzacja miesięczna generowana przez
[ewidencję środków trwałych](/docs/korzystanie-z-numify/fixed-assets)).

## Cztery kategorie dowodów własnych — ust. 3 [#cztery-kategorie-dowodów-własnych--ust-3]

> Podstawą zapisów mogą być również sporządzone przez jednostkę
> dowody księgowe:
>
> 1. zbiorcze — służące do dokonania łącznych zapisów zbioru dowodów źródłowych;
> 2. korygujące poprzednie zapisy;
> 3. zastępcze — wystawione do czasu otrzymania zewnętrznego obcego dowodu źródłowego;
> 4. rozliczeniowe — ujmujące już dokonane zapisy według nowych kryteriów klasyfikacyjnych.

| Kategoria         | Przykład                                        | Odpowiednik w Numify                                     |
| ----------------- | ----------------------------------------------- | -------------------------------------------------------- |
| **Zbiorczy**      | Jeden PK podsumowujący 50 paragonów             | Zapis z linkiem do wielu dokumentów źródłowych           |
| **Korygujący**    | Storno błędnie zaksięgowanej faktury            | Zapis z `source = 'manual'` odwracający poprzedni        |
| **Zastępczy**     | PK na czas oczekiwania na fakturę dostawcy      | Użycie wyjątkowe — wymaga zezwolenia kierownika (ust. 4) |
| **Rozliczeniowy** | Przeksięgowanie z konta kosztów ogólnych na MPK | Zapis typu „redeployment" między kontami                 |

### Uwaga dla dowodów zastępczych — ust. 4 [#uwaga-dla-dowodów-zastępczych--ust-4]

> W przypadku uzasadnionego braku możliwości uzyskania zewnętrznych
> obcych dowodów źródłowych, kierownik jednostki może zezwolić na
> udokumentowanie operacji gospodarczej za pomocą księgowych dowodów
> zastępczych, sporządzonych przez osoby dokonujące tych operacji.
> Nie może to jednak dotyczyć **operacji gospodarczych, których
> przedmiotem są zakupy opodatkowane podatkiem od towarów i usług**
> oraz skupu metali nieżelaznych od ludności.

Dla typowej sp. z o.o. istotne jest wyłączenie dla zakupów VAT —
**nie możesz zastąpić brakującej faktury zakupu PK**. Fakturę trzeba
uzyskać od dostawcy lub (w braku) potraktować koszt jako niemożliwy
do zaksięgowania.

## Sześć elementów dowodu — art. 21 ust. 1 [#sześć-elementów-dowodu--art-21-ust-1]

> Dowód księgowy powinien zawierać co najmniej:
>
> 1. określenie rodzaju dowodu i jego numeru identyfikacyjnego;
> 2. określenie stron (nazwy, adresy) dokonujących operacji gospodarczej;
> 3. opis operacji oraz jej wartość, jeżeli to możliwe, określoną także w jednostkach naturalnych;
> 4. datę dokonania operacji, a gdy dowód został sporządzony pod inną datą — także datę sporządzenia dowodu;
> 5. podpis wystawcy dowodu oraz osoby, której wydano lub od której przyjęto składniki aktywów;
> 6. stwierdzenie sprawdzenia i zakwalifikowania dowodu do ujęcia w księgach rachunkowych przez wskazanie miesiąca oraz sposobu ujęcia dowodu w księgach rachunkowych (dekretacja), podpis osoby odpowiedzialnej za te wskazania.

### Mapowanie na elementy faktury VAT [#mapowanie-na-elementy-faktury-vat]

Faktura VAT zgodna z <LegalRef act="VAT" art="106e" /> automatycznie
spełnia 5 z 6 elementów:

| Element art. 21 | Element faktury VAT                              |
| --------------- | ------------------------------------------------ |
| Rodzaj + numer  | „FAKTURA" + numer faktury                        |
| Strony          | Dane sprzedawcy + nabywcy (nazwa, NIP, adres)    |
| Opis + wartość  | Nazwa towaru/usługi, ilość, cena, kwota          |
| Data operacji   | Data dostawy/wykonania usługi + data wystawienia |
| Podpis          | Elektroniczny znacznik (ust. 4) lub KSeF         |
| Dekretacja      | **Dodawana przez księgową przy księgowaniu**     |

**Dekretacja** (pkt 6) to jedyny element, którego nie ma na fakturze —
powstaje w momencie zaksięgowania: wskazanie miesiąca, kont Wn/Ma i
podpisu osoby odpowiedzialnej. W Numify realizowane
automatycznie — każda pozycja w
[dzienniku](/docs/korzystanie-z-numify/journal) ma: `fiscalYear`,
`fiscalMonth`, linie z `accountCode` / `debitAmount` / `creditAmount`
oraz `createdBy` (ID użytkownika). To jest elektroniczny odpowiednik
dekretacji.

### Waluty obce — ust. 3 [#waluty-obce--ust-3]

> Dowód księgowy opiewający na waluty obce powinien zawierać
> przeliczenie ich wartości na walutę polską według kursu
> obowiązującego w dniu przeprowadzenia operacji gospodarczej. Wynik
> przeliczenia zamieszcza się bezpośrednio na dowodzie, chyba że
> system przetwarzania danych zapewnia automatyczne przeliczenie
> walut obcych na walutę polską.

W Numify **automatyczne przeliczenie** jest spełnione przez użycie
kursów NBP D−1 — zobacz
[Art. 30 UoR — kursy walut](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut).

### Tłumaczenie na żądanie — ust. 5 [#tłumaczenie-na-żądanie--ust-5]

> Na żądanie organów kontroli lub biegłego rewidenta należy zapewnić
> wiarygodne przetłumaczenie na język polski treści wskazanych przez
> nich dowodów, sporządzonych w języku obcym.

Obowiązek **warunkowy** (tylko na żądanie) i **ex post** (nie trzeba
tłumaczyć prewencyjnie każdej zagranicznej faktury). W praktyce
księgowa zostawia anglojęzyczną fakturę w oryginale i tłumaczy tylko
gdy poprosi inspektor US lub biegły.

## Cztery wymogi dla ksiąg komputerowych — art. 20 ust. 5 [#cztery-wymogi-dla-ksiąg-komputerowych--art-20-ust-5]

> Przy prowadzeniu ksiąg rachunkowych przy użyciu komputera za
> równoważne z dowodami źródłowymi uważa się zapisy w księgach
> rachunkowych, wprowadzane automatycznie za pośrednictwem urządzeń
> łączności, informatycznych nośników danych lub tworzone według
> algorytmu (programu) na podstawie informacji zawartych już w
> księgach, przy zapewnieniu, że podczas rejestrowania tych zapisów
> zostaną spełnione co najmniej następujące warunki:
>
> 1. uzyskają one trwale czytelną postać zgodną z treścią odpowiednich dowodów księgowych;
> 2. możliwe jest stwierdzenie źródła ich pochodzenia oraz ustalenie osoby odpowiedzialnej za ich wprowadzenie;
> 3. stosowana procedura zapewnia sprawdzenie poprawności przetworzenia odnośnych danych oraz kompletności i identyczności zapisów;
> 4. dane źródłowe w miejscu ich powstania są odpowiednio chronione, w sposób zapewniający ich niezmienność, przez okres wymagany do przechowywania danego rodzaju dowodów księgowych.

### Jak Numify spełnia każdy z czterech warunków [#jak-numify-spełnia-każdy-z-czterech-warunków]

| Warunek                          | Realizacja w Numify                                                                                                                                                                                                               |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **(1)** trwała czytelność        | Zapisy przechowywane jako dane strukturalne (PostgreSQL) + oryginał w R2; eksport do wydruku/PDF w każdym momencie; dane nigdy nie są kompresowane stratnie                                                                       |
| **(2)** źródło + osoba           | Każdy zapis ma `createdBy` (user UUID), `documentId` (link do dowodu źródłowego), `source` (np. `'ksef'`, `'manual'`, `'bank_import'`); pełna historia `createdAt` / `updatedAt`                                                  |
| **(3)** poprawność przetworzenia | Walidacja podwójnego zapisu (suma Wn = Ma) w `validateJournalBalance`; kontrola obrotów dziennika z ZOiS (<LegalRef act="UoR" art="14" paragraph="1" />); testy jednostkowe pokrywające krytyczne ścieżki                         |
| **(4)** ochrona przed zmianą     | Zasada braku usuwania (<LegalRef act="UoR" art="25" paragraph="1" />); soft delete + audit log; R2 z polityką niemutowalności; kopie zapasowe bazy; blokada ksiąg po `lockPeriod` (<LegalRef act="UoR" art="12" paragraph="5" />) |

## Realizacja w Numify — podsumowanie [#realizacja-w-numify--podsumowanie]

1. **Upload dokumentu** → dowód zewnętrzny obcy trafia do
   [dokumentów](/docs/korzystanie-z-numify/dokumenty) z oryginałem w R2.
2. **Parser AI** — rozpoznaje dane z dowodu i wyciąga transakcję
   (zobacz [document-detail](/docs/korzystanie-z-numify/document-detail)).
3. **Księgowanie** — zapis w [dzienniku](/docs/korzystanie-z-numify/journal)
   z linkiem do `documentId` (spełnia ust. 5 pkt 2 — źródło).
4. **Dekretacja** — automatyczna: `fiscalYear`, `fiscalMonth`, pary
   Wn/Ma na kontach, `createdBy` (pkt 6 art. 21).
5. **Przechowywanie** — 5 lat minimum, zobacz
   [Art. 73–74 UoR — archiwizacja](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-73-74-archiwizacja).

## Częste błędy [#częste-błędy]

* **Zaksięgowanie bez dowodu** — naruszenie ust. 2. Każdy zapis w
  dzienniku musi mieć oparcie w konkretnym dowodzie. Numify pozwala
  zapisać bez linku do `documentId` (np. w PK wewnętrznym), ale wymaga
  opisu operacji w polu `description`.
* **Dowód zastępczy na zakup VAT** — zakaz z ust. 4. W Numify brak
  faktury zakupu = brak KUP i brak VAT naliczonego do odliczenia.
* **Brak dekretacji** — faktura leżąca w teczce bez ujęcia w księgach
  nie jest zaksięgowana, nawet gdy jest poprawna. Tylko zapis w
  dzienniku finalizuje dekretację (pkt 6 art. 21).


---

# Art. 18 UoR — Zestawienie obrotów i sald
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-18-trial-balance
Description: Zestawienie obrotów i sald (ZOiS) — obowiązkowe miesięczne podsumowanie kont księgi głównej, zgodność z obrotami dziennika, zestawienie sald kont ksiąg pomocniczych na dzień zamknięcia ksiąg.
Review status: internal
Updated: 2026-04-16



<PolishTerm pl="Zestawienie obrotów i sald" en="Trial balance">Zestawienie
obrotów i sald</PolishTerm> (<PolishTerm pl="ZOiS" en="Trial balance">ZOiS</PolishTerm>)
to tabelaryczne podsumowanie stanu wszystkich kont księgi głównej na
dany moment. Jest punktem kontrolnym ksiąg — jeśli ZOiS się nie
zbilansuje, ksiegi są błędne.

<ComplianceDisclaimer />

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

> Na podstawie zapisów na kontach księgi głównej sporządza się na
> koniec każdego okresu sprawozdawczego, **nie rzadziej niż na koniec
> miesiąca**, zestawienie obrotów i sald, zawierające:
>
> 1. symbole lub nazwy kont;
> 2. salda kont na dzień otwarcia ksiąg rachunkowych, obroty za okres
>    sprawozdawczy i narastająco od początku roku obrotowego oraz salda
>    na koniec okresu sprawozdawczego;
> 3. sumę sald na dzień otwarcia ksiąg rachunkowych, obrotów za okres
>    sprawozdawczy i narastająco od początku roku obrotowego oraz sald
>    na koniec okresu sprawozdawczego.
>
> Obroty tego zestawienia powinny być zgodne z obrotami dziennika lub
> obrotami zestawienia obrotów dzienników częściowych.

Trzy kluczowe wymogi:

### 1. Częstotliwość — co najmniej miesięcznie [#1-częstotliwość--co-najmniej-miesięcznie]

ZOiS musi być sporządzane **co najmniej na koniec każdego miesiąca**.
Słowo „co najmniej" pozwala sporządzać je częściej (np. tygodniowo dla
celów kontrolnych), ale nie pozwala robić rzadziej (np. tylko
kwartalnie).

### 2. Obowiązkowa zawartość [#2-obowiązkowa-zawartość]

ZOiS musi zawierać dla każdego konta:

| Kolumna               | Opis                                              |
| --------------------- | ------------------------------------------------- |
| Symbol / nazwa konta  | Kod z planu kont (np. 202) i jego nazwa           |
| Saldo BO              | Saldo na dzień otwarcia ksiąg (początek roku)     |
| Obroty miesiąca Dt    | Suma debetów w danym miesiącu                     |
| Obroty miesiąca Ct    | Suma kredytów w danym miesiącu                    |
| Obroty narastająco Dt | Suma debetów od początku roku                     |
| Obroty narastająco Ct | Suma kredytów od początku roku                    |
| Saldo BZ Dt           | Saldo końcowe po stronie debetu (jeśli dodatnie)  |
| Saldo BZ Ct           | Saldo końcowe po stronie kredytu (jeśli dodatnie) |

Konto może mieć saldo BZ tylko po jednej stronie w danym momencie —
salda debetowe i kredytowe są wykluczające.

### 3. Zgodność z dziennikiem [#3-zgodność-z-dziennikiem]

Obroty dziennika (suma kolejnych zapisów) muszą być równe obrotom
ZOiS (suma Dt wszystkich kont = suma Ct wszystkich kont = suma obrotów
dziennika). Jest to **kontrola dziennikowa** — podstawowy test
spójności wynikający z podwójnego zapisu (<LegalRef act="UoR" art="15" />).

## Zestawienie sald kont ksiąg pomocniczych — art. 18 ust. 2 [#zestawienie-sald-kont-ksiąg-pomocniczych--art-18-ust-2]

> Co najmniej na dzień zamknięcia ksiąg rachunkowych sporządza się
> zestawienia sald wszystkich kont ksiąg pomocniczych, a na dzień
> inwentaryzacji — zestawienia sald inwentaryzowanej grupy składników
> aktywów.

Dwa dodatkowe zestawienia:

1. **Na dzień zamknięcia ksiąg** (koniec roku obrotowego, z reguły
   31 grudnia) — zestawienie sald **wszystkich** kont ksiąg
   pomocniczych. Ma za zadanie pokazać stan analityki odpowiadający
   stanom syntetycznym z bilansu.
2. **Na dzień inwentaryzacji** — zestawienie sald konkretnej
   inwentaryzowanej grupy (np. środków trwałych), żeby móc porównać
   z rzeczywistym stanem (inwentaryzacja jest z kolei regulowana
   <LegalRef act="UoR" art="26" /> – <LegalRef act="UoR" art="27" />).

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

### Generowanie ZOiS [#generowanie-zois]

Funkcja `generateTrialBalance` w
<ServiceRef path="src/lib/services/trial-balance.ts">trial-balance.ts</ServiceRef>
realizuje wymogi art. 18 ust. 1:

1. Pobiera wszystkie aktywne konta z `chart_accounts`.
2. Liczy salda otwarcia (obroty przed `startDate`).
3. Liczy obroty okresu (debet i kredyt między `startDate` i `endDate`).
4. Buduje saldo BZ = BO + obroty Dt – obroty Ct, rozdzielone na stronę
   debetową i kredytową.
5. Sumuje totals i sprawdza `isBalanced`:
   ```
   totals.periodDebit === totals.periodCredit
   && totals.openingDebit === totals.openingCredit
   && totals.closingDebit === totals.closingCredit
   ```

Jeśli `isBalanced = false`, aplikacja sygnalizuje rozjazd — to błąd
ksiąg wymagający interwencji (najczęściej konsekwencja ręcznej
modyfikacji bazy, co jest zabronione przez
<LegalRef act="UoR" art="25" />).

### Widok `/trial-balance` [#widok-trial-balance]

Ekran `/trial-balance` pokazuje ZOiS za wybrany okres (miesiąc /
kwartał / rok). Można:

* Zmienić zakres dat.
* Wyeksportować do PDF / XLSX (endpoint
  `/api/financial-reports/export/trial-balance`).
* Drillnąć z pozycji konta do jego księgi (ekran `/general-ledger`).

### Zestawienie sald kont ksiąg pomocniczych (ust. 2) [#zestawienie-sald-kont-ksiąg-pomocniczych-ust-2]

Dla kontrahentów — `getContractorLedgerSummary` w
<ServiceRef path="src/lib/services/subsidiary-ledger.ts">subsidiary-ledger.ts</ServiceRef>
daje listę sald per kontrahent. Dla środków trwałych — per karta
(`getFixedAssetLedger`). Oba są wymagane na dzień zamknięcia ksiąg
rocznych.

Zamknięcie roku w Numify (ekran `/fiscal-periods`) generuje zapis
przeksięgowań rocznych (<AccountRef code="860" /> → kapitały), blokuje
wszystkie 12 okresów miesięcznych oraz tworzy **bilans otwarcia**
kolejnego roku — wymogi <LegalRef act="UoR" art="12" /> (otwarcie ksiąg
i kontynuacja BO). Implementacja w
<ServiceRef path="src/lib/services/year-end-close.ts">year-end-close.ts</ServiceRef>
oraz <ServiceRef path="src/lib/services/opening-balance.ts">opening-balance.ts</ServiceRef>.

## Częste błędy [#częste-błędy]

* **„Moja suma Dt ≠ Ct"** — najczęściej oznacza ręczną zmianę w bazie,
  pominięcie wiersza przy imporcie, albo storno, które nie zostało
  skompletowane. Każdy zapis w dzienniku musi być samoważący.
* **„ZOiS nie zgadza się z bilansem"** — prawie zawsze błąd w
  znacznikach `balanceSheetTag` na kontach (zespół 0 Środki trwałe
  musi być zmapowany na `AKT_A_II`, amortyzacja skumulowana 070 na
  ten sam tag po stronie ujemnej itd.).
* **„ZOiS się zgadza co do grosza, ale raport mówi że nie"** — błąd
  zaokrągleń przy walutach obcych. Numify przechowuje wszystko w
  groszach (integer), ale jeśli ktoś zaimportował dane z systemu
  przechowującego w `decimal`, mogą być rozjazdy ±1 grosz per wiersz.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnym tekście art. 18 UoR (Dz.U.
    2023 poz. 120) oraz implementacji `generateTrialBalance` i
    `getContractorLedgerSummary` w `src/lib/services/`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 47 UoR — Rachunek zysków i strat
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-47-rzis
Description: RZiS — dwa warianty (porównawczy, kalkulacyjny) do wyboru przez kierownika jednostki, dane porównawcze za bieżący i poprzedni rok obrotowy, działalność kontynuowana i zaniechana, wzory w załącznikach 1 i 5. Struktura wyniku — operacyjny, pozostałe, finansowy, brutto, netto. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Rachunek zysków i strat** (dalej: RZiS) to drugi obligatoryjny
element SF (zobacz [art. 45 ust. 2](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-45-sprawozdanie-finansowe)).
Podczas gdy bilans pokazuje **stan** majątku na dzień bilansowy, RZiS
pokazuje **wynik** — jak jednostka doszła do zysku / straty w ciągu
roku obrotowego. <LegalRef act="UoR" art="47" /> określa zasady
prezentacji oraz dopuszcza **wybór** między dwoma wariantami.

<ComplianceDisclaimer />

## Oddzielne wykazanie przychodów i kosztów — ust. 1 i 2 [#oddzielne-wykazanie-przychodów-i-kosztów--ust-1-i-2]

> 1. W rachunku zysków i strat wykazuje się oddzielnie przychody,
>    koszty, zyski i straty oraz obowiązkowe obciążenia wyniku
>    finansowego za bieżący i poprzedni rok obrotowy.
>
> 2. W przypadku sporządzania rachunku zysków i strat za inny okres
>    sprawozdawczy niż określony w ust. 1, w rachunku zysków i strat
>    wykazuje się oddzielnie przychody, koszty, zyski i straty oraz
>    obowiązkowe obciążenia wyniku finansowego za bieżący okres
>    sprawozdawczy oraz analogiczny okres sprawozdawczy poprzedniego
>    roku obrotowego.

Konsekwencje praktyczne:

* **Zakaz netowania** — nie wolno prezentować wyniku jednej pozycji
  jako różnicy przychodów i kosztów. Np. przychody ze sprzedaży
  wykazuje się pełną kwotą, koszty własne sprzedaży pełną kwotą —
  **nie** kwotę netto.
* **Dwie kolumny** — bieżący i poprzedni rok obrotowy (lub analogiczny
  okres poprzedniego roku, jeśli RZiS jest śródroczny). Kolumna
  porównawcza musi zgadzać się z zatwierdzonym RZiS poprzedniego
  okresu.
* **Obowiązkowe obciążenia wyniku** — prezentowane w odrębnej pozycji
  (typowo „Podatek dochodowy"). Obciążenia to nie tylko CIT — również
  inne obciążenia ustawowe wyniku (np. wpłaty na PFRON w części
  obciążającej wynik, jeśli przepisy tak stanowią).

## Działalność zaniechana — ust. 3 [#działalność-zaniechana--ust-3]

> W przypadku gdy jednostka przewiduje zaprzestanie określonego
> zakresu działalności mającego wpływ na przychody i koszty przyszłych
> okresów sprawozdawczych, przy zachowaniu zasady kontynuacji —
> odpowiednie przychody i koszty z tym związane należy wykazać
> odrębnie od przychodów i kosztów działalności kontynuowanej.

Zasada: jeżeli jednostka **kontynuuje** działalność jako całość, ale
**zamyka jeden segment** (np. sklep stacjonarny, linia produktów,
oddział regionalny) — przychody i koszty **zaniechanej** części
prezentuje się osobno, aby użytkownik SF mógł ocenić **prawdziwą
zdolność zarobkową** działalności kontynuowanej.

Dla typowej sp. z o.o. to rzadki przypadek. Jeżeli wystąpi, Numify
pozwala oznaczyć wybrane konta analityczne / wymiary jako `segmentStatus = 'discontinued'`, co przekłada się na osobną prezentację w RZiS.

## Dwa warianty — ust. 4 pkt 1 [#dwa-warianty--ust-4-pkt-1]

> RZiS powinien zawierać informacje w zakresie ustalonym dla
> jednostek innych niż banki, zakłady ubezpieczeń i zakłady
> reasekuracji — w załączniku nr 1 do ustawy, **w wariancie
> kalkulacyjnym albo porównawczym, zależnie od wyboru dokonanego
> przez kierownika jednostki**.

Jednostki małe — załącznik 5 — również mają wybór wariantu (ust. 4
pkt 5).

### Różnice między wariantami [#różnice-między-wariantami]

| Cecha                              | Wariant porównawczy                                                                                                    | Wariant kalkulacyjny                                                            |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Koszty prezentowane według         | **rodzajów** (zespoły 4: amortyzacja, zużycie materiałów, usługi obce, podatki, wynagrodzenia, świadczenia, pozostałe) | **funkcji** (koszt własny sprzedaży, koszty sprzedaży, koszty ogólnego zarządu) |
| Wymaga ewidencji kosztów w zespole | 4                                                                                                                      | 5 (z możliwością rozliczania przez zespół 4 na konto 490)                       |
| Typowy przypadek                   | małe sp. z o.o. bez produkcji                                                                                          | jednostki produkcyjne, handlowe z wyraźnym kosztem własnym                      |
| Pozycja „Zmiana stanu produktów"   | tak — koryguje koszty rodzajowe o zmianę zapasów wyrobów                                                               | nie — koszty są już przypisane do funkcji                                       |

Wybór wariantu należy do **kierownika jednostki** (w sp. z o.o. —
zarząd) i **musi** być zapisany w polityce rachunkowości
(<LegalRef act="UoR" art="10" paragraph="1" />). Zmiana wariantu w
trakcie roku obrotowego — co do zasady niedopuszczalna.

### Dlaczego wybrać porównawczy [#dlaczego-wybrać-porównawczy]

Wariant porównawczy jest **prostszy technicznie** — wystarczy
ewidencja kosztów w zespole 4. Dla typowej sp. z o.o. usługowej,
doradczej, programistycznej — w której nie ma produkcji ani wyraźnego
kosztu własnego sprzedaży — jest to **domyślny i rekomendowany wybór**.

Numify domyślnie generuje RZiS **w wariancie porównawczym**.
Wariant kalkulacyjny jest dostępny, ale wymaga:

* ewidencji kosztów w zespole 5 (500, 501, 521, 531, 540, 550),
* mapowania kont zespołu 5 na funkcje (koszt wytworzenia,
  koszt sprzedaży, koszt ogólnego zarządu),
* uruchomienia w polityce rachunkowości (`profitLossVariant = 'calc'`).

## Struktura wyniku finansowego — art. 42 [#struktura-wyniku-finansowego--art-42]

<LegalRef act="UoR" art="42" paragraph="1" /> określa formułę
ustalania wyniku — powielaną w obu wariantach RZiS:

```
Wynik z działalności operacyjnej
  + Wynik z pozostałej działalności operacyjnej
  + Wynik z operacji finansowych
  = Zysk / strata brutto
  − Obowiązkowe obciążenia wyniku (podatek dochodowy)
  = Zysk / strata netto
```

### Trzy poziomy wyniku [#trzy-poziomy-wyniku]

| Poziom                               | Treść                                                                                                                                 | Typowe konta źródłowe       |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- |
| **Działalność operacyjna**           | przychody i koszty z podstawowej działalności — sprzedaż towarów, produktów, usług, koszty je wytwarzające                            | 700, 730, 740, 400–409, 500 |
| **Pozostała działalność operacyjna** | zysk / strata ze sprzedaży środków trwałych, odpisy aktualizujące, kary, odszkodowania, darowizny otrzymane, różnice inwentaryzacyjne | 760, 761, 765, 766          |
| **Operacje finansowe**               | odsetki, różnice kursowe, dywidendy otrzymane, prowizje od kredytów, straty ze zbycia aktywów finansowych                             | 750, 751, 755               |

Po zsumowaniu trzech poziomów powstaje **zysk / strata brutto**.
Po odjęciu **obowiązkowych obciążeń** (w praktyce głównie podatek
dochodowy CIT — zobacz [korzystanie/cit-data](/docs/korzystanie-z-numify/cit-data)) — **zysk / strata netto**.

### Ważne: wynik netto z RZiS = wynik netto w bilansie [#ważne-wynik-netto-z-rzis--wynik-netto-w-bilansie]

Wynik netto wykazany w RZiS **musi być identyczny** z pozycją
„Zysk / strata netto" w bilansie (pozycja A.VI kapitału własnego —
zobacz [art. 46](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-46-bilans)).
Tożsamość tych dwóch kwot jest **testem spójności SF** — rozjazd
oznacza błąd w mapowaniu lub w ewidencji.

## Wzory RZiS — załącznik 1 i 5 [#wzory-rzis--załącznik-1-i-5]

### Wariant porównawczy (załącznik 1, uproszczony) [#wariant-porównawczy-załącznik-1-uproszczony]

| Pozycja | Tytuł                                                |
| ------- | ---------------------------------------------------- |
| A       | Przychody netto ze sprzedaży i zrównane z nimi       |
| B       | Koszty działalności operacyjnej (rodzajowe)          |
| B.I     | Amortyzacja                                          |
| B.II    | Zużycie materiałów i energii                         |
| B.III   | Usługi obce                                          |
| B.IV    | Podatki i opłaty                                     |
| B.V     | Wynagrodzenia                                        |
| B.VI    | Ubezpieczenia społeczne i inne świadczenia           |
| B.VII   | Pozostałe koszty rodzajowe                           |
| B.VIII  | Wartość sprzedanych towarów i materiałów             |
| C       | Zysk / strata ze sprzedaży (A − B)                   |
| D       | Pozostałe przychody operacyjne                       |
| E       | Pozostałe koszty operacyjne                          |
| F       | Zysk / strata z działalności operacyjnej (C + D − E) |
| G       | Przychody finansowe                                  |
| H       | Koszty finansowe                                     |
| I       | Zysk / strata brutto (F + G − H)                     |
| J       | Podatek dochodowy                                    |
| K       | Zysk / strata netto (I − J)                          |

### Wariant kalkulacyjny (załącznik 1, uproszczony) [#wariant-kalkulacyjny-załącznik-1-uproszczony]

| Pozycja | Tytuł                                                        |
| ------- | ------------------------------------------------------------ |
| A       | Przychody netto ze sprzedaży produktów, towarów i materiałów |
| B       | Koszty sprzedanych produktów, towarów i materiałów           |
| C       | Zysk / strata brutto ze sprzedaży (A − B)                    |
| D       | Koszty sprzedaży                                             |
| E       | Koszty ogólnego zarządu                                      |
| F       | Zysk / strata ze sprzedaży (C − D − E)                       |
| G       | Pozostałe przychody operacyjne                               |
| H       | Pozostałe koszty operacyjne                                  |
| I       | Zysk / strata z działalności operacyjnej (F + G − H)         |
| J       | Przychody finansowe                                          |
| K       | Koszty finansowe                                             |
| L       | Zysk / strata brutto (I + J − K)                             |
| M       | Podatek dochodowy                                            |
| N       | Zysk / strata netto (L − M)                                  |

W obu wariantach pozycja „Zysk / strata brutto ze sprzedaży" lub
„Zysk / strata ze sprzedaży" — w zależności od szczegółowej numeracji
załącznika — jest często nazywana **marżą**. Analiza marży w czasie
wymaga spójnego wariantu między latami.

## Realizacja w Numify [#realizacja-w-numify]

| Krok                           | Funkcja Numify                                                                    | Efekt                                                |
| ------------------------------ | --------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Ewidencja kosztów rodzajowych  | dekretacja faktur zakupu na konta zespołu 4                                       | koszty w układzie rodzajowym                         |
| Mapowanie kont na pozycje RZiS | plan-kont (flaga `plPosition`)                                                    | każde konto wynikowe ma przypisaną pozycję A–K / A–N |
| Generowanie RZiS               | [profit-loss](/docs/korzystanie-z-numify/profit-loss)                             | agregacja obrotów kont wynikowych                    |
| Wybór wariantu                 | polityka rachunkowości (`profitLossVariant`)                                      | `comparative` (domyślnie) lub `calc`                 |
| Dane porównawcze               | [profit-loss](/docs/korzystanie-z-numify/profit-loss) — kolumna „poprzedni okres" | z zamkniętego poprzedniego roku                      |
| Eksport XML                    | [exports](/docs/korzystanie-z-numify/exports)                                     | RZiS wbudowany w e-Sprawozdanie                      |

### Uczciwe framing — stan implementacji [#uczciwe-framing--stan-implementacji]

* **Wariant porównawczy** — w pełni wspierany, domyślny.
* **Wariant kalkulacyjny** — wspierany technicznie (flagowanie pozycji
  w planie kont), ale wymaga pracy konfiguracyjnej: konfiguracja
  kont zespołu 5, polityka rozliczania przez 490, mapowanie na
  pozycje A–N. Rekomendowany workflow — ustalić z księgowym przed
  rozpoczęciem roku obrotowego.
* **Działalność zaniechana** (ust. 3) — osobna prezentacja jest
  **zaplanowana**; obecnie wymaga ręcznej korekty eksportowanego XML.

## Częste błędy [#częste-błędy]

* **Netowanie przychodów i kosztów** — narusza ust. 1.
* **Zmiana wariantu RZiS w trakcie roku** — wariant raz wybrany
  obowiązuje do końca roku; zmiana wymaga dostosowania polityki
  rachunkowości na kolejny rok.
* **Wynik netto z RZiS ≠ wynik netto w bilansie** — typowo błąd w
  mapowaniu konta 860 lub pominięcie podatku odroczonego.
* **Podatek dochodowy na podstawie CIT-8 zamiast zapisu księgowego** —
  kwota CIT w RZiS musi wynikać z zaksięgowanej operacji, nie z
  zeznania podatkowego (które może się różnić przez odroczenia).
* **Ujęcie wyniku ze sprzedaży środków trwałych w przychodach ze
  sprzedaży** — powinien być w pozostałych przychodach operacyjnych
  (pozycja D w wariancie porównawczym).
* **Różnice kursowe w przychodach operacyjnych** — powinny być w
  przychodach / kosztach finansowych (pozycje G / H).
* **Pominięcie „Zmiany stanu produktów"** w wariancie porównawczym
  przy ewidencji wyrobów gotowych — zafałszowuje wynik ze sprzedaży.

## Checklist — sporządzenie RZiS [#checklist--sporządzenie-rzis]

* [ ] Wariant RZiS zgodny z polityką rachunkowości jednostki.
* [ ] Wszystkie faktury sprzedaży roku zaksięgowane.
* [ ] Wszystkie faktury zakupu roku zaksięgowane i dekretowane.
* [ ] Amortyzacja grudniowa wygenerowana (<LegalRef act="UoR" art="32" />).
* [ ] Różnice kursowe z konta 751 / 755 naliczone.
* [ ] Odpisy aktualizujące zaksięgowane.
* [ ] Rezerwy na zobowiązania utworzone / rozwiązane.
* [ ] Obliczenie i zaksięgowanie CIT (bieżący + odroczony).
* [ ] RZiS wygenerowany — kolumna bieżąca + porównawcza.
* [ ] Wynik netto RZiS = wynik netto w bilansie (pozycja A.VI).
* [ ] Kolumna porównawcza zgodna z zatwierdzonym RZiS poprzedniego roku.


---

# Art. 73–74 UoR — Archiwizacja
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-73-74-archiwizacja
Description: Oryginalna postać dowodów księgowych i dokumentów inwentaryzacyjnych (art. 73 ust. 1), przeniesienie treści na informatyczne nośniki danych (art. 73 ust. 2), okresy przechowywania — 5 lat dla ksiąg i dowodów (art. 74 ust. 2), 5 lat dla zatwierdzonego sprawozdania finansowego (art. 74 ust. 1). Obliczanie okresu od początku roku następującego. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Archiwizacja dokumentów księgowych** jest obowiązkiem sp. z o.o.
przez **co najmniej 5 lat** — <LegalRef act="UoR" art="73" />
definiuje **sposób** przechowywania (oryginał, nośniki elektroniczne),
<LegalRef act="UoR" art="74" /> precyzuje **okresy** dla każdego typu
dokumentu. Dodatkowo Ordynacja podatkowa (art. 86) może wydłużyć
okres przechowywania dla dokumentów związanych z przedawnieniem
podatku.

<ComplianceDisclaimer />

## Sposób przechowywania — art. 73 ust. 1 [#sposób-przechowywania--art-73-ust-1]

> Dowody księgowe i dokumenty inwentaryzacyjne przechowuje się w
> jednostce, z zastrzeżeniem ust. 4, w **oryginalnej postaci**, w
> ustalonym porządku dostosowanym do sposobu prowadzenia ksiąg
> rachunkowych, w podziale na okresy sprawozdawcze, w sposób
> pozwalający na ich łatwe odszukanie.

Cztery wymogi:

1. **Oryginalna postać** — dowód w takiej postaci, w jakiej został
   otrzymany lub sporządzony. Dla faktury papierowej: papier. Dla
   faktury elektronicznej: plik elektroniczny + metadane podpisu.
2. **W ustalonym porządku** — systematycznie, nie „na kupie".
3. **Podział na okresy sprawozdawcze** — typowo roczne zbiory.
4. **Łatwe odszukanie** — indeks, numeracja, opisowe nazwy plików.

### „W jednostce" vs outsourcing [#w-jednostce-vs-outsourcing]

Ust. 4 dopuszcza przechowywanie **poza jednostką**:

* U świadczącego usługi przechowywania dokumentów (np. archiwa komercyjne).
* W biurze rachunkowym (wymóg informacyjny do US).

Przechowywanie w **chmurze** (Cloudflare R2, AWS S3, Azure) mieści
się w ust. 4 — jeśli usługodawca spełnia wymogi UoR i RODO, a spółka
ma dostęp do odtworzenia dokumentów na żądanie.

## Przeniesienie na nośniki elektroniczne — art. 73 ust. 2 [#przeniesienie-na-nośniki-elektroniczne--art-73-ust-2]

> Z wyłączeniem dokumentów dotyczących **przeniesienia praw majątkowych
> do nieruchomości**, **powierzenia odpowiedzialności za składniki
> aktywów**, **znaczących umów** i **innych ważnych dokumentów
> określonych przez kierownika jednostki**, treść dowodów księgowych
> może być przeniesiona na informatyczne nośniki danych pozwalające
> zachować w trwałej i niezmienionej postaci zawartość dowodów.
> Warunkiem stosowania tej metody przechowywania danych jest
> **posiadanie urządzeń pozwalających na odtworzenie dowodów w
> postaci wydruku**, o ile inne przepisy nie stanowią inaczej.
> Wydruk jest dowodem równoważnym z dowodem księgowym, z którego
> treść została przeniesiona na informatyczny nośnik danych.

### Trzy warunki digitalizacji [#trzy-warunki-digitalizacji]

1. **Trwałość i niezmienność** — nośnik musi chronić przed
   modyfikacją (R2 z polityką write-once, hash SHA-256 przy uploadzie).
2. **Odtwarzalność do wydruku** — system musi umożliwiać wygenerowanie
   czytelnego wydruku (PDF z iframe w Numify + eksport metadanych).
3. **Dokument nie na liście wyłączeń**.

### Dokumenty wyłączone z digitalizacji — muszą pozostać na papierze [#dokumenty-wyłączone-z-digitalizacji--muszą-pozostać-na-papierze]

* **Akt notarialny** przeniesienia własności nieruchomości.
* **Protokół powierzenia odpowiedzialności materialnej** (np. inwentaryzacja z podpisem odpowiedzialnego).
* **Znaczące umowy** — zakres określa kierownik jednostki w
  polityce rachunkowości.
* **Inne ważne dokumenty** — pozostawione uznaniu kierownika.

Dla typowej sp. z o.o. prowadzącej działalność usługową lista
wyłączeń jest krótka. Kluczowe są:

* Umowa spółki (akt notarialny).
* Akt nabycia nieruchomości (jeśli występuje).
* Umowy handlowe dużej wagi (np. długoterminowy kontrakt strategiczny).

Te dokumenty przechowuje się w oryginale (papier + skan jako
kopia operacyjna, nie zastępująca oryginału).

## Sprawozdania finansowe i polityka — art. 73 ust. 3 [#sprawozdania-finansowe-i-polityka--art-73-ust-3]

> **Po zatwierdzeniu sprawozdania finansowego** za dany rok
> obrotowy, dokumentację przyjętych zasad rachunkowości, księgi
> rachunkowe oraz sprawozdania finansowe, w tym również sprawozdanie
> z działalności jednostki, przechowuje się odpowiednio w sposób
> określony w ust. 1.

Kluczowy moment: **zatwierdzenie SF** przez zgromadzenie wspólników.
Po nim dokumentacja wchodzi w reżim archiwalny. Wcześniej jest
traktowana jako robocza (zmienialna).

## Okresy przechowywania — art. 74 [#okresy-przechowywania--art-74]

### Sprawozdanie finansowe — ust. 1 [#sprawozdanie-finansowe--ust-1]

> Zatwierdzone roczne sprawozdania finansowe, odmowa podpisu, o
> której mowa w art. 52 ust. 2, oraz oświadczenie lub odmowa
> złożenia oświadczenia, o których mowa w art. 52 ust. 2b, jeżeli
> zostały sporządzone, podlegają przechowywaniu przez okres **co
> najmniej 5 lat**, licząc od początku roku następującego po roku
> obrotowym, w którym zatwierdzono sprawozdanie finansowe.

Dla sp. z o.o. z rokiem obrotowym = kalendarzowym:

* SF za rok 2026, zatwierdzone czerwiec 2027 → przechowywane &#x2A;*do końca 2032 r.**
* SF za rok 2026, zatwierdzone styczeń 2028 (spóźnienie) → przechowywane &#x2A;*do końca 2033 r.**

Liczenie od **roku zatwierdzenia**, nie roku obrotowego — przesunięcie
zatwierdzenia wydłuża okres.

### Pozostałe zbiory — ust. 2 [#pozostałe-zbiory--ust-2]

| Pkt | Typ zbioru                                                                           | Okres                                                                                    |
| --- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| 1   | Księgi rachunkowe                                                                    | **5 lat**                                                                                |
| 2   | Karty wynagrodzeń                                                                    | Nie krócej niż **5 lat**, nie krócej niż wymagają przepisy emerytalne / podatkowe        |
| 3   | Dowody sprzedaży detalicznej                                                         | Do zatwierdzenia SF, **nie krócej niż rozliczenie osób odpowiedzialnych**                |
| 4   | Dowody środków trwałych w budowie / pożyczek / kredytów / umów handlowych / roszczeń | **5 lat** od końca roku, w którym operacja została zakończona, spłacona lub przedawniona |
| 5   | Dokumentacja polityki rachunkowości                                                  | **Nie krócej niż 5 lat** od upływu ważności                                              |
| 6   | Dokumenty rękojmi i reklamacji                                                       | **1 rok** po terminie rękojmi / rozliczeniu reklamacji                                   |
| 7   | Dokumenty inwentaryzacyjne                                                           | **5 lat**                                                                                |
| 8   | Pozostałe dowody księgowe i sprawozdania                                             | **5 lat**                                                                                |

### Obliczanie okresu — ust. 3 [#obliczanie-okresu--ust-3]

> Okresy przechowywania ustalone w ust. 2 oblicza się od **początku
> roku następującego po roku obrotowym**, którego dane zbiory
> dotyczą.

Przykład dla pkt 8 (5 lat, „pozostałe dowody"):

* Faktura z &#x2A;*marca 2026 r.** (rok obrotowy 2026).
* Licząc od &#x2A;*początku 2027 r.** (rok następujący po roku obrotowym).
* Okres 5 lat → do &#x2A;*końca 2031 r.**

**Uwaga**: to różni się od liczenia w Ordynacji podatkowej (OrdPod
art. 86 + art. 70 — od końca roku kalendarzowego, w którym upłynął
termin płatności podatku). Dla bezpieczeństwa: przyjmuj dłuższy
okres z obu systemów prawnych.

## Dłuższe okresy z OrdPod — art. 86 i 70 [#dłuższe-okresy-z-ordpod--art-86-i-70]

Ordynacja podatkowa wydłuża okres dla dokumentów związanych z
przedawnieniem zobowiązania podatkowego. Zobowiązanie podatkowe
przedawnia się **z upływem 5 lat**, licząc od końca roku kalendarzowego,
w którym upłynął termin płatności podatku (<LegalRef act="OrdPod" art="70" paragraph="1" />).

Przykład dla VAT i CIT:

* **VAT za marzec 2026** — termin płatności 25 kwietnia 2026 r.
* Przedawnienie: &#x2A;*5 lat od końca 2026 r.** → do końca 2031 r.
* Dla CIT-8 za 2026 r.: termin płatności 31 marca 2027 r. → przedawnienie do końca &#x2A;*2032 r.**

Dokumenty związane z tymi zobowiązaniami (faktury, JPK, dziennik)
podlegają wydłużonemu przechowywaniu **do czasu przedawnienia**.

**Zawieszenie biegu przedawnienia** (art. 70 § 6 OrdPod) — wydanie
decyzji ostatecznej, wszczęcie postępowania karnego skarbowego,
doręczenie zawiadomienia o zawieszeniu — może przedłużyć okres do
kilkunastu lat.

**Praktyczna reguła**: przechowuj dokumenty księgowe **przez 10 lat**,
nawet jeśli UoR wymaga 5 — dla bezpieczeństwa wobec ewentualnych
kontroli i postępowań.

## Realizacja w Numify [#realizacja-w-numify]

### Oryginał w R2 [#oryginał-w-r2]

Każdy dokument wgrany do [korzystanie/dokumenty](/docs/korzystanie-z-numify/dokumenty)
trafia do **Cloudflare R2** jako obiekt **niemutowalny**:

* Hash SHA-256 zapisany w bazie przy uploadzie.
* Polityka R2 blokująca nadpisanie (`if-none-match`).
* Kopie zapasowe bazy i R2 w osobnym regionie (geo-redundancja).

Wydruk / PDF jest zawsze dostępny przez przycisk „Open Original" w
[korzystanie/document-detail](/docs/korzystanie-z-numify/document-detail)
— spełnia warunek „urządzenia pozwalające na odtworzenie dowodów"
(<LegalRef act="UoR" art="73" paragraph="2" />).

### Faktury KSeF [#faktury-ksef]

Faktury pobrane z [KSeF](/docs/korzystanie-z-numify/ksef) są
archiwizowane jako &#x2A;*XML FA(3)** — oryginalna postać w rozumieniu
art. 73 ust. 1. System KSeF sam przechowuje faktury **przez 10 lat**
od końca roku wystawienia, co jest niezależnym źródłem archiwizacji.

### Retencja soft-delete [#retencja-soft-delete]

`src/lib/services/backup-retention.ts` zarządza polityką backupu i
zapewnia:

* **Soft delete** — usunięcie rekordu z UI nie usuwa obiektu R2 od razu.
* **Retencja domyślna 10 lat** — dłuższa niż 5-letni wymóg UoR, spójna
  z możliwym wydłużeniem z OrdPod.
* **Audit log** — każda operacja usunięcia zapisana z timestampem i
  user ID, by odtworzyć kto i kiedy usunął dokument.

### Nie usuwaj zaksięgowanych dokumentów [#nie-usuwaj-zaksięgowanych-dokumentów]

**Najważniejsza praktyczna reguła**: dokument, który jest powiązany z
zapisem w dzienniku, **nie powinien być usuwany przez 10 lat** od
zakończenia roku obrotowego. Usunięcie naruszałoby:

* <LegalRef act="UoR" art="20" paragraph="5" /> pkt 2 (stwierdzenie źródła).
* <LegalRef act="UoR" art="25" paragraph="1" /> (zakaz usuwania zapisów — rozciąga się na dowody).
* <LegalRef act="UoR" art="73" paragraph="1" /> (oryginalna postać).

Zobacz ostrzeżenie w
[korzystanie/document-detail](/docs/korzystanie-z-numify/document-detail).

## Checklist — archiwizacja roczna [#checklist--archiwizacja-roczna]

* [ ] Sprawozdanie finansowe zatwierdzone uchwałą zgromadzenia.
* [ ] Księgi zamknięte (`lockPeriod` dla wszystkich miesięcy).
* [ ] Eksport JPK\_KR\_PD wygenerowany i wysłany do US.
* [ ] e-Sprawozdanie złożone do KRS (15 dni od zatwierdzenia).
* [ ] Kopia zapasowa ksiąg + dowodów na nośnik poza R2 (dysk zewnętrzny / inna chmura) — **rekomendowane**, nie wymagane przez UoR.
* [ ] W polityce rachunkowości zapisane: gdzie przechowujesz dokumenty, kto odpowiada za archiwum, jak długo.

## Co po 5/10 latach [#co-po-510-latach]

Formalnie po upływie wymaganego okresu dokumenty można zniszczyć. W
praktyce:

* **Sp. z o.o. prowadząca działalność** — niszczenie jest ryzykowne
  (kontrola US, spór cywilny, roszczenia z umów); wielu księgowych
  rekomenduje zachowanie bezterminowe dla kluczowych dokumentów.
* **Sp. z o.o. w likwidacji** — dokumenty przekazywane do archiwum
  po wykreśleniu z KRS (zobacz przepisy o archiwach państwowych).
* **Zmiana biura rachunkowego** — dokumenty wracają do jednostki;
  zachowaj ślad wydania i odbioru.


---

# Art. 25 UoR — Ślad rewizyjny (storno, brak usuwania)
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny
Description: Audit trail ksiąg rachunkowych — poprawianie błędów wyłącznie przez storno (zapisy dodatnie lub ujemne) przy prowadzeniu ksiąg komputerem, zakaz usuwania i nadpisywania zapisów. Realizacja w Numify.
Review status: internal
Updated: 2026-04-16



Ślad rewizyjny to jedno z najważniejszych wymogów polskiej rachunkowości.
Księgi rachunkowe nie są „aktualnym stanem rzeczy" — są **historycznym
rejestrem wszystkich zdarzeń, w tym błędów i ich korekt**. Ustawa nie
pozwala „zamieść błędu pod dywan" przez nadpisanie lub usunięcie
zapisu. Każda korekta musi zostawić widoczny ślad.

<ComplianceDisclaimer />

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

> Stwierdzone błędy w zapisach poprawia się:
>
> 1. przez skreślenie dotychczasowej treści i wpisanie nowej, z
>    zachowaniem czytelności błędnego zapisu, oraz podpisanie poprawki
>    i umieszczenie daty; poprawki takie muszą być dokonane jednocześnie
>    we wszystkich księgach rachunkowych i **nie mogą nastąpić po
>    zamknięciu miesiąca** lub
> 2. przez wprowadzenie do ksiąg rachunkowych dowodu zawierającego
>    korekty błędnych zapisów, dokonywane tylko zapisami dodatnimi albo
>    tylko ujemnymi.

Dwa dopuszczalne sposoby:

### Sposób 1 — skreślenie (tylko dla ksiąg papierowych przed zamknięciem) [#sposób-1--skreślenie-tylko-dla-ksiąg-papierowych-przed-zamknięciem]

Historyczny sposób stosowany w księgach prowadzonych ręcznie:

* Skreślić błędną treść tak, żeby pozostała czytelna.
* Wpisać nad spodem poprawną treść.
* Podpisać poprawkę i umieścić datę.
* Zrobić to **jednocześnie** we wszystkich księgach (np. dzienniku i
  księdze głównej — ten sam błąd poprawić wszędzie).
* **Termin: przed zamknięciem miesiąca.** Po zamknięciu miesiąca ten
  sposób jest niedozwolony.

### Sposób 2 — storno / dowód korygujący [#sposób-2--storno--dowód-korygujący]

Wprowadzenie do ksiąg **nowego dowodu**, który zawiera korektę błędnego
zapisu. Obowiązują dwa warianty:

| Wariant                             | Jak wygląda                                                     | Gdy używać                                                       |
| ----------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Storno czarne** (zapisy dodatnie) | Drugi zapis o tej samej kwocie ale z odwróconymi stronami Dt/Ct | Gdy chcemy tylko cofnąć skutek błędu (np. zapisano na złe konto) |
| **Storno czerwone** (zapisy ujemne) | Zapis z kwotą ujemną anulujący błędny zapis                     | Formalnie dozwolone — historycznie używane dla czytelności       |

W obu wariantach **oryginalny błędny zapis zostaje w księgach**.
Nadal jest widoczny w dzienniku i księdze głównej, tylko obok pojawia
się zapis korygujący.

## Reguła dla ksiąg komputerowych — art. 25 ust. 2 [#reguła-dla-ksiąg-komputerowych--art-25-ust-2]

> W razie ujawnienia błędów po zamknięciu miesiąca lub prowadzenia
> ksiąg rachunkowych przy użyciu komputera, dozwolone są tylko korekty
> dokonane w sposób określony w ust. 1 pkt 2.

To kluczowe: **jeżeli księgi są prowadzone komputerem, sposób 1 (skreślenie)
w ogóle nie ma zastosowania**. Jedyna dozwolona forma korekty to dowód
zawierający storno.

Konsekwencje praktyczne dla systemu księgowego:

* Baza danych nie może pozwalać na edycję wcześniej zaksięgowanych
  zapisów (`UPDATE` na `journal_entries.is_posted = true` → zablokowane).
* Baza danych nie może pozwalać na usuwanie zapisów (`DELETE` →
  zablokowane).
* Korekta = utworzenie nowego zapisu, nie modyfikacja istniejącego.

## Powiązane artykuły [#powiązane-artykuły]

<LegalRef act="UoR" art="23" /> (Zasady dokonywania zapisów w księgach
rachunkowych) w ust. 2 wymaga, żeby każdy zapis wskazywał **rodzaj i
numer identyfikacyjny dowodu księgowego** stanowiącego podstawę zapisu,
wraz z jego datą. Dowód korygujący (storno) **musi być osobnym
dokumentem** — nie ten sam co oryginalny błędny dowód. Najczęściej jest
to nota księgowa własna opisująca przyczynę korekty.

<LegalRef act="UoR" art="24" /> nakłada cztery cechy prowadzenia ksiąg:

* **Rzetelnie** — zgodnie ze stanem rzeczywistym.
* **Bezbłędnie** — bez pomyłek rachunkowych / logicznych.
* **Sprawdzalnie** — z możliwością prześledzenia każdego zapisu do
  dowodu źródłowego.
* **Bieżąco** — w terminach umożliwiających sporządzenie obowiązkowych
  sprawozdań.

„Sprawdzalnie" oznacza wprost, że historia zapisów musi być zachowana.

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

### Niemutowalność zapisów po zaksięgowaniu [#niemutowalność-zapisów-po-zaksięgowaniu]

Zapisy w `journal_entries` z flagą `is_posted = true` nie mogą być
modyfikowane przez interfejs użytkownika ani przez endpointy API:

* Mutacje są blokowane w warstwie serwisów przed dotarciem do bazy.
* Edycja dozwolona jest tylko dla zapisów w stanie roboczym
  (`is_posted = false`), które nie zostały jeszcze „wysłane do ksiąg".

### Korekta = storno [#korekta--storno]

Korekta błędnego zaksięgowania wymaga utworzenia **nowego zapisu** o
odwrotnym skutku. Dwa typowe scenariusze:

* **Faktura zaksięgowana na złe konto** — tworzony jest zapis storno
  (odwrotny) oraz nowy prawidłowy zapis. W dzienniku widać: oryginał,
  storno, nowy zapis.
* **Faktura skorygowana fakturą korygującą** — korekta ma własny dowód
  (faktura korygująca) i osobny zapis w dzienniku. Nie modyfikuje
  oryginalnej faktury.

### Audit log — uzupełnienie art. 25 (nie wymóg UoR) [#audit-log--uzupełnienie-art-25-nie-wymóg-uor]

Niezależnie od wymogów art. 25, Numify prowadzi **dziennik audytu**
(`audit_log`) rejestrujący wszystkie operacje na kluczowych encjach:

| Pole                   | Zawartość                                    |
| ---------------------- | -------------------------------------------- |
| `userId`               | Osoba wykonująca operację                    |
| `entityType`           | Typ encji (transaction, journal\_entry, ...) |
| `entityId`             | ID konkretnej encji                          |
| `action`               | Typ operacji (create/update/delete/...)      |
| `changes.before/after` | Przed/po zmianie (dla update)                |
| `ipAddress`            | Adres IP osoby                               |
| `createdAt`            | Moment operacji                              |

Wpisy do audit log są **fire-and-forget** (błąd logowania nie blokuje
operacji głównej) i **immutable** (brak możliwości edycji lub usunięcia
wpisów) — implementacja w
<ServiceRef path="src/lib/audit.ts">audit.ts</ServiceRef>.

Audit log wykracza poza minimum art. 25 — przechowuje historię zmian
także dla operacji, które nie są zapisami księgowymi (np. zmiana
danych kontrahenta, akceptacja dokumentu). Jest pomocniczy dla
kontroli wewnętrznej i w razie audytu.

### Fiscal periods — blokada edycji przeszłych okresów [#fiscal-periods--blokada-edycji-przeszłych-okresów]

Uzupełniająco, moduł okresów obrachunkowych
(<ServiceRef path="src/lib/services/fiscal-periods.ts">fiscal-periods.ts</ServiceRef>)
pozwala zamknąć miesiąc lub cały rok. Zamknięcie wywołuje:

* `ensurePeriodOpen` rzuca błąd przy próbie utworzenia zapisu w
  zamkniętym okresie.
* Po zamknięciu jedyną drogą do korekty jest **zapis w bieżącym okresie
  korygujący wstecz** (data dokumentu może odnosić się do przeszłości,
  ale data księgowania w dzienniku jest z bieżącego okresu).
* Ponowne otwarcie zamkniętego okresu jest możliwe (metoda `reopenPeriod`),
  ale wymaga wyraźnej akcji i jest logowane w audit log.

## Częste problemy z art. 25 [#częste-problemy-z-art-25]

* **„Usunąłem zapis w bazie bezpośrednio"** — to naruszenie art. 25.
  Ślad po zapisie musi pozostać w dzienniku. Bezpośrednia modyfikacja
  bazy przez administratora (nawet z legalnym dostępem technicznym)
  łamie wymóg „sprawdzalności" z <LegalRef act="UoR" art="24" />.
* **„Chcę wycofać fakturę która okazała się pomyłką"** — nie wycofuje
  się, wystawia się **fakturę korygującą** na kwoty przeciwne i
  księguje ją jako nowy dowód. Oryginalna faktura zostaje w księgach.
* **„Poprawiłem literówkę w opisie zapisu"** — czysty opis (pole
  `description`) może być modyfikowany w okresie otwartym, ale zmiana
  jest logowana w audit log. Po zamknięciu miesiąca edycja opisu jest
  już zablokowana razem z całym zapisem.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnym tekście art. 25 UoR (Dz.U. 2023
    poz. 120) oraz implementacji `audit.ts`, `fiscal-periods.ts` i
    schematu `journal_entries` z flagą `is_posted`.
  </ChangeEntry>
</ChangeHistory>


---

# Załącznik 5 UoR — Jednostka mała
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-5
Description: Status jednostki małej — progi 33 mln zł aktywów / 66 mln zł przychodów / 50 osób zatrudnienia (po nowelizacji z 2024 r.). Uproszczona struktura SF, dostępne uproszczenia ewidencyjne, kiedy warto korzystać z Załącznika 5.
Review status: internal
Updated: 2026-04-16



Załącznik 5 do UoR definiuje **uproszczoną strukturę sprawozdania
finansowego dla jednostek małych**. Typowa sp. z o.o. kwalifikuje się
do statusu jednostki małej, jeśli mieści się w trzech progach z
<LegalRef act="UoR" art="3" paragraph="1" /> pkt 1b i kierownik
jednostki podjął formalną decyzję o stosowaniu uproszczeń. Załącznik 5
zastępuje wówczas pełny Załącznik 1.

<ComplianceDisclaimer />

## Progi jednostki małej — stan po nowelizacji z 2024 r. [#progi-jednostki-małej--stan-po-nowelizacji-z-2024-r]

Ustawa z dnia 6 grudnia 2024 r. o zmianie ustawy o rachunkowości
(Dz.U. 2024 poz. 1863, w życie od 1 stycznia 2025 r.) istotnie
podniosła progi klasyfikacji jednostek, implementując
Dyrektywę Delegowaną Komisji (UE) 2023/2775.

Aktualne progi jednostki małej (<LegalRef act="UoR" art="3" paragraph="1" />
pkt 1b) — jednostka nie przekroczyła w roku obrotowym **oraz w roku
poprzedzającym** co najmniej dwóch z trzech wielkości:

| Wielkość                                                 | Próg (od 2025 r.) | Próg (do 2024 r.) |
| -------------------------------------------------------- | ----------------- | ----------------- |
| Suma aktywów bilansu na koniec roku                      | **33 000 000 zł** | 25 500 000 zł     |
| Przychody netto ze sprzedaży towarów i produktów za rok  | **66 000 000 zł** | 51 000 000 zł     |
| Średnioroczne zatrudnienie w przeliczeniu na pełne etaty | **50 osób**       | 50 osób           |

Progi pieniężne wzrosły o ok. 30 %. Próg zatrudnienia pozostał na
tym samym poziomie.

> **Uwaga na wcześniejsze wersje dokumentów:** polityki rachunkowości,
> uchwały zarządu i komunikaty, które powstały przed 2025 r., często
> powołują się na stare progi (25,5 mln / 51 mln). Tekst tych
> dokumentów nie jest automatycznie nieważny, ale przy następnej
> rocznej aktualizacji polityki rachunkowości należy wartości
> uaktualnić.

## Dodatkowa ścieżka zachowania statusu — art. 3 ust. 1 pkt 1d [#dodatkowa-ścieżka-zachowania-statusu--art-3-ust-1-pkt-1d]

<LegalRef act="UoR" art="3" paragraph="1" /> przewiduje, że jednostka
**zachowuje status jednostki małej** także wtedy, gdy:

1. Za poprzedni rok obrotowy sporządziła SF z zastosowaniem uproszczeń
   dla jednostek małych, oraz
2. W roku obrotowym lub roku poprzedzającym przekroczyła dwie z trzech
   wielkości.

To oznacza, że przekroczenie progów nie wyrzuca automatycznie z
kategorii „mała" w pierwszym roku po przekroczeniu — utrata statusu
następuje po **dwóch kolejnych latach przekraczania dwóch progów**.
Analogicznie jednostki rozpoczynające działalność nie stosują wymogu
dwóch lat historii — oceniają swoje progi w pierwszym roku.

## Kto NIE może być jednostką małą [#kto-nie-może-być-jednostką-małą]

Nie każda spółka w progach może korzystać z Załącznika 5. Zgodnie z
<LegalRef act="UoR" art="3" paragraph="1" /> (ust. 1h) niektóre
jednostki zawsze traktuje się jako duże, niezależnie od progów:

* Emitenci papierów wartościowych dopuszczeni do obrotu na rynku
  regulowanym EOG.
* Emitenci notowani w ASO (alternatywny system obrotu — np. NewConnect,
  Catalyst).
* Banki, SKOK-i, zakłady ubezpieczeń, towarzystwa funduszy
  inwestycyjnych, alternatywne spółki inwestycyjne.
* Krajowe instytucje płatnicze i instytucje pieniądza elektronicznego.
* Jednostki ubiegające się o dopuszczenie do obrotu lub wpis do
  rejestru jednego z powyższych.

Typowa prywatna sp. z o.o. prowadząca działalność handlową, usługową
lub produkcyjną w progach 33/66/50 **kwalifikuje się bez przeszkód**.

## Uproszczenia w strukturze SF — Załącznik 5 [#uproszczenia-w-strukturze-sf--załącznik-5]

<LegalRef act="UoR" art="46" paragraph="5" /> pkt 5 i
<LegalRef act="UoR" art="47" paragraph="4" /> pkt 5 pozwalają jednostce
małej stosować uproszczony zakres SF wskazany w Załączniku 5.

### Bilans [#bilans]

Załącznik 5 zachowuje podział na aktywa trwałe / obrotowe oraz kapitały
/ zobowiązania, ale:

* **Łączy drobniejsze pozycje** — np. zamiast rozbicia rzeczowych
  aktywów trwałych na „grunty / budynki / maszyny / środki transportu /
  inne", Załącznik 5 pokazuje pozycję zbiorczą.
* **Pomija pozycje rzadko występujące** — np. szczegółowe rozbicie
  należności długoterminowych.
* **Upraszcza kapitały własne** — bez pełnej rozbiórki na warianty
  kapitału zapasowego (ustawowy / ze sprzedaży akcji / inny).

Efekt: bilans wg Załącznika 5 ma ok. 30–40 pozycji zamiast 100+ pozycji
pełnego Załącznika 1.

### Rachunek zysków i strat [#rachunek-zysków-i-strat]

Także uproszczony — wybór wariantu (kalkulacyjny albo porównawczy)
pozostaje po stronie kierownika jednostki (<LegalRef act="UoR" art="47" paragraph="4" />
pkt 5). Układ pozycji jest zredukowany, ale logika rozbijania wyniku
(działalność operacyjna → finansowa → brutto → podatek → netto) jest
identyczna jak w Załączniku 1.

### Informacja dodatkowa [#informacja-dodatkowa]

<LegalRef act="UoR" art="48" paragraph="4" /> pozwala jednostce małej
sporządzić **uproszczoną Informację dodatkową wg Załącznika 5** — w
miejscu kilkunastu sekcji Załącznika 1 pojawia się prosty zestaw:

* Wprowadzenie do sprawozdania (dane spółki, zasady wyceny).
* Uzupełniające dane o aktywach i pasywach (w minimalnym zakresie).
* Informacje o zatrudnieniu i wynagrodzeniach.

Dodatkowo jednostka mała może zrezygnować z:

* Sporządzania zestawienia zmian w kapitale własnym.
* Sporządzania rachunku przepływów pieniężnych (cash flow).
* Sporządzania sprawozdania z działalności zarządu
  (<LegalRef act="UoR" art="49" paragraph="5" />).

## Inne uproszczenia dla jednostek małych [#inne-uproszczenia-dla-jednostek-małych]

Status jednostki małej uprawnia do szeregu uproszczeń ewidencyjnych
rozsianych po różnych artykułach UoR. Najważniejsze:

| Uproszczenie                                                                       | Podstawa                                       |
| ---------------------------------------------------------------------------------- | ---------------------------------------------- |
| Brak obowiązku ustalania aktywów i rezerw z tytułu odroczonego podatku dochodowego | <LegalRef act="UoR" art="37" paragraph="10" /> |
| Kwalifikacja umów leasingu według zasad podatkowych (zamiast bilansowych)          | <LegalRef act="UoR" art="3" paragraph="6" />   |
| Uproszczone klasyfikowanie instrumentów finansowych                                | (przepisy wykonawcze MF)                       |
| Zwolnienie z badania SF przez biegłego rewidenta (do progów z art. 64)             | <LegalRef act="UoR" art="64" />                |

Każde z nich wymaga **świadomej decyzji w polityce rachunkowości**
— <LegalRef act="UoR" art="10" paragraph="1" /> pkt 2 nakazuje opisać
przyjęte metody wyceny. Uproszczenia nie są „automatyczne" tylko
dlatego, że spółka spełnia progi.

## Kiedy warto stosować Załącznik 5 [#kiedy-warto-stosować-załącznik-5]

**Plusy:**

* Krótsza procedura sporządzenia SF — mniej pozycji do uzupełnienia.
* Brak rachunku przepływów pieniężnych (duża oszczędność czasu).
* Brak zestawienia zmian w kapitale własnym.
* Uproszczona informacja dodatkowa.
* Zwolnienie z badania SF przez biegłego (przy braku innych przesłanek
  obowiązku badania).

**Minusy:**

* Mniejsza porównywalność z większymi firmami (inwestorzy, banki, nowi
  kontrahenci mogą preferować pełny format).
* Zmiana formatu przy przekroczeniu progów w przyszłości wymaga
  aktualizacji polityki rachunkowości oraz ponownego mapowania kont.
* Brak szczegółowych pozycji utrudnia analizę finansową.

W praktyce: nowo powstałe sp. z o.o. i spółki nastawione na prostotę
raportowania zazwyczaj korzystają z Załącznika 5. Spółki planujące
finansowanie zewnętrzne, pozyskanie inwestora lub wejście do grupy
kapitałowej częściej od razu stosują Załącznik 1.

## Jak Numify wspiera Załącznik 5 [#jak-numify-wspiera-załącznik-5]

Obecnie w Numify **zaimplementowany jest wyłącznie generator Informacji
dodatkowej w wersji uproszczonej dla jednostki małej**
(<ServiceRef path="src/lib/services/informacja-dodatkowa.ts">informacja-dodatkowa.ts</ServiceRef>).
Generatory bilansu i RZiS
(<ServiceRef path="src/lib/services/balance-sheet.ts">balance-sheet.ts</ServiceRef>,
<ServiceRef path="src/lib/services/profit-loss.ts">profit-loss.ts</ServiceRef>)
pracują na znacznikach `balanceSheetTag` i `pnlTag` z planu kont —
wspólnych dla Załącznika 1 i 5. Generator XML e-Sprawozdania
(<ServiceRef path="src/lib/services/e-sprawozdanie.ts">e-sprawozdanie.ts</ServiceRef>)
upraszcza strukturę zgodnie z aktualnym schemat MF.

> **Status:** formalna flaga „jednostka mała” w ustawieniach spółki
> oraz automatyczne przełączanie wszystkich generatorów między
> Załącznikiem 1 a 5 nie jest jeszcze zaimplementowane. Użytkownik
> spełniający progi i chcący korzystać z Załącznika 5 powinien na
> dziś zweryfikować wygenerowany dokument z księgowym przed złożeniem,
> oraz przełożyć decyzję o stosowaniu uproszczeń na politykę
> rachunkowości.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnych tekstach art. 3, 46, 47, 48
    UoR (Dz.U. 2023 poz. 120, z uwzględnieniem nowelizacji Dz.U. 2024
    poz. 1863 podnoszącej progi jednostki małej i restrukturyzującej
    art. 3 ust. 1 — wcześniej definicja jednostki małej była w
    art. 3 ust. 1c, obecnie jest w art. 3 ust. 1 pkt 1b).
  </ChangeEntry>
</ChangeHistory>


---

# Art. 15 UoR — Księga główna i podwójny zapis
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-15-ksiega-glowna
Description: Księga główna (konta syntetyczne) — ujęcie systematyczne zdarzeń, zasada podwójnego zapisu, kolejność chronologiczna zapisów na koncie. Polski plan kont zespołów 0–8.
Review status: internal
Updated: 2026-04-16



<PolishTerm pl="Księga główna" en="General ledger">Księga główna</PolishTerm>
grupuje wszystkie zapisy księgowe **według kont** — w przeciwieństwie
do dziennika, który grupuje je chronologicznie. To ten sam zbiór danych
w innym ułożeniu. Na jej podstawie powstaje
<PolishTerm pl="ZOiS" en="trial balance">zestawienie obrotów i sald</PolishTerm>,
a z niego — bilans i rachunek zysków i strat.

<ComplianceDisclaimer />

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

> Konta księgi głównej zawierają zapisy o zdarzeniach w ujęciu
> systematycznym. Na kontach księgi głównej obowiązuje ujęcie
> zarejestrowanych uprzednio lub równocześnie w dzienniku zdarzeń,
> zgodnie z zasadą podwójnego zapisu.

Trzy elementy:

1. **Ujęcie systematyczne** — zdarzenia są przypisane do konkretnych
   kont (np. 402, 201, 220), które tematycznie grupują operacje.
2. **Ujęcie uprzednio lub równocześnie w dzienniku** — nic nie może
   pojawić się w księdze głównej, zanim nie zostanie zarejestrowane
   w dzienniku. To gwarantuje, że dziennik jest kompletny.
3. **Zasada podwójnego zapisu** — każde zdarzenie ma co najmniej dwa
   skutki na kontach: jeden po stronie debetu (Dt) i jeden po stronie
   kredytu (Ct), a sumy obu stron muszą być równe.

## Zasada podwójnego zapisu [#zasada-podwójnego-zapisu]

Matematyczna zasada: **dla każdego zapisu księgowego suma debetów =
suma kredytów**. Dzięki temu:

* Bilans zawsze się bilansuje (aktywa = pasywa).
* Błąd w zapisie manifestuje się jako różnica między stronami.
* ZOiS służy jako automatyczna kontrola spójności.

Przykład — faktura zakupu usługi na 1 230 zł brutto (netto 1 000 zł + VAT 23%):

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

Suma się zgadza — zapis jest poprawny.

W Numify weryfikacja jest automatyczna — test na balansowanie każdego
zapisu jest wykonywany w
<ServiceRef path="src/lib/services/auto-journal.ts">auto-journal.ts</ServiceRef>
oraz pokryty testami jednostkowymi w `auto-journal.test.ts`.

## Kolejność chronologiczna na koncie — art. 15 ust. 2 [#kolejność-chronologiczna-na-koncie--art-15-ust-2]

> Zapisów na określonym koncie księgi głównej dokonuje się w kolejności
> chronologicznej.

Chronologia obowiązuje nie tylko w dzienniku, ale i **na każdym
oddzielnym koncie**. Oznacza to:

* Zapis na koncie 402 z 5 stycznia musi poprzedzać zapis z 10 stycznia
  na tym samym koncie.
* Salda narastająco liczą się od otwarcia ksiąg w kolejności dat.

Numify wyświetla księgę konta zawsze w porządku chronologicznym
(implementacja `getAccountLedger` w
<ServiceRef path="src/lib/services/general-ledger.ts">general-ledger.ts</ServiceRef>
— `ORDER BY journalEntries.date, journalEntries.entryNumber`).

## Polski plan kont — zespoły 0–8 [#polski-plan-kont--zespoły-08]

Zakładowy plan kont każdej sp. z o.o. oparty jest na wzorcowym układzie
9 zespołów (<LegalRef act="UoR" art="10" paragraph="1" />
pkt 3 lit. a nakłada obowiązek posiadania zakładowego planu kont w
polityce rachunkowości). Numify seeduje domyślny plan kont przez
<ServiceRef path="src/lib/services/seed-company-accounts.ts">seed-company-accounts.ts</ServiceRef>
z definicji w <ServiceRef path="src/db/seed-accounts.ts">src/db/seed-accounts.ts</ServiceRef>.

| Zespół | Nazwa                                          | Przykładowe konta                                                                                                                                                                  |
| ------ | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0      | Aktywa trwałe                                  | <AccountRef code="010" name="Środki trwałe" />, <AccountRef code="020" name="WNiP" />, <AccountRef code="070" name="Umorzenie ŚT" />                                               |
| 1      | Środki pieniężne i rachunki bankowe            | <AccountRef code="100" name="Kasa" />, <AccountRef code="130" name="Rachunek bieżący" />                                                                                           |
| 2      | Rozrachunki i roszczenia                       | <AccountRef code="201" name="Odbiorcy" />, <AccountRef code="202" name="Dostawcy" />, <AccountRef code="220" name="VAT należny" />, <AccountRef code="221" name="VAT naliczony" /> |
| 3      | Materiały i towary                             | <AccountRef code="310" name="Materiały" />, <AccountRef code="330" name="Towary" />                                                                                                |
| 4      | Koszty według rodzajów                         | <AccountRef code="401" name="Zużycie materiałów" />, <AccountRef code="402" name="Usługi obce" />, <AccountRef code="403" name="Podatki i opłaty" />                               |
| 5      | Koszty według typów działalności               | Wykorzystywane przy wariancie kalkulacyjnym RZiS                                                                                                                                   |
| 6      | Produkty i rozliczenia międzyokresowe          | <AccountRef code="640" name="RMK czynne" />                                                                                                                                        |
| 7      | Przychody i koszty związane z ich osiągnięciem | <AccountRef code="700" name="Sprzedaż" />, <AccountRef code="750" name="Przychody finansowe" />                                                                                    |
| 8      | Kapitały własne, fundusze specjalne, wynik     | <AccountRef code="800" name="Kapitał zakładowy" />, <AccountRef code="860" name="Wynik finansowy" />                                                                               |

Konta te są **syntetyczne** (3-cyfrowe). Analityka (np. `202-ACME-LTD`
dla konkretnego dostawcy) idzie do ksiąg pomocniczych — zobacz
[Art. 16–17 — księgi pomocnicze](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-16-ksiegi-pomocnicze).

## Saldo konta: debet-normal vs kredyt-normal [#saldo-konta-debet-normal-vs-kredyt-normal]

Konta mają „naturalny" stronę salda zależną od typu:

| Typ konta (UoR)  | Normalne saldo | Przykłady                                             |
| ---------------- | -------------- | ----------------------------------------------------- |
| Aktywa           | Debet          | 010 Środki trwałe, 201 Odbiorcy, 130 Rachunek bieżący |
| Pasywa / Kapitał | Kredyt         | 800 Kapitał zakładowy, 202 Dostawcy, 220 VAT należny  |
| Koszty           | Debet          | 402 Usługi obce, 401 Zużycie materiałów               |
| Przychody        | Kredyt         | 700 Sprzedaż, 750 Przychody finansowe                 |

Numify przechowuje typ w kolumnie `chart_accounts.type`
(`asset`/`liability`/`equity`/`revenue`/`expense`/`off_balance`) i
używa go przy generowaniu bilansu oraz RZiS (przez znaczniki
`balanceSheetTag` i `pnlTag` — zobacz [Załącznik 1](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1)).

## Jak wygląda księga główna w Numify [#jak-wygląda-księga-główna-w-numify]

Ekran `/general-ledger`:

* Po lewej stronie — lista kont, które miały ruch w wybranym okresie
  (pobierane przez `getGeneralLedgerSummary`).
* Po wybraniu konta — historia zapisów (data, numer dziennika, opis,
  Dt, Ct, saldo bieżące).
* Saldo wyliczane narastająco zgodnie z art. 15 ust. 2 (chronologicznie)
  — funkcja `getAccountLedger` w
  <ServiceRef path="src/lib/services/general-ledger.ts">general-ledger.ts</ServiceRef>.

Eksport księgi głównej do PDF / XLSX jest dostępny na tym samym ekranie
(wywołanie endpointu `/api/financial-reports/export/general-ledger`).

## Powiązanie z dziennikiem i ZOiS [#powiązanie-z-dziennikiem-i-zois]

Trzy księgi są powiązane matematycznie:

```
Dziennik (chronologia)
      ↔  (ten sam zbiór zapisów, ułożony inaczej)
Księga główna (wg kont)
      ↓  (agregacja per konto)
Zestawienie obrotów i sald (salda na koniec okresu)
      ↓
Bilans + RZiS
```

Obroty dziennika = obroty ZOiS (<LegalRef act="UoR" art="14" paragraph="1" />).
Suma debetów = suma kredytów w każdym zapisie i narastająco
(<LegalRef act="UoR" art="15" paragraph="1" />). Salda kont dają
wiersze bilansu i RZiS po zastosowaniu znaczników z planu kont.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnym tekście art. 15 UoR (Dz.U. 2023
    poz. 120) oraz na implementacji `general-ledger.ts` i planie kont
    w `src/db/seed-accounts.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 30 UoR — Kursy walut obcych
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut
Description: Wycena aktywów, pasywów i operacji wyrażonych w walutach obcych — średni kurs NBP z dnia poprzedzającego operację, wycena na dzień bilansowy, różnice kursowe jako przychody/koszty finansowe.
Review status: internal
Updated: 2026-04-16



Księgi rachunkowe prowadzi się w złotych polskich
(<LegalRef act="UoR" art="9" />) — każda operacja w walucie obcej
musi być przeliczona na PLN po odpowiednim kursie. Art. 30 UoR określa
**który kurs** i **z jakiego dnia** należy stosować. Błąd polega
najczęściej na zastosowaniu kursu z dnia operacji zamiast z dnia
poprzedzającego.

<ComplianceDisclaimer />

## Zasada ogólna — art. 30 ust. 2 [#zasada-ogólna--art-30-ust-2]

> Wyrażone w walutach obcych operacje gospodarcze ujmuje się w księgach
> rachunkowych na dzień ich przeprowadzenia — o ile odrębne przepisy
> dotyczące środków pochodzących z budżetu Unii Europejskiej (...) nie
> stanowią inaczej — odpowiednio po kursie:
>
> 1. **faktycznie zastosowanym** w tym dniu, wynikającym z charakteru
>    operacji — w przypadku sprzedaży lub kupna walut oraz zapłaty
>    należności lub zobowiązań;
> 2. **średnim ogłoszonym dla danej waluty przez Narodowy Bank Polski
>    z dnia poprzedzającego** ten dzień — w przypadku zapłaty
>    należności lub zobowiązań, jeżeli nie jest zasadne zastosowanie
>    kursu, o którym mowa w pkt 1, a także w przypadku pozostałych
>    operacji.

### Kiedy kurs faktyczny [#kiedy-kurs-faktyczny]

„Kurs faktycznie zastosowany" — np. kurs, po którym bank rzeczywiście
przeliczył walutę przy sprzedaży/kupnie. Stosowany przy:

* Kupnie waluty w kantorze lub banku.
* Przelewie walutowym, gdy bank przewalutował kwotę po swoim kursie.

### Kiedy średni NBP z dnia poprzedzającego [#kiedy-średni-nbp-z-dnia-poprzedzającego]

W pozostałych przypadkach — w tym &#x2A;*dla zdecydowanej większości operacji
w sp. z o.o.** — stosuje się **średni kurs NBP z Tabeli A z dnia
poprzedzającego** datę operacji. Typowe sytuacje:

| Operacja                            | Data operacji            | Kurs                                |
| ----------------------------------- | ------------------------ | ----------------------------------- |
| Wystawienie faktury sprzedaży w EUR | Data wystawienia         | NBP Tabela A z dnia poprzedzającego |
| Otrzymanie faktury zakupu w USD     | Data wystawienia faktury | NBP Tabela A z dnia poprzedzającego |
| Powstanie obowiązku podatkowego VAT | Data obowiązku           | NBP Tabela A z dnia poprzedzającego |

> **Weekendy i święta:** jeśli dzień poprzedzający to sobota, niedziela
> lub święto, NBP nie ogłasza tabeli. Stosuje się kurs z **ostatniego
> dnia roboczego poprzedzającego** operację (tabela A z np. piątku przed
> poniedziałkową operacją). Numify przeszukuje wstecz do 7 dni, aż
> znajdzie opublikowaną tabelę — implementacja w `getNbpRate` w
> <ServiceRef path="src/lib/services/nbp-exchange-rates.ts">nbp-exchange-rates.ts</ServiceRef>.

## Wycena na dzień bilansowy — art. 30 ust. 1 [#wycena-na-dzień-bilansowy--art-30-ust-1]

> Nie rzadziej niż na dzień bilansowy wycenia się wyrażone w walutach
> obcych:
>
> 1. składniki aktywów (...) i pasywów — po obowiązującym na ten dzień
>    średnim kursie ogłoszonym dla danej waluty przez Narodowy Bank
>    Polski (...);
> 2. gotówkę znajdującą się w jednostkach prowadzących kupno i
>    sprzedaż walut obcych — po kursie, po którym nastąpił jej zakup,
>    jednak w wysokości nie wyższej od średniego kursu ogłoszonego na
>    dzień wyceny (...).

Różnice:

* **Dzień bilansowy** (zwykle 31 grudnia) wymaga wyceny wszystkich
  pozycji walutowych (aktywów i pasywów) po **kursie z dnia bilansowego**
  — a nie z dnia poprzedzającego, jak przy normalnych operacjach.
* Wyjątek — kasa walutowa w firmach prowadzących kantor wymienia na
  kurs zakupu, ograniczony do góry przez średni NBP.

## Różnice kursowe — art. 30 ust. 4 [#różnice-kursowe--art-30-ust-4]

> Różnice kursowe (...) dotyczące pozostałych aktywów i pasywów
> wyrażonych w walutach obcych, powstałe na dzień ich wyceny oraz przy
> zapłacie należności i zobowiązań w walutach obcych, jak również
> sprzedaży walut, **zalicza się odpowiednio do przychodów lub kosztów
> finansowych** (...).

Różnica kursowa powstaje, kiedy ten sam walutowy składnik aktywów /
pasywów ma inną wartość PLN w dwóch momentach:

* Przy ujęciu — kurs NBP z dnia poprzedzającego wystawienie faktury.
* Przy zapłacie — kurs faktyczny (bankowy) albo NBP z dnia
  poprzedzającego zapłatę.

Przykład — faktura sprzedaży na 1 000 EUR:

| Data                      | Kurs   | PLN            | Strona księgi                     |
| ------------------------- | ------ | -------------- | --------------------------------- |
| 15 stycznia (wystawienie) | 4,3000 | 4 300,00       | Dt 201 / Ct 700                   |
| 10 lutego (zapłata)       | 4,3500 | 4 350,00       | Dt 130 4 350,00 / Ct 201 4 300,00 |
|                           |        | **50,00 zysk** | Ct 750 — różnica kursowa dodatnia |

Różnica trafia na konto <AccountRef code="750" name="Przychody finansowe" />
(dodatnia) lub <AccountRef code="755" name="Koszty finansowe" />
(ujemna). Numify auto-rozlicza różnice kursowe przy księgowaniu
płatności w module bankowym.

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

### Pobieranie kursów NBP [#pobieranie-kursów-nbp]

Funkcja `getNbpRate(currencyCode, invoiceDate)` w
<ServiceRef path="src/lib/services/nbp-exchange-rates.ts">nbp-exchange-rates.ts</ServiceRef>:

1. Dla PLN zwraca od razu kurs 1,0.
2. Dla innych walut — szuka kursu **dla dnia poprzedzającego**
   `invoiceDate`.
3. Jeśli ten dzień to weekend / święto — cofając się dzień po dniu do
   7 dni wstecz, aż znajdzie opublikowaną tabelę.
4. Odpowiada z pola `mid` z API NBP, cachuje wynik w tabeli
   `exchange_rates`.

Endpoint API NBP: `https://api.nbp.pl/api/exchangerates/rates/a/{code}/{date}/`
(wyłącznie HTTPS od sierpnia 2025 r.).

### Konwersja kwoty faktury do PLN [#konwersja-kwoty-faktury-do-pln]

Funkcja `convertToPln(amountGrosze, rate)` mnoży kwotę w groszach waluty
obcej przez kurs — wynikiem jest kwota w groszach PLN. Zaokrąglanie
jest matematyczne (`Math.round`).

### Batch-fetch kursów dla importu [#batch-fetch-kursów-dla-importu]

Funkcja `prefetchNbpRateRange(currencyCode, startDate, endDate)` pobiera
tabelę kursów dla zakresu dat (max 93 dni per wywołanie — ograniczenie
NBP). Służy do importu wyciągów bankowych z okresu dłuższego niż
pojedyncza data — zamiast wielu sekwencyjnych zapytań wykonywany jest
jeden masowy fetch i cache w `exchange_rates`.

### Domyślne stawki na faktury [#domyślne-stawki-na-faktury]

Kwoty walutowe przy wystawianiu faktury są automatycznie przeliczane
na PLN w momencie zapisu — pola `amountNetPln`, `amountVatPln`,
`amountGrossPln` w tabeli `transactions`. Przy zmianie daty wystawienia
kurs jest pobierany ponownie.

### Różnice kursowe przy zapłacie [#różnice-kursowe-przy-zapłacie]

Moduł płatności (`payment-journal.ts`) porównuje kurs przy wystawieniu
z kursem przy zapłacie i księguje różnicę na kontach 750 / 755.
Pokrycie testowe w `payment-journal.test.ts`.

## Częste błędy [#częste-błędy]

* **Zastosowanie kursu z dnia operacji, nie z dnia poprzedzającego** —
  klasyczny błąd, skutkuje niewielkimi różnicami, ale narusza
  <LegalRef act="UoR" art="30" paragraph="2" />. Cały dziennik
  wówczas trzeba korygować przez storno.
* **Brak wyceny na dzień bilansowy** — salda walutowe muszą być
  przewartościowane na 31 grudnia. Jeśli tego nie zrobiono, bilans
  jest nieprawidłowy.
* **Kurs NBP dla walut nie notowanych w Tabeli A** — niektóre waluty
  są tylko w Tabeli B (np. GEL, MMK). W takim przypadku stosuje się
  kurs krzyżowy przez USD / EUR
  (<LegalRef act="UoR" art="30" paragraph="3" />). Numify obsługuje
  wyłącznie waluty z Tabeli A.

## Zaokrąglenia i przechowywanie w groszach [#zaokrąglenia-i-przechowywanie-w-groszach]

Numify przechowuje wszystkie kwoty jako **liczby całkowite w groszach**
— zarówno w walucie oryginalnej, jak i w PLN po przeliczeniu. Eliminuje
to błędy zaokrągleń typowe dla typów `decimal`/`float` i gwarantuje, że
dwa zapisy o tych samych kwotach są bitowo identyczne.

Kurs NBP jest przechowywany w typie `decimal` z 4 miejscami dziesiętnymi
(zgodnie z publikacją NBP). Mnożenie `grosze * rate` i `Math.round`
daje deterministyczny wynik.

<ChangeHistory>
  <ChangeEntry date="2026-04-16" act="Phase 3a">
    Pierwsza wersja — oparta na aktualnym tekście art. 30 UoR (Dz.U.
    2023 poz. 120) oraz implementacji `nbp-exchange-rates.ts` i
    `payment-journal.ts`.
  </ChangeEntry>
</ChangeHistory>


---

# Art. 31–33 UoR — Środki trwałe
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-31-33-srodki-trwale
Description: Wartość początkowa środka trwałego (art. 31 ust. 1), odpisy amortyzacyjne i umorzeniowe (art. 31 ust. 2), systematyczne rozłożenie na okres ekonomicznej użyteczności (art. 32 ust. 1–2), uproszczenia dla ŚT o niskiej wartości (art. 32 ust. 6), odpowiednie stosowanie do wartości niematerialnych i prawnych (art. 33). Reżim bilansowy vs podatkowy (CIT art. 16a–16m). Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Środki trwałe** to największa kategoria majątku sp. z o.o. po
środkach pieniężnych i rozrachunkach. <LegalRef act="UoR" art="31" />–<LegalRef act="UoR" art="33" />
precyzują zasady wyceny, amortyzacji i obniżania wartości. Dla celów
podatkowych dublowany jest reżim w CIT (art. 16a–16m).

<ComplianceDisclaimer />

## Definicja środka trwałego — art. 3 ust. 1 pkt 15 [#definicja-środka-trwałego--art-3-ust-1-pkt-15]

> Środki trwałe — rzeczowe aktywa trwałe i zrównane z nimi, o
> **przewidywanym okresie ekonomicznej użyteczności dłuższym niż rok**,
> **kompletne**, **zdatne do użytku** i **przeznaczone na potrzeby
> jednostki**.

Cztery cechy muszą wystąpić **łącznie**. Zakres przedmiotowy:

* Nieruchomości — grunty, prawo użytkowania wieczystego, budynki, lokale, spółdzielcze prawo do lokalu.
* Maszyny, urządzenia, środki transportu.
* Ulepszenia w obcych środkach trwałych.
* Inwentarz żywy.

Środki trwałe oddane w leasing finansowy zaliczają się do ŚT
korzystającego (ust. 4), pod warunkiem spełnienia co najmniej jednego
z 7 kryteriów leasingu finansowego z <LegalRef act="UoR" art="3" paragraph="4" />.

## Wartość początkowa — art. 31 ust. 1 [#wartość-początkowa--art-31-ust-1]

> Wartość początkową stanowiącą cenę nabycia lub koszt wytworzenia
> środka trwałego powiększają koszty jego ulepszenia, polegającego na
> przebudowie, rozbudowie, modernizacji lub rekonstrukcji i
> powodującego, że wartość użytkowa tego środka po zakończeniu
> ulepszenia przewyższa posiadaną przy przyjęciu do używania wartość
> użytkową, mierzoną okresem używania, zdolnością wytwórczą, jakością
> produktów uzyskiwanych przy pomocy ulepszonego środka trwałego,
> kosztami eksploatacji lub innymi miarami.

### Co wchodzi do wartości początkowej [#co-wchodzi-do-wartości-początkowej]

**Cena nabycia** (dla zakupionych) — cena zakupu + koszty
bezpośrednio związane z przygotowaniem do używania:

* Koszty transportu, załadunku i wyładunku.
* Cło i niepodlegający odliczeniu VAT (jeśli nabywca jest zwolniony).
* Koszty montażu i uruchomienia.
* Koszty probierne, testowe, certyfikacji.
* Odsetki od kredytu sfinansowania zakupu **do dnia przyjęcia do używania** (potem w koszty finansowe).

**Koszt wytworzenia** (dla wytworzonych we własnym zakresie) —
bezpośrednie koszty materiałów, robocizny + uzasadniona część
kosztów pośrednich.

### Ulepszenia — granica między KUP a zwiększeniem wartości [#ulepszenia--granica-między-kup-a-zwiększeniem-wartości]

Wydatek na środek trwały jest albo:

* **Ulepszeniem** (zwiększa wartość początkową, amortyzuje się) — gdy
  powoduje **wzrost wartości użytkowej** mierzonej okresem,
  zdolnością, jakością, kosztami.
* **Remontem** (bieżący koszt, w KUP od razu) — gdy przywraca
  pierwotną wartość użytkową bez jej zwiększenia.

To jest kluczowa kwalifikacja z dużymi konsekwencjami podatkowymi —
ulepszenie amortyzuje się latami, remont jest kosztem jednorazowym.
Typowy spór z urzędem skarbowym.

## Amortyzacja bilansowa — art. 31 ust. 2 i art. 32 ust. 1 [#amortyzacja-bilansowa--art-31-ust-2-i-art-32-ust-1]

<LegalRef act="UoR" art="31" paragraph="2" />:

> Wartość początkową środków trwałych — z wyjątkiem gruntów
> niesłużących wydobyciu kopalin metodą odkrywkową — zmniejszają
> **odpisy amortyzacyjne lub umorzeniowe** dokonywane w celu
> uwzględnienia utraty ich wartości, na skutek używania lub upływu
> czasu.

<LegalRef act="UoR" art="32" paragraph="1" />:

> Odpisów amortyzacyjnych lub umorzeniowych od środka trwałego
> dokonuje się drogą **systematycznego, planowego rozłożenia** jego
> wartości początkowej na ustalony okres amortyzacji. Rozpoczęcie
> amortyzacji następuje **nie wcześniej niż po przyjęciu środka
> trwałego do używania**, a jej zakończenie — nie później niż z
> chwilą zrównania wartości odpisów amortyzacyjnych lub umorzeniowych
> z wartością początkową środka trwałego lub przeznaczenia go do
> likwidacji, sprzedaży lub stwierdzenia jego niedoboru.

Dwa kluczowe wymogi:

1. **Systematyczność** — równomierny plan (nie „czasem dużo, czasem nic").
2. **Ustalony okres** — zadeklarowany na dzień przyjęcia do używania, nie dobierany ad hoc.

Grunty (niesłużące wydobyciu) **nie amortyzują się** — nie tracą wartości użytkowej przez upływ czasu.

## Ekonomiczna użyteczność — ust. 2 [#ekonomiczna-użyteczność--ust-2]

> Przy ustalaniu okresu amortyzacji i rocznej stawki amortyzacyjnej
> uwzględnia się okres ekonomicznej użyteczności środka trwałego, na
> określenie którego wpływają w szczególności:
>
> 1. liczba zmian, na których pracuje środek trwały;
> 2. tempo postępu techniczno-ekonomicznego;
> 3. wydajność środka trwałego…;
> 4. prawne lub inne ograniczenia czasu używania środka trwałego;
> 5. przewidywana przy likwidacji cena sprzedaży netto istotnej pozostałości środka trwałego.

**Ekonomiczna użyteczność** to długość okresu, w którym ŚT generuje
spodziewane korzyści ekonomiczne — nie jego teoretyczny czas życia.

Przykłady:

* **Laptop** — wartość początkowa 6 000 zł. Okres ekonomicznej
  użyteczności 3 lata (tempo postępu technicznego → pkt 2). Stawka
  33,3%. Miesięczny odpis ≈ 167 zł.
* **Samochód osobowy** — cena nabycia 80 000 zł. Okres ekonomicznej
  użyteczności 5 lat. Stawka 20%. Miesięczny odpis 1 333 zł.
* **Budynek biurowy** — cena nabycia 2 000 000 zł. Okres 40 lat.
  Stawka 2,5%. Roczny odpis 50 000 zł.

### Okresowa weryfikacja — ust. 3 [#okresowa-weryfikacja--ust-3]

> Poprawność stosowanych okresów i stawek amortyzacji środków
> trwałych powinna być przez jednostkę okresowo weryfikowana,
> powodując odpowiednią korektę dokonywanych w następnych latach
> obrotowych odpisów amortyzacyjnych.

Oznacza to, że stawka **nie jest ustalona raz na zawsze** — przy
istotnej zmianie warunków (np. intensywne użytkowanie, postęp
technologiczny) jednostka koryguje stawkę prospektywnie (od następnych
okresów, nie retrospektywnie). Typowa weryfikacja: raz w roku, przy
sporządzaniu sprawozdania finansowego.

## Trwała utrata wartości — ust. 4 [#trwała-utrata-wartości--ust-4]

> W przypadku zmiany technologii produkcji, przeznaczenia do
> likwidacji, wycofania z używania lub innych przyczyn powodujących
> **trwałą utratę wartości środka trwałego**, dokonuje się — w
> ciężar pozostałych kosztów operacyjnych — odpowiedniego odpisu
> aktualizującego jego wartość.

Różnica od amortyzacji:

* **Amortyzacja** = planowe, systematyczne (ust. 1).
* **Odpis aktualizujący z ust. 4** = nadzwyczajne, odpowiadające
  zdarzeniu (np. maszyna wycofana z produkcji po wypadku).

Odpis trafia w **pozostałe koszty operacyjne**, nie w
amortyzację — zwiększa wartość pozycji „pozostałe koszty operacyjne"
w [RZiS](/docs/korzystanie-z-numify/profit-loss).

## Uproszczenia dla ŚT o niskiej wartości — ust. 6 [#uproszczenia-dla-śt-o-niskiej-wartości--ust-6]

> Dla środków trwałych o niskiej jednostkowej wartości początkowej
> można ustalać odpisy amortyzacyjne lub umorzeniowe w sposób
> uproszczony, przez dokonywanie zbiorczych odpisów dla grup środków
> zbliżonych rodzajem i przeznaczeniem lub jednorazowo odpisując
> wartość tego rodzaju środków trwałych.

**UoR nie definiuje kwotowego progu*&#x2A; „niskiej wartości" — to decyzja
jednostki w polityce rachunkowości. Najczęściej jednostki przyjmują
próg **≤ 10 000 zł** — spójny z limitem CIT (<LegalRef act="CIT" art="16d" paragraph="1" /> —
nie trzeba amortyzować).

Trzy dopuszczalne podejścia:

1. **Jednorazowy odpis** — cały koszt w miesiącu przyjęcia do używania (np. drukarka za 800 zł → jednorazowo).
2. **Zbiorczy odpis dla grupy** — np. 10 krzeseł biurowych po 300 zł traktowane jako jeden „zestaw krzeseł" z planem amortyzacji.
3. **Normalna amortyzacja** — bez uproszczeń, ale z prostą stawką liniową.

## Reżim bilansowy a podatkowy — ust. 7 [#reżim-bilansowy-a-podatkowy--ust-7]

> Jednostka mikro i jednostka mała mogą dokonywać odpisów
> amortyzacyjnych lub umorzeniowych od środków trwałych według zasad
> określonych w przepisach podatkowych.

To jest **duże uproszczenie**: mała sp. z o.o. (do 25 mln aktywów /
50 mln przychodów / 50 pracowników — art. 3 ust. 1e UoR) może
zrezygnować z liczenia osobno amortyzacji bilansowej i podatkowej,
stosując wyłącznie stawki podatkowe z załącznika do CIT
(<LegalRef act="CIT" art="16i" paragraph="1" />).

**Wyłączenia** (ust. 8) — z uproszczenia **nie mogą** korzystać:

* Jednostki sektora finansów publicznych.
* Spółki kapitałowe (a więc sp. z o.o.!).
* Spółki komandytowo-akcyjne.
* Niektóre spółki jawne i komandytowe z kapitałowymi wspólnikami.

Dla typowej sp. z o.o. **ust. 7 nie ma zastosowania**. Oznacza to, że:

* Można stosować stawki podatkowe dla wygody, ale wymaga to
  zadeklarowania w polityce rachunkowości i spójnego stosowania.
* Formalnie stawka bilansowa może się różnić od podatkowej, co
  wymaga prowadzenia dwóch równoległych ewidencji — to powód, dla
  którego w praktyce większość małych sp. z o.o. deklaruje w
  polityce, że stawki bilansowe = stawki podatkowe.

## Wartości niematerialne i prawne — art. 33 [#wartości-niematerialne-i-prawne--art-33]

<LegalRef act="UoR" art="33" paragraph="1" />:

> Do wyceny wartości niematerialnych i prawnych oraz sposobów
> dokonywania od nich odpisów amortyzacyjnych lub umorzeniowych
> stosuje się odpowiednio przepisy art. 31 ust. 2 i art. 32 ust. 1–4
> i 6–8.

WNiP (licencje, patenty, know-how, koszty prac rozwojowych)
amortyzują się **na tych samych zasadach co ŚT** — systematycznie,
przez okres ekonomicznej użyteczności.

Osobliwości:

* **Koszty prac rozwojowych** (ust. 2) — zaliczane do WNiP, jeśli
  spełniają 3 warunki (określony produkt, stwierdzona przydatność,
  zwrot z przychodów).
* **Wartość firmy** (ust. 4) — powstaje przy przejęciu jednostki;
  amortyzacja przez 5 lat (art. 44b).

Numify **nie prowadzi osobnej ewidencji WNiP** — traktuje je jak ŚT w
ramach tej samej tabeli `fixedAssets` z odpowiednim typem. To
uproszczenie dopuszczalne dla małych jednostek — dla większych
wymagane jest rozdzielenie pozycji w bilansie (A.I vs A.II).

## Reżim bilansowy vs podatkowy — kluczowe różnice [#reżim-bilansowy-vs-podatkowy--kluczowe-różnice]

| Aspekt                  | UoR (bilansowy)                                                              | CIT (podatkowy)                                                                              |
| ----------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Stawka                  | Wg ekonomicznej użyteczności (<LegalRef act="UoR" art="32" paragraph="2" />) | Wg wykazu stawek (załącznik do CIT)                                                          |
| Próg „niska wartość"    | Brak (polityka jednostki, zwykle 10 000 zł)                                  | 10 000 zł (<LegalRef act="CIT" art="16d" paragraph="1" />)                                   |
| Metody degresywne       | Dopuszczalne (ust. 1 — „systematyczne")                                      | Ograniczone do grup 3–6 i 8 KŚT (<LegalRef act="CIT" art="16k" />)                           |
| Samochody osobowe       | Brak limitu                                                                  | Limit amortyzacji 150 000 / 225 000 zł (<LegalRef act="CIT" art="16" paragraph="1" /> pkt 4) |
| Jednorazowa amortyzacja | Jako uproszczenie                                                            | Jako ulga dla małych podatników (do 50 000 EUR rocznie)                                      |

Różnice tworzą pozycje **odroczonego podatku dochodowego** — zobacz
[korzystanie/cit-data](/docs/korzystanie-z-numify/cit-data) i
[zgodnosc/ustawa-o-cit/kup-nkup](/docs/zgodnosc-z-prawem/ustawa-o-cit/kup-nkup).

## Realizacja w Numify [#realizacja-w-numify]

Szczegółowa dokumentacja funkcji:
[korzystanie/fixed-assets](/docs/korzystanie-z-numify/fixed-assets).

### Trzy metody amortyzacji [#trzy-metody-amortyzacji]

| Metoda       | Opis                                   | Typowe zastosowanie                                                          |
| ------------ | -------------------------------------- | ---------------------------------------------------------------------------- |
| `linear`     | Równe miesięczne odpisy                | Większość ŚT (domyślna)                                                      |
| `degressive` | Od wartości netto, współczynnik do 2,0 | Maszyny grup 3–6 i 8 KŚT (dopuszczalne w CIT)                                |
| `one_time`   | Cały odpis w miesiącu przyjęcia        | ŚT ≤ 10 000 zł (ust. 6 UoR + <LegalRef act="CIT" art="16d" paragraph="1" />) |

### Księgowanie miesięczne [#księgowanie-miesięczne]

`generateMonthlyDepreciation(companyId, year, month)` składa zapis:

* **Wn 400** (Amortyzacja, zespół 4) — suma odpisów miesiąca.
* **Ma 070** (Umorzenie środków trwałych, zespół 0) — ta sama suma.

Zapis jest idempotentny — ponowne wywołanie dla tego samego miesiąca
nie tworzy duplikatu.

### Likwidacja / zbycie [#likwidacja--zbycie]

`disposeFixedAsset` ustawia status `disposed` i księguje (w
zależności od typu zbycia):

* **Sprzedaż** — wyksięgowanie wartości netto na pozostałe koszty
  operacyjne, przychód na 700 (plus VAT jeśli dotyczy).
* **Likwidacja** — wyksięgowanie wartości netto na pozostałe koszty
  operacyjne.

ŚT pozostaje w ewidencji ze statusem `disposed` — nie jest fizycznie
usunięty (<LegalRef act="UoR" art="25" paragraph="1" />).


---

# Art. 12 UoR — Otwarcie i zamknięcie ksiąg
URL: https://numifyai.com/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-12-otwarcie-zamkniecie-ksiag
Description: Pięć momentów otwarcia ksiąg, siedem momentów zamknięcia, sytuacje gdy nie trzeba otwierać / zamykać, ostateczne zamknięcie w ciągu 15 dni od zatwierdzenia sprawozdania finansowego i nieodwracalny charakter zamknięcia ksiąg. Realizacja w Numify.
Review status: internal
Updated: 2026-04-17



**Otwarcie i zamknięcie ksiąg** to dwa najważniejsze zdarzenia w
cyklu życia ksiąg rachunkowych. <LegalRef act="UoR" art="12" /> precyzuje
każdy moment, w którym następują — oraz przesądza, że zamknięcie ksiąg
ma charakter **nieodwracalny** (ust. 5).

<ComplianceDisclaimer />

## Pięć momentów otwarcia — art. 12 ust. 1 [#pięć-momentów-otwarcia--art-12-ust-1]

> Księgi rachunkowe otwiera się, z zastrzeżeniem ust. 3:
>
> 1. na dzień rozpoczęcia działalności, którym jest dzień pierwszego zdarzenia wywołującego skutki o charakterze majątkowym lub finansowym,
> 2. na początek każdego następnego roku obrotowego,
> 3. na dzień zmiany formy prawnej,
> 4. na dzień wpisu do rejestru połączenia jednostek lub podziału jednostki, powodujących powstanie nowej jednostki (jednostek),
> 5. na dzień rozpoczęcia likwidacji lub ogłoszenia upadłości — w ciągu 15 dni od dnia zaistnienia tych zdarzeń.

### Dla typowej sp. z o.o. [#dla-typowej-sp-z-oo]

W praktyce spółki kontynuującej działalność liczą się dwa z pięciu
momentów:

1. **Rozpoczęcie działalności** — moment pierwszego zdarzenia
   majątkowego. Dla nowo zakładanej spółki typowo dzień wpisu do KRS
   lub pierwszy dzień, w którym spółka dokonuje zakupu, otrzymuje
   kapitał zakładowy itp.
2. **Początek każdego nowego roku obrotowego** — domyślnie 1 stycznia
   dla roku obrotowego pokrywającego się z kalendarzowym.

Pozostałe trzy scenariusze dotyczą reorganizacji, połączeń i likwidacji —
sytuacji wyjątkowych.

### Księgi otwarte = ewidencja gotowa do zapisu [#księgi-otwarte--ewidencja-gotowa-do-zapisu]

Otwarcie ksiąg polega technicznie na:

* Przeniesieniu bilansu zamknięcia poprzedniego roku jako **bilansu
  otwarcia** nowego roku (<LegalRef act="UoR" art="5" paragraph="1" /> —
  ciągłość bilansowa).
* Wyzerowaniu obrotów rocznych (dziennik zaczyna numerację od 1, konta
  wynikowe zespołu 4 i 7 startują z saldem 0).
* Zachowaniu sald kont bilansowych (zespoły 0, 1, 2, 3, 8).

Szczegółowe omówienie, jak to wygląda w Numify:
[korzystanie/opening-balance](/docs/korzystanie-z-numify/opening-balance)
i [korzystanie/fiscal-periods](/docs/korzystanie-z-numify/fiscal-periods).

## Siedem momentów zamknięcia — art. 12 ust. 2 [#siedem-momentów-zamknięcia--art-12-ust-2]

> Księgi rachunkowe zamyka się, z zastrzeżeniem ust. 3–3d:
>
> 1. na dzień kończący rok obrotowy,
> 2. na dzień zakończenia działalności jednostki, w tym również jej sprzedaży, zakończenia likwidacji lub postępowania upadłościowego, o ile nie nastąpiło jego umorzenie,
> 3. na dzień poprzedzający zmianę formy prawnej,
> 4. w jednostce przejmowanej na dzień połączenia związanego z przejęciem jednostki przez inną jednostkę,
> 5. na dzień poprzedzający dzień podziału lub połączenia jednostek, jeżeli w wyniku podziału lub połączenia powstaje nowa jednostka,
> 6. na dzień poprzedzający dzień postawienia jednostki w stan likwidacji lub ogłoszenia upadłości,
> 7. na inny dzień bilansowy określony odrębnymi przepisami — nie później niż w ciągu 3 miesięcy od dnia zaistnienia tych zdarzeń.

Dla typowej sp. z o.o. kontynuującej działalność liczy się pkt 1 —
dzień kończący rok obrotowy (typowo 31 grudnia).

## Kiedy można nie zamykać ani nie otwierać — ust. 3 [#kiedy-można-nie-zamykać-ani-nie-otwierać--ust-3]

> Można nie zamykać i nie otwierać ksiąg rachunkowych w przypadku:
>
> 1. przekształcenia spółki osobowej oraz spółki cywilnej w inną spółkę osobową, a także spółki kapitałowej w inną spółkę kapitałową;
> 2. połączenia jednostek, gdy w myśl ustawy rozliczenie połączenia następuje metodą łączenia udziałów i nie powoduje powstania nowej jednostki.

Przykład: przekształcenie sp. z o.o. w spółkę akcyjną **nie wymaga**
zamknięcia ksiąg — są prowadzone w ciągłości.

### Zawieszenie działalności — ust. 3b [#zawieszenie-działalności--ust-3b]

> Można nie zamykać ksiąg rachunkowych za rok obrotowy, w którym
> działalność jednostki przez cały czas pozostawała zawieszona, chyba
> że jednostka dokonuje odpisów amortyzacyjnych lub umorzeniowych lub
> występują inne zdarzenia wywołujące skutki o charakterze majątkowym
> lub finansowym.

Spółka w długotrwałym zawieszeniu (cały rok obrotowy) może
kontynuować księgi bez zamykania — o ile **nie ma** żadnego zdarzenia
majątkowego, w tym **odpisów amortyzacyjnych**. W praktyce niewiele
sp. z o.o. spełnia ten warunek, bo środki trwałe amortyzują się dalej.

## Ostateczne zamknięcie w ciągu 15 dni — ust. 4 [#ostateczne-zamknięcie-w-ciągu-15-dni--ust-4]

> Ostateczne zamknięcie i otwarcie ksiąg rachunkowych jednostki
> kontynuującej działalność powinno nastąpić najpóźniej w ciągu 15
> dni od dnia zatwierdzenia sprawozdania finansowego za rok obrotowy.

To jest **kluczowy termin** dla sp. z o.o.:

| Zdarzenie                                      | Termin                                                           |
| ---------------------------------------------- | ---------------------------------------------------------------- |
| Sporządzenie SF                                | 3 miesiące od dnia bilansowego (<LegalRef act="UoR" art="52" />) |
| Zatwierdzenie SF przez zgromadzenie wspólników | 6 miesięcy od dnia bilansowego                                   |
| **Ostateczne zamknięcie ksiąg**                | **15 dni od zatwierdzenia SF**                                   |

Dla roku kończącego się 31 XII: SF najpóźniej do 31 III, zatwierdzenie
do 30 VI, ostateczne zamknięcie ksiąg do 15 VII. Po tym dniu księgi
roku obrotowego stają się **niezmienialne** (patrz ust. 5).

## Nieodwracalność zamknięcia — ust. 5 [#nieodwracalność-zamknięcia--ust-5]

> Zamknięcie ksiąg rachunkowych polega na nieodwracalnym wyłączeniu
> możliwości dokonywania zapisów księgowych w zbiorach tworzących
> zamknięte księgi rachunkowe.

To jest **techniczny wymóg** o głębokich konsekwencjach:

* Po zamknięciu **nie wolno**: dodać zapisu, zmienić kwoty, usunąć
  pozycji, zmienić konta dekretacyjnego.
* Błąd wykryty po zamknięciu koryguje się **zapisem korygującym w
  bieżącym okresie** (storno lub nowy zapis z datą bieżącą), nie
  modyfikacją zapisu pierwotnego (zobacz też
  [Art. 25 — ślad rewizyjny](/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny)).
* **Backup bazy danych sprzed zamknięcia nie jest podstawą do
  modyfikacji** — przywrócenie stanu sprzed zamknięcia w celu
  wprowadzenia poprawki narusza ust. 5.

## Realizacja w Numify [#realizacja-w-numify]

Numify rozróżnia **dwa poziomy zamknięcia**:

| Status okresu | Co odpowiada w UoR                          | Czy dopuszcza modyfikację                   |
| ------------- | ------------------------------------------- | ------------------------------------------- |
| `open`        | Księgi otwarte dla bieżącego okresu         | Tak — dodawanie, edycja, storno             |
| `closed`      | Roboczy koniec okresu (miesiąca / kwartału) | Nie — ale można przywrócić (`reopenPeriod`) |
| `locked`      | **Ostateczne zamknięcie ksiąg** — ust. 5    | Nie — technicznie niemożliwe                |

Przejścia statusów:

1. **Miesięczne zamknięcie** (`close → reopen`) — workflow operacyjny,
   nie wynika wprost z UoR. Chroni przed przypadkową modyfikacją
   zaksięgowanego miesiąca.
2. **Trwałe zamknięcie** (`lock`) — po zatwierdzeniu rocznego
   sprawozdania finansowego. Realizuje wymóg ust. 5: okres z statusem
   `locked` odrzuca każdą próbę zapisu, w tym storno.

Szczegółowa dokumentacja:
[korzystanie/fiscal-periods](/docs/korzystanie-z-numify/fiscal-periods).

### Otwarcie nowego roku [#otwarcie-nowego-roku]

Numify otwiera nowy rok obrotowy **automatycznie** — pierwszy zapis w
nowym roku (typowo bilans otwarcia albo pierwsza faktura 2 stycznia)
uruchamia `getOrCreatePeriod` dla stycznia, a numeracja pozycji
dziennika zaczyna się od 1.

Bilans otwarcia z <LegalRef act="UoR" art="5" paragraph="1" /> jest
realizowany jako zapis z `source = 'opening_balance'` w dzienniku —
zobacz [korzystanie/opening-balance](/docs/korzystanie-z-numify/opening-balance).

## Orzecznictwo i interpretacje [#orzecznictwo-i-interpretacje]

* Dyrektor KIS w interpretacji z 2022 r. potwierdził, że brak
  faktycznego zdarzenia gospodarczego w zawieszonej spółce, **mimo
  dokonywanych odpisów amortyzacyjnych**, wyłącza możliwość
  niezamykania ksiąg z ust. 3b (wymaga weryfikacji aktualności przez
  doradcę).
* Sądy administracyjne wielokrotnie podkreślały, że „nieodwracalność"
  z ust. 5 obejmuje również nośniki komputerowe — system informatyczny
  musi uniemożliwiać modyfikację ksiąg zamkniętych na poziomie
  technicznym, nie wystarczy polityka.

## Checklist — zamknięcie roku [#checklist--zamknięcie-roku]

* [ ] Wszystkie faktury grudniowe zaksięgowane.
* [ ] Wyciągi bankowe pobrane do końca grudnia, wiersze dopasowane.
* [ ] Amortyzacja grudniowa wygenerowana.
* [ ] Bilans zamknięcia uzgodniony z ZOiS na 31 XII.
* [ ] Zapisy zamknięcia roku wygenerowane (zespół 4 i 7 wyzerowane).
* [ ] Sprawozdanie finansowe sporządzone i podpisane.
* [ ] Uchwała zgromadzenia wspólników o zatwierdzeniu SF.
* [ ] **W ciągu 15 dni od uchwały** — `lockPeriod` dla wszystkich 12 miesięcy roku.

Po ostatnim kroku rok obrotowy jest zamknięty w rozumieniu ust. 5 —
zmiana jakiegokolwiek zapisu jest technicznie niemożliwa.


---

# Wprowadzenie
URL: https://numifyai.com/docs/pierwsze-kroki/wprowadzenie
Description: Czym jest Numify — narzędzie księgowe dla pojedynczej sp. z o.o., łączące parsowanie dokumentów AI z pełną księgowością podwójnego zapisu zgodną z polskim prawem. Co obsługuje, czego nie, jakie warunki musi spełniać spółka, by sensownie z niego korzystać.
Review status: internal
Updated: 2026-04-16



**Numify** to narzędzie księgowe przeznaczone dla **jednej** sp. z o.o. —
zbudowane tak, żeby właściciel spółki mógł samodzielnie prowadzić pełną
księgowość, a księgowy miał kontrolę nad końcowym kształtem zapisów.

<ComplianceDisclaimer />

## Co Numify robi [#co-numify-robi]

1. **Parsuje dokumenty** — faktury zakupu PDF, paragony, zdjęcia
   wgrywane z telefonu. Model AI (Gemini) wyodrębnia kontrahenta, daty,
   kwoty netto/VAT, stawki — użytkownik tylko **weryfikuje** wynik.
2. **Prowadzi dziennik i księgę główną** — każda zatwierdzona transakcja
   generuje zapis w dzienniku zgodny z zasadą podwójnego księgowania
   (<LegalRef act="UoR" art="14" paragraph="1" />).
3. **Generuje rejestry VAT** — sprzedaży i zakupu, podstawa do JPK\_VAT
   i deklaracji VAT-7/VAT-7K.
4. **Wystawia faktury sprzedaży** — w PLN/EUR/USD, z przeliczeniem
   po kursie średnim NBP z dnia poprzedzającego operację
   (<LegalRef act="UoR" art="30" paragraph="2" />).
5. **Importuje wyciągi bankowe** — mBank, ING, PKO, Santander, Nest Bank
   oraz generyczny CSV. Dopasowuje wpłaty do faktur i księguje płatności.
6. **Sporządza sprawozdanie finansowe** — bilans, rachunek zysków i strat
   w układzie z załącznika 1 lub 5 UoR, informacja dodatkowa, podstawa
   e-sprawozdania w formacie XML dla KRS.
7. **Generuje JPK** — JPK\_KR\_PD (księgi podatkowe), JPK\_ST\_KR (środki
   trwałe), JPK\_VAT (rejestry VAT) — zgodnie z wymogami KAS.

## Czego Numify **nie** robi (lub jeszcze nie robi) [#czego-numify-nie-robi-lub-jeszcze-nie-robi]

* **Nie zastępuje księgowego.** Generuje dokumenty do akceptacji —
  polityka rachunkowości, bilans otwarcia, sprawozdanie finansowe wymagają
  weryfikacji przez osobę odpowiedzialną. Numify nie ponosi
  odpowiedzialności za błędną kwalifikację operacji.
* **Nie obsługuje kadr i płac.** Spółki z pracownikami prowadzą ZUS, PIT-4,
  PIT-11 w innych narzędziach (np. Płatnik, wFirma, Comarch Optima).
* **Nie wysyła e-deklaracji.** JPK i sprawozdanie finansowe generuje
  jako pliki do ręcznego złożenia w e-Urzędzie Skarbowym lub
  e-KRS (do czasu integracji).
* **Nie łączy się z KSeF produkcyjnym.** Parser FA(3) i generator istnieją,
  ale wysyłka/odbiór w trybie online będzie wdrażana zgodnie z terminami
  obowiązkowego KSeF (kwiecień 2026 dla podatników > 200 mln zł
  sprzedaży, lipiec 2026 dla pozostałych) — zobacz
  <FeatureRef slug="/docs/zgodnosc-z-prawem/zmiany-w-2026">Zmiany w 2026</FeatureRef>.
* **Nie prowadzi wielu spółek jako grupy.** Każda spółka to osobna
  przestrzeń — plan kont, bilans otwarcia, polityka rachunkowości są
  trzymane per-spółka.

## Dla jakich spółek Numify jest odpowiedni [#dla-jakich-spółek-numify-jest-odpowiedni]

Zgodnie z <LegalRef act="UoR" art="2" paragraph="1" /> **każda** spółka
z o.o. ma obowiązek prowadzenia **pełnej** księgowości — niezależnie od
wielkości przychodów, liczby pracowników czy formy opodatkowania.

Numify jest zoptymalizowany pod:

* **Mikro i małe spółki z o.o.** — do ok. 200 dokumentów miesięcznie.
* **Sprawozdanie finansowe w układzie załącznika 1** (pełny) lub
  **załącznika 5** (mała jednostka) — zobacz
  <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1">Załącznik 1 UoR</FeatureRef>.
* **Stawki CIT**: 19% standard lub 9% (mały podatnik). Estoński CIT
  jest dostępny w ustawieniach, ale wymaga szczególnej polityki
  rachunkowości — skonsultuj z księgowym.
* **Status VAT**: czynny podatnik VAT, zwolniony lub niezarejestrowany.
* **Waluta operacyjna** PLN, z opcjonalną sprzedażą w EUR/USD.

Dla innych form (JDG, spółka jawna, spółka akcyjna) Numify technicznie
zadziała, ale niektóre funkcje (np. generator e-sprawozdania XML)
zakładają strukturę kapitału sp. z o.o.

## Dla kogo Numify **nie** jest odpowiedni [#dla-kogo-numify-nie-jest-odpowiedni]

* **JDG na ryczałcie / KPiR** — pełna księgowość byłaby uciążliwa
  i nadmiarowa wobec wymogów ustawowych.
* **Spółki z księgowością MSR/MSSF** — Numify trzyma się wyłącznie
  polskiej UoR; <LegalRef act="UoR" art="2" paragraph="3" /> dopuszcza
  MSR dla określonych jednostek, ale nie jest to zakres Numify.
* **Duże spółki z wieloma oddziałami, konsolidacją, wielowalutową
  sprzedażą na dużą skalę.** Numify nie ma narzędzi konsolidacyjnych.

## Warunki techniczne [#warunki-techniczne]

* **Konto e-mail** do logowania (Better Auth).
* **Numer KRS** spółki — 10 cyfr, używany do automatycznego pobrania
  danych z rejestru KRS (via `lookupByKrsFirst`).
* **Rachunek bankowy firmowy** — wymagany dla spółek płatników VAT
  (rachunek z białej listy — zobacz
  <FeatureRef slug="/docs/integracje/biala-lista">Biała lista</FeatureRef>
  po uruchomieniu tej integracji).
* **Dowody księgowe w formie elektronicznej** (PDF, zdjęcie, XML FA(3))
  — Numify nie obsługuje skanerów papierowych; papier trzeba
  zeskanować osobno.

## Dalej [#dalej]

Jeśli powyższe pasuje do Twojej sytuacji, przejdź do
<FeatureRef slug="/docs/pierwsze-kroki/zakladanie-firmy">zakładania firmy</FeatureRef>.
Jeśli nie masz pewności co do formy prawnej lub obowiązków — zajrzyj
najpierw do <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci">Ustawy o rachunkowości</FeatureRef>
i <FeatureRef slug="/docs/zgodnosc-z-prawem/kalendarz-terminow">kalendarza terminów</FeatureRef>.


---

# Pierwsze kroki
URL: https://numifyai.com/docs/pierwsze-kroki
Description: Jak uruchomić sp. z o.o. w Numify — od założenia firmy, przez plan kont i bilans otwarcia, aż po pierwszy zaksięgowany dokument. Sześciostopniowy przewodnik dla właściciela spółki i księgowego obsługującego pierwszą konfigurację.
Review status: internal
Updated: 2026-04-16



**Pierwsze kroki** prowadzą Cię od pustego konta w Numify do pierwszego
zaksięgowanego dokumentu. Jest to **sekwencja jednorazowa** — wykonujesz
ją raz dla każdej spółki, zwykle w dniu migracji z poprzedniego systemu
lub w dniu rozpoczęcia działalności.

Kolejność ma znaczenie: plan kont musi istnieć przed bilansem otwarcia,
a bilans otwarcia przed pierwszym dokumentem bieżącym. Numify sam pilnuje
tej kolejności w większości miejsc, ale dobrze rozumieć dlaczego.

## Dla kogo ten rozdział [#dla-kogo-ten-rozdział]

* **Właściciel spółki** — rejestruje nową sp. z o.o. w KRS, chce zacząć
  prowadzić księgi w Numify od dnia rozpoczęcia działalności.
* **Księgowy** — przejmuje obsługę istniejącej spółki i migruje ją
  z innego systemu (wFirma, Comarch, Excel) do Numify.

W obu przypadkach workflow jest taki sam — różni się tylko **data
otwarcia ksiąg** i treść **bilansu otwarcia**.

## Sekwencja konfiguracji [#sekwencja-konfiguracji]

1. **<FeatureRef slug="/docs/pierwsze-kroki/wprowadzenie">Wprowadzenie</FeatureRef>** —
   co Numify robi, czego nie robi, jakie spółki obsługuje, co jest
   wymagane po stronie użytkownika (NIP, KRS, rachunek bankowy).
2. **<FeatureRef slug="/docs/pierwsze-kroki/zakladanie-firmy">Zakładanie firmy</FeatureRef>** —
   trzykrokowy kreator: KRS → dane firmy → waluta. Co dzieje się
   w tle (automatyczny plan kont) i co trzeba dokonfigurować potem.
3. **<FeatureRef slug="/docs/pierwsze-kroki/plan-kont">Plan kont</FeatureRef>** — domyślny
   plan kont zespołów 0–8 zgodny z <LegalRef act="UoR" art="10" paragraph="1" />,
   dostosowywanie, kiedy dodawać konta analityczne.
4. **<FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">Bilans otwarcia</FeatureRef>** —
   wprowadzanie sald początkowych zgodnie z <LegalRef act="UoR" art="12" paragraph="1" />,
   kiedy go pominąć (nowa spółka), kiedy jest obowiązkowy (migracja).
5. **<FeatureRef slug="/docs/pierwsze-kroki/polityka-rachunkowosci">Polityka rachunkowości</FeatureRef>** —
   dokument wymagany przez <LegalRef act="UoR" art="10" paragraph="2" />,
   generowany przez Numify jako draft do akceptacji przez Zarząd.
6. **<FeatureRef slug="/docs/pierwsze-kroki/pierwszy-dokument">Pierwszy dokument</FeatureRef>** —
   wgranie pierwszej faktury, weryfikacja ekstrakcji AI, powstanie
   transakcji i zapisu w dzienniku. Sprawdzian, że wszystko działa.

## Co nie jest w tym rozdziale [#co-nie-jest-w-tym-rozdziale]

* **Bieżąca praca** z dokumentami, transakcjami i dziennikiem → zobacz
  <FeatureRef slug="/docs/korzystanie-z-numify">Korzystanie z Numify</FeatureRef>.
* **Obowiązki prawne** (terminy VAT, KSeF, sprawozdanie finansowe) →
  zobacz <FeatureRef slug="/docs/zgodnosc-z-prawem">Zgodność z prawem</FeatureRef>.
* **Procesy cykliczne** (codzienne / miesięczne / roczne) → zobacz
  <FeatureRef slug="/docs/procesy">Procesy</FeatureRef>.

## Zanim zaczniesz [#zanim-zaczniesz]

Mieć pod ręką:

* **10-cyfrowy numer KRS** spółki — Numify podciągnie z niego nazwę, NIP,
  REGON, adres i formę prawną z rejestru KRS.
* **Datę rozpoczęcia działalności** (zwykle = data rejestracji w KRS).
* **Datę otwarcia roku obrotowego** — zazwyczaj 1 stycznia, ale dla
  pierwszego (niepełnego) roku może to być dzień rejestracji.
* **Salda kont na dzień otwarcia** — jeśli migrujesz z innego systemu.
* **Dostęp do rachunku bankowego** spółki (numer, IBAN) — dokonfigurujesz
  go w ustawieniach po założeniu firmy.

Nie musisz mieć gotowej polityki rachunkowości — Numify wygeneruje draft.
Nie musisz mieć planu kont — Numify zasieje domyślny zespołów 0–8.


---

# Plan kont
URL: https://numifyai.com/docs/pierwsze-kroki/plan-kont
Description: Domyślny plan kont zespołów 0–8 zasiewany przez Numify podczas tworzenia firmy — oparty na Ustawie o rachunkowości, z tagami balansowymi i RZiS oraz znacznikami JPK_KR_PD. Struktura syntetyczna, kiedy dodawać konta analityczne, jak odnosi się do załączników 1 i 5.
Review status: numify-source
Updated: 2026-04-16



**Plan kont** (zakładowy plan kont) to lista wszystkich kont
księgowych, na których spółka rejestruje operacje gospodarcze.
<LegalRef act="UoR" art="10" paragraph="1" /> (pkt 3 lit. a) wymaga,
aby stanowił część polityki rachunkowości i zawierał co najmniej
wykaz kont księgi głównej, zasady klasyfikacji zdarzeń oraz zasady
prowadzenia i powiązania kont ksiąg pomocniczych.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /chart-of-accounts — drzewo kont zespołów 0–8 z badge'ami typów */}

## Plan domyślny — co zostaje zasiane [#plan-domyślny--co-zostaje-zasiane]

Podczas <FeatureRef slug="/docs/pierwsze-kroki/zakladanie-firmy">zakładania firmy</FeatureRef>
Numify wywołuje <ServiceRef path="src/lib/services/seed-company-accounts.ts" function="seedChartOfAccounts" tests="15" />,
który kopiuje konta z <ServiceRef path="src/db/seed-accounts.ts" /> do
tabeli `chart_accounts` dla nowej spółki.

Wszystkie konta są **syntetyczne** (`isSynthetic: true`) — to konta
księgi głównej w rozumieniu <LegalRef act="UoR" art="15" />. Konta
**analityczne** (podkonta, np. `201-KONTRAH-ACME`) dodajesz sam, gdy
zajdzie potrzeba uszczegółowienia (<LegalRef act="UoR" art="16" paragraph="1" />).

### Zespoły 0–8 [#zespoły-08]

| Zespół | Zakres             | Przykłady                                                                                                                                                                                                     |
| ------ | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **0**  | Aktywa trwałe      | `010` Środki trwałe, `020` WNiP, `070` Umorzenie ST, `080` Środki trwałe w budowie                                                                                                                            |
| **1**  | Środki pieniężne   | `100` Kasa, `130` Rachunek bieżący, `135` Inne rachunki, `140` Krótkoterminowe aktywa finansowe                                                                                                               |
| **2**  | Rozrachunki        | `201` Rozrachunki z odbiorcami, `202` Rozrachunki z dostawcami, `220` VAT należny, `221` VAT naliczony, `229` Pozostałe publicznoprawne, `231` Rozrachunki z pracownikami                                     |
| **3**  | Materiały i towary | `300` Rozliczenie zakupu, `330` Towary, `340` Odchylenia od cen ewidencyjnych                                                                                                                                 |
| **4**  | Koszty wg rodzajów | `400` Amortyzacja, `401` Zużycie materiałów, `402` Usługi obce, `403` Podatki i opłaty, `404` Wynagrodzenia, `405` Ubezpieczenia i inne świadczenia                                                           |
| **7**  | Przychody i koszty | `700` Sprzedaż produktów, `701` Sprzedaż usług, `711` Wartość sprzedanych towarów, `750` Przychody finansowe, `751` Koszty finansowe, `760` Pozostałe przychody operacyjne, `761` Pozostałe koszty operacyjne |
| **8**  | Kapitały i wynik   | `800` Kapitał zakładowy, `801` Kapitał zapasowy, `820` Zysk/strata z lat ubiegłych, `860` Wynik finansowy, `870` Podatek dochodowy                                                                            |

Zespoły **5** i **6** (konta miejsc powstawania kosztów i produkty gotowe)
**nie są** domyślnie zasiewane — dodaj je ręcznie, jeśli spółka prowadzi
ewidencję kosztów według miejsc ich powstawania (tzw. „zespół 5") lub
produkcję wyrobów gotowych.

### Tagowanie kont [#tagowanie-kont]

Każde konto niesie trzy pola meta używane przez Numify:

* `balanceSheetTag` — pozycja w bilansie (<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1">załącznik 1</FeatureRef>).
  Przykład: `010` ma tag `AKT_A_II` (rzeczowe aktywa trwałe).
* `pnlTag` — pozycja w rachunku zysków i strat.
* `jpkPdMarker` — znacznik podatkowy dla JPK\_KR\_PD zgodny
  z Rozporządzeniem MF z 16.08.2024 (zobacz
  <FeatureRef slug="/docs/zgodnosc-z-prawem/zmiany-w-2026">zmiany w 2026</FeatureRef>).

Dzięki tym tagom Numify potrafi automatycznie składać bilans i RZiS
z sald kont — nie musisz ręcznie mapować w czasie zamykania roku.

## Dostosowywanie planu kont [#dostosowywanie-planu-kont]

{/* SCREENSHOT: ekran /chart-of-accounts — dialog „Dodaj konto" z polami kod/nazwa/typ/rodzic */}

### Dodawanie konta analitycznego [#dodawanie-konta-analitycznego]

Gdy potrzebujesz rozdzielić saldo jednego konta syntetycznego (np.
`201`) na poszczególnych kontrahentów:

1. Na `/chart-of-accounts` kliknij **Dodaj konto**.
2. Kod — rozszerzenie kodu rodzica (np. `201-ACME` lub `2010001`).
3. Rodzic — wybierz konto syntetyczne (np. `201`).
4. Typ — dziedziczony z rodzica (`liability` dla `201`).
5. `isSynthetic: false` — konto analityczne.

Konta analityczne **nie pojawią się** w trial balance jako osobna
pozycja — suma ich sald trafia do konta syntetycznego rodzica.
Widzisz je w <FeatureRef slug="/docs/korzystanie-z-numify">księdze pomocniczej</FeatureRef>
(gdy ten ekran zostanie udokumentowany).

### Dezaktywowanie konta [#dezaktywowanie-konta]

Konta niepotrzebne dla Twojej spółki (np. `711` jeśli nie sprzedajesz
towarów) możesz **dezaktywować** — ustawić `isActive: false`. Konto
nie znika (saldo historyczne pozostaje), ale nie można na nim
księgować nowych zapisów i nie pojawia się w podpowiedziach.

### Konta, których nie powinieneś usuwać [#konta-których-nie-powinieneś-usuwać]

Następujące konta są **krytyczne** dla automatycznych procesów Numify
i ich dezaktywacja spowoduje błędy:

* `130` Rachunek bieżący — domyślny debit/credit dla księgowania płatności.
* `220` / `221` — bez nich nie powstaną rejestry VAT.
* `201` / `202` — rozrachunki z kontrahentami, używane w auto-dekretowaniu.
* `860` Wynik finansowy — używane w zamknięciu roku.
* `800` Kapitał zakładowy — wymagane w bilansie otwarcia sp. z o.o.

## Mapowania kategoria → konto [#mapowania-kategoria--konto]

Razem z planem kont Numify zasiewa **domyślne mapowania** — dla każdej
kategorii transakcji (np. „usługi obce", „czynsz", „sprzedaż produktów")
określa, na jakie konto trafia debet, kredyt i VAT. Dzięki temu
auto-dekretowanie działa od razu po <FeatureRef slug="/docs/pierwsze-kroki/zakladanie-firmy">założeniu firmy</FeatureRef>,
bez konfiguracji.

Mapowania zobaczysz i zmienisz w `/settings` → „Mapowania kategorii".
Zmiana dotyczy **nowych** transakcji — historyczne zapisy pozostają
bez zmian (<LegalRef act="UoR" art="23" />).

## Relacja do załączników UoR [#relacja-do-załączników-uor]

* **<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/zalacznik-1">Załącznik 1</FeatureRef>**
  (pełny bilans) — tagi `balanceSheetTag` mapują konta na pozycje
  AKT\_A\_I, AKT\_A\_II, PAS\_A\_I itd. Używany dla spółek niespełniających
  kryteriów jednostki małej.
* **Załącznik 5** (mała jednostka) — uproszczony układ bilansu i RZiS.
  Spółka mała (zgodnie z art. 3 ust. 1c–1e UoR) może wybrać ten układ.
  Tagowanie w Numify zakłada układ z załącznika 1 — przy generowaniu
  sprawozdania w układzie z załącznika 5 zachodzi automatyczne
  zmapowanie do uproszczonych pozycji.

## Ograniczenia [#ograniczenia]

* **Brak importu planu kont z innego systemu.** Jeśli migrujesz ze spółki
  używającej niestandardowego planu kont (np. rozszerzonej numeracji
  typu `4-01-001-…`), musisz ręcznie dodać brakujące konta przed
  wprowadzeniem <FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilansu otwarcia</FeatureRef>.
* **Brak wersjonowania planu kont.** Zmiana nazwy lub tagu konta działa
  „od teraz" — historyczne zapisy zachowują referencję przez ID konta,
  ale w raportach pojawi się aktualna nazwa.
* **Brak wielowalutowych kont.** Wszystkie konta są w PLN. Operacje
  walutowe przeliczane są po kursie NBP na moment zapisu
  (<LegalRef act="UoR" art="30" paragraph="2" />).

## Dalej [#dalej]

Plan kont jest gotowy. Następny krok: <FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilans otwarcia</FeatureRef>
— wprowadzenie sald początkowych, aby księgi faktycznie rozpoczęły
swoje życie (<LegalRef act="UoR" art="12" paragraph="1" />).


---

# Pierwszy dokument
URL: https://numifyai.com/docs/pierwsze-kroki/pierwszy-dokument
Description: Kompletny przepływ od wgrania pierwszej faktury zakupu do zaksięgowania w dzienniku — pięć kroków, każdy z linkiem do strony szczegółowej. Sprawdzian, że onboarding, plan kont, bilans otwarcia i mapowania kategorii są poprawnie skonfigurowane.
Review status: internal
Updated: 2026-04-16



**Pierwszy dokument** to sprawdzian, że onboarding przeszedł pomyślnie.
Wgrywasz jedną fakturę zakupu i obserwujesz, jak Numify prowadzi ją
od pliku PDF do zapisu w dzienniku — przez pięć kroków, z weryfikacją
na każdym etapie.

<ComplianceDisclaimer />

Tutaj tylko **chodzimy przez flow na wysokim poziomie**. Po każdym
kroku jest link do strony, która opisuje go w pełni — nie będziemy
duplikować tych treści.

## Zanim zaczniesz [#zanim-zaczniesz]

Sprawdź, że masz:

* **Założoną spółkę** (<FeatureRef slug="/docs/pierwsze-kroki/zakladanie-firmy">zakładanie firmy</FeatureRef>)
  → plan kont zasiany automatycznie.
* **Bilans otwarcia** (<FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilans otwarcia</FeatureRef>)
  → przynajmniej konto <AccountRef code="130" /> ma saldo, z którego
  można zapłacić fakturę, i konto <AccountRef code="800" /> balansuje.
* **Status VAT** skonfigurowany w `/settings`.
* **Plik PDF** faktury zakupu (dostawca, data, kwoty, stawka VAT).

## Krok 1 — Wgranie dokumentu [#krok-1--wgranie-dokumentu]

{/* SCREENSHOT: ekran /documents — drag-and-drop zone z przeciąganą fakturą PDF */}

Na `/documents` przeciągasz plik PDF (lub PNG/JPG/HEIC) do obszaru
upload. Numify:

1. Zapisuje oryginał w Cloudflare R2 — bez modyfikacji.
2. Tworzy zadanie w kolejce BullMQ do asynchronicznego parsowania.
3. Pokazuje wiersz w tabeli ze statusem „Przetwarzanie…".

Pełny opis obsługiwanych formatów i pipeline'u parsowania →
<FeatureRef slug="/docs/korzystanie-z-numify/dokumenty">Dokumenty</FeatureRef>.

## Krok 2 — Ekstrakcja AI [#krok-2--ekstrakcja-ai]

{/* SCREENSHOT: ekran /documents/[id] — podgląd PDF z panelem wyekstrahowanych pól */}

Po 10–30 sekundach status zmienia się na „Do weryfikacji". Klikając
w wiersz, otwierasz podgląd z dwoma panelami:

* **Lewy** — oryginał faktury (PDF).
* **Prawy** — dane wyodrębnione przez model AI:
  * Nazwa i NIP dostawcy.
  * Numer faktury.
  * Data wystawienia i data sprzedaży.
  * Kwota netto, VAT, brutto per stawka.
  * Sugerowana kategoria kosztowa.

Dane spełniają schemat Zod — jeśli model nie wyekstrahuje pola
wymaganego (np. NIP), Numify pokaże puste pole do ręcznego uzupełnienia.

## Krok 3 — Weryfikacja [#krok-3--weryfikacja]

**Ty decydujesz, czy dane są poprawne.** To jest **zasada HITL**
(Human in the Loop) w Numify — model AI nigdy nie księguje bez
potwierdzenia przez człowieka.

Typowe rzeczy do sprawdzenia:

* **NIP dostawcy** — czy zgadza się z nagłówkiem faktury. Jeśli
  dostawca nie istnieje jeszcze w <FeatureRef slug="/docs/korzystanie-z-numify/kontrahenci">kontrahentach</FeatureRef>,
  Numify zaproponuje utworzenie nowego rekordu (z automatycznym
  pobraniem z <ServiceRef path="src/lib/services/krs-lookup.ts" /> / GUS).
* **Kwoty** — czy netto + VAT = brutto z dokładnością co do grosza.
  Błędy rachunkowe w fakturze źródłowej to problem dostawcy
  (<LegalRef act="UoR" art="22" paragraph="2" /> — korekta przez
  wysłanie sprostowania), ale zauważyć je należy teraz.
* **Stawka VAT** — 23%, 8%, 5%, 0%, „zw." — model czasami myli, zwłaszcza
  na fakturach zagranicznych (VIES).
* **Kategoria** — czy sugerowana kategoria (np. „usługi obce") pasuje
  do treści faktury. Kategoria wyznacza konta debet/credit/VAT przez
  mapowania z <FeatureRef slug="/docs/pierwsze-kroki/plan-kont">planu kont</FeatureRef>.

## Krok 4 — Powstaje transakcja [#krok-4--powstaje-transakcja]

{/* SCREENSHOT: ekran /transactions z nowo utworzoną transakcją w statusie Unverified */}

Kliknięcie **Zatwierdź dane** tworzy **transakcję** (`type: expense`)
w tabeli `transactions` ze statusem **niezweryfikowana**. Transakcja
to *zamiar* księgowania — nie wygenerowała jeszcze zapisu w dzienniku.

Na ekranie <FeatureRef slug="/docs/korzystanie-z-numify/transakcje">transakcje</FeatureRef>
widzisz ten wiersz i możesz:

* Zmienić kategorię / konto przed zaksięgowaniem.
* Dodać opis / notatkę.
* Przypisać projekt (jeśli projekt istnieje).
* Oznaczyć jako **B+R** (badania i rozwój) — wpływa na ulgi podatkowe.

## Krok 5 — Zapis w dzienniku [#krok-5--zapis-w-dzienniku]

Klikasz **Zweryfikuj transakcję**. Numify:

1. Sprawdza, że okres obrachunkowy jest **otwarty** (przez
   <ServiceRef path="src/lib/services/fiscal-periods.ts" function="ensurePeriodOpen" />).
2. Wywołuje auto-dekretowanie — dobiera konta debet/credit/VAT
   z mapowań kategorii.
3. Tworzy zapis w `journal_entries` (źródło: `transaction`) i wiersze
   w `journal_lines` — co najmniej dwa (debet + kredyt), zgodnie
   z zasadą podwójnego zapisu (<LegalRef act="UoR" art="14" paragraph="1" />).
4. Waliduje, że debet = kredyt (co do grosza).
5. Ustawia zapisowi `isPosted: true`, nadaje kolejny numer w dzienniku.

Dla typowej faktury zakupu usługi (kategoria „usługi obce", 23% VAT)
zapis wygląda tak:

| Nr | Konto                                              | Debet | Kredyt |
| -- | -------------------------------------------------- | ----- | ------ |
| 1  | <AccountRef code="402" /> Usługi obce              | Netto | —      |
| 2  | <AccountRef code="221" /> VAT naliczony            | VAT   | —      |
| 3  | <AccountRef code="202" /> Rozrachunki z dostawcami | —     | Brutto |

Zapis pojawia się w **dzienniku** (`/journal`) z kolejnym numerem
i jest **nieusuwalny** (<LegalRef act="UoR" art="25" paragraph="1" />).
Ewentualną korektę wprowadza się zapisem storno.

## Co dzieje się **po** zaksięgowaniu [#co-dzieje-się-po-zaksięgowaniu]

Po pierwszym zapisie można zaobserwować:

* **Pulpit** (`/dashboard`) — karta „Koszty" zwiększa się o kwotę
  brutto zatwierdzonej transakcji (zobacz
  <FeatureRef slug="/docs/korzystanie-z-numify/pulpit">pulpit</FeatureRef>).
* **Dziennik** — zapis z kolejnym numerem, statusem „Zaksięgowany"
  i źródłem „transaction".
* **Księga główna** (`/general-ledger`) — salda kont <AccountRef code="402" />,
  <AccountRef code="221" /> i <AccountRef code="202" /> zaktualizowane.
* **Rejestr VAT zakupu** — dodany wiersz z kwotą netto i VAT do
  odliczenia.
* **Trial balance** (<LegalRef act="UoR" art="18" paragraph="1" />) —
  zaktualizowane saldo; zapis można zwierzyć z dziennikiem.

## Kiedy coś pójdzie nie tak [#kiedy-coś-pójdzie-nie-tak]

| Objaw                                     | Najprawdopodobniejsza przyczyna                                                          | Gdzie zajrzeć                                                                                         |
| ----------------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| „Okres jest zamknięty" przy zatwierdzaniu | Okres obrachunkowy zamknięty lub zablokowany — transakcja ma datę spoza otwartego okresu | <FeatureRef slug="/docs/korzystanie-z-numify">Okresy obrachunkowe</FeatureRef> (docs w przygotowaniu) |
| „Brak mapowania dla kategorii"            | Kategoria nie ma przypisanych kont debet/credit                                          | `/settings` → Mapowania kategorii                                                                     |
| Debet ≠ kredyt                            | Błąd zaokrągleń w danych wyekstrahowanych                                                | Wróć do weryfikacji dokumentu; sprawdź kwoty co do grosza                                             |
| Status „Błąd parsowania"                  | Plik uszkodzony lub model nie wyodrębnił wymaganych pól                                  | <FeatureRef slug="/docs/korzystanie-z-numify/dokumenty">Dokumenty → sekcja błędów</FeatureRef>        |

## Dalej [#dalej]

Jeśli pierwszy dokument zaksięgował się poprawnie — **onboarding jest
zakończony**. Do pracy bieżącej zajrzyj do
<FeatureRef slug="/docs/korzystanie-z-numify">Korzystania z Numify</FeatureRef>,
a do planowania terminów (VAT, CIT, sprawozdanie) — do
<FeatureRef slug="/docs/zgodnosc-z-prawem/kalendarz-terminow">kalendarza terminów</FeatureRef>.


---

# Polityka rachunkowości
URL: https://numifyai.com/docs/pierwsze-kroki/polityka-rachunkowosci
Description: Dokument wymagany przez art. 10 Ustawy o rachunkowości, opisujący zasady prowadzenia ksiąg. Numify generuje draft w języku polskim na podstawie ustawień spółki, ale Zarząd musi go zweryfikować i zatwierdzić pisemnie przed przyjęciem.
Review status: numify-source
Updated: 2026-04-17



**Polityka rachunkowości** to pisemny dokument opisujący, **jak** spółka
prowadzi księgi — rok obrotowy, metody wyceny, plan kont, system ochrony
danych. <LegalRef act="UoR" art="10" paragraph="1" /> nakłada obowiązek
posiadania takiej dokumentacji; <LegalRef act="UoR" art="10" paragraph="2" />
określa, że ustala ją i aktualizuje **kierownik jednostki** (dla sp. z o.o.
— zarząd) **w formie pisemnej**.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /accounting-policy — iframe z wygenerowanym dokumentem HTML + przyciski Drukuj/Pobierz/Generuj */}

## Co zawiera [#co-zawiera]

Zgodnie z <LegalRef act="UoR" art="10" paragraph="1" /> dokumentacja
polityki rachunkowości powinna określać co najmniej:

1. **Rok obrotowy** i wchodzące w jego skład okresy sprawozdawcze.
2. **Metody wyceny** aktywów i pasywów oraz ustalania wyniku finansowego.
3. **Sposób prowadzenia ksiąg rachunkowych**, w tym:
   * **Zakładowy plan kont** — wykaz kont księgi głównej, zasady
     klasyfikacji zdarzeń, zasady prowadzenia kont ksiąg pomocniczych.
   * **Wykaz ksiąg rachunkowych** — a przy prowadzeniu komputerowym
     wykaz zbiorów danych, ich struktura i wzajemne powiązania.
   * **Opis systemu przetwarzania danych** — a przy systemie
     informatycznym: opis programu, algorytmów, zabezpieczeń, wersji
     oprogramowania i daty rozpoczęcia eksploatacji.
4. **System ochrony danych** i dowodów księgowych — zasady kopii
   zapasowych, dostępu, archiwizacji.

## Jak Numify generuje draft [#jak-numify-generuje-draft]

Na ekranie `/accounting-policy` po kliknięciu **Generuj ponownie**
Numify wywołuje <ServiceRef path="src/lib/services/accounting-policy.ts" function="generateAccountingPolicy" tests="27" />,
który czyta z bazy:

* Dane spółki (nazwa, NIP, adres) z `companies`.
* Rok obrotowy (`fiscalYearStartMonth`) z `companies`.
* Status VAT (`vatStatus`), częstotliwość (`vatFilingFrequency`),
  stawkę CIT (`citRate`).
* Liczbę aktywnych kont (`chart_accounts`).
* Obecność środków trwałych (`fixed_assets`).

Na tej podstawie składa dokument HTML w języku polskim, zawierający
sekcje od „I. Postanowienia ogólne" po „XII. Ochrona danych" —
z odwołaniami do konkretnych przepisów UoR.

{/* SCREENSHOT: ekran /accounting-policy — wygenerowany dokument rozdziały I–XII widoczne w iframe */}

Dokument można:

* **Wydrukować** lub zapisać jako PDF (przez okno drukowania przeglądarki).
* **Pobrać jako HTML** — do edycji we własnym edytorze.

## Co draft zawiera, czego nie [#co-draft-zawiera-czego-nie]

Wygenerowany draft pokrywa **ramę** wymaganą przez UoR, ale **nie**
jest gotowy do przyjęcia „w ciemno" — kierownik jednostki musi:

* Sprawdzić, czy **metody wyceny** pasują do rzeczywistej polityki
  spółki (np. FIFO vs. średnia ważona dla zapasów, metoda amortyzacji
  środków trwałych).
* Uzupełnić **indywidualne uproszczenia** (zgodnie z art. 4 ust. 4
  UoR), jeśli spółka z nich korzysta.
* Opisać **system informatyczny** — w drafcie Numify znajdzie się
  zapis typu „system Numify AI, wersja X.Y, wdrożony od RRRR-MM-DD", ale
  szczegóły ochrony danych, kopii zapasowych i kontroli dostępu
  **są po stronie spółki**.
* Dodać **listę ksiąg pomocniczych** — jeśli spółka używa kont
  analitycznych (np. rozrachunki wg kontrahentów), wyliczyć je.
* Określić **metody inwentaryzacji** — Numify nie prowadzi
  inwentaryzacji; zapis powinien wskazać praktykę spółki.

## Proces przyjęcia [#proces-przyjęcia]

1. **Generuj draft** w Numify → pobierz HTML.
2. **Przeredaguj** w edytorze (Word, Google Docs, etc.) dostosowując
   brakujące sekcje.
3. **Przedstaw Zarządowi** — uchwała Zarządu o przyjęciu polityki
   rachunkowości (art. 10 ust. 2 — „w formie pisemnej").
4. **Archiwizuj** — podpisany dokument trzymaj z dokumentacją spółki
   przez cały okres obowiązywania + 5 lat po zmianie (analogicznie
   do <LegalRef act="UoR" art="74" />).
5. **Aktualizuj**, gdy zmieni się coś istotnego — np. stawka CIT, forma
   opodatkowania (przejście na estoński CIT), struktura planu kont.

## Data przyjęcia i retroaktywność [#data-przyjęcia-i-retroaktywność]

<LegalRef act="UoR" art="8" paragraph="2" /> zasadniczo wyłącza
retroaktywną zmianę polityki rachunkowości w trakcie roku obrotowego —
zmiana wchodzi w życie **od początku kolejnego roku**. Wyjątek: jeśli
wyniknie, że dotychczasowa polityka nie daje rzetelnego obrazu sytuacji
finansowej, zmiana z uzasadnieniem jest dopuszczalna.

Przy zmianie Numify nie wersjonuje automatycznie polityki — aktualizacja
to ręczny proces: nowa uchwała Zarządu, nowy dokument, stary zachowany
w archiwum.

## Relacja do innych dokumentów [#relacja-do-innych-dokumentów]

* **Plan kont** — jest **częścią** polityki rachunkowości (art. 10 ust. 1
  pkt 3 lit. a). W drafcie pojawia się jako załącznik z wyliczeniem
  kont zasianych przez Numify — zobacz
  <FeatureRef slug="/docs/pierwsze-kroki/plan-kont">plan kont</FeatureRef>.
* **Bilans otwarcia** — dokument osobny, ale **opiera się na** polityce
  (np. metoda wyceny środków trwałych wpływa na saldo konta <AccountRef code="010" />) —
  zobacz <FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilans otwarcia</FeatureRef>.
* **Standardy krajowe (KSR)** — <LegalRef act="UoR" art="10" paragraph="3" />
  pozwala stosować krajowe standardy rachunkowości w sprawach
  nieuregulowanych UoR. Jeśli spółka z nich korzysta, wyszczególnij
  w polityce (np. „w zakresie leasingu stosuje się KSR nr 5").

## Ograniczenia [#ograniczenia]

* **Brak wielowersyjności.** Generator zawsze tworzy dokument „na teraz"
  z aktualnych ustawień spółki. Historyczne wersje musisz archiwizować
  we własnym zakresie.
* **Brak szablonów dla innych form prawnych.** Draft zakłada sp. z o.o.
  z pełną księgowością. Dla spółki cywilnej, JDG lub jednostki małej
  stosującej załącznik 5 wygenerowany tekst wymaga poważnej edycji.
* **Brak weryfikacji prawnej.** Treść drafta opiera się na typowych
  zapisach UoR, ale **nie jest opinią księgową ani prawną**. Konsultacja
  z księgowym / biegłym rewidentem jest zalecana.
* **Format wyjściowy tylko HTML.** Brak bezpośredniego eksportu do DOCX
  — konwersję wykonujesz we własnym edytorze (Word potrafi otworzyć HTML).

## Dalej [#dalej]

Polityka rachunkowości to ostatni formalny krok przed pracą bieżącą.
Czas sprawdzić, że całość działa — przejdź do
<FeatureRef slug="/docs/pierwsze-kroki/pierwszy-dokument">pierwszego dokumentu</FeatureRef>.


---

# Bilans otwarcia
URL: https://numifyai.com/docs/pierwsze-kroki/bilans-otwarcia
Description: Wprowadzanie sald początkowych kont na dzień otwarcia ksiąg rachunkowych. Kiedy jest obowiązkowy (rozpoczęcie działalności, początek roku obrotowego, migracja z innego systemu), jak wprowadzić w Numify, jak walidowane jest równanie bilansowe aktywa = pasywa.
Review status: numify-source
Updated: 2026-04-17



**Bilans otwarcia** to pierwszy zapis w księdze głównej na dzień
otwarcia ksiąg rachunkowych. Wprowadza salda początkowe wszystkich
kont bilansowych (aktywa, pasywa, kapitał własny) — bez niego księgi
nie mają „zera startowego" i żadne późniejsze saldo nie byłoby
wiarygodne.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /opening-balance — tabela z wierszami konto/kwota + suma aktywów/pasywów u dołu */}

## Kiedy wprowadzasz bilans otwarcia [#kiedy-wprowadzasz-bilans-otwarcia]

<LegalRef act="UoR" art="12" paragraph="1" /> wymienia momenty, w których
otwiera się księgi rachunkowe:

| Sytuacja                                           | Co wprowadzasz                                                                                       | Data otwarcia                                           |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| **Nowa spółka** (pierwszy dzień działalności)      | Tylko kapitał zakładowy (<AccountRef code="800" />) + środki na rachunku (<AccountRef code="130" />) | Dzień pierwszego zdarzenia gospodarczego                |
| **Początek roku obrotowego** (spółka kontynuująca) | Salda wszystkich kont bilansowych z zamknięcia roku poprzedniego                                     | Pierwszy dzień roku obrotowego                          |
| **Migracja z innego systemu**                      | Salda wszystkich kont na dzień przejęcia przez Numify                                                | Dzień przejęcia (zwykle 1. dzień miesiąca lub kwartału) |
| **Zmiana formy prawnej**                           | Salda ze spółki przed zmianą                                                                         | Dzień wpisu zmiany                                      |

Zasada **ciągłości** (<LegalRef act="UoR" art="5" paragraph="1" />)
oznacza, że **bilans zamknięcia** poprzedniego roku musi równać się
**bilansowi otwarcia** roku bieżącego — co do grosza.

## Jak wprowadzić w Numify [#jak-wprowadzić-w-numify]

Na ekranie `/opening-balance`:

1. Wybierz **rok obrotowy** (domyślnie bieżący).
2. Wybierz **datę otwarcia** (zwykle `YYYY-01-01` lub dzień rozpoczęcia
   działalności).
3. Dla każdego konta z niezerowym saldem dodaj wiersz:
   * **Konto** — wybierasz z planu kont (tylko aktywne).
   * **Kwota** — wpisujesz w PLN; Numify przechowuje wewnętrznie
     w **groszach** (1 PLN = 100 groszy).
4. Numify automatycznie rozdziela salda:
   * Konta **aktywne** (`type: asset`) → strona **debet**.
   * Konta **pasywne** i **kapitałowe** (`liability`, `equity`) →
     strona **kredyt**.
5. U dołu widzisz sumę aktywów i sumę pasywów — muszą być **równe**.

{/* SCREENSHOT: ekran /opening-balance — błąd walidacji „Aktywa ≠ Pasywa" z różnicą w groszach */}

Jeśli suma się nie zgadza, Numify **nie zapisze** zapisu — wywołuje
<ServiceRef path="src/lib/services/opening-balance.ts" function="createOpeningBalance" tests="12" />,
który używa `validateOpeningBalance` z `src/lib/validation/financial.ts`
i rzuca błąd.

## Co dzieje się po „Zapisz" [#co-dzieje-się-po-zapisz]

Po kliknięciu **Zapisz bilans otwarcia** Numify:

1. Tworzy okres obrachunkowy otwarcia (np. styczeń roku X) — przez
   <ServiceRef path="src/lib/services/fiscal-periods.ts" function="getOrCreatePeriod" tests="30" />.
2. Tworzy **pojedynczy zapis w dzienniku** z polem `source: "opening_balance"`:
   * Numer zapisu — kolejny w danym roku obrotowym (zaczynamy od 1).
   * Opis — `Bilans otwarcia YYYY`.
   * `isPosted: true`, `postedAt: now` — zaksięgowany od razu.
3. Tworzy wiersze zapisu (`journalLines`) — po jednym na każde konto
   z niezerowym saldem.
4. Waliduje równanie **debet = kredyt** (zasada zapisu podwójnego,
   <LegalRef act="UoR" art="15" />).

Zapis pozostaje **nieusuwalny** — zgodnie z <LegalRef act="UoR" art="25" paragraph="1" />.
Korekta błędu w bilansie otwarcia odbywa się przez zapis storno
w tym samym okresie (jeśli jeszcze otwarty) — zobacz
<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-25-slad-rewizyjny">art. 25 UoR</FeatureRef>.

## Typowy bilans otwarcia nowej sp. z o.o. [#typowy-bilans-otwarcia-nowej-sp-z-oo]

Nowa spółka z o.o. zarejestrowana w KRS, z kapitałem zakładowym 5 000 PLN
wpłaconym na rachunek bankowy, ma bardzo prosty bilans otwarcia:

| Konto                     | Nazwa             | Strona | Kwota                     |
| ------------------------- | ----------------- | ------ | ------------------------- |
| <AccountRef code="130" /> | Rachunek bieżący  | Debet  | 5 000,00 PLN              |
| <AccountRef code="800" /> | Kapitał zakładowy | Kredyt | 5 000,00 PLN              |
| **Razem**                 |                   |        | **5 000,00 = 5 000,00** ✓ |

W rzeczywistości często jest nieco bardziej skomplikowany (koszty
rejestracji, zaliczka na PCC, opłata notarialna), ale zasada pozostaje
ta sama — **aktywa = pasywa**.

## Typowy bilans otwarcia przy migracji [#typowy-bilans-otwarcia-przy-migracji]

Spółka przenosząca się z innego systemu (np. po zamknięciu wFirmy
na 31.12) wprowadza **salda końcowe** wszystkich kont bilansowych:

| Przykładowe konto                                     | Po której stronie | Dlaczego                                                        |
| ----------------------------------------------------- | ----------------- | --------------------------------------------------------------- |
| <AccountRef code="010" /> Środki trwałe               | Debet             | Wartość brutto środków trwałych.                                |
| <AccountRef code="070" /> Umorzenie środków trwałych  | Kredyt            | Narastające umorzenie (saldo dodatnie, ale konto kontraktywne). |
| <AccountRef code="130" /> Rachunek bieżący            | Debet             | Saldo bankowe na 31.12.                                         |
| <AccountRef code="201" /> Rozrachunki z odbiorcami    | Debet lub kredyt  | Debet = należności; kredyt = zaliczki od klientów.              |
| <AccountRef code="202" /> Rozrachunki z dostawcami    | Kredyt lub debet  | Kredyt = zobowiązania; debet = zaliczki dla dostawców.          |
| <AccountRef code="220" /> VAT należny                 | Kredyt            | Zobowiązanie wobec US.                                          |
| <AccountRef code="221" /> VAT naliczony               | Debet             | Należność od US (do odliczenia).                                |
| <AccountRef code="800" /> Kapitał zakładowy           | Kredyt            | Kapitał pierwotny.                                              |
| <AccountRef code="801" /> Kapitał zapasowy            | Kredyt            | Skumulowane zyski zatrzymane.                                   |
| <AccountRef code="820" /> Zysk/strata z lat ubiegłych | Kredyt lub debet  | Wynik nierozliczony.                                            |

**Ważne:** konta zespołu 4 i 7 (koszty/przychody) na **koniec** roku są
zamykane na <AccountRef code="860" /> (wynik finansowy), więc w bilansie
otwarcia kolejnego roku **nie powinny** mieć sald. Numify technicznie
dopuszcza wprowadzenie salda na koncie kosztów/przychodów (np. przy
migracji w trakcie roku), ale to wyjątek — wymaga uzasadnienia
w polityce rachunkowości.

## Ograniczenia [#ograniczenia]

* **Jeden bilans otwarcia na rok obrotowy.** Próba wprowadzenia
  drugiego dla tego samego roku zwraca błąd „Opening balance already
  exists for fiscal year YYYY".
* **Konta pozabilansowe** (`off_balance`) są **pomijane** — wymagają
  osobnych zapisów pozabilansowych, nie obsługiwanych przez ten kreator.
* **Konta analityczne** traktowane są tak samo jak syntetyczne —
  wprowadź saldo na tym poziomie szczegółowości, w jakim chcesz śledzić
  dalej.
* **Brak importu CSV.** Salda wprowadzasz ręcznie wiersz po wierszu —
  dla dużego planu kont jest to pracochłonne. Funkcja importu jest
  w planach.
* **Walidacja wymaga sumy aktywów = sumy pasywów z kapitałem.** Jeśli
  migrujesz spółkę z ujemnym kapitałem własnym, wprowadź stratę
  z lat ubiegłych na <AccountRef code="820" /> po stronie debetowej
  (saldo ujemne = debet kapitału = strata).

## Dalej [#dalej]

Po wprowadzeniu bilansu otwarcia czas na formalność: wygenerowanie
<FeatureRef slug="/docs/pierwsze-kroki/polityka-rachunkowosci">polityki rachunkowości</FeatureRef>
— dokumentu wymaganego przez <LegalRef act="UoR" art="10" paragraph="2" />.


---

# Zakładanie firmy
URL: https://numifyai.com/docs/pierwsze-kroki/zakladanie-firmy
Description: Trzykrokowy kreator onboardingowy w Numify — KRS lookup, dane firmy, waluta. Jak Numify pobiera dane z rejestru KRS, co dzieje się automatycznie po utworzeniu (zasianie planu kont), co trzeba dokonfigurować w ustawieniach przed pierwszym dokumentem.
Review status: numify-source
Updated: 2026-04-16



**Zakładanie firmy** to pierwsza czynność po zalogowaniu do Numify —
trzykrokowy kreator, który w tle uruchamia pełne księgi rachunkowe
nowej sp. z o.o.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /onboarding krok 1 — pole KRS + przycisk Szukaj */}

## Krok 1 — KRS [#krok-1--krs]

Na ekranie `/onboarding` podajesz **10-cyfrowy numer KRS** spółki.
Numify wysyła zapytanie do publicznego rejestru KRS i pobiera:

* **Nazwę pełną** (np. „Przykładowa Spółka z o.o.") i **skróconą**
  (bez formy prawnej — „Przykładowa").
* **NIP** i **REGON**.
* **Formę prawną** (domyślnie `sp_z_oo`, wykrywana z treści rejestru).
* **Adres** (ulica, kod pocztowy, miasto).

Jeśli lookup się powiedzie — kreator automatycznie przechodzi do
kroku 2 z uzupełnionymi polami i zielonym banerem „Uzupełniono
automatycznie z rejestru KRS". Jeśli nie — możesz wypełnić ręcznie.

Pobieranie realizuje <ServiceRef path="src/lib/services/krs-lookup.ts" tests="29" /> —
brak rachunku bankowego w tym źródle (to pole wypełniasz osobno
w ustawieniach).

## Krok 2 — Dane firmy [#krok-2--dane-firmy]

{/* SCREENSHOT: ekran /onboarding krok 2 — formularz z wypełnionymi polami po KRS lookupie */}

Na tym etapie potwierdzasz / poprawiasz pobrane dane:

| Pole           | Wymagane      | Uwagi                                                              |
| -------------- | ------------- | ------------------------------------------------------------------ |
| Nazwa firmy    | Tak           | Pełna nazwa z formą prawną, używana na fakturach i w sprawozdaniu. |
| Nazwa skrócona | Nie           | Bez formy prawnej, używana w eksportach i raportach.               |
| NIP            | Tak (10 cyfr) | Używany do filtrowania rejestrów VAT i JPK.                        |
| KRS            | Tak (10 cyfr) | Identyfikator sp. z o.o. w rejestrze.                              |
| REGON          | Nie           | Wypełnia się automatycznie po KRS lookup.                          |
| Adres          | Nie           | Używany na fakturach i w polityce rachunkowości.                   |

Walidacja w kreatorze: NIP i KRS muszą mieć dokładnie 10 cyfr, nazwa
firmy nie może być pusta. Po przekazaniu walidacji przechodzisz dalej.

## Krok 3 — Waluta [#krok-3--waluta]

{/* SCREENSHOT: ekran /onboarding krok 3 — wybór waluty PLN/EUR/USD */}

Wybierasz **walutę operacyjną** (domyślnie PLN). To waluta, w której
Numify będzie:

* Przechowywać kwoty w dzienniku i księdze głównej (w groszach — zobacz
  <FeatureRef slug="/docs/koncepcje">koncepcje → grosze</FeatureRef>
  gdy ta strona powstanie).
* Prezentować raporty (bilans, RZiS, trial balance).

Dla sp. z o.o. zarejestrowanej w Polsce walutą prawidłową jest
**PLN** — to wymóg przeliczenia dowodów walutowych
(<LegalRef act="UoR" art="21" paragraph="3" />) oraz prowadzenia
ksiąg w języku i walucie polskiej (<LegalRef act="UoR" art="9" />).

Waluty EUR/USD zostawione są jako opcja dla jednostek zagranicznych
lub szczególnych przypadków — w typowej sp. z o.o. nie zmieniaj PLN.

## Co dzieje się automatycznie po „Utwórz firmę" [#co-dzieje-się-automatycznie-po-utwórz-firmę]

Po kliknięciu **Utwórz firmę** Numify wykonuje synchronicznie:

1. Tworzy rekord `companies` w bazie.
2. Wywołuje <ServiceRef path="src/lib/services/seed-company-accounts.ts" function="seedCompanyDefaults" tests="15" />,
   który:
   * Zasiewa pełny plan kont zespołów 0–8 (ok. 50 syntetycznych kont)
     z <ServiceRef path="src/db/seed-accounts.ts" /> — zobacz
     <FeatureRef slug="/docs/pierwsze-kroki/plan-kont">plan kont</FeatureRef>.
   * Tworzy domyślne mapowania kategoria → konto (debit/credit/VAT)
     dla automatycznego dekretowania.
3. Przekierowuje do `/dashboard`.

W tle **nie** są jeszcze tworzone:

* Okresy obrachunkowe (tworzone on-demand przy pierwszym zapisie
  — zobacz <ServiceRef path="src/lib/services/fiscal-periods.ts" function="getOrCreatePeriod" tests="30" />).
* Bilans otwarcia (wprowadzasz ręcznie — zobacz
  <FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilans otwarcia</FeatureRef>).
* Polityka rachunkowości (generowana on-demand — zobacz
  <FeatureRef slug="/docs/pierwsze-kroki/polityka-rachunkowosci">polityka rachunkowości</FeatureRef>).
* Rachunek bankowy (dodajesz osobno — zobacz
  <FeatureRef slug="/docs/korzystanie-z-numify/konta-bankowe">konta bankowe</FeatureRef>).

## Co dokonfigurować po onboardingu [#co-dokonfigurować-po-onboardingu]

Kreator onboardingowy celowo zbiera **minimum** wymagane do założenia
spółki. Resztę ustawień uzupełniasz w `/settings` **przed** pierwszym
dokumentem:

| Ustawienie                                                        | Gdzie                                       | Dlaczego ważne                                                                                                      |
| ----------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Data rejestracji** (`registrationDate`)                         | `/settings` → Dane firmy                    | Selektory dat w raportach nie pokażą okresów wcześniejszych niż rejestracja.                                        |
| **Status VAT** (`czynny_vat` / `zwolniony` / `niezarejestrowany`) | `/settings` → Ustawienia podatkowe          | Określa, czy Numify generuje JPK\_VAT i czy pokazuje pole VAT na fakturach.                                         |
| **Częstotliwość VAT** (miesięcznie / kwartalnie)                  | `/settings` → Ustawienia podatkowe          | Wpływa na terminy w <FeatureRef slug="/docs/zgodnosc-z-prawem/kalendarz-terminow">kalendarzu terminów</FeatureRef>. |
| **Stawka CIT** (`standard_19` / `small_9` / `estonian`)           | `/settings` → Ustawienia podatkowe          | Wybiera odpowiedni szablon polityki rachunkowości i oblicza zaliczki CIT.                                           |
| **Rok obrotowy** (`fiscalYearStartMonth`)                         | `/settings` → Dane firmy                    | Domyślnie 1 (styczeń). Zmień tylko jeśli polityka rachunkowości spółki określa inny rok obrotowy.                   |
| **Rachunek bankowy** (numer, bank)                                | `/settings` → Dane firmy + `/bank-accounts` | Wymagany na fakturach sprzedaży i do importu wyciągów.                                                              |
| **Urząd skarbowy** (`taxOfficeName`, `taxOfficeCode`)             | `/settings` → Dane firmy                    | Potrzebne do JPK i deklaracji.                                                                                      |

Bez wypełnienia tych pól Numify technicznie zadziała, ale:

* Faktury sprzedaży wydrukują się bez numeru rachunku bankowego.
* JPK\_VAT nie wygeneruje się poprawnie dla spółek VAT-czynnych bez
  `taxOfficeCode`.
* Polityka rachunkowości (<FeatureRef slug="/docs/pierwsze-kroki/polityka-rachunkowosci">dokument art. 10</FeatureRef>)
  zostanie wygenerowana z lukami („—").

## Ograniczenia [#ograniczenia]

* **Brak trybu „wieloosobowego"** w samym onboardingu — zakładasz spółkę
  jako pojedynczy użytkownik-właściciel. Zaproszenie księgowego (jeśli
  taka funkcja zostanie dodana) odbywa się po zalogowaniu.
* **Brak kreatora bilansu otwarcia** w onboardingu — dla migracji
  z innego systemu trzeba osobno wejść na `/opening-balance`.
* **Brak cofania.** Po kliknięciu „Utwórz firmę" spółka istnieje z pełnym
  planem kont. Usunięcie firmy z poziomu UI nie jest przewidziane —
  z założenia Numify zakłada, że zakładasz *swoją* spółkę, nie testową.
  W razie potrzeby — kontakt z administratorem bazy.

## Dalej [#dalej]

Po założeniu firmy zajrzyj do <FeatureRef slug="/docs/pierwsze-kroki/plan-kont">planu kont</FeatureRef>
— zobacz, co zostało zasiane i czy potrzebujesz kont analitycznych.


---

# Słownik pojęć
URL: https://numifyai.com/docs/referencje/slownik
Description: Alfabetyczny słownik polskiej terminologii księgowej i podatkowej używanej w Numify AI, z angielskimi odpowiednikami i linkami do podstawy prawnej.
Review status: szkic
Updated: 2026-04-16



Polska terminologia księgowa nie tłumaczy się jeden-do-jednego na
angielskie odpowiedniki — często polskie pojęcia są szersze, węższe
lub mają inne zakresy prawne niż ich angielskie „analogi". Ten słownik
definiuje terminy tak, jak są używane w Numify i w polskim prawie
księgowym.

Skróty nazw aktów prawnych:

* **UoR** — [Ustawa o rachunkowości](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20230000120)
* **VAT** — [Ustawa o podatku od towarów i usług](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20250000775)
* **CIT** — [Ustawa o podatku dochodowym od osób prawnych](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20250000278)
* **KSEF** — [Ustawa o KSeF](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20230001598)

## A [#a]

**Amortyzacja** (en: *depreciation*) — systematyczne, stopniowe
odpisywanie wartości środków trwałych w koszty zgodnie z przyjętą
metodą (liniowa, degresywna, jednorazowa). Podstawa:
<LegalRef act="CIT" art="16h" /> – <LegalRef act="CIT" art="16m" />.

**Aktywa** (en: *assets*) — zasoby kontrolowane przez jednostkę z
poprzednich zdarzeń, z których spodziewany jest wpływ korzyści
ekonomicznych. Strona lewa bilansu. <LegalRef act="UoR" art="3" /> pkt 12.

## B [#b]

**Bilans** (en: *balance sheet*) — zestawienie aktywów i pasywów
jednostki na dzień kończący rok obrotowy. Podstawa:
<LegalRef act="UoR" art="46" /> oraz Załącznik nr 1/5.

**Biała lista** (en: *VAT white list*) — publiczny rejestr MF
zawierający NIP-y, rachunki bankowe i statusy VAT podatników.
Weryfikacja rachunku przed przelewem > <Grosze value="1500000" />
brutto jest obowiązkowa (<LegalRef act="VAT" art="117ba" />).

## C [#c]

**CIT** (en: *Corporate Income Tax*) — podatek dochodowy od osób
prawnych. Stawki: 9 % (mały podatnik, przychody \< 2 mln EUR) lub 19 %.
Podstawa: <LegalRef act="CIT" />.

**CIT-8** (en: *annual CIT return*) — roczne zeznanie podatkowe CIT,
składane do końca 3. miesiąca po roku obrotowym.
<LegalRef act="CIT" art="27" />.

## D [#d]

**Dziennik** (<PolishTerm pl="Dziennik" en="Journal">Dziennik</PolishTerm>)
— chronologiczny zapis wszystkich operacji gospodarczych w roku
obrotowym. Każda pozycja ma kolejny numer w ciągłej sekwencji
rocznej. Podstawa: <LegalRef act="UoR" art="14" />.

## E [#e]

**Ewidencja środków trwałych** (en: *fixed asset register*) — wykaz
wszystkich środków trwałych z podaniem KŚT, wartości początkowej,
metody amortyzacji i stanu umorzenia. Podstawa: <LegalRef act="CIT" art="16a" />
– <LegalRef act="CIT" art="16m" />.

## F [#f]

**Faktura ustrukturyzowana** (en: *structured invoice*) — faktura w
formacie FA(3) XML przesłana przez KSeF. Od 1 kwietnia 2026 r. —
obowiązkowa dla faktur B2B. Podstawa: <LegalRef act="VAT" art="106ga" />.

## G [#g]

**GTU** (*Grupa Towarowa Usług*) — kody od GTU\_01 do GTU\_13
oznaczające kategorie towarów i usług wymienione w Załączniku 15 do
ustawy o VAT (split payment / MPP). Obowiązkowe na JPK\_V7M i FA(3).

**Grosze** — najmniejsza jednostka PLN; 1 grosz = 1/100 zł. W Numify
wszystkie kwoty są przechowywane jako liczby całkowite groszy, żeby
uniknąć błędów zaokrąglenia zmiennoprzecinkowego. Zob.
[Grosze i waluta](/docs/koncepcje/grosze-i-waluta).

## I [#i]

**Informacja dodatkowa** (en: *notes to financial statements*) —
trzeci obowiązkowy element sprawozdania finansowego; zawiera
wprowadzenie, opis polityki rachunkowości, objaśnienia do bilansu
i RZiS. Podstawa: <LegalRef act="UoR" art="48" />.

**Inwentaryzacja** (en: *stocktaking*) — coroczne potwierdzenie
stanu aktywów i pasywów przed zamknięciem roku — spis z natury,
potwierdzenia sald, weryfikacja dokumentacji. Podstawa:
<LegalRef act="UoR" art="26" />.

## J [#j]

**Jednostka Mała** (en: *small entity*) — zgodnie z
<LegalRef act="UoR" art="3" /> ust. 1c: aktywa \< 25,5 mln zł,
przychody \< 51 mln zł, zatrudnienie \< 50 osób. Może korzystać z
uproszczonej formy sprawozdania finansowego (Załącznik nr 5 do UoR).

**JPK** (*Jednolity Plik Kontrolny*; en: *SAF-T*) — standard
plików XML dla sprawozdawczości podatkowej. Wersje:

* `JPK_V7M` — miesięczna deklaracja + ewidencja VAT.
* `JPK_KR_PD` — księgi rachunkowe z danymi podatkowymi.
* `JPK_ST_KR` — ewidencja środków trwałych.
* `JPK_FA` — faktury na żądanie organu.

## K [#k]

**Kontrahent** (en: *counterparty*) — drugi podmiot transakcji
(dostawca lub odbiorca). W Numify — rekord w tabeli `contractors`.

**Korekta storno** (en: *reversing entry*) — poprawa błędnego
zapisu przez wprowadzenie odwrotnej pozycji, bez usuwania
pierwotnej. Wymagana przez <LegalRef act="UoR" art="25" /> (ślad
rewizyjny). Zob. [Korekty typu storno](/docs/koncepcje/korekty-storno).

**KŚT** (*Klasyfikacja Środków Trwałych*) — urzędowy system kodów
dla środków trwałych, określający stawki amortyzacji. Kod jest
3-cyfrowy; np. 491 — zestawy komputerowe (30 %), 624 —
oprogramowanie (50 %).

**KSeF** (*Krajowy System e-Faktur*; en: *National e-Invoicing System*)
— centralna platforma MF dla faktur B2B. Obowiązkowy od 1 kwietnia
2026 r. dla większości sp. z o.o. Zob. [KSeF — przegląd](/docs/zgodnosc-z-prawem/ksef).

**KRS** (*Krajowy Rejestr Sądowy*; en: *National Court Register*) —
publiczny rejestr polskich spółek. Sprawozdania finansowe składane do
eKRS są publicznie dostępne.

**KUP** (*Koszt Uzyskania Przychodu*; en: *tax-deductible expense*) —
wydatek, który obniża podstawę opodatkowania CIT. Przeciwieństwo:
NKUP. Podstawa: <LegalRef act="CIT" art="15" />.

**Księga Główna** (<PolishTerm pl="Księga Główna" en="General Ledger">Księga Główna</PolishTerm>)
— syntetyczny układ wszystkich kont z saldami początkowymi, obrotami
i saldami końcowymi. Podstawa: <LegalRef act="UoR" art="15" />.

**Księgi Pomocnicze** (en: *subsidiary ledgers*) — analityczne
rozwinięcie kont syntetycznych — per kontrahent, per środek trwały,
per waluta. Podstawa: <LegalRef act="UoR" art="16" />.

## M [#m]

**MPP** (*Mechanizm Podzielonej Płatności*; en: *split payment*) —
obligatoryjny dla transakcji > <Grosze value="1500000" /> brutto
z Załącznika 15 ustawy o VAT. Nabywca dzieli płatność: kwota netto
na konto dostawcy, VAT na specjalne konto VAT.
<LegalRef act="VAT" art="108a" />.

## N [#n]

**NBP** (en: *National Bank of Poland*) — Narodowy Bank Polski,
źródło urzędowych kursów walut. Tabela A publikowana codziennie.
Transakcje walutowe księguje się kursem z dnia poprzedzającego
wystawienie dokumentu (<LegalRef act="UoR" art="30" />).

**NIP** (*Numer Identyfikacji Podatkowej*; en: *Tax Identification
Number*) — 10-cyfrowy identyfikator podatnika w Polsce. Walidowany
algorytmem sumy kontrolnej. Dla UE — poprzedzany prefiksem `PL`.

**NKUP** (*Niestanowiący Kosztu Uzyskania Przychodu*; en:
*non-deductible expense*) — wydatek niepodlegający odliczeniu od
dochodu. Zamknięty katalog w <LegalRef act="CIT" art="16" /> — m.in.
kary umowne, reprezentacja, odsetki za zwłokę.

## O [#o]

**Odwrotne obciążenie** (en: *reverse charge*) — mechanizm, w
którym nabywca, a nie dostawca, odprowadza VAT. Typowe zastosowanie:
import usług od kontrahenta z UE lub spoza UE.
<LegalRef act="VAT" art="28b" />.

## P [#p]

**Pełna księgowość** (en: *full double-entry accounting*) — system
księgowy wymagany dla sp. z o.o., oparty na zapisach dwustronnych
i sporządzaniu rocznego sprawozdania finansowego. Alternatywa dla
KPiR, którą prowadzą osoby fizyczne.

**Plan kont** (en: *chart of accounts*) — spis wszystkich kont
syntetycznych i analitycznych stosowanych przez jednostkę. Wymagany
element polityki rachunkowości. <LegalRef act="UoR" art="10" />.

**Polityka rachunkowości** (en: *accounting policy*) — dokument
opisujący zasady wyceny, plan kont, metody amortyzacji, schemat
obiegu dokumentów. Zatwierdzany uchwałą zarządu.
<LegalRef act="UoR" art="10" />.

## R [#r]

**RODO** (en: *GDPR*) — ogólne rozporządzenie UE 2016/679 o ochronie
danych osobowych. Dotyczy wszystkich danych osobowych
(kontrahenci-osoby fizyczne, pracownicy).

**RZiS** (*Rachunek Zysków i Strat*; en: *Profit and Loss Statement*)
— drugi obowiązkowy element sprawozdania finansowego; zestawienie
przychodów i kosztów za rok obrotowy. Wariant porównawczy lub
kalkulacyjny. <LegalRef act="UoR" art="47" />.

## S [#s]

**Sprawozdanie finansowe** (en: *financial statement*) — roczny
dokument sprawozdawczy: bilans + RZiS + informacja dodatkowa (oraz
opcjonalnie rachunek przepływów pieniężnych i zestawienie zmian w
kapitale). <LegalRef act="UoR" art="45" />.

**Ślad rewizyjny** (en: *audit trail*) — trwała i kompletna historia
wszystkich zmian w księgach; korekta nigdy nie usuwa pierwotnego
wpisu, tylko wprowadza wpis przeciwstawny. <LegalRef act="UoR" art="25" />.

## V [#v]

**VAT** (*Podatek od Towarów i Usług*; en: *Value Added Tax*) —
podatek pośredni od sprzedaży towarów i usług. Stawki podstawowe:
<VatRate rate="23" />, <VatRate rate="8" />, <VatRate rate="5" />,
<VatRate rate="0" />, <VatRate rate="zw" />, <VatRate rate="np" />.

**VAT-UE** (en: *EU VAT summary*) — informacja podsumowująca
transakcje wewnątrzwspólnotowe (WNT, WDT, usługi). Składana do 25.
kolejnego miesiąca. <LegalRef act="VAT" art="100" />.

**VIES** (en: *VAT Information Exchange System*) — unijny system
weryfikacji numerów VAT kontrahentów z UE. API:
`ec.europa.eu/taxation_customs/vies/`.

## W [#w]

**WDT** (*Wewnątrzwspólnotowa Dostawa Towarów*; en:
*Intra-Community Supply*) — sprzedaż towarów do podatnika VAT w
innym kraju UE. Stawka 0 % po spełnieniu warunków dokumentacyjnych.
<LegalRef act="VAT" art="13" />.

**WNT** (*Wewnątrzwspólnotowe Nabycie Towarów*; en:
*Intra-Community Acquisition*) — zakup towarów od podatnika VAT w
innym kraju UE. Nabywca samoopodatkowuje się VAT.
<LegalRef act="VAT" art="9" />.

## Z [#z]

**Zapis podwójny** (en: *double-entry bookkeeping*) — każda
operacja gospodarcza jest ujmowana na dwóch kontach — po stronie
debet (Dr) i po stronie kredyt (Cr) — w równych kwotach. Podstawa:
<LegalRef act="UoR" art="15" />. Zob. [Zapis podwójny](/docs/koncepcje/zapis-podwojny).

**ZOiS** (*Zestawienie Obrotów i Sald*; en: *Trial Balance*) —
miesięczne lub roczne zestawienie wszystkich kont z saldami
początkowymi, obrotami debet / kredyt i saldami końcowymi.
Zrównoważenie (suma Dr = suma Cr) potwierdza poprawność zapisów.
<LegalRef act="UoR" art="18" />.

**ZUS** (*Zakład Ubezpieczeń Społecznych*; en: *Social Security*)
— instytucja zarządzająca składkami emerytalnymi, rentowymi i
zdrowotnymi w Polsce.

**ZZW** (*Zwyczajne Zgromadzenie Wspólników*; en: *Annual General
Meeting*) — coroczne zgromadzenie wspólników sp. z o.o., na którym
zatwierdzane jest sprawozdanie finansowe. Termin: do 6 miesięcy od
końca roku obrotowego. <LegalRef act="UoR" art="53" />.


---

# Eksporty
URL: https://numifyai.com/docs/korzystanie-z-numify/exports
Description: Generatory plików urzędowych — JPK_V7M (rejestr VAT), JPK_KR_PD (księgi rachunkowe), JPK_ST_KR (środki trwałe), e-Sprawozdanie XML oraz eksporty CSV dla audytora (transakcje, rejestr VAT, zestawienie obrotów i sald, kontrahenci).
Review status: numify-source
Updated: 2026-04-17



**Eksporty** to zestaw generatorów plików, które wysyła się do urzędu
skarbowego lub przekazuje audytorowi. Numify składa dane z dziennika,
rejestru VAT, ewidencji środków trwałych i danych spółki w formatach
wymaganych przez przepisy.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /exports — cztery sekcje (CSV dla audytora, JPK_V7, JPK_KR_PD + JPK_ST_KR, e-Sprawozdanie) z przyciskami Podgląd i Pobierz */}

## Co generuje Numify [#co-generuje-numify]

| Format                  | Co zawiera                                                          | Podstawa prawna                                                                                  | Kiedy składasz                                        |
| ----------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------- |
| **JPK\_V7M / JPK\_V7K** | Rejestr VAT (sprzedaż + zakupy) + deklaracja                        | <LegalRef act="VAT" art="99" paragraph="11c" />, <LegalRef act="VAT" art="109" paragraph="3b" /> | Miesięcznie lub kwartalnie, do 25 dnia                |
| **JPK\_KR\_PD**         | Księgi rachunkowe (dziennik + plan kont + zapisy)                   | <LegalRef act="CIT" art="9" paragraph="1c" />                                                    | Po zakończeniu roku, z CIT-8                          |
| **JPK\_ST\_KR**         | Ewidencja środków trwałych                                          | <LegalRef act="CIT" art="9" paragraph="1c" />                                                    | Po zakończeniu roku, z CIT-8                          |
| **e-Sprawozdanie**      | Bilans + RZiS + informacja dodatkowa (XML)                          | <LegalRef act="UoR" art="45" paragraph="1g" />                                                   | 3 mies. od dnia bilansowego (do KRS po zatwierdzeniu) |
| **CSV dla audytora**    | Transakcje / Rejestr VAT / Zestawienie obrotów i sald / Kontrahenci | Brak — na potrzeby audytu                                                                        | Na żądanie                                            |

## JPK\_V7M / JPK\_V7K — rejestr VAT [#jpk_v7m--jpk_v7k--rejestr-vat]

### Co to jest [#co-to-jest]

Plik XML w strukturze logicznej łączący **deklarację VAT** i
**ewidencję VAT** (<LegalRef act="VAT" art="99" paragraph="11c" />).
Obowiązek złożenia wynika z ustawy o VAT — ewidencja z
<LegalRef act="VAT" art="109" paragraph="3" /> przesyłana razem z
deklaracją (<LegalRef act="VAT" art="109" paragraph="3b" />).

### Co obejmuje ewidencja [#co-obejmuje-ewidencja]

* **Sprzedaż** — faktury wystawione, z podziałem na stawki (23%, 8%, 5%, 0%, zw., np.), kodami GTU (01–13), znacznikami procedur (MPP, TP, WEW),
* **Zakupy** — faktury otrzymane z prawem do odliczenia VAT naliczonego, z podziałem na stawki,
* **Korekty** — faktury korygujące (in plus / in minus),
* **Kontrahenci** — NIP nabywcy / dostawcy, niezbędny do prawidłowego rozliczenia.

### Dwa warianty [#dwa-warianty]

* **JPK\_V7M** — miesięczny. Standard. Składany do 25 dnia miesiąca następującego po miesiącu rozliczeniowym.
* **JPK\_V7K** — kwartalny. Ewidencja nadal wysyłana co miesiąc (<LegalRef act="VAT" art="109" paragraph="3c" />), ale deklaracja tylko raz na kwartał. Dostępny dla małych podatników i podatników estońskiego CIT.

### Workflow [#workflow]

1. Zaksięguj wszystkie faktury z miesiąca (<FeatureRef slug="faktury" />).
2. Sprawdź rejestr VAT (<FeatureRef slug="vat-register" />) — czy sumy się zgadzają, czy nie ma niespójności GTU.
3. Otwórz `/exports` → sekcja JPK\_V7M → **Podgląd** (widok XML z walidacją struktury).
4. **Pobierz** plik XML.
5. Wyślij przez bramkę Ministerstwa Finansów (Numify nie wysyła automatycznie — to celowe ograniczenie, faktyczne złożenie deklaracji wymaga świadomej decyzji podatnika).

Numify udostępnia plik podpisany kryptograficznie przez użytkownika
na bramce e-Urzędu Skarbowego lub profilem zaufanym.

## JPK\_KR\_PD — księgi rachunkowe [#jpk_kr_pd--księgi-rachunkowe]

### Co to jest [#co-to-jest-1]

Obowiązek wprowadzony <LegalRef act="CIT" art="9" paragraph="1c" />:
podatnicy prowadzący księgi rachunkowe przesyłają je po zakończeniu
roku podatkowego w postaci elektronicznej o strukturze logicznej.
Szczegółowa struktura — rozporządzenie MF z 16.08.2024 (Dz.U. 2024
poz. 1314), zmienione rozporządzeniem z 15.12.2025 (Dz.U. 2025
poz. 1828, obowiązuje od 1.01.2026).

### Terminy wejścia w życie [#terminy-wejścia-w-życie]

* **Rok 2025** — duzi podatnicy (przychody > 50 mln EUR w poprzednim roku) i podatkowe grupy kapitałowe.
* **Rok 2026** — pozostali podatnicy CIT prowadzący księgi rachunkowe.

Dla przeciętnej spółki z o.o. obowiązek zaczyna się od roku
obrotowego 2026 — plik za rok 2026 trzeba przesłać razem z CIT-8 (do
końca 3. miesiąca po zakończeniu roku).

### Zawartość [#zawartość]

* **Dziennik** — wszystkie zapisy z numerem, datą, opisem,
* **Plan kont** — lista kont z typami, tagami bilansowymi i RZiS, znacznikami JPK\_KR\_PD (`jpkPdMarker`),
* **Zapisy księgi głównej i ksiąg pomocniczych** — z pełną analityką,
* **Zestawienie obrotów i sald** — na koniec roku,
* **Metadane spółki** — NIP, nazwa, rok obrotowy.

Każde konto w <FeatureRef slug="chart-of-accounts">planie kont</FeatureRef>
ma pole `jpkPdMarker` używane do mapowania na strukturę JPK (np.
`KOSZT_REPR` dla reprezentacji, `KUP` / `NKUP` dla kwalifikacji
kosztowej).

## JPK\_ST\_KR — środki trwałe [#jpk_st_kr--środki-trwałe]

### Co to jest [#co-to-jest-2]

Osobna struktura JPK dla ewidencji środków trwałych —
<ServiceRef path="src/lib/services/jpk-st-kr-generator.ts" tests="24" /> składa
plik na podstawie <FeatureRef slug="fixed-assets">rejestru ŚT</FeatureRef>.

### Zawartość [#zawartość-1]

* Każdy ŚT z nazwą, kodem KŚT, wartością początkową, datą przyjęcia,
* Metoda amortyzacji i stawka,
* Dotychczasowe umorzenie,
* Data i typ zbycia (jeśli dotyczy — sprzedaż / likwidacja).

Numify nie waliduje kodu KŚT — odpowiedzialność za prawidłowy kod
leży po stronie użytkownika (patrz <FeatureRef slug="fixed-assets" />).

## e-Sprawozdanie — XML sprawozdania finansowego [#e-sprawozdanie--xml-sprawozdania-finansowego]

### Co to jest [#co-to-jest-3]

<LegalRef act="UoR" art="45" paragraph="1g" /> wymaga, aby jednostki
wpisane do KRS sporządzały sprawozdanie finansowe w **strukturze
logicznej** udostępnionej w BIP Ministra Finansów. Format: XML
zgodny ze schemą XSD opublikowaną przez MF.

### Co generuje Numify [#co-generuje-numify-1]

<ServiceRef path="src/lib/services/e-sprawozdanie.ts" tests="16" /> składa
pełne e-Sprawozdanie:

* **Wprowadzenie** — dane spółki, zasady sporządzenia, metody wyceny,
* **Bilans** — aktywa + pasywa w strukturze załącznika nr 1 UoR (lub nr 5 dla jednostek małych),
* **Rachunek zysków i strat** — wariant porównawczy lub kalkulacyjny,
* **Informacja dodatkowa** — generowana przez <ServiceRef path="src/lib/services/informacja-dodatkowa.ts" tests="16" /> z danych spółki.

### Honest framing — co wymaga ręcznego uzupełnienia [#honest-framing--co-wymaga-ręcznego-uzupełnienia]

Automatyczna generacja **nie zastępuje** kierownika jednostki:

* Informacja dodatkowa w wielu sekcjach wymaga narracji (np. zdarzenia po dniu bilansowym, transakcje z podmiotami powiązanymi, opis ryzyka walutowego) — Numify generuje szkielet, nie pełny tekst.
* Sprawozdanie z działalności zarządu (<LegalRef act="UoR" art="45" paragraph="4" />) jest odrębnym dokumentem, nieobjętym generatorem.
* **Podpis elektroniczny** — e-Sprawozdanie wymaga podpisów kwalifikowanych / profilem zaufanym członków zarządu. Numify wyprodukuje plik niepodpisany — podpisy dokładacie poza systemem.

### Workflow [#workflow-1]

1. Zamknij rok obrotowy w <FeatureRef slug="fiscal-periods" />, wygeneruj zapisy zamknięcia.
2. Uzgodnij <FeatureRef slug="balance-sheet" /> i <FeatureRef slug="profit-loss" />.
3. Otwórz `/exports` → sekcja e-Sprawozdanie → **Podgląd** (XML).
4. **Pobierz** plik XML, uzupełnij informację dodatkową gdzie wymagana narracja.
5. Podpisz (członkowie zarządu) w e-Urzędzie Skarbowym lub innym systemie.
6. Złóż do KRS w ciągu 15 dni od zatwierdzenia SF (<LegalRef act="UoR" art="12" paragraph="4" />).

## Eksporty CSV — dla audytora i analiz własnych [#eksporty-csv--dla-audytora-i-analiz-własnych]

Nie są wymagane prawem — służą współpracy z audytorem, doradcą
podatkowym i własnym analizom w Excelu.

| CSV                            | Źródło                           | Typowe użycie                                          |
| ------------------------------ | -------------------------------- | ------------------------------------------------------ |
| **Transakcje**                 | Tabela `transactions`            | Audyt: lista wszystkich transakcji spółki z metadanymi |
| **Rejestr VAT**                | VAT\_REGISTER                    | Kontrola zewnętrzna JPK\_V7 przed wysłaniem            |
| **Zestawienie obrotów i sald** | `chartAccounts` + `journalLines` | Uzgodnienia z księgowym zewnętrznym                    |
| **Kontrahenci**                | Tabela `contractors`             | Baza do kampanii mailingowych, analiz należności       |

Wszystkie eksporty używają **spójnego modelu minor units** — kwoty
w groszach (dla PLN) lub centach (EUR/USD), zgodnie z konwencją
repozytorium. Konwersja do złotówek: `groszeToPlnStr()` z
<ServiceRef path="src/lib/services/export-service.ts" tests="27" />.

## Powiązania [#powiązania]

* <FeatureRef slug="vat-register">Rejestr VAT</FeatureRef> — źródło danych dla JPK\_V7M.
* <FeatureRef slug="journal">Dziennik</FeatureRef> + <FeatureRef slug="chart-of-accounts">Plan kont</FeatureRef> — źródło JPK\_KR\_PD.
* <FeatureRef slug="fixed-assets">Środki trwałe</FeatureRef> — źródło JPK\_ST\_KR.
* <FeatureRef slug="balance-sheet">Bilans</FeatureRef> + <FeatureRef slug="profit-loss">RZiS</FeatureRef> — źródło e-Sprawozdania.
* <FeatureRef slug="cit-data">Dane do CIT</FeatureRef> — wynik finansowy brutto do zeznania CIT-8.
* <FeatureRef slug="ksef">KSeF</FeatureRef> — faktury wystawione w KSeF są automatycznie ujmowane w rejestrze VAT i JPK\_V7M.


---

# Dane do CIT
URL: https://numifyai.com/docs/korzystanie-z-numify/cit-data
Description: Szacunkowe wyliczenie dochodu podatkowego i kwoty CIT — dochód księgowy, korekty o NKUP (koszty niestanowiące kosztów uzyskania przychodów), zastosowanie stawki 19% lub 9%. Pomoc w wyliczeniu zaliczki miesięcznej; nie zastępuje zeznania CIT-8.
Review status: numify-source
Updated: 2026-04-17



**Dane do CIT** to ekran pomagający wyliczyć dochód podatkowy spółki
i szacunkową kwotę podatku dochodowego od osób prawnych — na
podstawie zaksięgowanych przychodów i kosztów skorygowanych o NKUP.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /cit-data — selektor roku, wynik księgowy, tabela NKUP z kontami i kwotami, wyliczenie dochodu podatkowego, kwota CIT */}

## Honest framing — co to jest, a czego nie [#honest-framing--co-to-jest-a-czego-nie]

**Co Numify liczy:**

* ✅ Wynik finansowy brutto (przychody – koszty księgowe) z zapisów w <FeatureRef slug="journal">dzienniku</FeatureRef>.
* ✅ Rozpoznaje koszty zaksięgowane na kontach oznaczonych jako **NKUP** (np. <AccountRef code="403" /> reprezentacja, kary — per <FeatureRef slug="chart-of-accounts" />).
* ✅ Stosuje stawkę 19% lub 9% zgodnie z ustawieniem spółki (`citRate`).
* ✅ Zwraca szacunkowy dochód podatkowy i kwotę CIT — przydatne do wyliczenia **zaliczki miesięcznej** (<LegalRef act="CIT" art="25" paragraph="1" />).

**Czego Numify nie robi:**

* ❌ **Nie zastępuje zeznania CIT-8** — deklarację roczną składa podatnik, po konsultacji z księgowym / doradcą podatkowym.
* ❌ **Nie obsługuje wszystkich korekt podatkowych** — w szczególności: straty z lat ubiegłych (<LegalRef act="CIT" art="7" paragraph="5" />), ulgi (B+R, IP Box, sponsoring), podatek u źródła (WHT), ceny transferowe, minimum tax, estoński CIT (ryczałt od dochodów spółek), podatek od przerzuconych dochodów.
* ❌ **Nie wykrywa automatycznie wszystkich NKUP** — detekcja opiera się na **tagach konta** z planu kont. Koszt zaksięgowany na „zwykłym" koncie kosztowym, ale który ustawa kwalifikuje jako NKUP (np. samochód osobowy powyżej limitu z <LegalRef act="CIT" art="16" paragraph="1" /> pkt 4), wymaga ręcznej korekty.

**Traktuj wynik jako punkt wyjścia do weryfikacji, nie gotową kwotę
do wpłaty do urzędu.**

## Jak liczone jest w Numify [#jak-liczone-jest-w-numify]

<ServiceRef path="src/lib/services/cit-data.ts" tests="15" /> wywołuje
`generateCitData(companyId, fiscalYear)` i zwraca strukturę:

```
accountingRevenue    // przychody księgowe narastająco
accountingCosts      // koszty księgowe narastająco
accountingResult     // wynik księgowy brutto
nonDeductibleCosts   // suma NKUP
nkupItems[]          // lista pozycji NKUP (konto, kwota, powód)
taxableRevenue       // przychody podatkowe
taxDeductibleCosts   // koszty podatkowe (= accountingCosts - NKUP)
taxResult            // dochód podatkowy
citRate              // stawka (19 lub 9)
citDue               // szacunkowa kwota CIT
```

### Wynik księgowy [#wynik-księgowy]

Suma obrotów kont typu `revenue` (zespół 7 — przychody) minus suma
obrotów kont typu `expense` (zespół 4 / 5 — koszty), za wybrany rok.
To samo co wynik widoczny w <FeatureRef slug="profit-loss" /> na dzień
bilansowy.

### Detekcja NKUP [#detekcja-nkup]

Numify wylicza NKUP na podstawie **tagów** przypisanych do kont w
<FeatureRef slug="chart-of-accounts">planie kont</FeatureRef>:

* Konto `403` (reprezentacja) — domyślnie tagowane NKUP (<LegalRef act="CIT" art="16" paragraph="1" /> pkt 28: koszty reprezentacji, w szczególności gastronomia i napoje alkoholowe).
* Konta kar, grzywien, odsetek od zaległości podatkowych — tagowane NKUP.
* Darowizny, PFRON powyżej limitu — tagowane NKUP.

**Wyświetlona tabela NKUP** (`nkupItems`) pokazuje każdą pozycję z
opisem powodu (`reason`) — np. „Reprezentacja — art. 16 ust. 1 pkt 28
CIT". Użytkownik widzi, które konkretnie kwoty zostały odjęte.

### Dochód podatkowy [#dochód-podatkowy]

```
dochód podatkowy = przychody księgowe - (koszty księgowe - NKUP)
                 = wynik księgowy + NKUP
```

Tożsamościowo: dodanie NKUP do wyniku księgowego daje dochód
podatkowy w uproszczonym modelu (bez uwzględnienia różnic trwałych i
przejściowych poza NKUP).

### Stawka CIT [#stawka-cit]

| Stawka           | Warunki                                                                                                       | Ustawienie w Numify                                                   |
| ---------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| **19%**          | Stawka podstawowa (<LegalRef act="CIT" art="19" paragraph="1" /> pkt 1)                                       | `citRate = "standard_19"`                                             |
| **9%**           | Mały podatnik — przychody ≤ 2 mln EUR w roku poprzednim (<LegalRef act="CIT" art="19" paragraph="1" /> pkt 2) | `citRate = "small_9"`                                                 |
| **Estoński CIT** | Ryczałt od dochodów spółek (art. 28j–28t CIT)                                                                 | `citRate = "estonian"` — nieobsługiwany przez generator danych do CIT |

Próg 2 mln EUR dla stawki 9%: kwota przeliczona na złote po kursie
średnim NBP z pierwszego dnia roboczego roku podatkowego, zaokrąglona
do 1000 zł. Numify nie weryfikuje automatycznie, czy spółka nadal
kwalifikuje się jako mały podatnik — ustawienie `citRate` zmienia
zarząd spółki świadomie.

## Zaliczki miesięczne [#zaliczki-miesięczne]

<LegalRef act="CIT" art="25" paragraph="1" /> wymaga wpłacania
zaliczek miesięcznych na CIT do **20 dnia miesiąca następującego** po
miesiącu, którego dotyczy zaliczka. Kwota zaliczki: różnica między
podatkiem od dochodu **narastająco** a sumą zaliczek zapłaconych w
poprzednich miesiącach tego roku.

### Workflow miesięczny [#workflow-miesięczny]

1. Zamknij <FeatureRef slug="fiscal-periods">okres miesięczny</FeatureRef> — wszystkie faktury zaksięgowane, wszystkie płatności dopasowane.
2. Otwórz `/cit-data`, wybierz rok bieżący.
3. Przeczytaj `taxResult` (dochód narastająco) i `citDue` (CIT należny narastająco).
4. Odejmij zaliczki już wpłacone.
5. Wpłać różnicę na mikrorachunek podatkowy spółki do 20 dnia miesiąca.

Numify nie wysyła powiadomień o terminach — to obszar planowany jako
osobne ostrzeżenia w <FeatureRef slug="pulpit">pulpicie</FeatureRef>.

### Mały podatnik — zaliczki kwartalne [#mały-podatnik--zaliczki-kwartalne]

<LegalRef act="CIT" art="25" paragraph="1" /> ust. 1b: rozpoczynający
działalność (w pierwszym roku) i mali podatnicy mogą wpłacać zaliczki
**kwartalne** — do 20 dnia miesiąca następującego po kwartale. Numify
wyświetla wynik narastająco i pozostawia decyzję o terminie
użytkownikowi — formularz CIT-8 i deklaracje cząstkowe nie są tutaj
generowane.

## Co wymaga ręcznej korekty przed zeznaniem CIT-8 [#co-wymaga-ręcznej-korekty-przed-zeznaniem-cit-8]

Lista najczęstszych sytuacji, w których szacunek Numify różni się od
dochodu podatkowego w CIT-8:

| Sytuacja                                                                                                    | Co zrobić                                                                                                                                  |
| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Koszty samochodu osobowego** powyżej limitu (<LegalRef act="CIT" art="16" paragraph="1" /> pkt 4, 49, 51) | Ręcznie wyliczyć nadwyżkę (amortyzacja powyżej 150 000 zł, leasing, 25% wydatków dla samochodu mieszanego) i dodać do NKUP                 |
| **Straty z lat ubiegłych** (<LegalRef act="CIT" art="7" paragraph="5" />)                                   | Odjąć od dochodu bieżącego roku do 50% kwoty straty rocznie (lub jednorazowo do 5 mln zł)                                                  |
| **Ulga B+R / IP Box / sponsoring**                                                                          | Odjąć odliczenia od podstawy opodatkowania                                                                                                 |
| **WHT — podatek u źródła**                                                                                  | Pomniejsza CIT do zapłaty (nie dochód)                                                                                                     |
| **Różnice kursowe naliczone vs zrealizowane**                                                               | Weryfikacja: Numify ujmuje zrealizowane; naliczone (metoda bilansowa) wymagają odrębnej analizy                                            |
| **Koszty niedokumentowane lub bez NIP**                                                                     | Ręczna weryfikacja — automatyczna detekcja ich nie wyłapie                                                                                 |
| **Rezerwy i odpisy aktualizujące** bez uprawdopodobnienia                                                   | NKUP per <LegalRef act="CIT" art="16" paragraph="1" /> pkt 26–27; Numify oznaczy je poprawnie tylko jeśli konto jest odpowiednio otagowane |

Dla każdego z tych przypadków polityka: &#x2A;*konsultacja z doradcą
podatkowym przed wysłaniem CIT-8.**

## Widok `/cit-data` [#widok-cit-data]

{/* SCREENSHOT: selektor roku (cap: bieżący rok, earliest: rok rejestracji spółki), karty Wynik księgowy / NKUP / Dochód podatkowy / CIT, tabela pozycji NKUP */}

* **Selektor roku** — ograniczony do przedziału `[registrationYear, currentYear]` (nie ma danych CIT dla lat przyszłych ani przed rejestracją spółki).
* **Karty podsumowujące** — przychody, koszty, wynik księgowy, NKUP, dochód podatkowy, stawka, CIT należny.
* **Tabela NKUP** — lista pozycji z kolumnami: kod konta, nazwa, kwota, powód.
* **Brak przycisku „Wyślij"** — celowe. Faktyczne zeznanie CIT-8 składasz poza Numify, z podpisem zarządu.

## Powiązania [#powiązania]

* <FeatureRef slug="profit-loss">RZiS</FeatureRef> — wynik księgowy z RZiS zgadza się z `accountingResult` w danych do CIT.
* <FeatureRef slug="chart-of-accounts">Plan kont</FeatureRef> — tagi kont NKUP determinują detekcję.
* <FeatureRef slug="exports">Eksporty</FeatureRef> — JPK\_KR\_PD zawiera znaczniki `jpkPdMarker` dla każdego zapisu, spójne z tą logiką.
* <FeatureRef slug="fiscal-periods">Okresy fiskalne</FeatureRef> — warto zamknąć okres przed generowaniem szacunku CIT, żeby dane nie były „żywe".


---

# Okresy fiskalne
URL: https://numifyai.com/docs/korzystanie-z-numify/fiscal-periods
Description: Zarządzanie rokiem obrotowym i okresami miesięcznymi — statusy open / closed / locked, zamykanie i ponowne otwieranie okresu, trwałe zamknięcie roku (lock) oraz zapisy zamknięcia rocznego.
Review status: numify-source
Updated: 2026-04-17



**Okresy fiskalne** to miesięczne „koperty", w które Numify wkłada zapisy
z <FeatureRef slug="journal">dziennika</FeatureRef>. Każdy okres ma
status (`open` / `closed` / `locked`), który kontroluje, czy można w
nim jeszcze dodawać, modyfikować lub odwracać zapisy.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /fiscal-periods — lista 12 okresów roku z badge'ami statusu i przyciskami Zamknij / Otwórz ponownie / Zamknij trwale */}

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

<LegalRef act="UoR" art="12" paragraph="1" /> wymaga otwierania
ksiąg na początek roku obrotowego i ich zamknięcia na dzień kończący
rok (<LegalRef act="UoR" art="12" paragraph="2" />). W praktyce
księgi prowadzi się w podziale na miesięczne okresy sprawozdawcze —
zgodnie z deklaracją z <FeatureRef slug="accounting-policy">polityki
rachunkowości</FeatureRef> (<LegalRef act="UoR" art="10" paragraph="1" />).

Numify wymusza tę strukturę programowo:

* każdy zapis w dzienniku jest przypisany do konkretnego `(fiscalYear, fiscalMonth)`,
* do okresu `closed` nie można dodawać nowych zapisów ani modyfikować istniejących,
* do okresu `locked` nie można nawet wystawić storna — jest nieodwracalnie zamknięty.

## Model — rok obrotowy i okresy miesięczne [#model--rok-obrotowy-i-okresy-miesięczne]

**Rok obrotowy** to domyślnie rok kalendarzowy (1 I – 31 XII), ale
zgodnie z <LegalRef act="UoR" art="3" paragraph="1" /> (pkt 9) może
być dowolnym okresem 12 pełnych miesięcy. Rok obrotowy deklaruje się w
ustawieniach spółki (`fiscalYearStartMonth`) i w polityce
rachunkowości.

**Okres miesięczny** to `(companyId, fiscalYear, fiscalMonth)`. Numify
automatycznie tworzy okres przy pierwszym zapisie w danym miesiącu
(`getOrCreatePeriod`) — ręczne zakładanie okresów nie jest wymagane.

## Trzy statusy okresu [#trzy-statusy-okresu]

| Status       | Można księgować? |              Można storno?             | Kiedy?                                                                                                                                                                              |
| ------------ | :--------------: | :------------------------------------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **`open`**   |         ✅        |                    ✅                   | Domyślny. Okres otwarty — dodawanie, modyfikacje, storno dozwolone.                                                                                                                 |
| **`closed`** |         ❌        | ✅ (w okresie otwartym, z datą bieżącą) | Po miesięcznym / kwartalnym zamknięciu. Błędy można korygować przez storno w kolejnym otwartym okresie.                                                                             |
| **`locked`** |         ❌        |                    ❌                   | Trwałe zamknięcie po zatwierdzeniu sprawozdania finansowego (<LegalRef act="UoR" art="12" paragraph="5" />). Odpowiada „nieodwracalnemu wyłączeniu możliwości dokonywania zapisów". |

Funkcja `isPeriodModifiable(period)` w <ServiceRef path="src/lib/services/fiscal-periods.ts" tests="30" />
zwraca `true` tylko dla statusu `open` — jest wywoływana przez wszystkie
endpointy modyfikujące dziennik.

## Zamykanie okresu [#zamykanie-okresu]

Przycisk „Zamknij okres" (`closePeriod`) ustawia status na `closed`.
Przed zamknięciem warto:

1. Sprawdzić, że wszystkie faktury z miesiąca są zaksięgowane (<FeatureRef slug="faktury" />).
2. Sprawdzić, że wszystkie wiersze wyciągu są dopasowane (<FeatureRef slug="konta-bankowe" />).
3. Uzgodnić salda w <FeatureRef slug="trial-balance">zestawieniu obrotów i sald</FeatureRef>.
4. Uzgodnić rejestr VAT i wygenerować JPK\_V7 (<FeatureRef slug="vat-register" />).

Zamknięcie nie jest obowiązkowe prawnie w cyklu miesięcznym — to
**dyscyplina operacyjna**, która zabezpiecza przed przypadkową edycją
zaksięgowanych już miesięcy. Obowiązkowe jest dopiero zamknięcie na
koniec roku (<LegalRef act="UoR" art="12" paragraph="2" />).

## Ponowne otwarcie (`reopenPeriod`) [#ponowne-otwarcie-reopenperiod]

Jeśli po zamknięciu okazuje się, że miesiąc wymaga korekty (np.
znaleziona po czasie faktura kosztowa), można ponownie otworzyć okres
— wraca do statusu `open`. Uwaga:

* Ponowne otwarcie **nie jest dostępne**, jeśli okres ma status `locked` (jest to zamknięcie nieodwracalne, <LegalRef act="UoR" art="12" paragraph="5" />).
* Ponowne otwarcie po zatwierdzeniu sprawozdania finansowego stanowi istotną zmianę — jeśli wpływa na dane już wykazane w bilansie / RZiS, wymaga korekty sprawozdania zgodnie z KSR 7 (błędy lat ubiegłych).

Rekomendacja: w trakcie roku preferuj **korekty przez storno** w
bieżącym okresie, a ponowne otwieranie traktuj jako wyjątek.

## Trwałe zamknięcie (`lockPeriod`) [#trwałe-zamknięcie-lockperiod]

Po zatwierdzeniu rocznego sprawozdania finansowego przez zarząd /
zgromadzenie wspólników okresy roku podlegają **trwałemu zamknięciu**
— status `locked`. Termin: **15 dni od zatwierdzenia**
(<LegalRef act="UoR" art="12" paragraph="4" />).

Trwałe zamknięcie:

* uniemożliwia dodawanie zapisów, modyfikacje oraz storno,
* realizuje wymóg „nieodwracalnego wyłączenia możliwości dokonywania zapisów" (<LegalRef act="UoR" art="12" paragraph="5" />),
* jest warunkiem zgodności ksiąg z zatwierdzonym sprawozdaniem.

Po zablokowaniu jedyną drogą korekty pozostaje **storno w kolejnym
roku obrotowym** — zgodnie z zasadą, że błędy wykryte po zamknięciu
ksiąg koryguje się w okresie bieżącym.

## Generowanie zapisów zamknięcia rocznego [#generowanie-zapisów-zamknięcia-rocznego]

<ServiceRef path="src/lib/services/fiscal-periods.ts" tests="30" /> eksportuje
`generateYearEndClosingEntries` — funkcja składa zapisy zamknięcia
kont wynikowych (zespoły 4, 7) na <AccountRef code="860" /> (wynik
finansowy bieżącego roku), a następnie przeksięgowuje saldo na
<AccountRef code="820" /> (wynik finansowy).

Generowanie jest **odrębną czynnością** od zamknięcia okresu — tworzy
konkretne zapisy w dzienniku na dzień bilansowy. Workflow:

1. Uzgodnij RZiS za cały rok (<FeatureRef slug="profit-loss" />).
2. Uruchom generator — powstaje zapis „Zamknięcie roku YYYY" na 31 XII.
3. Zweryfikuj, że salda kont zespołu 4 i 7 są wyzerowane.
4. Zatwierdź sprawozdanie finansowe.
5. Zablokuj okresy roku (`lockPeriod` dla każdego miesiąca).

## Widok `/fiscal-periods` [#widok-fiscal-periods]

{/* SCREENSHOT: tabela 12 miesięcy — kolumny Miesiąc / Liczba zapisów / Obrót Wn / Obrót Ma / Status / Akcje */}

* **Selektor roku** — przełączanie między latami obrotowymi.
* **Tabela miesięcy** — 12 wierszy z licznikiem zapisów i sumą obrotów.
* **Badge statusu** — `otwarty` (zielony), `zamknięty` (żółty), `zablokowany` (szary).
* **Akcje kontekstowe** — zależne od statusu (Zamknij / Otwórz ponownie / Zamknij trwale).

## Typowe błędy i jak ich uniknąć [#typowe-błędy-i-jak-ich-uniknąć]

* **Zamknięcie okresu z niezaksięgowanymi fakturami** — faktura zaksięgowana później trafi do kolejnego miesiąca, zaburzając VAT. Zawsze księguj przed zamknięciem.
* **Lock przed zatwierdzeniem SF** — nie ma prawnego uzasadnienia przed uchwałą zgromadzenia wspólników. Odwróć przez `reopenPeriod` zanim okres zostanie zablokowany.
* **Praca w dwóch latach jednocześnie** — zapisy BO (<FeatureRef slug="opening-balance" />) trafiają do nowego roku na 1 I, ale wymagają zamkniętego poprzedniego. Nie otwieraj ksiąg roku YYYY+1 bez zapisów zamknięcia roku YYYY.

## Powiązania [#powiązania]

* <FeatureRef slug="journal">Dziennik</FeatureRef> — każdy zapis ma `(fiscalYear, fiscalMonth)` i respektuje status okresu.
* <FeatureRef slug="opening-balance">Bilans otwarcia</FeatureRef> — używa `ensurePeriodOpen` i tworzy okres pierwszego miesiąca, jeśli go brak.
* <FeatureRef slug="trial-balance">Zestawienie obrotów i sald</FeatureRef> — filtruje zapisy po roku / miesiącu.
* <FeatureRef slug="balance-sheet">Bilans</FeatureRef> i <FeatureRef slug="profit-loss">RZiS</FeatureRef> — sporządzane na dzień zamknięcia ksiąg zgodnie z <LegalRef act="UoR" art="45" paragraph="1" />.


---

# Ustawienia spółki
URL: https://numifyai.com/docs/korzystanie-z-numify/settings
Description: Konfiguracja spółki w Numify — dane rejestrowe (NIP, REGON, KRS), adres, ustawienia podatkowe (status VAT, częstotliwość JPK_V7, stawka CIT, urząd skarbowy), rachunek bankowy, mapowanie kategorii na konta księgowe. Ustawienia te są źródłem prawdy dla polityki rachunkowości, generatorów JPK, e-Sprawozdania i integracji KSeF.
Review status: internal
Updated: 2026-04-17



**Ustawienia** to konfiguracja spółki, z której korzystają wszystkie
inne funkcje Numify — generator <FeatureRef slug="accounting-policy">polityki
rachunkowości</FeatureRef>, generatory JPK, e-Sprawozdanie, kalkulacja
<FeatureRef slug="cit-data">danych do CIT</FeatureRef>, integracja
<FeatureRef slug="ksef">KSeF</FeatureRef>, sugestie księgowania w
<FeatureRef slug="transakcje">transakcjach</FeatureRef>.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /settings — sekcje Company Info, Address, Tax Settings, Bank Info, Account Mappings */}

## Dlaczego to ma znaczenie [#dlaczego-to-ma-znaczenie]

Ustawienia spółki są **źródłem prawdy**. Błędna wartość (np. zły NIP,
błędny kod urzędu skarbowego, nieaktualna stawka CIT) przechodzi
przez całą aplikację i pojawia się:

* na wystawianych fakturach (NIP sprzedawcy → KSeF),
* w plikach JPK\_V7M wysyłanych do urzędu skarbowego,
* w szablonie polityki rachunkowości przedstawianym zarządowi,
* w szacunku zaliczki CIT,
* w e-Sprawozdaniu składanym do KRS.

Dlatego: &#x2A;*po każdej zmianie w rejestrze (KRS, zgłoszenie VAT-R,
zmiana adresu)** zaktualizuj ustawienia w Numify w tym samym dniu.

## Sekcje [#sekcje]

### 1. Company Info — dane rejestrowe [#1-company-info--dane-rejestrowe]

| Pole                       | Źródło / wymóg                     | Używane w                                                                                                           |
| -------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Nazwa spółki**           | Odpis z KRS, pełna nazwa           | Faktury, JPK, e-Sprawozdanie, polityka                                                                              |
| **Nazwa skrócona**         | Opcjonalnie, do UI                 | Nagłówki w interfejsie                                                                                              |
| **Forma prawna**           | z KRS (spółka z o.o.)              | e-Sprawozdanie (`Kod_Formy_Prawnej`)                                                                                |
| **NIP**                    | 10 cyfr, walidacja sumy kontrolnej | Faktury, JPK, KSeF, CIT-8                                                                                           |
| **REGON**                  | 9 lub 14 cyfr                      | JPK\_KR\_PD, e-Sprawozdanie                                                                                         |
| **KRS**                    | Numer z rejestru                   | e-Sprawozdanie (składane do KRS), podpowiedź przy weryfikacji białej listy                                          |
| **Data rejestracji (KRS)** | Z odpisu                           | Cap dolnego roku w <FeatureRef slug="cit-data" />, <FeatureRef slug="fiscal-periods" /> — brak danych przed tą datą |
| **Waluta**                 | PLN (domyślnie)                    | Baza do rozliczeń; waluty obce osobno                                                                               |

Walidacja NIP i REGON dzieje się po stronie klienta (suma kontrolna);
Numify **nie pobiera automatycznie** danych z KRS — aktualizację
wykonujesz ręcznie. Podpowiadanie po numerze KRS jest dostępne w
<FeatureRef slug="kontrahenci">kontrahentach</FeatureRef>, ale nie
uzupełnia danych własnej spółki.

### 2. Address — adres siedziby [#2-address--adres-siedziby]

Standardowe pola: ulica, kod pocztowy, miasto, kraj. Adres jest:

* **drukowany na fakturach** (sprzedawca),
* **przekazywany do KSeF** jako dane sprzedawcy,
* **ujęty w e-Sprawozdaniu** jako adres jednostki.

Zmiana siedziby spółki wymaga aktualizacji KRS (uchwała
zgromadzenia wspólników + zgłoszenie do rejestru) i **dopiero
potem** zmiany w Numify — by adres na fakturach zgadzał się z
oficjalnym rejestrem.

### 3. Tax Settings — ustawienia podatkowe [#3-tax-settings--ustawienia-podatkowe]

| Pole                      | Opcje                                            | Wpływ                                                                                                                         |
| ------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| **VAT Status**            | `czynny_vat` / `zwolniony` / `niezarejestrowany` | Czy Numify prowadzi <FeatureRef slug="vat-register" />, generuje JPK\_V7, wystawia faktury VAT                                |
| **VAT Filing Frequency**  | `monthly` / `quarterly`                          | JPK\_V7M vs JPK\_V7K — patrz <FeatureRef slug="exports" />                                                                    |
| **CIT Rate**              | `standard_19` / `small_9` / `estonian`           | Stawka w <FeatureRef slug="cit-data" />. 9% tylko dla małych podatników (<LegalRef act="CIT" art="19" paragraph="1" /> pkt 2) |
| **Urząd skarbowy**        | Dowolny tekst                                    | Nagłówek zeznań, informacje dodatkowe                                                                                         |
| **Tax Office Code (JPK)** | Kod urzędu z wykazu MF                           | Wymagany w nagłówku JPK\_V7M, JPK\_KR\_PD                                                                                     |

**Tax Office Code** to czterocyfrowy identyfikator urzędu skarbowego
z oficjalnego wykazu Ministerstwa Finansów (np. `1432` dla US
Warszawa-Mokotów). Kod jest obligatoryjny w plikach JPK — wpisanie
błędnego skutkuje odrzuceniem pliku przez bramkę.

### 4. Bank Info — rachunek bankowy spółki [#4-bank-info--rachunek-bankowy-spółki]

* **IBAN** — numer rachunku na fakturach sprzedaży.
* **Bank Name** — nazwa banku (opcjonalnie).

To jest **główny rachunek firmowy** — pojawia się jako domyślny na
wystawianych fakturach. Dla ewidencji transakcji i wyciągów używa
się osobnej tabeli <FeatureRef slug="konta-bankowe">konta bankowe</FeatureRef>
(wiele rachunków per spółka).

Wykorzystanie IBAN z ustawień jako **tego podanego na fakturze**
odpowiada wymogowi **białej listy podatników VAT** — nabywca płacący
na rachunek spoza białej listy ponosi odpowiedzialność solidarną za
VAT. Numify nie waliduje automatycznie obecności IBAN na białej
liście dla własnej spółki (planowane).

### 5. Account Mappings — mapowanie kategorii na konta [#5-account-mappings--mapowanie-kategorii-na-konta]

Ustawienia, które **pośrednio wpływają na księgowania**:

* **Kategorie → konta kosztowe** — np. `services` (usługi obce) → <AccountRef code="402" />. Używane w sugestiach przy księgowaniu <FeatureRef slug="faktury">faktur</FeatureRef>.
* **Kategoria → konto VAT** — np. dla danej kategorii VAT naliczony trafia na dedykowane subkonto <AccountRef code="220" />.
* **Domyślny rachunek bankowy per spółka** — używany w pustych stanach formularzy.

Mapowania są warstwą **produktu** — mają ułatwić codzienne
księgowanie bez ręcznego wybierania konta. Domyślne mapowania
seedują się przy zakładaniu spółki wspólnie z <FeatureRef slug="chart-of-accounts" />.

## Workflow — pierwsze uruchomienie [#workflow--pierwsze-uruchomienie]

1. **Podczas onboardingu** — podstawowe pola (nazwa, NIP, KRS, rok obrotowy) wprowadzasz w kreatorze (<FeatureRef slug="pulpit" /> → onboarding). Po zakończeniu onboardingu dane są widoczne na `/settings`.
2. **Dopełnij brakujące pola** — REGON, adres, kod urzędu skarbowego, IBAN — ze strony `/settings`.
3. **Ustaw VAT i CIT** — na podstawie stanu faktycznego (zgłoszenie VAT-R, decyzja o 9% CIT).
4. **Zapisz** — każda zmiana wymaga potwierdzenia; Numify aktualizuje tabelę `companies` i regeneruje szablon polityki przy następnym otwarciu <FeatureRef slug="accounting-policy" />.

## Zmiany ustawień a ciągłość ksiąg [#zmiany-ustawień-a-ciągłość-ksiąg]

Niektóre zmiany mają **daleko idące skutki**:

| Zmiana                                         | Konsekwencja                                                                                                                                                              |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **NIP**                                        | Faktury wystawione przed zmianą zostają — zmiana NIP w trakcie roku to rzadka sytuacja (zmiana formy prawnej, sukcesja) i wymaga osobnego procesu                         |
| **VAT Status z czynny na zwolniony**           | Faktury VAT przestajesz wystawiać, rejestr VAT zamyka się; konsultacja z doradcą konieczna                                                                                |
| **CIT Rate z 9% na 19% (przekroczenie progu)** | Zaliczki od miesiąca następującego po przekroczeniu progu; zeznanie CIT-8 uwzględnia obie stawki proporcjonalnie                                                          |
| **Rok obrotowy**                               | Zmiana wymaga uchwały zgromadzenia wspólników i zgłoszenia do KRS (<LegalRef act="UoR" art="3" paragraph="1" /> pkt 9); pierwszy rok po zmianie jest dłuższy niż 12 mies. |
| **Kod urzędu skarbowego**                      | Skutkuje dopiero zgłoszeniem zmiany do rejestru (NIP-8); w plikach JPK nowy kod od dnia skuteczności zgłoszenia                                                           |

Historia zmian ustawień **nie jest** wersjonowana w Numify — UI
pokazuje aktualny stan. Jeśli potrzebujesz śladu audytowego
(„dlaczego w lutym NIP był X, a w marcu Y?"), prowadź rejestr zmian
poza systemem (np. w dokumentacji polityki rachunkowości).

## Powiązania [#powiązania]

* <FeatureRef slug="accounting-policy">Polityka rachunkowości</FeatureRef> — generator czyta rok obrotowy, metody wyceny, VAT, CIT z ustawień.
* <FeatureRef slug="chart-of-accounts">Plan kont</FeatureRef> — mapowania kategorii wskazują na konta GL.
* <FeatureRef slug="faktury">Faktury</FeatureRef> — dane sprzedawcy, IBAN, kod urzędu skarbowego.
* <FeatureRef slug="exports">Eksporty</FeatureRef> — nagłówki JPK\_V7M / JPK\_KR\_PD / e-Sprawozdanie.
* <FeatureRef slug="cit-data">Dane do CIT</FeatureRef> — stawka i rok rejestracji.
* <FeatureRef slug="ksef">KSeF</FeatureRef> — NIP, nazwa, adres w FA(3).


---

# Konta bankowe
URL: https://numifyai.com/docs/korzystanie-z-numify/konta-bankowe
Description: Rejestr rachunków bankowych spółki, import wyciągów CSV (mBank, ING, PKO, Santander, Nest Bank + generyczny), dopasowywanie wpłat do faktur (auto-match + ręczne) oraz automatyczne księgowanie płatności z wyceną różnic kursowych.
Review status: numify-source
Updated: 2026-04-16



**Konta bankowe** to rejestr rachunków spółki z o.o., punkt importu wyciągów
bankowych oraz miejsce, gdzie wiersze wyciągu zostają **dopasowane** do
konkretnych faktur i — w efekcie — **zaksięgowane w dzienniku** jako zapłata.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /bank-accounts — kafelki rachunków, poniżej tabela wierszy wyciągu z badge'ami Matched/Unmatched */}

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

Każda operacja na rachunku bankowym spółki to **operacja gospodarcza** w
rozumieniu <LegalRef act="UoR" art="14" paragraph="1" /> — musi zostać
chronologicznie ujęta w dzienniku. W praktyce oznacza to trzy kroki:

1. **Import** wyciągu (CSV z banku),
2. **Dopasowanie** wiersza wyciągu do faktury (automatyczne lub ręczne),
3. **Zaksięgowanie** zapłaty w dzienniku — z automatycznym rozliczeniem rozrachunku (<AccountRef code="201" /> / <AccountRef code="202" />) i ewentualnymi różnicami kursowymi (<AccountRef code="750" /> / <AccountRef code="751" />).

Numify realizuje krok 2 i 3 automatycznie, pod warunkiem że rachunek
bankowy jest zmapowany na odpowiednie &#x2A;*konto księgowe (GL)**.

## Model danych [#model-danych]

Rachunek bankowy ma pola:

| Pole                            | Przeznaczenie                                                                                                               |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Nazwa                           | Etykieta („Konto firmowe mBank").                                                                                           |
| IBAN                            | Numer rachunku (wymagany, unikalny w obrębie spółki).                                                                       |
| Bank                            | Dowolny opis, pomocny przy wielu rachunkach.                                                                                |
| Waluta                          | PLN / EUR / USD (musi zgadzać się z walutą CSV przy imporcie).                                                              |
| Konto księgi (`chartAccountId`) | Najczęściej <AccountRef code="130" /> (PLN) lub <AccountRef code="135" /> (waluta obca) — to na tym koncie powstają zapisy. |
| Stan początkowy                 | Kwota otwarcia (używana przy rozliczaniu rocznym).                                                                          |
| Rachunek podstawowy             | Flaga `isPrimary` — domyślny rachunek do sugestii.                                                                          |

Numify automatycznie proponuje GL: **PLN → 130, waluta obca → 135**, ale
użytkownik może wybrać subkonto (np. `135-EUR`, `135-USD`).

## Obsługiwane formaty CSV [#obsługiwane-formaty-csv]

Parser obsługuje sześć profilów: `generic` (auto-detekcja separatora),
`mbank`, `ing`, `pko`, `santander`, `nestbank`. Wszystkie kwoty są
normalizowane do **minor units** (grosze dla PLN, centy dla EUR/USD) —
bezpośrednio zgodne z repozytorium i plikami JPK.

<ServiceRef path="src/lib/services/bank-csv-parser.ts" tests="27">
  bank-csv-parser.ts
</ServiceRef>

### Co parser rozumie poza kwotą i datą [#co-parser-rozumie-poza-kwotą-i-datą]

* Format PL („1 234,56") i mieszany („1.234,56") — z groszami.
* Daty DD.MM.YYYY, DD-MM-YYYY, DD/MM/YYYY, YYYY-MM-DD.
* Waluta z kolumny CSV (tylko ISO-4217 — np. `EUR`, `USD`; wartości typu „EURO", „pln " są odrzucane, żeby zabezpieczyć walidację waluty rachunku).
* Nazwa kontrahenta, IBAN kontrahenta, referencja / tytuł przelewu.

### Zabezpieczenia importu [#zabezpieczenia-importu]

* **Walidacja waluty** — jeśli CSV deklaruje walutę inną niż waluta rachunku bankowego, import odrzuca plik z komunikatem (brak miksu EUR na rachunek PLN).
* **Deduplikacja** — wiersze powielone (ta sama kombinacja data + kwota + opis) są rozpoznawane jako duplikaty i pomijane (komunikat: `skipped N duplicates`).
* **Auto-match po imporcie** — wiersze pasujące 1:1 do istniejących faktur są automatycznie oznaczane jako dopasowane.

## Dopasowywanie (matching) [#dopasowywanie-matching]

### Auto-match [#auto-match]

Numify dopasowuje wiersz wyciągu do faktury na podstawie:

* kwoty (z pełną tolerancją groszową dla walut),
* numeru faktury w opisie / referencji,
* NIP-u / nazwy kontrahenta,
* dat (wpłata w rozsądnym oknie od terminu płatności).

W praktyce na standardowych wyciągach trafia to **większość** pozycji. Reszta
trafia do kolejki **niedopasowanych** — do obsługi ręcznej.

### Ręczne [#ręczne]

Użytkownik może ręcznie dopasować wiersz do faktury z listy otwartych
rozrachunków lub **cofnąć** (unmatch) wcześniejsze dopasowanie.

## Automatyczne księgowanie płatności [#automatyczne-księgowanie-płatności]

Przy każdym dopasowaniu (automatycznym lub ręcznym) Numify tworzy zapis w
dzienniku o standardowej strukturze:

| Operacja                              | Przychód (income)                                                 | Koszt (expense)                                                    |
| ------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------ |
| Wpływ na rachunek bankowy             | <AccountRef code="130" /> / <AccountRef code="135" /> — **Debet** | <AccountRef code="201" /> — **Debet**                              |
| Wyksięgowanie należności/zobowiązania | <AccountRef code="201" /> — **Kredyt**                            | <AccountRef code="135" /> / <AccountRef code="130" /> — **Kredyt** |

Dla rozrachunków z dostawcami używamy <AccountRef code="202" /> zamiast
<AccountRef code="201" />.

<ServiceRef path="src/lib/services/payment-journal.ts" tests="30">
  payment-journal.ts
</ServiceRef>

### Różnice kursowe [#różnice-kursowe]

Gdy faktura jest w walucie obcej, **kurs NBP w dniu zaksięgowania faktury**
i **kurs w dniu otrzymania zapłaty** różnią się. <LegalRef act="UoR" art="30" paragraph="4" />
wymaga ujęcia różnicy w wyniku okresu:

* **Zysk kursowy** → konto <AccountRef code="750" name="Przychody finansowe" /> (tu trafia dodatnia różnica kursowa).
* **Strata kursowa** → konto <AccountRef code="751" name="Koszty finansowe" />.

Dokładny zapis prawny — <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-30-kursy-walut">UoR — kursy walut</FeatureRef>.

Numify liczy różnicę jako:

```
|bankLinePaidPln - (proporcja faktury zaksięgowanej w PLN)|
```

...i dobiera konto 750 lub 751 w zależności od znaku. Płatności częściowe
są obsługiwane proporcjonalnie, z korektą finałową na ostatniej racie —
tak, żeby po zamknięciu całej faktury rozrachunek (<AccountRef code="201" /> / <AccountRef code="202" />)
wynosił **dokładnie zero** (bez ±1 gr resztek zaokrągleń).

### Płatności częściowe [#płatności-częściowe]

Jeśli wpłata \< kwota faktury, Numify:

1. Tworzy zapis księgowy tylko na proporcję faktury.
2. Oznacza fakturę jako **częściowo zapłaconą**.
3. Resztę rozlicza przy kolejnych wpłatach.

Suma wszystkich rat musi zamknąć fakturę co do grosza.

## Cofanie dopasowania (unmatch) [#cofanie-dopasowania-unmatch]

<LegalRef act="UoR" art="25" paragraph="1" /> zakazuje usuwania zapisów w księgach.
Gdy użytkownik cofa dopasowanie:

1. Numify tworzy **storno** — zapis odwrotny w dzienniku (debety ↔ kredyty, kwoty bez minusów, ale odwrócone strony).
2. Wiersz wyciągu wraca do puli niedopasowanych.
3. Oryginalny zapis pozostaje w dzienniku — audytor widzi pełną historię.

**Nie ma przycisku „Usuń zapis"** — to konsekwencja <LegalRef act="UoR" art="25" />.

## Ograniczenia [#ograniczenia]

1. **Brak bezpośredniego podpięcia do banku** (Open Banking / PSD2) — zawsze importujemy z CSV. Roadmapa przewiduje PSD2 w drugiej połowie 2026 r.
2. **Auto-match bywa zachowawczy** — przy niejednoznacznych opisach wiersz zostaje oznaczony jako niedopasowany, zamiast zgadywać. Lepsze to niż błędne dopasowanie i błędne księgowanie.
3. **Korekty faktur nie są jeszcze wspierane w auto-match** — zobacz [issue #5](https://github.com/kacperkwapisz/numify/issues/5).
4. **Waluta wiersza musi zgadzać się z walutą rachunku.** Mieszane waluty na jednym rachunku nie są wspierane — prowadzić je jako osobne rachunki księgowe (typowa praktyka dla 135).

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Dodaj rachunek** — domyślny GL 130 (PLN) lub 135 (waluta obca).
2. **Importuj wyciąg CSV** z panelu banku (wybierz profil banku z listy).
3. **Pozwól Numify zrobić auto-match** — najczęściej większość wierszy zostanie dopasowana.
4. **Obsłuż niedopasowane wiersze** — ręcznie dopasuj lub utwórz brakującą transakcję.
5. **Cofnij dopasowanie** (jeśli trzeba) — Numify zrobi storno; nie dotykaj dziennika ręcznie.

{/* SCREENSHOT: dialog „Import Bank Statement" z listą banków + polem pliku */}

## Powiązane [#powiązane]

* <FeatureRef slug="transakcje">transakcje</FeatureRef> — każda dopasowana wpłata wskazuje transakcję, do której należy.
* <FeatureRef slug="faktury">faktury</FeatureRef> — status „Opłacona" wynika z dopasowania wiersza bankowego.
* <FeatureRef slug="kontrahenci">kontrahenci</FeatureRef> — rachunek kontrahenta ułatwia matching po IBAN.
* <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-30-kursy-walut">UoR — kursy walut</FeatureRef>.


---

# Pulpit
URL: https://numifyai.com/docs/korzystanie-z-numify/pulpit
Description: Pulpit — punkt startowy Numify. Szybki podgląd przychodów, kosztów, statusu weryfikacji, zobowiązań VAT, terminów płatności i otwartych okresów obrachunkowych dla wybranej spółki.
Review status: internal
Updated: 2026-04-16



**Pulpit** to ekran startowy Numify po zalogowaniu. Pokazuje stan spółki
w jednym rzucie oka: przychody, koszty, statusy weryfikacji, zobowiązania
VAT, nadchodzące i przeterminowane płatności oraz otwarte okresy
obrachunkowe.

Jest **czysto informacyjny** — nie księguje, nie zmienia danych. Służy do
**nawigacji** („co jest do zrobienia?") i do **kontroli stanu**.

{/* SCREENSHOT: ekran /dashboard — stats karty + VAT Summary + wykres miesięczny + tabela nadchodzących płatności */}

## Selektor zakresu dat [#selektor-zakresu-dat]

Wszystkie kafelki reagują na przełącznik zakresu u góry ekranu:

| Opcja           | Obejmuje                                         |
| --------------- | ------------------------------------------------ |
| **Ten miesiąc** | Od 1. dnia bieżącego miesiąca do dziś.           |
| **Ten kwartał** | Od 1. dnia bieżącego kwartału do dziś.           |
| **Ten rok**     | Od 1 stycznia bieżącego roku do dziś (domyślne). |
| **Zakres**      | Ręcznie wybrane daty od–do.                      |

Dane nie obejmują okresów wcześniejszych niż `registrationDate` spółki
(data rejestracji w KRS) i nigdy nie sięgają w przyszłość — zgodnie
z zasadą, że księgowość nie istnieje w przyszłości ani przed powstaniem
spółki.

## Karty kluczowych metryk [#karty-kluczowych-metryk]

### Przychody [#przychody]

Suma kwot brutto w PLN **zweryfikowanych** transakcji typu `income`
w wybranym zakresie. Niezweryfikowane nie są sumowane — mogą mieć
jeszcze niepełne dane (np. kurs waluty).

Obok: porównanie z miesiącem poprzednim (strzałka `↑` / `↓`).

Szczegóły → <FeatureRef slug="transakcje">transakcje</FeatureRef>.

### Koszty [#koszty]

Analogicznie — suma kwot brutto zweryfikowanych transakcji typu
`expense`. Dodatkowo pokazuje liczbę transakcji oznaczonych jako **B+R**
(kategoria na potrzeby ulgi B+R — szczegóły →
<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-cit/ulga-br">ulga B+R</FeatureRef>).

### Do weryfikacji [#do-weryfikacji]

Liczba transakcji ze statusem `isVerified = false` — oczekują na
potwierdzenie człowieka. Im niższa ta liczba, tym bliżej „zamknięcia"
miesiąca.

Kliknięcie prowadzi do tabeli transakcji z preustawionym filtrem.

### Dokumenty [#dokumenty]

Liczba wszystkich wrzuconych dokumentów + podliczka tych, które są
w trakcie parsowania AI. Duża liczba w stanie „w trakcie" oznacza, że
kolejka BullMQ pracuje.

## VAT Summary [#vat-summary]

Karta u góry środkowej części ekranu pokazuje:

* **VAT należny** (output) — suma VAT ze sprzedaży w bieżącym okresie.
* **VAT naliczony** (input) — suma VAT z zakupów.
* **Saldo** — `należny − naliczony`. Dodatnie → **do zapłaty**. Ujemne → **do zwrotu / do przeniesienia** na następny okres.

Okres to bieżący miesiąc (format `YYYY-MM`) — zgodny z cyklem JPK\_V7M
(<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/jpk-v7m">JPK\_V7M</FeatureRef>).
Pełna deklaracja i terminy → <FeatureRef slug="/docs/zgodnosc-z-prawem/kalendarz-terminow">Kalendarz terminów</FeatureRef>.

## Płatności [#płatności]

Trzy sygnały w jednej karcie:

* **Niezapłacone faktury** — liczba transakcji ze statusem `isPaid = false`.
* **Przeterminowane** (na czerwono) — liczba + łączna kwota faktur po terminie.
* **Otwarte okresy** — liczba nie-zamkniętych okresów obrachunkowych. Otwarte okresy blokują roczne zamknięcie, ale pozwalają na bieżące księgowania.

## Wykres miesięczny [#wykres-miesięczny]

Ostatnie 6 miesięcy — zielony słupek przychodów + czerwony słupek
kosztów, znormalizowane do maksimum z okresu. Dane — z już zaksięgowanych
(zweryfikowanych) transakcji.

## Zysk netto [#zysk-netto]

Prosty wskaźnik: `przychody − koszty` z okresu. Zieleń = zysk, czerwień
\= strata. Dodatkowo pokazuje łączną liczbę transakcji w okresie i liczbę
zweryfikowanych — szybki sygnał, że „miesiąc jest domknięty" albo
„potrzeba jeszcze pracy".

## Nadchodzące płatności (14 dni) [#nadchodzące-płatności-14-dni]

Lista **zobowiązań** (wystawionych faktur zakupowych) z terminem
płatności w najbliższych 14 dniach. Każda pozycja pokazuje:

* nazwę kontrahenta,
* numer faktury,
* datę płatności,
* kwotę brutto.

Pozwala rano spojrzeć na pulpit i zobaczyć, co trzeba zapłacić w tym
tygodniu, bez wchodzenia w moduł <FeatureRef slug="transakcje">transakcji</FeatureRef>.

## Szybkie akcje [#szybkie-akcje]

Przyciski poniżej nadchodzących płatności:

* **Dodaj dokument** → <FeatureRef slug="dokumenty">dokumenty</FeatureRef>,
* **Przeglądaj transakcje** → <FeatureRef slug="transakcje">transakcje</FeatureRef>,
* **Zweryfikuj N oczekujących** (pojawia się, gdy liczba niezweryfikowanych > 0) → lista z filtrem.

## Stan pusty [#stan-pusty]

Jeśli spółka nie ma jeszcze żadnych dokumentów ani transakcji, zamiast
kart metryk pojawia się onboarding:

> Prześlij pierwszą fakturę — AI automatycznie wyodrębni dane.

Z przyciskiem „Prześlij fakturę" prowadzącym do <FeatureRef slug="dokumenty">dokumentów</FeatureRef>.
Jest to celowa „wydma" — pulpit nie udaje, że ma dane, których nie ma.

## Ograniczenia [#ograniczenia]

1. **Brak pełnej księgi głównej / bilansu** w pulpicie — do tego służą osobne moduły (Księga Główna, Bilans, RZiS). Pulpit to skrót operacyjny.
2. **Porównania vs ubiegły miesiąc są proste** — tylko dla przychodów (strzałka `↑` / `↓`). Pełna analiza trendu w kolejnych phase'ach (Panele raportowe).
3. **VAT podsumowanie jest dla bieżącego miesiąca**, niezależnie od wybranego zakresu dat — by zawsze odpowiadało na pytanie „ile zapłacę VAT-u do 25. dnia".
4. **Wykres pokazuje ostatnie 6 miesięcy** — nie konfigurowalny w obecnej wersji.

## Powiązane [#powiązane]

* <FeatureRef slug="dokumenty">dokumenty</FeatureRef> — punkt wejścia danych.
* <FeatureRef slug="transakcje">transakcje</FeatureRef> — szczegółowy widok.
* <FeatureRef slug="konta-bankowe">konta bankowe</FeatureRef> — reconciliation.
* <FeatureRef slug="faktury">faktury</FeatureRef> — wystawiane faktury.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/kalendarz-terminow">Kalendarz terminów</FeatureRef>.


---

# Transakcje
URL: https://numifyai.com/docs/korzystanie-z-numify/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.
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>.


---

# Raporty
URL: https://numifyai.com/docs/korzystanie-z-numify/reports
Description: Centralny hub wszystkich raportów księgowych i podatkowych w Numify — zestawienie obrotów i sald, bilans, RZiS, rejestr VAT, dane do CIT oraz eksporty JPK. Punkt wyjścia dla miesięcznego i rocznego zamknięcia ksiąg.
Review status: internal
Updated: 2026-04-17



**Raporty** to centralny hub wszystkich zestawień, raportów i eksportów
w Numify. Sam ekran `/reports` nie generuje raportów — jest punktem
wyjścia, który kieruje do właściwej strony w zależności od potrzeby.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /reports — siatka kafelków z linkami do poszczególnych raportów, pogrupowane w sekcje */}

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

Zamknięcie miesiąca lub roku obrotowego to sekwencja raportów, które
czyta się w kolejności:

1. **Zestawienie obrotów i sald** — kontrolne: czy wszystko się zgadza,
2. **Rejestr VAT** — podstawa deklaracji JPK\_V7,
3. **Bilans + RZiS** — obraz finansowy spółki,
4. **Dane do CIT** — zaliczka lub zeznanie roczne,
5. **Eksporty JPK** — wysyłka do urzędu skarbowego.

Hub `/reports` porządkuje te kroki w jednym miejscu, z linkami do
funkcji, które szczegółowo opisano na osobnych stronach.

## Trzy grupy raportów [#trzy-grupy-raportów]

### 1. Operacyjne — dla bieżącej kontroli [#1-operacyjne--dla-bieżącej-kontroli]

Używane w trakcie miesiąca, nie tylko przy zamknięciu.

| Raport                     | Po co                                            | Dokumentacja                         |
| -------------------------- | ------------------------------------------------ | ------------------------------------ |
| Dziennik                   | Chronologiczny log zapisów księgowych            | <FeatureRef slug="journal" />        |
| Księga główna              | Salda i obroty per konto, z rozwinięciem zapisów | <FeatureRef slug="general-ledger" /> |
| Zestawienie obrotów i sald | Kontrola bilansowania: suma Wn = suma Ma         | <FeatureRef slug="trial-balance" />  |
| Rejestr VAT                | Lista faktur sprzedaży i zakupu z stawkami VAT   | <FeatureRef slug="vat-register" />   |

### 2. Statutowe — elementy sprawozdania finansowego [#2-statutowe--elementy-sprawozdania-finansowego]

Wymagane prawem (<LegalRef act="UoR" art="45" paragraph="1" />) na
koniec roku obrotowego; warto sprawdzać również śródrocznie.

| Raport                  | Rola                                                             | Dokumentacja                            |
| ----------------------- | ---------------------------------------------------------------- | --------------------------------------- |
| Bilans                  | Obraz majątku i źródeł finansowania na dzień bilansowy           | <FeatureRef slug="balance-sheet" />     |
| Rachunek zysków i strat | Wynik finansowy za okres — wariant porównawczy                   | <FeatureRef slug="profit-loss" />       |
| Informacja dodatkowa    | Trzeci element SF — nie generowany automatycznie, patrz polityka | <FeatureRef slug="accounting-policy" /> |

### 3. Podatkowe i audyt — do urzędu skarbowego [#3-podatkowe-i-audyt--do-urzędu-skarbowego]

Materiały do zaliczki CIT, zeznania rocznego i plików JPK.

| Raport             | Rola                                               | Dokumentacja                   |
| ------------------ | -------------------------------------------------- | ------------------------------ |
| Dane do CIT        | Dochód podatkowy, NKUP, szacunkowa kwota podatku   | <FeatureRef slug="cit-data" /> |
| Eksporty CSV + JPK | JPK\_V7M, JPK\_KR\_PD, JPK\_ST\_KR, e-Sprawozdanie | <FeatureRef slug="exports" />  |

## Jak wybrać raport — szybka ścieżka [#jak-wybrać-raport--szybka-ścieżka]

| Jeśli chcesz…                          | Idź do                                                                                                         |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Sprawdzić, czy miesiąc się zbilansował | <FeatureRef slug="trial-balance" />                                                                            |
| Zidentyfikować konkretny zapis         | <FeatureRef slug="journal" /> lub <FeatureRef slug="general-ledger" />                                         |
| Wygenerować JPK\_V7 do urzędu          | <FeatureRef slug="exports" />                                                                                  |
| Oszacować zaliczkę CIT za okres        | <FeatureRef slug="cit-data" />                                                                                 |
| Zobaczyć, jak spółka wygląda majątkowo | <FeatureRef slug="balance-sheet" />                                                                            |
| Ocenić rentowność miesiąca / roku      | <FeatureRef slug="profit-loss" />                                                                              |
| Zamknąć rok i zatwierdzić SF           | <FeatureRef slug="fiscal-periods" /> + <FeatureRef slug="balance-sheet" /> + <FeatureRef slug="profit-loss" /> |

## Zgodność z prawem [#zgodność-z-prawem]

Raporty w Numify nie są same w sobie sprawozdaniem finansowym —
**sprawozdanie finansowe** w rozumieniu <LegalRef act="UoR" art="45" paragraph="1" />
obejmuje bilans, RZiS i informację dodatkową, sporządzone w formacie
logicznym (dla jednostek KRS) zgodnie z załącznikiem do ustawy. Ekrany
<FeatureRef slug="balance-sheet" /> i <FeatureRef slug="profit-loss" />
dostarczają **zawartości merytorycznej**; wygenerowanie
formalnego e-Sprawozdania (XML) wykonuje <FeatureRef slug="exports" />.

Każdy raport ma jasno oznaczone źródło danych (dziennik /
zapisy analityczne / tabela rejestru VAT) — co ułatwia audyt i
potwierdza spójność z wymaganiami <LegalRef act="UoR" art="4" paragraph="1" />
(rzetelne i jasne przedstawienie sytuacji).

## Powiązania [#powiązania]

* <FeatureRef slug="fiscal-periods">Okresy fiskalne</FeatureRef> — każdy raport filtruje się po roku / miesiącu i bierze pod uwagę status okresu.
* <FeatureRef slug="exports">Eksporty</FeatureRef> — zawiera generatory JPK i e-Sprawozdania w formacie wymaganym przez urząd.
* <FeatureRef slug="accounting-policy">Polityka rachunkowości</FeatureRef> — definiuje zasady wyceny, na których opierają się wszystkie raporty.


---

# Zestawienie obrotów i sald
URL: https://numifyai.com/docs/korzystanie-z-numify/trial-balance
Description: Zestawienie wszystkich kont księgi głównej z saldami otwarcia, obrotami okresu i saldami zamknięcia. Obrót dziennika = obrót zestawienia — kontrola bilansowania ksiąg rachunkowych.
Review status: internal
Updated: 2026-04-17



**Zestawienie obrotów i sald** (potocznie: „obrotówka") to przegląd wszystkich
kont księgi głównej z saldami otwarcia, obrotami okresu i saldami zamknięcia.
Dla każdego konta syntetycznego widzisz cztery pary liczb (OD/OK × Wn/Ma) oraz
obroty (Wn/Ma) okresu. Suma wszystkich sald Wn musi być równa sumie sald Ma —
to najważniejsza kontrola bilansowania ksiąg.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /trial-balance — tabela kont z kolumnami Kod / Nazwa / Saldo otwarcia Wn/Ma / Obroty okresu Wn/Ma / Saldo zamknięcia Wn/Ma; pasek sumy u dołu z badge'em "Zbilansowane" */}

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

<LegalRef act="UoR" art="13" paragraph="1" /> wymienia zestawienie obrotów i
sald jako jeden z pięciu obowiązkowych elementów ksiąg rachunkowych. Art. 18
doprecyzowuje:

* **Częstotliwość**: nie rzadziej niż na koniec miesiąca
  (<LegalRef act="UoR" art="18" paragraph="1" />).
* **Zawartość**: symbole i nazwy kont, salda otwarcia roku, obroty okresu,
  obroty narastająco od początku roku, salda zamknięcia okresu.
* **Zgodność z dziennikiem**: obroty zestawienia muszą się zgadzać z obrotami
  dziennika za ten sam okres (<LegalRef act="UoR" art="14" paragraph="1" />).
* **Zamknięcie ksiąg**: dodatkowo zestawienie sald wszystkich kont ksiąg
  pomocniczych (<LegalRef act="UoR" art="18" paragraph="2" />).

Numify wyznacza zestawienie „na żądanie" z zapisów w <FeatureRef slug="journal">dzienniku</FeatureRef> —
nie trzeba go generować ani „zamykać miesiąca"; obrotówka jest zawsze aktualna
na podstawie zapisów `isPosted: true`.

## Model danych [#model-danych]

Usługa <ServiceRef path="src/lib/services/trial-balance.ts" /> zwraca dla
każdego aktywnego konta:

| Pole                             | Opis                                                                                                                                    |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `openingDebit` / `openingCredit` | Saldo otwarcia okresu — liczone z zapisów **przed** `startDate`. Dla kont debetowych ujmowane po stronie Wn, kredytowych po stronie Ma. |
| `periodDebit` / `periodCredit`   | Obroty okresu — suma Wn i Ma zapisów w przedziale `[startDate, endDate]`.                                                               |
| `closingDebit` / `closingCredit` | Saldo zamknięcia — `opening ± period`, znormalizowane na właściwą stronę.                                                               |
| `isSynthetic`                    | Czy konto jest syntetykiem (3-cyfrowe) czy analityką (4+ cyfr).                                                                         |

Zwracana jest też flaga &#x2A;*`isBalanced`** — `true`, gdy `sum(closingDebit) = sum(closingCredit)` w obrębie tolerancji 1 grosza. Fałsz oznacza błąd w danych
(np. ręczny zapis niezbilansowany — co Numify w normalnym obiegu blokuje,
ale flaga jest dodatkową siatką bezpieczeństwa).

## Ekran `/trial-balance` [#ekran-trial-balance]

Górny pasek:

* **Zakres dat** — `startDate`, `endDate`. Domyślnie bieżący miesiąc; można
  rozwinąć do kwartału, roku lub dowolnego przedziału.
* **Typ konta** — filtr po `accountType` (aktywa, pasywa, kapitały, przychody,
  koszty).
* **Ukryj zerowe** — pomija konta bez obrotów i bez salda (domyślnie włączone).

Kolumny tabeli (od lewej): kod konta, nazwa, saldo otwarcia Wn, saldo otwarcia Ma,
obroty okresu Wn, obroty okresu Ma, saldo zamknięcia Wn, saldo zamknięcia Ma.

Pasek sumy u dołu pokazuje sumy wszystkich sześciu kolumn oraz badge
&#x2A;*„Zbilansowane"*&#x2A; (zielony) lub &#x2A;*„Nieuzgodnione"** (czerwony, z różnicą w
groszach). Ten badge to bezpośrednia realizacja kontroli z
<LegalRef act="UoR" art="18" paragraph="1" />.

{/* SCREENSHOT: pasek sumy u dołu obrotówki z kolumną Wn = Ma = 847 216,42 zł i zielonym badge'em „Zbilansowane" */}

## Obrotówka na różnych poziomach [#obrotówka-na-różnych-poziomach]

* **Syntetyka (`isSynthetic: true`)** — domyślny widok, wymagany przez
  <LegalRef act="UoR" art="18" paragraph="1" />. Tylko konta 3-cyfrowe (np.
  <AccountRef code="201" />, <AccountRef code="400" />).
* **Syntetyka + analityka** — przełącznik rozwija konta analityczne (4+ cyfr).
  Przydatne do rekoncyliacji rozrachunków per-kontrahent.
* **Tylko ksiegi pomocnicze** — zgodnie z <LegalRef act="UoR" art="18" paragraph="2" />,
  sporządzane co najmniej na dzień zamknięcia ksiąg. Numify udostępnia ten
  widok jako filtr `isSynthetic: false`.

## Uzgodnienie z dziennikiem [#uzgodnienie-z-dziennikiem]

Suma obrotów Wn dziennika w okresie = suma `periodDebit` wszystkich kont
syntetycznych = suma `periodCredit` wszystkich kont syntetycznych. To równanie
jest tożsamościowe w Numify, bo każdy `journal_line` jest policzony raz — i po
stronie dziennika (chronologicznie), i po stronie księgi głównej (na koncie).
Rozjazd jest technicznie niemożliwy dla zapisów `isPosted: true`.

Niemniej — w podstopce ekranu Numify wyświetla sumę obrotów dziennika w tym
samym okresie, jako kontrola wzrokowa.

## Zamknięcie miesiąca / roku [#zamknięcie-miesiąca--roku]

UoR nie wymaga „rytualnego" zamknięcia miesiąca; wymaga jedynie, żeby
zestawienie **istniało** na koniec każdego miesiąca (było dostępne do wydruku
lub przeniesienia na informatyczny nośnik danych —
<LegalRef act="UoR" art="13" paragraph="6" />). Numify spełnia ten wymóg przez
stałą dostępność `/trial-balance` oraz eksporty (<FeatureRef slug="exports">eksporty</FeatureRef>,
w przygotowaniu).

Zamknięcie **roku obrotowego** to osobna operacja — zob.
<FeatureRef slug="fiscal-periods">okresy obrachunkowe</FeatureRef> (strona w
przygotowaniu). Polega na oznaczeniu roku jako zamkniętego, przeniesieniu sald
kont wynikowych na <AccountRef code="860" /> (wynik finansowy) i zestawieniu
sald kont bilansowych jako bilans otwarcia kolejnego roku.

## Ograniczenia [#ograniczenia]

* **Brak eksportu do PDF/CSV z poziomu tego ekranu** — zaplanowane; dane są
  dostępne przez JPK\_KR\_PD, który zawiera pełne zestawienie.
* **Saldo analityki liczone on-the-fly** — nie materializujemy sald kont
  analitycznych w osobnej tabeli. Dla bardzo dużej liczby zapisów analityki
  (> 100 tys. linii w okresie) widok może być wolniejszy.
* **Brak porównania z okresem poprzednim na tym ekranie** — zamierzone
  rozdzielenie odpowiedzialności: porównanie międzyokresowe realizują
  <FeatureRef slug="balance-sheet">bilans</FeatureRef> i
  <FeatureRef slug="profit-loss">RZiS</FeatureRef>.

## Dlaczego obrotówka ma moc dowodową [#dlaczego-obrotówka-ma-moc-dowodową]

<LegalRef act="OrdPod" art="193" paragraph="1" /> przyznaje księgom prowadzonym
rzetelnie i w sposób niewadliwy moc dowodową. Zestawienie obrotów i sald jest
technicznym dowodem „niewadliwości" — pokazuje, że:

1. księgi są kompletne (wszystkie konta, wszystkie okresy),
2. są zbilansowane (`isBalanced: true`),
3. są uzgodnione z dziennikiem (obroty się zgadzają).

Brak obrotówki lub rozjazd sum to typowa przesłanka do uznania ksiąg za
wadliwe. Dlatego Numify eksponuje badge „Zbilansowane" i trzyma zapisy
`isPosted` jako jedyne źródło — szkice nie mogą zepsuć uzgodnienia.


---

# Bilans
URL: https://numifyai.com/docs/korzystanie-z-numify/balance-sheet
Description: Bilans aktywów i pasywów spółki na wybrany dzień, w strukturze Załącznika 1 do ustawy o rachunkowości. Saldo aktywów = saldo pasywów — kontrola bilansowa wymagana przez art. 46 UoR.
Review status: internal
Updated: 2026-04-17



**Bilans** to statutowe zestawienie aktywów i pasywów spółki na dzień
bilansowy — jeden z trzech obowiązkowych elementów sprawozdania finansowego
(<LegalRef act="UoR" art="45" paragraph="2" />). Numify generuje go w
strukturze **Załącznika 1 do UoR** (pełny, dla spółek niebędących jednostkami
mikro/małymi) na dowolny dzień i dla dowolnych dwóch okresów porównawczych.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /balance-sheet — po lewej aktywa, po prawej pasywa, kolumny „Stan na 31.12.RRRR" i „Stan na 31.12.RRRR-1" (porównawczy), dół strony z sumą kontrolną A = P i badge „Zbilansowany" */}

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

UoR wymaga, żeby bilans:

1. był sporządzony **na dzień zamknięcia ksiąg rachunkowych** oraz opcjonalnie
   na inny dzień bilansowy (<LegalRef act="UoR" art="45" paragraph="1" />),
2. pokazywał stany **bieżącego i poprzedniego roku** (<LegalRef act="UoR" art="46" paragraph="1" />),
3. miał strukturę z Załącznika 1 (<LegalRef act="UoR" art="46" paragraph="5" />).

Numify wyznacza bilans z zapisów w <FeatureRef slug="journal">dzienniku</FeatureRef>
„na żądanie" — każda zmiana w księdze głównej jest natychmiast widoczna w
bilansie, bez osobnego procesu „zamknięcia".

## Jak Numify agreguje konta [#jak-numify-agreguje-konta]

Każde konto w planie kont ma pole &#x2A;*`balanceSheetTag`** wskazujące pozycję
Załącznika 1, do której trafia jego saldo. Tagi mają strukturę hierarchiczną:

```
AKT_A          → A. Aktywa trwałe
AKT_A_I        → A.I.   Wartości niematerialne i prawne
AKT_A_II       → A.II.  Rzeczowe aktywa trwałe
AKT_A_II_1     → A.II.1 Środki trwałe (dalej rozbite)
AKT_B          → B. Aktywa obrotowe
AKT_B_I        → B.I.   Zapasy
...
PAS_A          → A. Kapitał (fundusz) własny
PAS_B          → B. Zobowiązania i rezerwy na zobowiązania
```

Usługa <ServiceRef path="src/lib/services/balance-sheet.ts" /> sumuje salda
wszystkich kont z danym tagiem (i jego „dziećmi") na wybrany `asOf` i zwraca
strukturę drzewiastą zgodną z Załącznikiem 1.

Pełna mapa pozycji (A.I.1, A.I.2, …, D, oraz wszystkie pozycje pasywów) —
zob. <FeatureRef slug="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe">sprawozdanie
finansowe → bilans</FeatureRef>. Ta strona opisuje **jak Numify liczy bilans**,
nie powtarza ustawowego katalogu pozycji.

## Reguła agregacji sald [#reguła-agregacji-sald]

Dla każdego konta bierzemy saldo na dzień `asOf`:

* **Konta aktywowe** (typ `asset`, `expense` — grupy 0–3, 4, niektóre 6): saldo
  debetowe (Wn). Jeśli saldo jest po stronie Ma, oznacza to sytuację nietypową
  (np. nadpłatę należności) — trafia do odpowiedniej pozycji pasywów (jako
  zobowiązanie) lub kompensuje się z pokrewnym kontem.
* **Konta pasywowe** (`liability`, `equity`, `revenue`): saldo kredytowe (Ma).
* **Rozrachunki** (<AccountRef code="201" />, <AccountRef code="202" />): per
  kontrahent analitycznie — saldo Wn u jednego trafia do aktywów jako
  należności, saldo Ma u innego trafia do pasywów jako zobowiązania. Nie
  kompensujemy per syntetyk (art. 46 ust. 2a UoR dopuszcza kompensatę tylko w
  określonych przypadkach).

### Korekty wartości aktywów (art. 46 ust. 2) [#korekty-wartości-aktywów-art-46-ust-2]

<LegalRef act="UoR" art="46" paragraph="2" /> wymaga, żeby w bilansie wykazywać
wartości aktywów **po korektach**:

* Środki trwałe — po odpisach amortyzacyjnych (<AccountRef code="070" />
  umorzenie jako kontra do <AccountRef code="010" /> środki trwałe).
* Należności — po odpisach aktualizujących.
* Zapasy — po odpisach aktualizujących wartość.

W Numify odpisy są osobnymi kontami kontrarywnymi z typem `contra_asset`.
Saldo netto pozycji bilansowej wynika z różnicy: `010 − 070`, gdzie konto
umorzenia ma `balanceSheetTag` wskazujące tę samą pozycję A.II.1 z przeciwnym
znakiem.

## Okres porównawczy [#okres-porównawczy]

Bilans zawsze pokazuje dwie kolumny: stan na wybrany `asOf` oraz stan na
odpowiadający mu dzień roku poprzedniego (domyślnie `asOf - 1 year`).
Jest to wymóg <LegalRef act="UoR" art="46" paragraph="1" />.

Dla pierwszego roku obrotowego spółki kolumna porównawcza pokazuje **bilans
otwarcia** (zob. <FeatureRef slug="/docs/pierwsze-kroki/bilans-otwarcia">bilans
otwarcia</FeatureRef>).

## Kontrola bilansowa: A = P [#kontrola-bilansowa-a--p]

Na dole ekranu Numify pokazuje:

* Sumę aktywów (`totalAssets`).
* Sumę pasywów (`totalLiabilities`).
* Badge &#x2A;*„Zbilansowany"** (`isBalanced: true&#x60;) lub &#x2A;*„Nieuzgodniony"** z
  różnicą w groszach.

Rozjazd oznacza błąd w konfiguracji planu kont (np. konto bez
`balanceSheetTag`) lub nieprawidłowe księgowanie. Przy poprawnie prowadzonych
księgach rozjazd jest **niemożliwy** — bilans wynika z tych samych
`journal_lines` co <FeatureRef slug="trial-balance">zestawienie obrotów i sald</FeatureRef>,
w którym `sum(Wn) = sum(Ma)` jest wymuszone.

## Ekran `/balance-sheet` [#ekran-balance-sheet]

Górny pasek:

* **Dzień bilansowy** — `asOf`. Domyślnie ostatni dzień zamkniętego miesiąca.
  Dla rocznego sprawozdania: 31 grudnia.
* **Dzień porównawczy** — domyślnie `asOf - 1 rok`; można zmienić ręcznie.
* **Eksport** — PDF w układzie Załącznika 1, CSV z pełnym rozwinięciem.

Tabela ma dwie kolumny liczbowe (bieżący / porównawczy) i układ drzewiasty —
domyślnie rozwinięte poziomy A/B (sekcje), poziomy I/II/III (kategorie) — po
kliknięciu rozwijają się detale (A.II.1, A.II.2…).

{/* SCREENSHOT: sekcja „A. Aktywa trwałe" rozwinięta do poziomu A.II.1 „Środki trwałe" — widać wartość brutto, umorzenie i wartość netto */}

## Wycena (rozdział 4 UoR) [#wycena-rozdział-4-uor]

<LegalRef act="UoR" art="45" paragraph="1" /> wymaga wyceny aktywów i pasywów
zgodnie z rozdziałem 4 UoR. Kluczowe zasady (implementowane przez politykę
rachunkowości, nie przez ten ekran):

* Wycena walutowa — po kursie średnim NBP z dnia bilansowego
  (art. 30 UoR), z różnicami kursowymi na <AccountRef code="750" /> /
  <AccountRef code="751" />.
* Wycena zapasów — według ceny nabycia lub kosztu wytworzenia (art. 28).
* Odpisy aktualizujące — obligatoryjne w przypadku trwałej utraty wartości.

Jeśli spółka stosuje te zasady w <FeatureRef slug="/docs/pierwsze-kroki/polityka-rachunkowosci">polityce
rachunkowości</FeatureRef>, bilans wyliczany przez Numify odzwierciedla je
automatycznie — bo są one wdrożone jako zasady księgowania, nie jako logika
raportu.

## Ograniczenia [#ograniczenia]

* **Wariant pełny (Załącznik 1)** — obecnie jedyny obsługiwany. Uproszczone
  warianty dla jednostek mikro (Załącznik 4) i małych (Załącznik 5) nie są
  zaimplementowane. Typowa spółka z o.o. podlegająca kontrolowanej
  księgowości korzysta z Załącznika 1.
* **Brak podpisu kwalifikowanego na tym ekranie** — <LegalRef act="UoR" art="45" paragraph="1" />
  wymaga podpisu kwalifikowanego, podpisu zaufanego albo osobistego na
  sprawozdaniu finansowym. Podpis składa się na pliku e-Sprawozdania (zob.
  <ServiceRef path="src/lib/services/e-sprawozdanie.ts" />), nie na podglądzie
  w aplikacji.
* **Porównanie do innych dni niż zamknięcie roku** — technicznie działa, ale
  UoR wymaga bilansu głównie na dzień zamknięcia ksiąg. Widoki śródroczne są
  pomocne operacyjnie, nie zastępują sprawozdania finansowego.

## Relacja do innych raportów [#relacja-do-innych-raportów]

* <FeatureRef slug="profit-loss">RZiS</FeatureRef> — drugi obowiązkowy
  element sprawozdania; wynik netto z RZiS trafia do bilansu jako pozycja
  A.VI „Zysk (strata) netto" w kapitale własnym.
* <FeatureRef slug="trial-balance">Zestawienie obrotów i sald</FeatureRef> —
  techniczne zestawienie sald, z którego wyprowadzany jest bilans. Sumy sald
  kont aktywowych = `totalAssets`, sumy sald kont pasywowych = `totalLiabilities`.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe">Sprawozdanie
  finansowe (pełna dokumentacja)</FeatureRef> — katalog pozycji Załącznika 1,
  reguły wyceny, informacja dodatkowa, e-Sprawozdanie w strukturze XBRL.

## Sprawozdanie finansowe = bilans + RZiS + informacja dodatkowa [#sprawozdanie-finansowe--bilans--rzis--informacja-dodatkowa]

<LegalRef act="UoR" art="45" paragraph="2" /> zawsze wymaga trzech elementów.
Niektóre jednostki (nie jednostki mikro i małe) dodatkowo — zestawienia zmian
w kapitale własnym i rachunku przepływów pieniężnych. Dla typowej spółki z
o.o. niekwalifikującej się jako mikro/mała obowiązkowe są wszystkie pięć.
Numify obsługuje bilans + RZiS natywnie; pozostałe elementy — przez
<ServiceRef path="src/lib/services/informacja-dodatkowa.ts" /> i eksport
e-Sprawozdania.


---

# KSeF
URL: https://numifyai.com/docs/korzystanie-z-numify/ksef
Description: Integracja z Krajowym Systemem e-Faktur (KSeF) — zapis tokena API, otwieranie i zamykanie sesji, synchronizacja faktur otrzymanych oraz wysyłanie faktur wystawionych w schemacie FA(3). Obowiązkowy KSeF od 1 kwietnia 2026 r. dla podatników VAT czynnych z siedzibą w Polsce.
Review status: numify-source
Updated: 2026-04-17



**KSeF** (Krajowy System e-Faktur) to centralny system Ministerstwa
Finansów, przez który podatnicy VAT w Polsce wystawiają i otrzymują
faktury ustrukturyzowane. **Obowiązkowy** od 1 lutego 2026 r. dla
dużych podatników i od 1 kwietnia 2026 r. dla pozostałych — obecnie
obowiązuje dla wszystkich spółek z o.o. zarejestrowanych jako czynni
podatnicy VAT.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /ksef — karta statusu sesji (aktywna / nieaktywna), sekcja tokenu, przycisk Synchronizuj faktury, tabela otrzymanych faktur KSeF */}

## Obowiązek w pigułce [#obowiązek-w-pigułce]

<LegalRef act="VAT" art="106ga" paragraph="1" />: **podatnicy są
obowiązani wystawiać faktury ustrukturyzowane przy użyciu KSeF**.
Faktura wystawiona poza KSeF po 1 kwietnia 2026 r. to faktura
wadliwa — nie daje nabywcy prawa do odliczenia VAT naliczonego.

**Wyjątki** (<LegalRef act="VAT" art="106ga" paragraph="2" />):

* Faktury dla **osób fizycznych nieprowadzących działalności
  gospodarczej** (B2C) — wystawiasz zwykłą fakturę / paragon.
* Faktury wystawione przez **podatnika bez siedziby w Polsce** (lub
  bez stałego miejsca prowadzenia działalności uczestniczącego w
  dostawie).
* Faktury w procedurach szczególnych (**OSS / IOSS** — sprzedaż
  konsumencka UE, usługi elektroniczne).
* Podatnicy zwolnieni z art. 113a (sprzedaż poniżej progu przez
  podatnika z siedzibą w innym państwie UE).

Dla typowej spółki z o.o. prowadzącej działalność B2B w Polsce
**wszystkie faktury sprzedaży i zakupu przechodzą przez KSeF**.

## Architektura — co robi Numify [#architektura--co-robi-numify]

Integracja KSeF w Numify ma trzy warstwy:

1. **`ksef-api.ts`** (<ServiceRef path="src/lib/services/ksef-api.ts" tests="21" />) — niskopoziomowe wywołania REST API Ministerstwa Finansów: autoryzacja, sesja, wysyłka, odbiór, status.
2. **`ksef-service.ts`** (<ServiceRef path="src/lib/services/ksef-service.ts" tests="40" />) — warstwa aplikacji: zarządzanie danymi uwierzytelniającymi, synchronizacja z lokalną bazą, powiązanie z fakturami Numify.
3. **`ksef-fa3-generator.ts` / `ksef-fa3-parser.ts`** (<ServiceRef path="src/lib/services/ksef-fa3-generator.ts" tests="35" /> / <ServiceRef path="src/lib/services/ksef-fa3-parser.ts" tests="29" />) — konwersja między modelem faktury Numify a schemą &#x2A;*FA(3)** (<LegalRef act="VAT" art="106nda" paragraph="1" />).
4. **`ksef-qr.ts`** (<ServiceRef path="src/lib/services/ksef-qr.ts" tests="11" />) — generowanie kodów QR na wydrukach faktur (wymagane, gdy faktura z KSeF jest udostępniana poza KSeF, np. drukowana dla nabywcy).

## Przepływ danych — cztery ścieżki [#przepływ-danych--cztery-ścieżki]

### A. Sprzedaż: wystawienie faktury przez Numify → KSeF [#a-sprzedaż-wystawienie-faktury-przez-numify--ksef]

1. Użytkownik wystawia fakturę w Numify (<FeatureRef slug="faktury" />).
2. Numify konwertuje fakturę do **FA(3) XML** (`ksef-fa3-generator.ts`).
3. `sendInvoiceToKsef` wysyła XML do KSeF przez aktywną sesję (`ksefReferenceNumber` → status `processing` → `ok` / `failed`).
4. KSeF zwraca **numer KSeF** (unikalny identyfikator faktury w systemie).
5. Numify zapisuje numer KSeF przy fakturze; od tego momentu faktura jest „w KSeF".

Data wystawienia (<LegalRef act="VAT" art="106nda" paragraph="10" />)
to data wskazana przez podatnika na fakturze (`data wystawienia`), a
nie data przydzielenia numeru KSeF — ma to znaczenie przy księgowaniu.

### B. Zakup: synchronizacja faktur otrzymanych [#b-zakup-synchronizacja-faktur-otrzymanych]

1. `syncReceivedInvoices(companyId)` odpytuje KSeF o nowe faktury, gdzie nabywcą jest spółka (po NIP).
2. Dla każdej nowej faktury Numify:
   * Pobiera XML (`downloadInvoice`),
   * Parsuje FA(3) do modelu Numify (`ksef-fa3-parser.ts`),
   * Tworzy wpis w tabeli faktur otrzymanych z flagą `source = 'ksef'`,
   * Próbuje dopasować do <FeatureRef slug="dokumenty">dokumentu</FeatureRef> (jeśli nabywca już przetworzył PDF tej samej faktury).
3. Użytkownik widzi nowe faktury w liście z banerem „Pobrane z KSeF".

Synchronizacja jest **ręczna** (przycisk „Synchronizuj") — planowana
jest obsługa automatycznego pollingu (`updatePollSettings` już istnieje,
ale scheduler nie jest jeszcze włączony).

### C. Status wysłanej faktury [#c-status-wysłanej-faktury]

Po wysłaniu faktury do KSeF status (`refreshInvoiceKsefStatus`)
przechodzi przez stany:

| Status       | Znaczenie                                       |
| ------------ | ----------------------------------------------- |
| `pending`    | Faktura wysłana, oczekuje na przetworzenie      |
| `processing` | KSeF walidację schematu FA(3)                   |
| `ok`         | Faktura zaakceptowana, numer KSeF przydzielony  |
| `failed`     | Odrzucona — Numify przechowuje kod błędu i opis |

W przypadku `failed` faktura **nie jest uznawana za wystawioną**
prawnie — wymaga korekty i ponownego wysłania.

### D. Kod QR dla wersji drukowanej / PDF [#d-kod-qr-dla-wersji-drukowanej--pdf]

<LegalRef act="VAT" art="106nda" paragraph="6" /> wymaga, aby faktura
z KSeF udostępniana poza KSeF (np. w PDF dla nabywcy) była oznaczona
**kodem QR** umożliwiającym weryfikację autentyczności. Numify
generuje kod przez `ksef-qr.ts` i umieszcza na PDF faktury.

## Konfiguracja w Numify [#konfiguracja-w-numify]

{/* SCREENSHOT: sekcja konfiguracji — pole tokenu API, przycisk Otwórz sesję, status sesji z datą ważności */}

### 1. Token uwierzytelniający [#1-token-uwierzytelniający]

Spółka uzyskuje token KSeF w e-Urzędzie Skarbowym (profil zaufany lub
podpis kwalifikowany członka zarządu). Token daje Numify uprawnienia
do wystawiania faktur w imieniu spółki.

* `saveCredentials(companyId, token)` — zapisuje zaszyfrowany token w bazie.
* Token nigdy nie jest zwracany w API Numify — tylko używany wewnętrznie do negocjacji sesji.

### 2. Otwieranie sesji [#2-otwieranie-sesji]

* `openSession(companyId)` — wywołuje KSeF, pobiera challenge, szyfruje token, otrzymuje `sessionToken` ważny 2 godziny.
* Numify trzyma `sessionToken` w pamięci / bazie, odświeża przy potrzebie.

### 3. Zamykanie sesji [#3-zamykanie-sesji]

* `closeSession(companyId, userId)` — ręczne zakończenie sesji (np. przy zmianie tokenu).

## Workflow — pierwsze uruchomienie [#workflow--pierwsze-uruchomienie]

1. **W e-Urzędzie Skarbowym** — wygeneruj token KSeF dla swojej spółki (uprawnienia: wystawianie i odbiór faktur).
2. **W Numify** — wklej token na `/ksef` i zapisz.
3. **Otwórz sesję** (przycisk „Otwórz sesję" lub automatyczne otwarcie przy pierwszym użyciu).
4. **Synchronizuj faktury otrzymane** — pierwszy raz ściągnie wszystkie faktury od momentu rozpoczęcia obowiązywania KSeF dla spółki.
5. **Wystaw testowo fakturę** w Numify → zostanie automatycznie wysłana do KSeF.
6. **Zweryfikuj numer KSeF** na fakturze w liście — powinien pojawić się w ciągu kilkudziesięciu sekund.

## Korekty faktur KSeF [#korekty-faktur-ksef]

<LegalRef act="VAT" art="106nda" paragraph="12" />: faktura
korygująca fakturę wystawioną w KSeF jest **także wystawiana w KSeF**
po przydzieleniu numeru identyfikującego fakturze pierwotnej. Numify
tworzy fakturę korygującą, pobiera numer KSeF pierwotnej z bazy i
wysyła korektę jako osobny dokument FA(3) z odwołaniem.

## Awarie KSeF i tryb offline [#awarie-ksef-i-tryb-offline]

Ustawa przewiduje **tryb awaryjny** — gdy KSeF jest niedostępny,
podatnik wystawia fakturę poza KSeF (w postaci elektronicznej
zgodnie ze wzorem) i ma obowiązek przesłać ją do KSeF nie później
niż **następnego dnia roboczego** po dniu jej wystawienia
(<LegalRef act="VAT" art="106nda" paragraph="2" />).

Numify w stanie niedostępności KSeF:

* Zapisuje fakturę lokalnie z flagą `pending`,
* Dodaje zadanie retry do kolejki (obecnie: ręczne, planowane: automatyczne via BullMQ),
* Pozwala wydrukować fakturę z kodem QR offline (<LegalRef act="VAT" art="106nda" paragraph="6" />).

Po odzyskaniu łączności Numify automatycznie ponowi próbę wysłania.

## Bezpieczeństwo tokenu [#bezpieczeństwo-tokenu]

* Token jest **szyfrowany** przed zapisem do bazy — klucz szyfrowania w zmiennej środowiskowej (nie w kodzie).
* Token nie pojawia się w logach, w odpowiedziach API Eden ani w zrzutach błędów.
* Rotacja tokenu: usuń stary z bazy (`saveCredentials` z nowym tokenem), sesja zostanie zamknięta przy następnym wywołaniu.

## Zakres obecnej implementacji — co jest, a czego nie ma [#zakres-obecnej-implementacji--co-jest-a-czego-nie-ma]

**Jest:**

* ✅ Autoryzacja tokenem, zarządzanie sesją (2 h TTL).
* ✅ Wysyłanie faktur sprzedaży w schemacie FA(3).
* ✅ Synchronizacja faktur otrzymanych (po NIP nabywcy).
* ✅ Kody QR na wydrukach faktur.
* ✅ Korekty faktur KSeF.

**W planach / brak pełnego pokrycia:**

* ⏳ Automatyczny polling faktur otrzymanych (harmonogram).
* ⏳ Faktury zaliczkowe i faktury WDT ze specjalnym oznaczeniem.
* ⏳ Obsługa pełnej palety komunikatów błędów KSeF (obecnie: podstawowe kody).
* ⏳ Uprawnienia wielu użytkowników do KSeF (obecnie: jedno konto tokena per spółka).

## Księgowanie faktur KSeF [#księgowanie-faktur-ksef]

Faktury KSeF (sprzedaż i zakup) są księgowane identycznie jak
faktury „klasyczne":

* **Sprzedaż** — zapis w dzienniku: <AccountRef code="201" /> (Wn) / <AccountRef code="700" /> (Ma) + VAT na <AccountRef code="220" /> (Ma).
* **Zakup** — zapis w dzienniku: <AccountRef code="400" /> (Wn) + <AccountRef code="220" /> VAT naliczony (Wn) / <AccountRef code="202" /> (Ma).

Patrz szczegółowo: <FeatureRef slug="faktury" />.

## Powiązania [#powiązania]

* <FeatureRef slug="faktury">Faktury</FeatureRef> — integracja KSeF działa automatycznie w tle; użytkownik wystawia fakturę, Numify wysyła do KSeF.
* <FeatureRef slug="dokumenty">Dokumenty</FeatureRef> — faktury pobrane z KSeF są dopasowywane do dokumentów PDF/IMG, jeśli nabywca już przetworzył wizualną wersję.
* <FeatureRef slug="vat-register">Rejestr VAT</FeatureRef> — wszystkie faktury KSeF trafiają do rejestru VAT automatycznie.
* <FeatureRef slug="exports">Eksporty</FeatureRef> — JPK\_V7 agreguje faktury z rejestru VAT bez względu na źródło (KSeF / ręczne / import).


---

# Rachunek zysków i strat
URL: https://numifyai.com/docs/korzystanie-z-numify/profit-loss
Description: RZiS w wariancie porównawczym per Załącznik 1 UoR — od przychodów netto ze sprzedaży (A) do zysku/straty netto (L). Generowany na żądanie z zapisów dziennika za wybrany okres.
Review status: internal
Updated: 2026-04-17



**Rachunek zysków i strat** (RZiS) pokazuje wynik finansowy spółki za okres —
od przychodów netto ze sprzedaży (pozycja A) przez kolejne poziomy wyniku
(C — wynik ze sprzedaży, F — z działalności operacyjnej, I — brutto) do
zysku/straty netto (L). Numify stosuje **wariant porównawczy** Załącznika 1
UoR — koszty grupowane rodzajowo (zużycie materiałów, wynagrodzenia,
amortyzacja itd.).

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /profit-loss — struktura RZiS A→L w jednej kolumnie, dwie kolumny liczbowe „Okres bieżący" i „Okres poprzedni", na dole zysk netto wyróżniony */}

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

<LegalRef act="UoR" art="45" paragraph="2" /> wymienia RZiS jako drugi z
trzech obowiązkowych elementów sprawozdania finansowego (obok bilansu i
informacji dodatkowej). Art. 47 dookreśla strukturę:

* Oddzielne wykazanie przychodów, kosztów, zysków, strat oraz obowiązkowych
  obciążeń wyniku (<LegalRef act="UoR" art="47" paragraph="1" />).
* Okres porównawczy — bieżący rok i poprzedni rok obrotowy (lub bieżący okres
  sprawozdawczy i analogiczny okres roku poprzedniego, <LegalRef act="UoR" art="47" paragraph="2" />).
* Wybór wariantu — **porównawczy albo kalkulacyjny** — należy do kierownika
  jednostki (<LegalRef act="UoR" art="47" paragraph="4" />). Numify stosuje
  porównawczy; wybór ten należy odzwierciedlić w
  <FeatureRef slug="/docs/pierwsze-kroki/polityka-rachunkowosci">polityce
  rachunkowości</FeatureRef>.

## Wariant porównawczy vs. kalkulacyjny [#wariant-porównawczy-vs-kalkulacyjny]

W **porównawczym** koszty grupuje się **rodzajowo** (grupa 4 planu kont):
<AccountRef code="400" /> (amortyzacja), <AccountRef code="401" /> (zużycie
materiałów), <AccountRef code="402" /> (usługi obce), <AccountRef code="403" />
(podatki i opłaty), <AccountRef code="404" /> (wynagrodzenia),
<AccountRef code="405" /> (ubezpieczenia społeczne).

W **kalkulacyjnym** koszty grupuje się **funkcjonalnie** — koszt wytworzenia
sprzedanych produktów, koszty sprzedaży, koszty ogólnego zarządu (grupy 5 i 7
planu kont).

Numify opiera się na grupie 4 i dlatego domyślnie generuje porównawczy.
Przejście na kalkulacyjny wymagałoby prowadzenia równoległej ewidencji kosztów
według miejsc powstawania — nieobecne w obecnej implementacji. Dla typowej
spółki usługowo-handlowej z o.o. porównawczy jest wystarczający i powszechnie
stosowany.

## Struktura (Załącznik 1) [#struktura-załącznik-1]

Pełny katalog pozycji Załącznika 1 jest opisany w
<FeatureRef slug="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe">sprawozdaniu
finansowym</FeatureRef>. Poniżej najwyższy poziom, który Numify liczy:

| Poz.  | Nazwa                                          | Obliczenie                                                                            |
| ----- | ---------------------------------------------- | ------------------------------------------------------------------------------------- |
| **A** | Przychody netto ze sprzedaży i zrównane z nimi | Suma kont 700/701 (+ zmiana stanu produktów, + koszty wytworzenia na własne potrzeby) |
| **B** | Koszty działalności operacyjnej                | Suma kont grupy 4 (400–409) oraz wartości sprzedanych towarów                         |
| **C** | Zysk (strata) ze sprzedaży                     | A − B                                                                                 |
| **D** | Pozostałe przychody operacyjne                 | Konta 760 i powiązane                                                                 |
| **E** | Pozostałe koszty operacyjne                    | Konta 761 i powiązane                                                                 |
| **F** | Zysk (strata) z działalności operacyjnej       | C + D − E                                                                             |
| **G** | Przychody finansowe                            | Odsetki, różnice kursowe, dywidendy — <AccountRef code="750" /> i pokrewne            |
| **H** | Koszty finansowe                               | Odsetki od kredytów, ujemne różnice kursowe — <AccountRef code="751" />               |
| **I** | Zysk (strata) brutto                           | F + G − H                                                                             |
| **J** | Podatek dochodowy                              | Konto <AccountRef code="870" /> — podatek bieżący + odroczony                         |
| **K** | Pozostałe obowiązkowe zmniejszenia zysku       | Rzadko stosowane                                                                      |
| **L** | Zysk (strata) netto                            | I − J − K                                                                             |

`PnlResult` z <ServiceRef path="src/lib/services/profit-loss.ts" /> zawiera
wszystkie te pola jako osobne liczby (`salesRevenue`, `operatingCosts`,
`salesResult`, …, `netResult`) oraz tablicę `lines` rozbitą do pełnego poziomu
z Załącznika 1.

## Jak Numify agreguje konta [#jak-numify-agreguje-konta]

Każde konto w planie kont ma pole &#x2A;*`pnlTag`** wskazujące pozycję RZiS, do
której trafia jego saldo. Tagi są hierarchiczne, analogiczne do tagów
bilansowych:

```
PNL_A          → A. Przychody netto ze sprzedaży
PNL_A_I        → A.I.   Przychody ze sprzedaży produktów
PNL_A_II       → A.II.  Zmiana stanu produktów
PNL_A_III      → A.III. Koszt wytworzenia produktów na własne potrzeby
PNL_A_IV       → A.IV.  Przychody ze sprzedaży towarów i materiałów
PNL_B          → B. Koszty działalności operacyjnej
PNL_B_I        → B.I.   Amortyzacja
PNL_B_II       → B.II.  Zużycie materiałów i energii
...
```

Tag ma też znak (`sign: +1` lub `-1`) — jest dodawany/odejmowany od wyniku
na danym poziomie.

## Okres i zakres dat [#okres-i-zakres-dat]

Wybierasz `startDate` i `endDate` — typowo:

* **Rok**: 1 stycznia – 31 grudnia.
* **Kwartał**: np. 1 kwietnia – 30 czerwca.
* **Miesiąc**: 1 stycznia – 31 stycznia (użyteczne do kontroli zarządczej,
  nie jest to samo co sprawozdanie finansowe).

Kolumna porównawcza pokazuje **analogiczny okres roku poprzedniego**
(<LegalRef act="UoR" art="47" paragraph="2" />) — np. 1 stycznia – 31 grudnia
roku poprzedniego. Dla pierwszego roku działalności kolumna porównawcza
pozostaje pusta (nie istniejemy jeszcze).

## Wynik na kilku poziomach [#wynik-na-kilku-poziomach]

Typowy błąd: patrzenie tylko na wynik netto (L). RZiS ma **cztery poziomy
wyniku**, każdy odpowiadający na inne pytanie:

* **C — Zysk ze sprzedaży** — czy podstawowa działalność jest rentowna?
* **F — Zysk operacyjny** — jak wypadamy po uwzględnieniu pozostałych
  operacji (różnice inwentaryzacyjne, sprzedaż środków trwałych, odpisy)?
* **I — Zysk brutto** — jaki jest wynik przed opodatkowaniem?
  To punkt wyjścia do wyliczenia podstawy CIT w korekcie fiskalnej.
* **L — Zysk netto** — ostatecznie, po podatku. Trafia do bilansu jako
  pozycja kapitału własnego (A.VI).

Numify wyświetla wszystkie cztery wyraźnie — nie tylko L na dole.

## Relacja z CIT [#relacja-z-cit]

<LegalRef act="UoR" art="47" paragraph="1" /> wymaga, żeby w RZiS osobno
wykazać „obowiązkowe obciążenia wyniku finansowego" — m.in. podatek
dochodowy. W Numify:

* Pozycja J agreguje konta grupy 87 (typowo <AccountRef code="870" />).
* Wartość pokazana w J to **podatek księgowy** — wynik podatku ustalonego
  zgodnie z art. 38 UoR (bieżący + odroczony). Nie jest to bezpośrednio kwota
  do zapłaty do urzędu skarbowego.
* Kwota do zapłaty (CIT-8) wynika z osobnej kalkulacji — zob.
  <FeatureRef slug="cit-data">dane do CIT</FeatureRef> (strona w przygotowaniu)
  z korektą wyniku bilansowego o pozycje niestanowiące KUP, przychodów
  wolnych, itd.

Różnica między wynikiem bilansowym (I) a podstawą opodatkowania CIT to
typowa różnica trwała/przejściowa, którą Numify dokumentuje w
<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-cit">rozdziałach o CIT</FeatureRef>.

## Działalność zaniechana [#działalność-zaniechana]

<LegalRef act="UoR" art="47" paragraph="3" /> wymaga odrębnego wykazania
przychodów i kosztów związanych z planowanym zaprzestaniem działalności.
W Numify obecnie **nie ma dedykowanego tagu** dla działalności zaniechanej —
jeśli spółka taką prowadzi, wymaga to ręcznego wyodrębnienia przez konta
analityczne i korekty raportu. Planowane jako rozszerzenie.

## Ekran `/profit-loss` [#ekran-profit-loss]

Górny pasek:

* **Zakres dat** — `startDate`, `endDate`. Domyślnie bieżący rok obrotowy.
* **Okres porównawczy** — automatycznie `-1 rok`; można zmienić.
* **Wariant** — obecnie tylko porównawczy; przełącznik wyłączony z
  tooltipem „kalkulacyjny w przygotowaniu".
* **Eksport** — PDF w układzie Załącznika 1, CSV z pełnym rozwinięciem.

Struktura pionowa A → L z wcięciami odpowiadającymi poziomom (0=sekcja
A/B/C…, 1=I/II/III…, 2=1/2/3…). Pozycje wyliczeniowe (C, F, I, L) są
pogrubione i oddzielone od pozycji agregujących.

{/* SCREENSHOT: zbliżenie na poziom C/F/I/L z wyraźnym pogrubieniem i znakiem (+/-) dla pozycji dodawanych/odejmowanych */}

## Uzgodnienie z bilansem [#uzgodnienie-z-bilansem]

Wynik netto (L) z RZiS za rok obrotowy = zmiana kapitału własnego w bilansie
(pozycja A.VI „Zysk/strata netto"). Jeśli się nie zgadza — błąd w mapowaniu
tagów lub w zapisach podziałowych. Numify uzgadnia to automatycznie, bo oba
raporty wychodzą z tych samych `journal_lines`, a pozycja A.VI bilansu bierze
dane z tego samego zbioru co RZiS.

## Ograniczenia [#ograniczenia]

* **Tylko wariant porównawczy** — zgodne z <LegalRef act="UoR" art="47" paragraph="4" />,
  ale ogranicza spółki, które już stosują kalkulacyjny.
* **Brak RZiS miesięcznego w układzie ustawowym z oficjalnym podpisem** — do
  celów podatkowych / sprawozdawczych wymagany roczny. Widok miesięczny/
  kwartalny jest operacyjny.
* **Brak osobnego wyodrębnienia działalności zaniechanej** (art. 47 ust. 3) —
  zaplanowane.
* **Podatek odroczony** — obecnie liczony ręcznie i księgowany na
  <AccountRef code="870" />; dedykowany workflow podatku odroczonego (art. 37
  UoR) nie jest jeszcze zaimplementowany.

## Relacja do innych ekranów [#relacja-do-innych-ekranów]

* <FeatureRef slug="balance-sheet">Bilans</FeatureRef> — drugi statutowy
  raport; wynik netto L zasila pozycję A.VI kapitału własnego.
* <FeatureRef slug="trial-balance">Zestawienie obrotów i sald</FeatureRef> —
  saldo kont przychodowych i kosztowych to podstawa wyliczenia wszystkich
  pozycji RZiS.
* <FeatureRef slug="cit-data">Dane do CIT</FeatureRef> — korekta wyniku
  bilansowego (I) do podstawy opodatkowania.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/sprawozdanie-finansowe">Sprawozdanie
  finansowe (pełna dokumentacja)</FeatureRef> — katalog pozycji A.I.1,
  B.II.3 itp., zasady wyboru wariantu, informacja dodatkowa.


---

# Szczegóły dokumentu
URL: https://numifyai.com/docs/korzystanie-z-numify/document-detail
Description: Widok detalu pojedynczego dokumentu (PDF, skan faktury, zdjęcie paragonu) — podgląd oryginału, metadane, status parsingu AI oraz lista powiązanych transakcji wyciągniętych z dokumentu. Punkt audytowy dla dowodów źródłowych wg ustawy o rachunkowości.
Review status: internal
Updated: 2026-04-17



**Szczegóły dokumentu** to widok detalu pojedynczego pliku wgranego
do <FeatureRef slug="dokumenty">dokumentów</FeatureRef> — PDF
faktury, skan, zdjęcie paragonu. Pozwala zobaczyć oryginał, metadane
i transakcje wyciągnięte z niego przez parser AI.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /documents/[id] — z lewej podgląd PDF w iframe, z prawej panel Details i lista Extracted Transactions */}

## Rola dokumentu w rachunkowości [#rola-dokumentu-w-rachunkowości]

Dokumenty wgrane do Numify pełnią rolę **dowodów księgowych** w
rozumieniu <LegalRef act="UoR" art="20" paragraph="2" />. Najczęściej
są to **dowody zewnętrzne obce** — faktury zakupowe otrzymane od
dostawców.

<LegalRef act="UoR" art="20" paragraph="5" /> dopuszcza komputerowe
prowadzenie ksiąg pod warunkiem:

1. **trwałej czytelności** zapisów zgodnej z dowodami,
2. **możliwości stwierdzenia źródła** i osoby odpowiedzialnej,
3. **poprawności przetwarzania** i kompletności,
4. **ochrony danych źródłowych** przed zmianą.

Numify spełnia te wymogi: oryginał pliku przechowywany jest w
Cloudflare R2 (niemutowalne obiekty), każdy upload ma zapisanego
użytkownika i timestamp, parser zapisuje wyniki atomowo, a
transakcje powstałe z dokumentu są powiązane z ID dokumentu w
bazie.

## Struktura ekranu [#struktura-ekranu]

### Nagłówek [#nagłówek]

* **Przycisk powrotu** — nawiguje do listy <FeatureRef slug="dokumenty" />.
* **Ikona + nazwa pliku** — oryginalna nazwa przy uploadzie.
* **Badge statusu** — `Oczekujący` / `Przetwarzanie` / `Przetworzony` / `Błąd` (kolor zależy od statusu).
* **Rozmiar i MIME type** — dane techniczne pliku.
* **Przycisk „Open Original"** — otwiera oryginał w nowej karcie (bezpośredni link do obiektu R2 przez tymczasowy podpisany URL).

### Preview — podgląd oryginału [#preview--podgląd-oryginału]

Lewa (szeroka) kolumna na większych ekranach:

* **PDF** — osadzony w iframe z natywnym podglądem przeglądarki.
* **Obraz** (JPG, PNG, WEBP) — wyświetlany jako `<img>` z `object-contain`.
* **Inne typy** — ikona placeholder z komunikatem „Preview not available".

Podgląd jest **tylko do odczytu** — nie pozwala na modyfikację,
komentarze ani zaznaczenia. Wymóg niezmienności dowodu
(<LegalRef act="UoR" art="20" paragraph="5" />) jest spełniony
architektonicznie: Numify nie daje narzędzi do edycji pliku
źródłowego.

### Details — metadane [#details--metadane]

Prawa kolumna, pierwsza karta:

| Pole             | Opis                                                          |
| ---------------- | ------------------------------------------------------------- |
| **Created**      | Data i czas uploadu do Numify                                 |
| **Last Updated** | Ostatnia modyfikacja rekordu (np. zmiana statusu po parsingu) |
| **File name**    | Oryginalna nazwa z uploadu                                    |
| **Size**         | Rozmiar w bajtach (formatowany do KB/MB)                      |
| **MIME type**    | Typ pliku (np. `application/pdf`)                             |
| **Status**       | Aktualny stan parsingu                                        |

### Extracted Transactions — transakcje wyciągnięte z dokumentu [#extracted-transactions--transakcje-wyciągnięte-z-dokumentu]

Prawa kolumna, druga karta. Parser AI (<ServiceRef path="src/lib/services/document-parser.ts" />)
próbuje rozpoznać w dokumencie jedną lub więcej transakcji:

* faktura zakupowa → typowo jedna transakcja główna z pozycjami,
* paragon / rachunek → jedna lub kilka transakcji,
* wyciąg bankowy → wiele transakcji (tu używa się zwykle osobnej ścieżki importu CSV — patrz <FeatureRef slug="konta-bankowe" />).

Każda wyciągnięta transakcja pokazuje:

* **Datę** operacji,
* **Kontrahenta** (jeśli rozpoznany),
* **Kwotę** (netto + VAT + brutto),
* **Status powiązania** — `Linked` (przekonwertowane na rekord <FeatureRef slug="transakcje">transakcji</FeatureRef> w dzienniku) lub `Pending` (wymaga ręcznego potwierdzenia).

### Status parsingu — co oznaczają stany [#status-parsingu--co-oznaczają-stany]

| Status            | Znaczenie                                                              | Co zrobić                                                                             |
| ----------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| **Oczekujący**    | Plik w kolejce do parsera                                              | Poczekaj — kolejka BullMQ przetwarza w tle                                            |
| **Przetwarzanie** | Parser aktualnie analizuje dokument                                    | Typowo 10–60 s                                                                        |
| **Przetworzony**  | Parsing zakończony, dane dostępne                                      | Zweryfikuj transakcje; jeśli parser pominął / źle rozpoznał coś, dodaj/popraw ręcznie |
| **Błąd**          | Parser nie poradził sobie (np. zdjęcie złej jakości, format nietypowy) | Dodaj transakcję ręcznie na podstawie obejrzanego oryginału                           |

Status jest aktualizowany **asynchronicznie** — ekran nie odświeża
się automatycznie, ale odświeżenie karty pokaże nowy stan.

## Dowody księgowe wg UoR art. 21 ust. 1 [#dowody-księgowe-wg-uor-art-21-ust-1]

Numify nie walidacje automatycznie, czy każdy wgrany dokument
spełnia kryteria dowodu księgowego z <LegalRef act="UoR" art="21" paragraph="1" /> — kryteria obejmują:

1. **Rodzaj i numer dowodu** — faktura zazwyczaj ma (Nr faktury).
2. **Strony operacji** — nazwy i adresy sprzedawcy i nabywcy.
3. **Opis i wartość** — treść operacji + kwota.
4. **Data operacji** — i (jeśli inna) data sporządzenia dowodu.
5. **Podpis wystawcy** — w praktyce zastępowany znakami elektronicznymi (<LegalRef act="UoR" art="21" paragraph="4" />) dla faktur elektronicznych.
6. **Dekretacja** — „stwierdzenie sprawdzenia i zakwalifikowania do ujęcia w księgach" — to robi się przy księgowaniu w <FeatureRef slug="journal">dzienniku</FeatureRef>, nie na samym dokumencie.

W praktyce: dokument wgrany do Numify + zaksięgowana transakcja w
dzienniku (z numerem pozycji dziennika i kontami Wn/Ma) stanowią
razem kompletny ślad audytowy.

## Archiwizacja — ile i jak długo [#archiwizacja--ile-i-jak-długo]

<LegalRef act="UoR" art="74" paragraph="2" /> pkt 8: dowody księgowe
przechowuje się przez **co najmniej 5 lat** licząc od początku roku
następującego po roku obrotowym, którego dotyczą. Dla faktury z 2026
r. oznacza to archiwizację do końca 2031 r. — przez cały ten okres
plik musi pozostać odtwarzalny.

Numify przechowuje pliki w **Cloudflare R2** z polityką niemutowalności:

* pliki nie są nadpisywane,
* usunięcie rekordu dokumentu nie usuwa natychmiast obiektu z R2 (soft delete, retencja zgodna z <LegalRef act="UoR" art="74" paragraph="2" />),
* kopie zapasowe bazy metadanych + obiektów R2 wykonywane zgodnie z polityką backupu (<ServiceRef path="src/lib/services/backup-retention.ts" />).

<LegalRef act="UoR" art="73" paragraph="2" /&#x3E; dopuszcza przeniesienie
treści dowodów na informatyczne nośniki danych — pod warunkiem, że
system pozwala na odtworzenie dokumentu w postaci wydruku. Przycisk
&#x2A;*„Open Original"** realizuje ten wymóg.

## Usuwanie dokumentu — uwaga [#usuwanie-dokumentu--uwaga]

Dokument można usunąć z UI (z poziomu listy <FeatureRef slug="dokumenty" />),
ale:

* **Transakcje powiązane** (z dziennika) **nie są usuwane** — zostają, tracąc odwołanie do dokumentu źródłowego. To naruszenie wymogu identyfikacji źródła (<LegalRef act="UoR" art="20" paragraph="5" />). Unikaj usuwania dokumentów, które zostały już zaksięgowane.
* Usunięcie wprowadza **soft delete** w bazie; plik R2 pozostaje przez okres retencji. Fizyczne usunięcie z R2 wymaga osobnego procesu administracyjnego.

Praktyczna reguła: jeśli dokument został zaksięgowany, **nie usuwaj
go** z systemu aż do upływu 5-letniego okresu archiwizacji.

## Powiązania [#powiązania]

* <FeatureRef slug="dokumenty">Dokumenty</FeatureRef> — lista wszystkich dokumentów spółki, skąd nawigujesz do tego widoku.
* <FeatureRef slug="transakcje">Transakcje</FeatureRef> — pozycje `Linked` w ekranie to rekordy transakcji z referencją do ID dokumentu.
* <FeatureRef slug="faktury">Faktury</FeatureRef> — faktury zakupu wystawione na podstawie dokumentów; numer faktury jest polem transakcji.
* <FeatureRef slug="journal">Dziennik</FeatureRef> — zaksięgowanie transakcji tworzy zapis w dzienniku; dokument pozostaje dowodem źródłowym dla tego zapisu.
* <FeatureRef slug="ksef">KSeF</FeatureRef> — faktury pobrane z KSeF trafiają automatycznie jako „dokumenty" z oryginałem XML FA(3).


---

# Rejestr VAT
URL: https://numifyai.com/docs/korzystanie-z-numify/vat-register
Description: Ewidencja sprzedaży i zakupu VAT wymagana przez art. 109 ust. 3 ustawy o VAT. Źródło danych dla pliku JPK_V7M/V7K oraz deklaracji VAT. Obsługa WNT, importu usług (art. 28b), MPP, GTU oraz oznaczeń proceduralnych.
Review status: internal
Updated: 2026-04-17



**Rejestr VAT** to dwuczęściowa ewidencja (sprzedaż + zakup) wymagana przez
<LegalRef act="VAT" art="109" paragraph="3" />. Zawiera dane potrzebne do
rozliczenia VAT za okres oraz do wysłania pliku **JPK\_V7M** (miesięczny) lub
**JPK\_V7K** (kwartalny). W Numify każdy zapis do rejestru powstaje
**automatycznie** z zweryfikowanej transakcji — ręczne edycje są wyjątkiem.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /vat-register — przełącznik roku/miesiąca, taby „Sprzedaż / Zakup", tabela pozycji z kolumnami Data / Nr dok / Kontrahent / NIP / Netto / VAT / Brutto / Stawka / Oznaczenia */}

## Dwa rejestry, jedna ewidencja [#dwa-rejestry-jedna-ewidencja]

UoV art. 109 ust. 3 mówi o **jednej** ewidencji zawierającej dane sprzedaży i
zakupu. W praktyce księgowej rozdziela się ją na dwa rejestry:

* **Rejestr sprzedaży VAT** (`registerType: "sprzedaz"`) — faktury wystawione
  przez spółkę, sprzedaż opodatkowana, WDT, eksport, sprzedaż zwolniona, a
  także **self-assessed VAT należny** od WNT i importu usług.
* **Rejestr zakupu VAT** (`registerType: "zakup"`) — faktury zakupowe z VAT
  naliczonym podlegającym odliczeniu, zakupy bez prawa do odliczenia, a także
  **VAT naliczony** od WNT i importu usług (lustrzany do rejestru sprzedaży).

Oba są generowane z tych samych `vatEntries` w bazie — filtrowanie następuje
po `registerType`.

## Automatyczne powstawanie zapisów [#automatyczne-powstawanie-zapisów]

<ServiceRef path="src/lib/services/vat-register.ts" /> tworzy zapis w rejestrze,
gdy transakcja przechodzi w stan zweryfikowany. Kluczowe pola:

| Pole                                      | Źródło                                                                                                                                                               |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `documentNumber`                          | `transaction.invoiceNumber` (lub fallback `TXN-<id>`).                                                                                                               |
| `documentDate`                            | Data wystawienia faktury.                                                                                                                                            |
| `accountingDate`                          | Data ujęcia w rejestrze VAT — dla zakupu data faktury (lub otrzymania, jeśli późniejsza), dla sprzedaży data faktury.                                                |
| `counterpartyName` / `counterpartyTaxId`  | Z transakcji.                                                                                                                                                        |
| `netAmount` / `vatAmount` / `grossAmount` | W groszach PLN. Dla faktur walutowych użyte są wartości `amountNetPln`, `amountVatPln`, `amountGrossPln` — przeliczone po kursie średnim NBP z dnia poprzedzającego. |
| `vatRate`                                 | Stawka VAT.                                                                                                                                                          |
| `gtuCodes`                                | Lista kodów GTU zebrana z pozycji faktury.                                                                                                                           |
| `procedureMarkers`                        | Oznaczenia proceduralne (np. `MPP`).                                                                                                                                 |
| `ksefFlag`                                | `NrKSeF` jeśli faktura ma numer KSeF, inaczej `DI` (dokument inny).                                                                                                  |
| `periodYear` / `periodMonth`              | Rok/miesiąc ujęcia VAT.                                                                                                                                              |

Idempotencja: jeśli `vatEntry` dla transakcji już istnieje, funkcja zwraca
`null` i nie tworzy duplikatu.

## Moment powstania obowiązku podatkowego (data ujęcia) [#moment-powstania-obowiązku-podatkowego-data-ujęcia]

Pole `accountingDate` określa, do **którego okresu** trafia zapis — nie data
wystawienia faktury. Numify stosuje reguły:

* **Sprzedaż** — co do zasady data dostawy towaru / wykonania usługi; w
  typowym przypadku równa dacie faktury.
* **Zakup (prawo do odliczenia)** — zgodnie z <LegalRef act="VAT" art="86" paragraph="10" />
  prawo do odliczenia powstaje w okresie powstania obowiązku podatkowego u
  sprzedawcy; <LegalRef act="VAT" art="86" paragraph="10b" /> dodaje, że nie
  wcześniej niż w okresie otrzymania faktury. Numify używa daty faktury jako
  domyślnej, a jeśli data otrzymania jest późniejsza — tej późniejszej.
* **Opóźnione odliczenie** — <LegalRef act="VAT" art="86" paragraph="11" />
  pozwala odliczyć w jednym z trzech kolejnych okresów. Obecnie realizowane
  przez ręczną zmianę `accountingDate` (zaplanowany dedykowany workflow).

## Reverse charge: WNT i import usług (art. 28b) [#reverse-charge-wnt-i-import-usług-art-28b]

Zakup **usług z UE** (art. 28b ustawy o VAT) lub **towarów z UE** (WNT,
art. 9) wymaga samo-naliczenia VAT: nabywca wystawia jednocześnie VAT należny
(tak jakby sam był sprzedawcą) i VAT naliczony (jako nabywca). Kwoty są
równe, więc w deklaracji się znoszą — ale oba muszą pojawić się osobno w
rejestrze i w JPK\_V7.

Numify wykrywa reverse charge automatycznie po kraju kontrahenta (UE, != PL)
i typie transakcji (usługa → `import28b`, towar → `wnt`). Tworzy **dwa** zapisy:

1. `sprzedaz` z `foreignPurchaseType: "import28b"` lub `"wnt"` — trafia do
   pól K\_29/K\_30 (import usług) lub K\_23/K\_24 (WNT) w JPK\_V7.
2. `zakup` z tym samym `foreignPurchaseType` — trafia do K\_42/K\_43 jako VAT
   naliczony do odliczenia.

Domyślna stawka samo-naliczenia to 23%; można nadpisać na transakcji, jeśli
usługa/towar ma stawkę niższą.

## GTU i oznaczenia proceduralne [#gtu-i-oznaczenia-proceduralne]

**Kody GTU** (01–13) oznaczają dostawy wybranych kategorii towarów/usług
wrażliwych z punktu widzenia JPK — zbierane z pozycji faktury
(`lineItems.gtuCode`) i zapisywane w `gtuCodes` jako lista rozdzielona
przecinkami (np. `GTU_07,GTU_08`).

**Procedury** (`procedureMarkers`):

* **`MPP`** — mechanizm podzielonej płatności. Numify ustawia automatycznie
  dla transakcji z `amountGross >= 15 000 PLN` (≥ 1 500 000 groszy) — próg
  ustawowy obowiązkowego MPP dla towarów/usług z załącznika 15 UoV.
  **Ograniczenie**: obecnie nie sprawdzamy kategorii towaru — flaga jest
  nakładana ze wzgledu na próg kwotowy. Dla faktur poniżej 15 000 PLN bez
  dobrowolnego MPP flaga nie powstaje.
* Inne oznaczenia (TP, WEW, FP, IED itp.) są zaplanowane jako rozszerzenie.

Oznaczenia KSeF: `ksefFlag` przyjmuje wartość `NrKSeF` (faktura ma numer
KSeF) lub `DI` (dokument inny — papierowy, PDF poza KSeF). Od kwietnia 2026 r.
dominujący stan to `NrKSeF`.

## MPP, biała lista i JPK [#mpp-biała-lista-i-jpk]

MPP w rejestrze to jedno — weryfikacja rachunku kontrahenta na **białej liście
podatników VAT** to osobna kontrola, robiona na etapie płatności.
Zob. <FeatureRef slug="/docs/integracje/biala-lista">biała lista</FeatureRef>
(strona w przygotowaniu).

Dane z rejestru VAT są źródłem dla <FeatureRef slug="exports">eksportu JPK\_V7M/V7K</FeatureRef>
(generator <ServiceRef path="src/lib/services/jpk-vat-generator.ts" />).
Sam proces wysyłki pliku do Ministerstwa Finansów — zob.
<FeatureRef slug="/docs/poradniki">poradnik „Jak wysłać JPK\_V7"</FeatureRef>
(w przygotowaniu).

## Ekran `/vat-register` [#ekran-vat-register]

Górny pasek:

* **Rok / Miesiąc** — domyślnie bieżący okres. Dla spółki rozliczającej się
  kwartalnie widok sumuje trzy miesiące kwartału (JPK\_V7K).
* **Taby**: „Sprzedaż" / „Zakup" — dwa widoki rejestru z jedną bazą danych.
* **Eksport** — przycisk generujący JPK\_V7 dla wybranego okresu.

Tabela pozycji:

| Kolumna              | Opis                                                                    |
| -------------------- | ----------------------------------------------------------------------- |
| Data ujęcia          | `accountingDate` — decyduje o okresie.                                  |
| Nr dokumentu         | `documentNumber` (numer faktury lub `TXN-…` dla dokumentów bez numeru). |
| Kontrahent + NIP     | Z transakcji.                                                           |
| Netto / VAT / Brutto | Kwoty w PLN, po przeliczeniu walut.                                     |
| Stawka               | 23% / 8% / 5% / 0% / zw. / NP.                                          |
| GTU                  | Lista kodów GTU, jeśli jakiekolwiek.                                    |
| Procedury            | `MPP`, `KSeF`, reverse charge badge, itd.                               |
| Status               | Badge: `Aktywny` / `Skorygowany` (jeśli była faktura korygująca).       |

{/* SCREENSHOT: tab „Zakup" z pozycją WNT od kontrahenta niemieckiego — netto 4 200,00 zł, VAT self-assessed 966,00 zł, badge „WNT" i „Reverse charge" */}

## Podsumowanie rozliczenia [#podsumowanie-rozliczenia]

Pod tabelą Numify pokazuje **podsumowanie** zgodne ze strukturą JPK\_V7:

* Suma netto, VAT i brutto — per stawka (23/8/5/0/zw).
* VAT należny (z rejestru sprzedaży) − VAT naliczony (z rejestru zakupu) =
  **kwota do zapłaty lub nadwyżka do przeniesienia**.
* Osobne pola dla WNT, importu usług, WDT, eksportu — odpowiadające pozycjom
  K\_\* w JPK.

Podsumowanie to podgląd — nie zastępuje deklaracji. Oficjalny dokument
powstaje w momencie wygenerowania JPK\_V7.

## Korekty (faktury korygujące) [#korekty-faktury-korygujące]

Faktura korygująca od dostawcy powoduje dwa działania w rejestrze:

1. Powstaje **nowy** `vatEntry` powiązany z korygującą transakcją, z
   kwotami korekty (dodatnimi lub ujemnymi).
2. Oryginalny zapis pozostaje — zapis korekty to zmiana narastająca, nie
   zastąpienie.

Zasada zgodna z <LegalRef act="UoR" art="25" paragraph="1" />: nie usuwa się
zapisów; wprowadza się zapisy korygujące. W deklaracji VAT korekta trafia do
okresu, w którym podatnik otrzymał korektę — zgodnie z
<LegalRef act="VAT" art="86" paragraph="10b" /> dla korekt in-minus po stronie
odliczenia.

**Ograniczenie**: obecny workflow wymaga ręcznego powiązania korekty z
oryginałem. Automatyczne dopasowanie korekt jest zgłoszone jako
usprawnienie — zob. [Issue #5](https://github.com/kacperkwapisz/numify/issues/5).

## Wyłączenia z prawa do odliczenia (art. 88) [#wyłączenia-z-prawa-do-odliczenia-art-88]

<LegalRef act="VAT" art="88" paragraph="1" /> wyłącza prawo do odliczenia m.in.
od usług noclegowych i gastronomicznych. W Numify takie faktury trafiają do
rejestru zakupu, ale z `vatRate` oznaczonym jako koszt bez odliczenia —
kwota VAT nie obniża należnego podatku.

<LegalRef act="VAT" art="88" paragraph="3a" /> wyłącza odliczenie od faktur od
podmiotu nieistniejącego, dokumentujących czynności niedokonane itp. — to
należy wychwycić na etapie weryfikacji dokumentu, przed utworzeniem zapisu
VAT.

## Relacja do księgi głównej [#relacja-do-księgi-głównej]

Każdy `vatEntry` ma **odpowiadający mu zapis w dzienniku** (`journal_entries`),
utworzony przez <ServiceRef path="src/lib/services/auto-journal.ts" tests="15" />.
Kwoty VAT w rejestrze muszą się uzgadniać z saldami kont VAT w księdze głównej:

* <AccountRef code="220" /> — VAT należny (strona Ma rośnie przy sprzedaży).
* <AccountRef code="221" /> — VAT naliczony (strona Wn rośnie przy zakupie).

Rozliczenie VAT na koniec okresu to przeksięgowanie obrotu z 220 i 221 na
rozrachunek z US (<AccountRef code="222" /> — jeśli istnieje w planie kont).

## Ograniczenia [#ograniczenia]

* **Brak OSS (one-stop shop)** — sprzedaż konsumencka do UE w procedurze OSS
  wymaga osobnego rejestru i JPK-V7-OSS; obecnie nie jest obsługiwana.
  Planowane jako rozszerzenie dla spółek prowadzących B2C w UE.
* **Brak metody kasowej** — obecnie zakładamy metodę memoriałową. Mali
  podatnicy stosujący kasową mają inny moment powstania obowiązku podatkowego
  (art. 21 UoV) — nie jest to dziś obsługiwane.
* **Brak współczynnika struktury sprzedaży** (art. 90–91 UoV) — dla spółek z
  mieszaną sprzedażą (opodatkowana + zwolniona) współczynnik VAT proporcji
  wymaga ręcznego wyliczenia i korekt rocznych.

## Dowód i sankcje [#dowód-i-sankcje]

<LegalRef act="VAT" art="109" paragraph="3b" /> nakłada obowiązek przesyłania
ewidencji razem z deklaracją (JPK\_V7M) w terminie do 25. dnia miesiąca
następującego. Naruszenia (błędy w ewidencji, brak korekty na wezwanie)
skutkują karą 500 zł za błąd — zgodnie z art. 109 ust. 3h UoV.

Numify minimalizuje ryzyko, automatyzując ujęcie (nie ma „zapomnianych"
faktur, o ile transakcja została zweryfikowana) oraz generując JPK\_V7
bezpośrednio z rejestru. Weryfikacja zgodności z deklaracją pozostaje po
stronie użytkownika — Numify nie wysyła pliku automatycznie.


---

# Bilans otwarcia
URL: https://numifyai.com/docs/korzystanie-z-numify/opening-balance
Description: Wprowadzenie sald początkowych na rozpoczęcie roku obrotowego lub migrację z innego systemu — z automatyczną kontrolą Aktywa = Pasywa + Kapitał, przypisaniem strony Wn/Ma według typu konta i idempotencją (jeden BO na rok).
Review status: numify-source
Updated: 2026-04-17



**Bilans otwarcia (BO)** to zapis księgowy wprowadzający salda
początkowe kont — na dzień rozpoczęcia działalności lub pierwszy dzień
nowego roku obrotowego. W Numify jest to **jeden zapis w dzienniku** z
`source = 'opening_balance'`, podlegający tym samym regułom co zwykły
zapis (podwójny zapis, zakaz usuwania).

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /opening-balance — selektor roku i daty, tabela pozycji (konto, kwota Wn/Ma), live sumy Aktywa / Pasywa+Kapitał i badge balansu */}

## Kiedy używać [#kiedy-używać]

Trzy typowe scenariusze:

1. **Start nowej spółki w Numify** — spółka istniała wcześniej, ma już aktywa (kapitał zakładowy na rachunku, wyposażenie). BO na dzień pierwszego zapisu.
2. **Migracja z innego systemu** — spółka była księgowana w wFirma / księgowej zewnętrznej. BO to salda kont przeniesione na konkretny dzień (<LegalRef act="UoR" art="12" paragraph="1" />).
3. **Początek nowego roku obrotowego** — BO na 1 stycznia to **salda końcowe poprzedniego roku** (<LegalRef act="UoR" art="5" paragraph="1" /> — ciągłość). W Numify generuje się je poprzez <FeatureRef slug="fiscal-periods">zamknięcie roku</FeatureRef>, nie ręcznie.

Ta strona dotyczy scenariuszy 1 i 2.

## Zasada — Aktywa = Pasywa + Kapitał [#zasada--aktywa--pasywa--kapitał]

Każdy BO musi spełniać równanie bilansowe:

```
Aktywa = Pasywa + Kapitał
```

Numify sprawdza to na dwóch poziomach:

1. **Równanie bilansowe** — `validateOpeningBalance` w warstwie aplikacji: suma sald kont typu `asset` = suma kont `liability` + suma kont `equity`.
2. **Podwójny zapis w dzienniku** — `validateJournalBalance`: suma Wn = suma Ma w utworzonym zapisie (<LegalRef act="UoR" art="15" paragraph="1" />).

Przy niebilansowym wprowadzeniu zapis **nie zostanie utworzony** —
ekran pokaże czerwony badge „niezbilansowany" i przycisk zapisu
pozostanie zablokowany.

## Przypisanie strony Wn / Ma [#przypisanie-strony-wn--ma]

Użytkownik wprowadza **saldo** każdego konta (liczba dodatnia =
normalne saldo dla typu konta). Numify automatycznie kieruje je na
właściwą stronę zapisu:

| Typ konta            | Strona          | Przykład                                                                   |
| -------------------- | --------------- | -------------------------------------------------------------------------- |
| `asset` (aktywa)     | **Wn (debit)**  | <AccountRef code="130" /> rachunek bieżący 10 000 zł → Wn 10 000           |
| `liability` (pasywa) | **Ma (credit)** | <AccountRef code="202" /> zobowiązania wobec dostawców 3 000 zł → Ma 3 000 |
| `equity` (kapitał)   | **Ma (credit)** | <AccountRef code="800" /> kapitał podstawowy 5 000 zł → Ma 5 000           |
| `off_balance`        | **pomijane**    | Konta pozabilansowe nie wchodzą do A = P + K                               |

Konta typu `revenue` / `expense` w BO pojawiają się wyjątkowo — tylko
przy migracji w trakcie roku, gdy przenosi się narastające saldo kont
wynikowych. Normalnie rok zaczyna się z zerowymi saldami kont zespołu
4 i 7.

## Idempotencja — jeden BO na rok [#idempotencja--jeden-bo-na-rok]

Przed utworzeniem BO Numify sprawdza `hasOpeningBalance(companyId, fiscalYear)`:

* Jeśli istnieje już zapis z `source = 'opening_balance'` i `fiscalYear = YYYY`, próba utworzenia drugiego BO rzuci wyjątek `Opening balance already exists for fiscal year YYYY`.
* Korekta istniejącego BO **nie odbywa się przez ponowne wprowadzenie** — wymaga storna (zapis odwrotny) i ewentualnie kolejnego zapisu z prawidłowymi kwotami (zakaz usuwania, <LegalRef act="UoR" art="25" paragraph="1" />).

Ekran `/opening-balance` pokazuje istniejący BO (jeśli jest) w trybie
tylko do odczytu — wraz z datą, liczbą pozycji i sumami.

## Integracja z okresami fiskalnymi [#integracja-z-okresami-fiskalnymi]

Przed utworzeniem BO serwis wywołuje:

* `ensurePeriodOpen(companyId, year, month)` — sprawdza, że okres nie jest `closed` / `locked`,
* `getOrCreatePeriod(companyId, year, month)` — tworzy okres pierwszego miesiąca, jeśli go brak.

Oznacza to, że **BO wymaga otwartego okresu** w miesiącu zapisu. Patrz
<FeatureRef slug="fiscal-periods" />.

## Workflow — migracja z innego systemu [#workflow--migracja-z-innego-systemu]

Rekomendowany proces:

1. **Wybierz dzień graniczny** — np. 1 stycznia nowego roku obrotowego albo dzień rozpoczęcia pracy w Numify.
2. **Pobierz z poprzedniego systemu** zestawienie obrotów i sald na ten dzień (zestawienie musi być zbilansowane — wykonaj w starym systemie własną walidację).
3. **Rozwiń analitykę** — dla <AccountRef code="201" /> / <AccountRef code="202" /> wprowadzaj salda **per kontrahent** (subkonto), nie tylko saldo syntetyczne. Inaczej księga główna się zgadza, ale nie będzie zgodna z rejestrem kontrahentów.
4. **Sprawdź <AccountRef code="220" /> (rozrachunki publicznoprawne)** — saldo z urzędu skarbowego (VAT do zapłaty / zwrot, CIT, PIT-4R) i z ZUS.
5. **Wprowadź BO w Numify** — pozycja po pozycji. Live sumy Aktywa / Pasywa+Kapitał pozwalają od razu zauważyć niezbilansowanie.
6. **Zapisz** — Numify utworzy jeden zapis „Bilans otwarcia YYYY" w dzienniku.
7. **Zweryfikuj** — otwórz <FeatureRef slug="trial-balance" /> i porównaj z zestawieniem ze starego systemu.

## Typowe pułapki [#typowe-pułapki]

* **Salda walutowe** — pamiętaj o przeliczeniu na PLN po kursie średnim NBP z dnia BO. Numify w BO przyjmuje kwoty w groszach PLN; analityka walutowa (kwota + waluta) wymaga osobnego wpisu w księdze pomocniczej rachunku bankowego.
* **Środki trwałe bez umorzenia** — jeśli wprowadzasz <AccountRef code="010" /> ze stanem 50 000 zł, a umorzenie dotąd wyniosło 20 000 zł, potrzebujesz **dwóch pozycji**: <AccountRef code="010" /> po stronie Wn (wartość początkowa brutto) i <AccountRef code="070" /> po stronie Ma (umorzenie). Patrz <FeatureRef slug="fixed-assets" />.
* **Kapitał własny jako różnica** — nie traktuj kapitału jako „resztki" do zbilansowania. Wprowadź rzeczywiste salda <AccountRef code="800" /> (kapitał podstawowy) i <AccountRef code="820" /> (wynik z lat ubiegłych), a następnie zweryfikuj, że BO rzeczywiście się zgadza. Rozjazd to sygnał błędu w danych źródłowych, nie do wyrównania ręcznie.
* **Brak aktywnych kont** — jeśli konto jest nieaktywne (<FeatureRef slug="chart-of-accounts" />), nie pojawi się w podpowiedziach. Aktywuj je przed wprowadzeniem BO.

## Co po zapisie [#co-po-zapisie]

* BO jest zwykłym zapisem w <FeatureRef slug="journal">dzienniku</FeatureRef> z `source = 'opening_balance'` — ma numer, datę, pozycje.
* Salda trafiają do <FeatureRef slug="general-ledger">księgi głównej</FeatureRef> i <FeatureRef slug="trial-balance">zestawienia obrotów i sald</FeatureRef>.
* Wpływa na <FeatureRef slug="balance-sheet">bilans</FeatureRef> jako stan początkowy; nie wpływa na <FeatureRef slug="profit-loss">RZiS</FeatureRef> (chyba że — wyjątkowo — BO zawierał konta wynikowe z migracji w trakcie roku).
* Z BO można generować pozycje <FeatureRef slug="fixed-assets">środków trwałych</FeatureRef> i rozrachunków — każda pozycja analityczna powinna mieć odpowiednik w rejestrze operacyjnym (nie wystarczy saldo syntetyczne).

## Powiązania [#powiązania]

* <FeatureRef slug="chart-of-accounts">Plan kont</FeatureRef> — BO używa wyłącznie aktywnych kont spółki.
* <FeatureRef slug="fiscal-periods">Okresy fiskalne</FeatureRef> — BO wymaga otwartego okresu na dzień zapisu.
* <FeatureRef slug="journal">Dziennik</FeatureRef> — BO to zapis z `source = 'opening_balance'`.
* <FeatureRef slug="fixed-assets">Środki trwałe</FeatureRef> — po BO uzupełnij ewidencję ŚT (ten sam saldo na <AccountRef code="010" /> musi mieć odpowiedniki w rejestrze).


---

# Plan kont
URL: https://numifyai.com/docs/korzystanie-z-numify/chart-of-accounts
Description: Zakładowy plan kont spółki — struktura zespołów 0–8, rozróżnienie kont syntetycznych i analitycznych, domyślny plan seedowany dla nowej spółki oraz aktywacja, dezaktywacja i dodawanie kont.
Review status: internal
Updated: 2026-04-17



**Plan kont** (zakładowy plan kont) to lista wszystkich kont księgowych
spółki — fundament, na którym Numify opiera dziennik, księgę główną,
bilans i rachunek zysków i strat. Jest to obowiązkowy element polityki
rachunkowości zgodnie z <LegalRef act="UoR" art="10" paragraph="1" />.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /chart-of-accounts — drzewo kont pogrupowane w zespoły 0–8 z badge'ami typu i statusu */}

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

Każdy zapis w <FeatureRef slug="journal">dzienniku</FeatureRef> trafia na
dwa konta — jedno po stronie Wn, drugie po stronie Ma (zasada
podwójnego zapisu, <LegalRef act="UoR" art="15" paragraph="1" />).
Plan kont definiuje zbiór dopuszczalnych kont i ich typy, dzięki czemu
Numify może:

* generować <FeatureRef slug="trial-balance">zestawienie obrotów i sald</FeatureRef> pogrupowane po zespołach,
* składać <FeatureRef slug="balance-sheet">bilans</FeatureRef> i <FeatureRef slug="profit-loss">RZiS</FeatureRef> na podstawie tagów `balanceSheetTag` / `pnlTag` przypisanych do każdego konta,
* wypełniać pola `JPK_KR_PD` na podstawie `jpkPdMarker`.

## Struktura — zespoły 0–8 [#struktura--zespoły-08]

Domyślny plan Numify jest zgodny z powszechnie stosowanym podziałem na
dziewięć zespołów. Każde konto ma trzycyfrowy kod syntetyczny; kod
zaczyna się cyfrą zespołu.

| Zespół | Nazwa                        | Typ dominujący        | Przykłady (z domyślnego planu)                                                                                                                                |
| ------ | ---------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **0**  | Aktywa trwałe                | `asset`               | <AccountRef code="010" /> środki trwałe, <AccountRef code="070" /> umorzenie ŚT                                                                               |
| **1**  | Środki pieniężne             | `asset`               | <AccountRef code="130" /> rachunek bieżący PLN, <AccountRef code="135" /> rachunek walutowy                                                                   |
| **2**  | Rozrachunki                  | `asset` / `liability` | <AccountRef code="201" /> rozrachunki z odbiorcami, <AccountRef code="202" /> rozrachunki z dostawcami, <AccountRef code="220" /> rozrachunki publicznoprawne |
| **3**  | Materiały i towary           | `asset`               | <AccountRef code="300" /> materiały i towary                                                                                                                  |
| **4**  | Koszty wg rodzajów           | `expense`             | <AccountRef code="400" /> usługi obce, amortyzacja, wynagrodzenia                                                                                             |
| **5**  | Koszty wg miejsc powstawania | `expense`             | <AccountRef code="500" /> koszty działalności podstawowej (fakultatywne)                                                                                      |
| **6**  | Produkty / rozliczenia       | `asset`               | rozliczenia międzyokresowe, produkcja w toku                                                                                                                  |
| **7**  | Przychody i koszty finansowe | `revenue` / `expense` | <AccountRef code="700" /> przychody ze sprzedaży, <AccountRef code="750" /> przychody finansowe, <AccountRef code="751" /> koszty finansowe                   |
| **8**  | Kapitały i wynik finansowy   | `equity`              | <AccountRef code="800" /> kapitał podstawowy, <AccountRef code="820" /> wynik finansowy, <AccountRef code="860" /> wynik bieżącego roku                       |

Dziewięć zespołów to **konwencja rynkowa**, nie sztywna litera ustawy —
UoR wymaga jedynie, aby plan kont był opisany w polityce rachunkowości
i stosowany w sposób ciągły (<LegalRef act="UoR" art="10" paragraph="1" />,
<LegalRef act="UoR" art="5" paragraph="1" />). Minister Finansów
może wydać wzorcowe plany kont w drodze rozporządzenia
(<LegalRef act="UoR" art="83" paragraph="1" />) — dla zwykłej
spółki z o.o. takie rozporządzenie nie obowiązuje.

## Konta syntetyczne i analityczne [#konta-syntetyczne-i-analityczne]

* **Syntetyczne** (księga główna) — kody trzycyfrowe, np. `201`. Na nich działa zasada podwójnego zapisu i z nich powstaje zestawienie obrotów i sald.
* **Analityczne** (księgi pomocnicze) — rozszerzenia kodem z kreską, np. `201-ACME` dla konkretnego odbiorcy. Muszą uzgadniać się z saldem konta syntetycznego (<LegalRef act="UoR" art="16" paragraph="1" />).

W Numify konta analityczne tworzy się przy księgowaniu faktur
(<FeatureRef slug="kontrahenci">kontrahent</FeatureRef> → analityka na
<AccountRef code="201" /> / <AccountRef code="202" />) oraz przy
rozrachunkach publicznoprawnych (VAT należny/naliczony na subkontach
<AccountRef code="220" />).

## Domyślny plan dla nowej spółki [#domyślny-plan-dla-nowej-spółki]

Przy zakładaniu spółki Numify seeduje **jeden wzorcowy plan kont**
(`src/db/seed-accounts.ts`) — ok. 68 kont syntetycznych pokrywających
typowe operacje spółki z o.o. Każde konto ma:

* `code` — kod konta (np. `201`),
* `type` — typ księgowy (`asset`, `liability`, `equity`, `revenue`, `expense`, `off_balance`),
* `balanceSheetTag` — pozycja w bilansie (A.I.1, B.II.2 itd.),
* `pnlTag` — pozycja w RZiS,
* `jpkPdMarker` — znacznik JPK\_KR\_PD (jeśli dotyczy).

<ServiceRef path="src/lib/services/seed-company-accounts.ts" /> kopiuje
plan wzorcowy do tabeli `chartAccounts` przypisanej do ID spółki. Od
tego momentu jest to **plan spółki** — edycje nie propagują się
wstecz do wzorca.

## Widok `/chart-of-accounts` [#widok-chart-of-accounts]

{/* SCREENSHOT: drzewo kont — zespoły rozwinięte, kolumny Kod / Nazwa / Typ / Status / Saldo */}

* **Drzewo** — konta są pogrupowane po zespołach z możliwością rozwinięcia / zwinięcia.
* **Wyszukiwarka** — filtruje po kodzie, nazwie i nazwie angielskiej.
* **Typ (badge)** — kolor zależny od typu (aktywa zielone, pasywa czerwone itd.).
* **Status** — `aktywne` / `nieaktywne` (patrz niżej).

## Aktywacja i dezaktywacja [#aktywacja-i-dezaktywacja]

Domyślnie wszystkie konta z planu wzorcowego są **aktywne**. Konto
można **dezaktywować**, jeśli spółka nie wykorzystuje go w praktyce —
wtedy znika z podpowiedzi przy księgowaniu, ale pozostaje w bazie
(wraz z historią zapisów — zakaz usuwania z <LegalRef act="UoR" art="25" paragraph="1" />).

Dezaktywacja jest **miękka** — można ją cofnąć. Dezaktywowane konto z
saldem różnym od zera wciąż pojawi się w bilansie i zestawieniu obrotów
i sald — ukrywana jest tylko podpowiedź w UI.

## Dodawanie nowych kont [#dodawanie-nowych-kont]

Przycisk „+ Nowe konto" otwiera modal, w którym podaje się kod, nazwę,
typ i (opcjonalnie) konto nadrzędne. Najczęstsze przypadki:

1. **Nowe subkonto walutowe** — np. `135-EUR`, `135-USD` z typem `asset`.
2. **Nowe konto kosztowe** — gdy spółka wchodzi w nową kategorię wydatków nieobecną w planie wzorcowym.
3. **Subkonta VAT** — analityka na <AccountRef code="220" /> rozdzielająca VAT należny, naliczony i rozliczenie z urzędem.

Kod konta musi być **unikalny w obrębie spółki**. Pierwsza cyfra
wyznacza zespół — ze względu na spójność raportów nie należy dodawać
kont spoza zakresu 0–8.

## Zmiana planu kont a ciągłość [#zmiana-planu-kont-a-ciągłość]

Plan kont jest elementem polityki rachunkowości. Jego zmiana w trakcie
roku obrotowego (np. zmiana typu istniejącego konta, usunięcie konta)
narusza zasadę ciągłości (<LegalRef act="UoR" art="5" paragraph="1" />)
i wymaga uzasadnienia oraz zapisu w polityce. Rekomendowany workflow:

1. **W trakcie roku** — dodawanie nowych kont (nie zmienia historii) jest bezpieczne.
2. **Na początek nowego roku obrotowego** — dezaktywacja nieużywanych kont i uporządkowanie analityki.
3. **Zmiana typu istniejącego konta z saldem** — unikać; w razie konieczności przenieść saldo zapisem korygującym i dezaktywować stare konto.

Numify nie pozwala usuwać kont fizycznie — pozostają w bazie dla
audytu (zakaz usuwania, <LegalRef act="UoR" art="25" paragraph="1" />).

## Powiązania z innymi funkcjami [#powiązania-z-innymi-funkcjami]

* <FeatureRef slug="opening-balance">Bilans otwarcia</FeatureRef> — używa kont aktywnych do wprowadzenia sald początkowych.
* <FeatureRef slug="konta-bankowe">Konta bankowe</FeatureRef> — każdy rachunek mapuje się na konto GL, typowo <AccountRef code="130" /> / <AccountRef code="135" />.
* <FeatureRef slug="accounting-policy">Polityka rachunkowości</FeatureRef> — generowany dokument zawiera zakładowy plan kont.
* <FeatureRef slug="balance-sheet">Bilans</FeatureRef> i <FeatureRef slug="profit-loss">RZiS</FeatureRef> — agregują salda po tagach `balanceSheetTag` / `pnlTag`.

## Co dalej [#co-dalej]

Pełna referencja kont (kod → opis → typowe księgowania) jest
zaplanowana jako osobna strona w sekcji **Zgodność z prawem** i nie jest
jeszcze dostępna.


---

# Dziennik
URL: https://numifyai.com/docs/korzystanie-z-numify/journal
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.
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.


---

# Faktury sprzedaży
URL: https://numifyai.com/docs/korzystanie-z-numify/faktury
Description: Wystawianie własnych faktur sprzedaży — faktura podstawowa, korygująca, zaliczkowa. Generowanie XML FA(3), wysyłka do KSeF, podgląd i pobieranie pliku. Zgodność z wymaganiami art. 106e ustawy o VAT.
Review status: internal
Updated: 2026-04-16



> **Nie mylić z [Dokumenty](/docs/korzystanie-z-numify/dokumenty).** Ta
> strona opisuje **wystawianie własnych faktur sprzedażowych** i wysyłkę
> do KSeF. Faktury otrzymane od dostawców trafiają do
> [Dokumentów](/docs/korzystanie-z-numify/dokumenty).

**Faktury** to moduł wystawiania faktur sprzedaży: tworzenie w formularzu,
generowanie pliku &#x2A;*FA(3)** (XML), wysyłka do KSeF i śledzenie statusu.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /invoices — lista faktur z kolumnami Numer / Nabywca / Netto / Brutto / KSeF status */}

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

Każda sp. z o.o. jako czynny podatnik VAT ma obowiązek wystawiać faktury
zgodne z <LegalRef act="VAT" art="106e" paragraph="1" /> — 27 wymaganych punktów
(data, numer, strony, pozycje, stawki, sumy, oznaczenia typu MPP). Od &#x2A;*1
kwietnia 2026 r.** (dla większości sp. z o.o.) faktura musi być dodatkowo
wystawiona w **Krajowym Systemie e-Faktur** w strukturze FA(3). Szczegóły
harmonogramu — <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/harmonogram">KSeF — harmonogram</FeatureRef>.

## Typy faktur [#typy-faktur]

Numify obsługuje trzy typy:

| Typ                           | Kiedy używać                                                                        |
| ----------------------------- | ----------------------------------------------------------------------------------- |
| **Podstawowa** (`podstawowa`) | Domyślna faktura dokumentująca sprzedaż.                                            |
| **Korygująca** (`korygujaca`) | Korekta wcześniej wystawionej faktury — zmiany cen, ilości, stawki VAT, odwrócenia. |
| **Zaliczkowa** (`zaliczkowa`) | Faktura zaliczkowa na poczet przyszłej dostawy.                                     |

Każdy typ trafia do właściwego segmentu schematu FA(3) — generator
(`ksef-fa3-generator.ts`) sam dobiera sekcję XML.

## Formularz tworzenia faktury [#formularz-tworzenia-faktury]

Pola wejściowe formularza:

**Nagłówek faktury**

* Typ (podstawowa / korygująca / zaliczkowa)
* Data wystawienia, data sprzedaży, termin płatności
* Forma płatności (przelew / gotówka / karta / kompensata)

**Nabywca**

* Nazwa (wymagane) + NIP + adres + kraj

**Pozycje**

* Opis, ilość, jednostka miary, cena jednostkowa netto, stawka VAT (23 / 8 / 5 / 0 / zw)
* Opcjonalnie: GTU (kod grupy towarowej dla JPK), PKWiU

**Podsumowanie** (liczone automatycznie)

* Suma netto / VAT / brutto — w PLN, na podstawie pozycji

**Uwagi** — tekst wolny (wypełniany na fakturze).

<ServiceRef path="src/lib/services/ksef-service.ts">
  ksef-service.ts
</ServiceRef>

### Walidacja [#walidacja]

Numify sprawdza **przed** zapisem:

* Co najmniej jedna pozycja z niepustym opisem.
* Nazwa nabywcy niepusta.
* Spójność sum (netto + VAT = brutto, dla każdej stawki osobno).

Dodatkowe wymogi (NIP nabywcy, `saleDate`) są wymagane dopiero na etapie
walidacji FA(3) przed wysyłką do KSeF.

## Generowanie XML FA(3) [#generowanie-xml-fa3]

Po utworzeniu faktury **od razu** generowany jest plik XML zgodny ze
schematem FA(3) — trzecią oficjalną wersją struktury faktury
ustrukturyzowanej (szczegóły sekcji: <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/format-fa3">format FA(3)</FeatureRef>).

<ServiceRef path="src/lib/services/ksef-fa3-generator.ts">
  ksef-fa3-generator.ts
</ServiceRef>

XML można:

* **Obejrzeć** (przycisk „Podgląd XML" — otwiera dialog z kodem).
* **Pobrać** — np. do awaryjnego przesłania biuru rachunkowemu.
* **Wysłać do KSeF** — pod warunkiem skonfigurowanych poświadczeń.

<ServiceRef path="src/lib/services/ksef-fa3-parser.ts">
  ksef-fa3-parser.ts
</ServiceRef>

## Wysyłka do KSeF [#wysyłka-do-ksef]

Statusy faktury widoczne w kolumnie KSeF:

| Status     | Znaczenie                                                                        |
| ---------- | -------------------------------------------------------------------------------- |
| `not_sent` | Nie wysłano — dostępny przycisk **Wyślij**.                                      |
| `pending`  | Wysłano, oczekuje na numer KSeF od serwera MF.                                   |
| `accepted` | Przyjęta; Numify zapisał nadany numer KSeF.                                      |
| `rejected` | Odrzucona — w UI widoczny komunikat błędu. Dostępna ponowna wysyłka po poprawie. |

<ServiceRef path="src/lib/services/ksef-api.ts">
  ksef-api.ts
</ServiceRef>

Szczegółowa procedura (sesja, bramka testowa vs produkcyjna, obsługa
zbiorczych sesji) → <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/wystawianie">KSeF — wystawianie</FeatureRef>
i <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/uwierzytelnianie">uwierzytelnianie</FeatureRef>.

### Tryb Offline24 / awaria KSeF [#tryb-offline24--awaria-ksef]

Jeśli KSeF jest niedostępny w trybie awaryjnym, faktura może być
wystawiona „offline" i przesłana po przywróceniu dostępności. Detale →
<FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/tryb-offline24">tryb Offline24</FeatureRef>.

## Faktura VAT-RR, odwrotne obciążenie, MPP [#faktura-vat-rr-odwrotne-obciążenie-mpp]

* **MPP** — przy kwocie brutto ≥ 15 000 zł i pozycji z załącznika 15, Numify dodaje obowiązkowe oznaczenie „mechanizm podzielonej płatności" na fakturze (<LegalRef act="VAT" art="106e" paragraph="1 pkt 18a" />).
* **Odwrotne obciążenie** — dla transakcji, gdzie nabywca rozlicza VAT, faktura zawiera oznaczenie „odwrotne obciążenie" (<LegalRef act="VAT" art="106e" paragraph="1" /> pkt 18). Szczegóły → <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/odwrotne-obciazenie">odwrotne obciążenie</FeatureRef>.
* **Stawka 0 % / zwolniona** — na fakturze musi pojawić się podstawa prawna zwolnienia (<LegalRef act="VAT" art="106e" paragraph="1" /> pkt 19).

## Generowanie PDF [#generowanie-pdf]

Niezależnie od KSeF można wygenerować PDF dla danej faktury — np. jako
podgląd wizualny dla nabywcy (KSeF zwraca XML; „wygląd" faktury
generowany jest po stronie każdego systemu).

<ServiceRef path="src/lib/services/invoice-pdf.ts">
  invoice-pdf.ts
</ServiceRef>

## Ograniczenia [#ograniczenia]

1. **GTU i PKWiU** — pola są dostępne, ale Numify nie przypisuje ich automatycznie — konieczne ręczne wskazanie kodu. Liczba kombinacji w praktyce sp. z o.o. jest niewielka, więc nie jest to wąskie gardło.
2. **Korekty** wymagają podania odniesienia do oryginalnej faktury — interfejs obecnie zakłada ręczne wprowadzenie numeru. Domniemana automatyzacja (wybierz fakturę → stwórz korektę) jest na roadmapie.
3. **Brak automatycznej integracji z <FeatureRef slug="transakcje">transakcjami</FeatureRef>** — fakturę sprzedaży trzeba osobno zaksięgować jako transakcję przychodową (rekomendowany workflow ręczny do pełnej automatyzacji w Phase 4b).
4. **Faktury w walucie obcej** — formularz obsługuje wiele walut, ale kurs do przeliczenia VAT musi być wybrany zgodnie z <LegalRef act="VAT" art="106e" paragraph="11" /> (kurs NBP z dnia poprzedzającego obowiązek podatkowy).
5. **Od 1 kwietnia 2026** faktura poza KSeF (jako PDF / papier) nie dokumentuje sprzedaży dla podatnika VAT podlegającego KSeF — wyjątki tylko B2C i offline24.

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Otwórz „Nowa faktura"** — wybierz typ i uzupełnij daty.
2. **Dodaj nabywcę** — najlepiej przez <FeatureRef slug="kontrahenci">kontrahentów</FeatureRef> (uzupełni się z Białej Listy po NIP).
3. **Dodaj pozycje** — opis, ilość, cena netto, stawka VAT. Numify liczy sumy.
4. **Zatwierdź fakturę** → wygenerowany XML pojawi się w widoku.
5. **Obejrzyj XML** (opcjonalnie) → **Wyślij do KSeF**.
6. **Po sukcesie KSeF** — numer KSeF zostaje przypisany; fakturę można wtedy rozesłać nabywcy (PDF lub link do KSeF).
7. **Zaksięguj** sprzedaż jako transakcję przychodową w <FeatureRef slug="transakcje">transakcjach</FeatureRef> (do automatyzacji w kolejnej iteracji).

{/* SCREENSHOT: dialog "Nowa faktura sprzedaży" z sekcjami nagłówek / nabywca / pozycje / sumy */}

## Powiązane [#powiązane]

* <FeatureRef slug="dokumenty">dokumenty</FeatureRef> — faktury przychodzące (od dostawców), nie mylić z tym modułem.
* <FeatureRef slug="kontrahenci">kontrahenci</FeatureRef> — nabywcy wystawianych faktur.
* <FeatureRef slug="transakcje">transakcje</FeatureRef> — fakturę sprzedaży księguje się jako transakcję przychodową.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/wystawianie">KSeF — wystawianie</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/format-fa3">KSeF — format FA(3)</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/harmonogram">KSeF — harmonogram</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/odwrotne-obciazenie">Odwrotne obciążenie</FeatureRef>.


---

# Środki trwałe
URL: https://numifyai.com/docs/korzystanie-z-numify/fixed-assets
Description: Ewidencja środków trwałych — wartość początkowa, trzy metody amortyzacji (liniowa, degresywna, jednorazowa), miesięczny plan odpisów, likwidacja i zbycie oraz generowanie danych do JPK_ST_KR. 9 testów integracyjnych pokrywa logikę amortyzacji.
Review status: numify-source
Updated: 2026-04-17



**Środki trwałe (ŚT)** to rzeczowe aktywa trwałe spółki o okresie
użytkowania dłuższym niż rok (<LegalRef act="UoR" art="3" paragraph="1" /> pkt 15).
Numify prowadzi ewidencję każdego składnika, generuje miesięczny plan
amortyzacji, księguje odpisy w dzienniku i składa dane do JPK\_ST\_KR.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /fixed-assets — lista ŚT z kolumnami Nazwa / KŚT / Wartość początkowa / Metoda / Stawka / Umorzenie / Status */}

## Co jest, a co nie jest środkiem trwałym [#co-jest-a-co-nie-jest-środkiem-trwałym]

Zgodnie z <LegalRef act="UoR" art="3" paragraph="1" /> (pkt 15) ŚT
to rzeczowe aktywa trwałe **kompletne, zdatne do użytku i przeznaczone
na potrzeby jednostki**, o przewidywanym okresie użyteczności dłuższym
niż rok:

* nieruchomości (grunty, prawo użytkowania wieczystego, budynki, lokale, spółdzielcze prawo do lokalu),
* maszyny, urządzenia, środki transportu,
* ulepszenia w obcych środkach trwałych,
* inwentarz żywy.

**Nie są ŚT**: materiały i towary (zespół 3), wartości niematerialne i
prawne (licencje, know-how — zespół 0 ale osobny rejestr), inwestycje
(nieruchomości posiadane dla zysku, nieużywane przez spółkę).

## Dwa reżimy: bilansowy i podatkowy [#dwa-reżimy-bilansowy-i-podatkowy]

Dla ŚT istnieją **dwa odrębne reżimy amortyzacji**, które w Numify
prowadzi się równolegle:

| Reżim               | Podstawa                                       | Stawki                                                                            | Cel                          |
| ------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------- | ---------------------------- |
| **Bilansowy** (UoR) | <LegalRef act="UoR" art="32" paragraph="1" />  | Wg ekonomicznej użyteczności (<LegalRef act="UoR" art="32" paragraph="2" />)      | Wiarygodność bilansu i RZiS  |
| **Podatkowy** (CIT) | <LegalRef act="CIT" art="16a" paragraph="1" /> | Wg Wykazu stawek amortyzacyjnych (<LegalRef act="CIT" art="16i" paragraph="1" />) | Ustalenie kosztu podatkowego |

W praktyce większość spółek z o.o. stosuje **stawki podatkowe** również
dla celów bilansowych — <LegalRef act="UoR" art="32" paragraph="7" />
dopuszcza to dla jednostek mikro i małych. Dla większych jednostek
reżimy mogą się różnić i wymagają osobnej ewidencji różnic.

Numify prowadzi **jedną ewidencję** z metodą i stawką wspólną dla obu
reżimów. Jeśli spółka potrzebuje rozdzielonej amortyzacji, obecnie
wymaga to ręcznego prowadzenia drugiej tabeli poza systemem.

## Klasyfikacja Środków Trwałych (KŚT) [#klasyfikacja-środków-trwałych-kśt]

Każdy ŚT otrzymuje kod z **Klasyfikacji Środków Trwałych** (KŚT) —
klasyfikacja GUS z rozporządzenia Rady Ministrów z 3 października 2016 r.
(Dz.U. 2016 poz. 1864). Kod KŚT determinuje stawkę amortyzacji
podatkowej (Wykaz stawek jest załącznikiem do ustawy o CIT) i jest
wymagany w JPK\_ST\_KR.

Typowe kody:

| KŚT   | Opis                                      | Stawka podatkowa |
| ----- | ----------------------------------------- | ---------------- |
| 10–18 | Budynki                                   | 1,5% – 4,5%      |
| 21    | Budowle                                   | 2,5% – 4,5%      |
| 491   | Zespoły komputerowe                       | 30%              |
| 629   | Pozostałe środki łączności (np. telefony) | 20%              |
| 741   | Samochody osobowe                         | 20%              |
| 803   | Wyposażenie biurowe                       | 20%              |

Numify nie waliduje kodu KŚT — pole `classificationCode` jest
dowolnym tekstem. Odpowiedzialność za prawidłowy kod leży po stronie
użytkownika.

## Metody amortyzacji [#metody-amortyzacji]

Numify wspiera trzy metody (`DepreciationMethod`):

### 1. Liniowa (`linear`) [#1-liniowa-linear]

Równe miesięczne odpisy przez cały okres amortyzacji:

```
odpis miesięczny = (wartość początkowa × stawka roczna) / 12
```

Standardowa metoda, zgodna z <LegalRef act="UoR" art="32" paragraph="1" />
(systematyczne, planowe rozłożenie) i domyślna w Wykazie stawek CIT.

### 2. Degresywna (`degressive`) [#2-degresywna-degressive]

Odpis liczony od **wartości netto** (wartość początkowa – dotychczasowe
umorzenie), ze współczynnikiem ≤ 2,0 (<LegalRef act="CIT" art="16i" paragraph="2" />).
W miesiącu, w którym odpis degresywny zrównałby się lub spadł poniżej
odpisu liniowego, metoda **przełącza się na liniową** — zgodnie z art.
16k ust. 1 CIT (odwołanie w tekście; artykuł nie jest osobno
cytowany).

Dostępna dla maszyn i urządzeń z grup 3–6 i 8 KŚT oraz środków
transportu (z wyjątkiem samochodów osobowych).

### 3. Jednorazowa (`one_time`) [#3-jednorazowa-one_time]

Cały odpis w miesiącu oddania do używania. Zastosowanie:

* **ŚT o niskiej wartości** — ≤ 10 000 zł (<LegalRef act="CIT" art="16d" paragraph="1" /> — brak konieczności amortyzacji; <LegalRef act="CIT" art="16f" paragraph="3" /> — wybór między jednorazowym a planowym).
* **Uproszczenia zbiorcze dla jednostki mikro/małej** (<LegalRef act="UoR" art="32" paragraph="6" />).
* **Jednorazowa amortyzacja podatkowa dla małych podatników i rozpoczynających działalność** — art. 16k ust. 7 CIT, do równowartości 50 000 euro rocznie (odwołanie; nie cytowane osobno).

## Tworzenie ŚT [#tworzenie-śt]

Formularz „Nowy ŚT" wymaga:

| Pole                         | Wymagane? | Uwagi                                                                                                                        |
| ---------------------------- | :-------: | ---------------------------------------------------------------------------------------------------------------------------- |
| Nazwa                        |     ✅     | Np. „Laptop MacBook Pro 14""                                                                                                 |
| Numer inwentarzowy           |     ✅     | Unikalny w obrębie spółki                                                                                                    |
| Kod KŚT                      |     ❌     | Zalecane — używane w JPK\_ST\_KR                                                                                             |
| Nazwa grupy KŚT              |     ❌     | Dla czytelności                                                                                                              |
| Data nabycia                 |     ✅     | Data faktury / dokumentu zakupu                                                                                              |
| Data rozpoczęcia amortyzacji |     ❌     | Domyślnie = data nabycia; zgodnie z <LegalRef act="UoR" art="32" paragraph="1" /> nie wcześniej niż po przyjęciu do używania |
| Wartość początkowa           |     ✅     | W groszach; <LegalRef act="UoR" art="31" paragraph="1" /> — cena nabycia + koszty przygotowania do używania                  |
| Metoda                       |     ✅     | `linear` / `degressive` / `one_time`                                                                                         |
| Stawka roczna                |     ✅     | Procent (np. 20 dla 20%)                                                                                                     |

Numify nie oblicza automatycznie wartości początkowej z faktury —
podajesz ją ręcznie. Uwzględnij koszty transportu, montażu, cła i
innych kosztów bezpośrednio związanych z przygotowaniem do używania
(<LegalRef act="UoR" art="31" paragraph="1" />).

## Plan amortyzacji [#plan-amortyzacji]

Funkcja `getDepreciationSchedule(assetId)` zwraca pełen plan — miesiąc
po miesiącu, od daty rozpoczęcia amortyzacji do miesiąca, w którym
wartość odpisów zrówna się z wartością początkową. Dla metody
`one_time` plan ma jedną pozycję.

Obliczanie pojedynczego miesiąca: `calculateMonthlyDepreciation({ valueGrosze, rate, method, ... })`.

## Księgowanie odpisów miesięcznych [#księgowanie-odpisów-miesięcznych]

`generateMonthlyDepreciation(companyId, year, month)` tworzy zapis
zbiorczy w <FeatureRef slug="journal">dzienniku</FeatureRef>:

* **Wn <AccountRef code="400" />** (Amortyzacja, zespół 4) — suma odpisów miesiąca
* **Ma <AccountRef code="070" />** (Umorzenie środków trwałych, zespół 0) — ta sama suma

Funkcja jest **idempotentna** — wywołanie dla miesiąca, w którym odpis
już zaksięgowano, nie utworzy duplikatu.

Pokrycie testowe: <ServiceRef path="src/lib/services/fixed-assets.ts" />
ma 9-testowy pakiet `fixed-assets.test.ts` weryfikujący wszystkie trzy
metody, idempotencję, przełączenie degresywna → liniowa i obsługę
brzegów (rozpoczęcie w trakcie miesiąca, pełne umorzenie).

## Likwidacja i zbycie [#likwidacja-i-zbycie]

`disposeFixedAsset(assetId, { date, disposalType })` zmienia status ŚT
na `disposed` i księguje w dzienniku:

* **sprzedaż** — wyksięgowanie wartości netto na pozostałe koszty operacyjne, przychód ze sprzedaży na <AccountRef code="700" /> (z VAT jeśli dotyczy),
* **likwidacja** — wartość netto w pozostałe koszty operacyjne (dokument LT).

Szczegółowe księgowania zależą od stanu umorzenia na moment zbycia;
Numify składa zapis automatycznie na podstawie bieżącej wartości z
planu amortyzacji.

Po zbyciu ŚT **nie jest usuwany** — pozostaje w ewidencji ze statusem
`disposed` (zakaz usuwania, <LegalRef act="UoR" art="25" paragraph="1" />).

## JPK\_ST\_KR [#jpk_st_kr]

<ServiceRef path="src/lib/services/jpk-st-kr-generator.ts" /> składa
plik JPK\_ST\_KR — ewidencję środków trwałych wymaganą od 2026 r.
Struktura obejmuje wartość początkową, stawkę, metodę, datę
przyjęcia, KŚT, dotychczasowe umorzenie i datę zbycia (jeśli dotyczy).

Generowanie pliku jest częścią <FeatureRef slug="journal">eksportów
JPK</FeatureRef> — dokumentacja eksportów jest zaplanowana jako
osobna strona.

## Widok `/fixed-assets` [#widok-fixed-assets]

{/* SCREENSHOT: lista + formularz dodawania ŚT, podgląd planu amortyzacji per ŚT */}

* **Lista** — tabela wszystkich ŚT z kolumnami KŚT, wartość początkowa, metoda, stawka, umorzenie narastająco, status.
* **Licznik „aktywnych"** — ŚT w statusie `active`.
* **„+ Nowy ŚT"** — formularz opisany wyżej.
* **Detale ŚT** — pełen plan amortyzacji, historia odpisów, przycisk zbycia.
* **„Generuj amortyzację miesiąca"** — uruchamia `generateMonthlyDepreciation` dla wybranego roku i miesiąca.

## Powiązania [#powiązania]

* <FeatureRef slug="opening-balance">Bilans otwarcia</FeatureRef> — ŚT przenoszone z innego systemu wymagają dwóch pozycji BO (<AccountRef code="010" /> wartość brutto + <AccountRef code="070" /> umorzenie) plus wpisu w rejestrze ŚT.
* <FeatureRef slug="accounting-policy">Polityka rachunkowości</FeatureRef> — metody i stawki ustalone dla spółki są elementem polityki.
* <FeatureRef slug="journal">Dziennik</FeatureRef> — odpisy miesięczne i zbycie trafiają tutaj jako zapisy z `source = 'fixed_assets'`.
* <FeatureRef slug="balance-sheet">Bilans</FeatureRef> — wartość netto ŚT (A.II.1) = saldo <AccountRef code="010" /> – saldo <AccountRef code="070" />.
* <FeatureRef slug="profit-loss">RZiS</FeatureRef> — amortyzacja z <AccountRef code="400" /> jako koszt rodzajowy.


---

# Księga główna
URL: https://numifyai.com/docs/korzystanie-z-numify/general-ledger
Description: Ujęcie systematyczne zapisów księgowych — ten sam zbiór zapisów co w dzienniku, ale pogrupowany po kontach syntetycznych, z obrotami i saldem dla każdego konta za wybrany okres.
Review status: internal
Updated: 2026-04-17



**Księga główna** pokazuje ten sam zbiór zapisów co <FeatureRef slug="journal">dziennik</FeatureRef>,
ale w **ujęciu systematycznym** — pogrupowany po kontach syntetycznych.
Dla każdego konta widzisz saldo otwarcia, obroty okresu (Wn i Ma) oraz saldo
zamknięcia.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /general-ledger — lista kont z saldami po lewej, po wyborze konta kartoteka zapisów z kolumnami Nr / Data / Opis / Wn / Ma / Saldo bieżące */}

## Dziennik vs. księga główna [#dziennik-vs-księga-główna]

To dwa ujęcia tych samych danych (`journal_lines`), wymagane osobno przez UoR:

| Aspekt          | Dziennik                                      | Księga główna                                        |
| --------------- | --------------------------------------------- | ---------------------------------------------------- |
| Porządek        | Chronologiczny                                | Systematyczny (po kontach)                           |
| Perspektywa     | „Co się wydarzyło w czasie"                   | „Jakie jest saldo tego konta"                        |
| Podstawa prawna | <LegalRef act="UoR" art="14" paragraph="1" /> | <LegalRef act="UoR" art="15" paragraph="1" />        |
| Numeracja       | Ciągła, niepowtarzalna                        | Zapisy w kolejności chronologicznej na każdym koncie |

Obroty dziennika za okres muszą się zgadzać z sumą obrotów wszystkich kont
księgi głównej — Numify uzgadnia to automatycznie, bo oba widoki agregują te
same `journal_lines` z zapisów w stanie `isPosted: true`.

## Model danych [#model-danych]

Usługa <ServiceRef path="src/lib/services/general-ledger.ts" /> zwraca dla
wybranego konta:

| Pole                         | Opis                                                                                                                                                                                                                       |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `openingBalance`             | Saldo konta na początek okresu — suma Wn minus suma Ma wszystkich zaksięgowanych zapisów przed `startDate`.                                                                                                                |
| `totalDebit` / `totalCredit` | Obroty konta w okresie (Wn / Ma).                                                                                                                                                                                          |
| `closingBalance`             | Saldo konta na koniec okresu — `openingBalance + totalDebit - totalCredit`. Dla kont debetowych (aktywa, koszty) saldo dodatnie oznacza stronę Wn; dla kredytowych (pasywa, przychody) — saldo dodatnie oznacza stronę Ma. |
| `entries`                    | Lista zapisów konta w okresie, z kolumną `runningBalance` (saldo narastająco po każdym zapisie).                                                                                                                           |

Tylko zapisy `isPosted: true` wchodzą do kalkulacji. Szkice (`isPosted: false`)
nie wpływają na salda.

## Jak czytać saldo [#jak-czytać-saldo]

Znak salda zależy od typu konta:

* **Konta debetowe** (aktywa, koszty — grupy 0–3, 4, 7 koszty): saldo dodatnie
  po stronie Wn oznacza wartość dodatnią (np. <AccountRef code="100" /> z
  saldem 5 000,00 zł Wn = 5 000,00 zł w kasie).
* **Konta kredytowe** (pasywa, kapitały, przychody — grupy 2 rozrachunki
  zobowiązaniowe, 8 kapitały, 7 przychody): saldo dodatnie po stronie Ma
  oznacza wartość dodatnią (np. <AccountRef code="700" /> z saldem 50 000,00 zł
  Ma = 50 000,00 zł przychodu ze sprzedaży).
* **Rozrachunki** (<AccountRef code="201" />, <AccountRef code="202" />): mogą
  mieć saldo po obu stronach — Wn oznacza należność, Ma oznacza zobowiązanie.
  W analityce per-kontrahent salda rozwijają się jednoznacznie.

Numify wyświetla saldo zamknięcia w tej konwencji w kolumnie odpowiadającej
„naturalnej" stronie danego typu konta, ale w bazie przechowuje oba pola
(`closingDebit`, `closingCredit`) osobno — interpretacja pozostaje bez
wątpliwości.

## Konta syntetyczne vs. analityka [#konta-syntetyczne-vs-analityka]

<LegalRef act="UoR" art="16" paragraph="1" /> wymaga, żeby konta ksiąg
pomocniczych (analityka) były **uzgodnione z saldami i zapisami na kontach
księgi głównej**. W Numify realizowane to jest przez:

* **Konta syntetyczne** — trzycyfrowe (np. `201`, `400`, `700`) — to konta
  księgi głównej w rozumieniu art. 15 UoR. Ich salda trafiają wprost do
  zestawienia obrotów i sald, bilansu i RZiS.
* **Konta analityczne** — cztery+ cyfrowe (np. `201-KONTRAHENT-1`), tworzone
  automatycznie w tle, np. osobne konto analityczne na każdego kontrahenta
  dla rozrachunków, osobne na każdy środek trwały dla amortyzacji.

Obroty analityki z definicji sumują się do obrotów syntetyka — Numify nie
pozwala na rozjazd, bo każdy `journal_line` wskazuje dokładnie jedno
`accountId`, a hierarchia wynika z `chartAccounts.parentAccountId`.

Zakres obowiązkowej analityki opisuje <LegalRef act="UoR" art="17" paragraph="1" /> —
w praktyce dla spółki z o.o. oznacza to analitykę dla:

* środków trwałych i wartości niematerialnych (<AccountRef code="010" />, amortyzacja),
* rozrachunków z kontrahentami (<AccountRef code="201" />, <AccountRef code="202" />),
* rozrachunków z pracownikami,
* operacji sprzedaży i zakupu (<FeatureRef slug="vat-register">rejestr VAT</FeatureRef>).

## Ekran `/general-ledger` [#ekran-general-ledger]

Lewa kolumna — **lista kont** z filtrem zakresu dat. Dla każdego konta widzisz
kod, nazwę oraz saldo zamknięcia na wybraną datę. Konta bez obrotów i bez
salda otwarcia są domyślnie ukryte.

Prawa kolumna — po kliknięciu konta — **kartoteka konta**: chronologiczna
lista zapisów tego konta z kolumnami: numer zapisu w dzienniku, data, opis,
kwota Wn, kwota Ma, saldo narastająco.

{/* SCREENSHOT: dwie kolumny — lewa z listą kont i saldami, prawa z kartoteką konta 201 „Rozrachunki z odbiorcami" — zapisy chronologicznie, saldo narastająco */}

Klik w numer zapisu w kartotece otwiera ten sam dialog szczegółów co na
ekranie <FeatureRef slug="journal">dziennika</FeatureRef>.

## Filtry [#filtry]

* **Zakres dat** — `startDate`, `endDate`. Saldo otwarcia liczy się ze
  wszystkich zaksięgowanych zapisów **przed** `startDate`; obroty i saldo
  zamknięcia — z zapisów w przedziale `[startDate, endDate]`.
* **Typ konta** — aktywa, pasywa, kapitały, przychody, koszty — opcjonalnie,
  żeby zawęzić listę.
* **Tylko konta z ruchem** — domyślnie włączone; wyłącz, jeśli chcesz widzieć
  wszystkie aktywne konta z planu kont, również zerowe.

## Relacja do innych ekranów [#relacja-do-innych-ekranów]

* <FeatureRef slug="journal">Dziennik</FeatureRef> — źródło wszystkich
  zapisów. Kartoteka konta pokazuje podzbiór dotyczący jednego konta.
* <FeatureRef slug="trial-balance">Zestawienie obrotów i sald</FeatureRef> —
  zbiorczy widok wszystkich kont z księgi głównej, wymagany przez
  <LegalRef act="UoR" art="13" paragraph="1" />.
* <FeatureRef slug="balance-sheet">Bilans</FeatureRef> i
  <FeatureRef slug="profit-loss">RZiS</FeatureRef> — statutowe raporty
  agregujące salda kont syntetycznych.

## Ograniczenia [#ograniczenia]

* **Brak eksportu kartoteki konta do PDF/CSV z tego ekranu** — użyj
  <FeatureRef slug="exports">eksportów</FeatureRef> (w przygotowaniu) lub
  JPK\_KR\_PD, który zawiera pełne dane.
* **Szkice (`isPosted: false`) nie wchodzą do księgi głównej** — to zgodne z
  UoR (zapis trafia do księgi głównej dopiero po zaksięgowaniu), ale oznacza,
  że podgląd „co by było, gdyby" wymaga najpierw zaksięgowania zapisu.
* **Brak drukowania księgi głównej** — <LegalRef act="UoR" art="13" paragraph="6" />
  dopuszcza zamiennie przeniesienie treści ksiąg na informatyczny nośnik
  danych zapewniający trwałość zapisu. Numify spełnia ten wymóg przez
  eksporty i JPK\_KR\_PD.

## Dlaczego to ważne z punktu widzenia kontroli [#dlaczego-to-ważne-z-punktu-widzenia-kontroli]

Księga główna jest głównym punktem wejścia dla kontrolera podatkowego — to
tutaj widać saldo każdego konta i zapisy, które je utworzyły. Wymagania UoR
(systematyczność, chronologia na koncie, powiązanie z dziennikiem, uzgodnienie
z analityką) są jednocześnie warunkami „niewadliwości" z
<LegalRef act="OrdPod" art="193" paragraph="3" />. Dziennik + księga główna +
analityka + zestawienie obrotów i sald = komplet wymagany do tego, żeby księgi
zachowały moc dowodową w postępowaniu podatkowym.


---

# Dokumenty
URL: https://numifyai.com/docs/korzystanie-z-numify/dokumenty
Description: Przesyłanie, parsowanie i zarządzanie dokumentami przychodzącymi — faktury od dostawców, paragony, inne dowody księgowe. AI wyodrębnia dane, człowiek weryfikuje, a Numify zamienia to w transakcję do zaksięgowania.
Review status: internal
Updated: 2026-04-16



> **Nie mylić z [Faktury](/docs/korzystanie-z-numify/faktury).** Ta strona
> opisuje **dokumenty przychodzące** — faktury od dostawców, paragony,
> które AI parsuje i zamienia w transakcje. Jeśli chcesz **wystawić**
> fakturę sprzedażową, zobacz [Faktury](/docs/korzystanie-z-numify/faktury).

**Dokumenty** to punkt wejścia do księgowości — miejsce, gdzie spółka
przesyła dowody księgowe (faktury zakupu, paragony, inne), a Numify
automatycznie wyodrębnia z nich dane do dalszej obróbki.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /documents — upload zone + tabela z kolumnami Nazwa/Status/Kwota/Data/Typ */}

## 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 w postaci zapisu. Podstawą tego
zapisu musi być **dowód księgowy** (art. 20 ust. 2) — w praktyce dla sp. z o.o.
najczęściej faktura zakupu otrzymana od kontrahenta.

Numify:

1. **Przechowuje oryginał** dokumentu (PDF, obraz) w Cloudflare R2 — elektronicznie, zgodnie z <LegalRef act="UoR" art="73" paragraph="2" />.
2. **Parsuje dane** modelem AI i podsuwa je do weryfikacji.
3. **Tworzy <FeatureRef slug="transakcje">transakcję</FeatureRef>** po zatwierdzeniu — to z niej zostanie utworzony zapis w dzienniku (<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">UoR art. 14</FeatureRef>).

## Co można przesłać [#co-można-przesłać]

| Format    | Obsługa                            | Uwagi               |
| --------- | ---------------------------------- | ------------------- |
| PDF       | Pełna — tekstowa + skany z OCR     | Preferowany format  |
| PNG / JPG | Pełna — OCR w ramach modelu        | Jakość ma znaczenie |
| HEIC      | Automatycznie konwertowane do JPEG | iPhone scans        |
| XML FA(3) | Tak — bezpośredni parsing (bez AI) | Faktury z KSeF      |

**Limit wielkości:** domyślnie 10 MB na plik. Wiele plików można wgrać
jednocześnie (drag-and-drop) — każdy jest przetwarzany asynchronicznie
w tle (BullMQ).

## Pipeline parsowania [#pipeline-parsowania]

```
Upload → R2 (oryginał) → ekstrakcja tekstu (PDF/OCR)
       → model Gemini 2.5 Flash → schema Zod → draft transakcji
       → (ludzki przegląd) → zaakceptowanie → dziennik
```

<ServiceRef path="src/lib/services/document-parser.ts">
  document-parser.ts
</ServiceRef>

### Co AI wyciąga z dokumentu [#co-ai-wyciąga-z-dokumentu]

Schemat (`invoiceSchema`) obejmuje m.in.:

* typ dokumentu (`invoice` / `receipt` / `credit_note` / `other`),
* numer dokumentu, data wystawienia, termin płatności,
* sprzedawcę (nazwa, NIP, adres, kraj),
* nabywcę (nazwa, NIP, adres),
* pozycje (opis, ilość, cena jednostkowa, netto, stawka VAT, brutto),
* sumy (netto, VAT, brutto, waluta),
* kategorię kosztu (dopasowaną do <LegalRef act="UoR" art="21" paragraph="1" /> pkt 6 — „dekretacja").

Przed zaakceptowaniem jako transakcja **zawsze** trafia to do weryfikacji
ludzkiej — AI może się mylić, zwłaszcza przy paragonach o niskiej jakości.

## Statusy dokumentu [#statusy-dokumentu]

| Status       | Znaczenie                                                            |
| ------------ | -------------------------------------------------------------------- |
| `pending`    | Wrzucony, w kolejce BullMQ.                                          |
| `processing` | AI parsuje w tej chwili (UI odpytuje co 5 s).                        |
| `completed`  | Sparsowany; czeka na akceptację lub edytę.                           |
| `failed`     | Parsing zawiódł (np. dokument nieczytelny) — możliwa obsługa ręczna. |

Po zaakceptowaniu transakcji dokument zostaje **na stałe** powiązany z tą
transakcją (i z wpisem w dzienniku) — to materializuje wymóg
<LegalRef act="UoR" art="21" paragraph="1" /> pkt 1–2 (rodzaj i numer dowodu, strony).

## Wymogi art. 21 — 6 elementów dowodu [#wymogi-art-21--6-elementów-dowodu]

Zgodnie z <LegalRef act="UoR" art="21" paragraph="1" /> dowód księgowy **powinien
zawierać co najmniej** sześć elementów:

| # | Element                                    | Skąd w Numify                                                                                                   |
| - | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
| 1 | Rodzaj i numer dowodu                      | Z faktury (`invoiceNumber`) + klasyfikacja Numify (`invoice` / `receipt` …).                                    |
| 2 | Strony operacji (nazwy, adresy)            | Z faktury (`seller`, `buyer`).                                                                                  |
| 3 | Opis operacji + wartość                    | Pozycje + sumy (linie dokumentu).                                                                               |
| 4 | Data operacji                              | `invoiceDate` (+ `saleDate` jeśli różne).                                                                       |
| 5 | Podpis wystawcy                            | Typowo brak na e-fakturach — zastępuje go cyfrowa autentyczność wystawienia. W KSeF — numer KSeF pełni tę rolę. |
| 6 | Dekretacja (konta, miesiąc, sposób ujęcia) | Nadawana przy akceptacji transakcji (propozycja AI + korekta użytkownika).                                      |

## Bezpieczne przechowywanie [#bezpieczne-przechowywanie]

Zgodnie z <LegalRef act="UoR" art="73" paragraph="2" /> dowody elektroniczne są
akceptowalne, jeśli zapewniona jest **niezmienność przez wymagany okres
przechowywania** (5 lat dla większości dowodów — szczegóły →
<FeatureRef slug="/docs/zgodnosc-z-prawem/przechowywanie-dokumentow">przechowywanie dokumentów</FeatureRef>).

Numify realizuje to tak:

* Oryginał w R2 jest **write-once** (kluczowany hashem zawartości — nadpisanie nie jest możliwe bez świadomej akcji).
* Powiązanie dokument ↔ transakcja ↔ zapis księgowy jest twarde (klucze obce) — nie da się „osierocić" zapisu.
* Usunięcie dokumentu jest zablokowane, gdy istnieje powiązana transakcja (ślad rewizyjny → <LegalRef act="UoR" art="25" />).

## Ograniczenia [#ograniczenia]

1. **AI czasem się myli** na paragonach niskiej jakości (wyblakły druk, odręczne notatki). Wymaga ręcznej poprawki.
2. **Dokumenty wielopozycyjne** o nietypowym układzie (skany książek przychodów z XIX w., faktury rękopisy) mogą wymagać pełnej edycji ręcznej.
3. **Brak rozpoznawania języków innych niż PL / EN** — faktury w DE / FR / IT są obsługiwane, ale jakość klasyfikacji jest gorsza.
4. **Dokumenty obraz + tekst w jednym PDF** — model zazwyczaj radzi sobie z obydwoma, ale przy bardzo dużych plikach (200+ stron) zalecane jest dzielenie.
5. **Brak zbiorczego uploadu faktur z KSeF** w pełnej automatyzacji — odbiór z KSeF działa, ale wymaga skonfigurowanej sesji (→ <FeatureRef slug="/docs/zgodnosc-z-prawem/ksef/odbieranie">KSeF — odbieranie</FeatureRef>).

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Prześlij PDF / obraz** — przeciągnij do strefy lub kliknij Upload.
2. **Poczekaj kilka sekund** — status zmienia się z `pending` → `processing` → `completed`.
3. **Otwórz dokument**, sprawdź wyciągnięte dane (kontrahent, kwoty, stawki VAT).
4. **Popraw błędy**, jeśli występują — jeden klik → edycja pola.
5. **Utwórz transakcję** — dokument zostaje trwale powiązany.
6. **Nie usuwaj dokumentu** po zaksięgowaniu — zamiast tego użyj korekty w <FeatureRef slug="transakcje">transakcjach</FeatureRef>.

{/* SCREENSHOT: pojedynczy dokument — panel boczny z danymi wyodrębnionymi przez AI */}

## Powiązane [#powiązane]

* <FeatureRef slug="transakcje">transakcje</FeatureRef> — powstają z zaakceptowanych dokumentów.
* <FeatureRef slug="faktury">faktury</FeatureRef> — faktury wystawiane (nie mylić z przychodzącymi).
* <FeatureRef slug="kontrahenci">kontrahenci</FeatureRef> — parser tworzy kontrahentów z NIP-u wystawcy.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-rachunkowosci/art-14-dziennik">UoR — dziennik</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/przechowywanie-dokumentow">Przechowywanie dokumentów</FeatureRef>.


---

# Kontrahenci
URL: https://numifyai.com/docs/korzystanie-z-numify/kontrahenci
Description: Rejestr dostawców i odbiorców w Numify — wyszukiwanie po NIP z Białej Listy, automatyczne uzupełnianie danych, weryfikacja statusu VAT i numeru VAT UE (VIES), przechowywanie rachunków bankowych do weryfikacji MPP.
Review status: internal
Updated: 2026-04-16



**Kontrahenci** to rejestr firm, z którymi spółka prowadzi rozliczenia — zarówno
**dostawców** (od których kupuje), jak i **odbiorców** (którym sprzedaje). Dane
z tego rejestru są używane przy parsowaniu <PolishTerm pl="dokumentów przychodzących" en="incoming documents" />,
wystawianiu własnych faktur oraz dopasowywaniu wyciągów bankowych.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /contractors — lista kontrahentów z kartami (nazwa, NIP, miasto) */}

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

Spółka z o.o. musi na każdej fakturze umieścić **nazwę i adres oraz NIP
podatnika i nabywcy** (<LegalRef act="VAT" art="106e" paragraph="1" /> pkt 3–5).
Przechowywanie tych danych w jednym miejscu eliminuje błędy przepisywania
i pozwala:

* **automatycznie uzupełniać** dane nowego kontrahenta po wpisaniu samego NIP — z rejestru publicznego (Biała Lista);
* **dopasowywać** fakturę przychodzącą do już istniejącego dostawcy (zamiast tworzyć duplikat);
* **weryfikować rachunek bankowy** przed zapłatą (→ <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista">Biała Lista</FeatureRef>);
* **walidować numer VAT UE** dla transakcji wewnątrzwspólnotowych (VIES).

## Model danych [#model-danych]

Każdy kontrahent ma następujące pola widoczne w formularzu:

| Pole                    | Przeznaczenie                                                     |
| ----------------------- | ----------------------------------------------------------------- |
| Nazwa                   | Pełna nazwa firmy (pojawia się na fakturach).                     |
| Skrót (opcjonalnie)     | Krótka etykieta na listach.                                       |
| NIP                     | 10-cyfrowy numer identyfikacji podatkowej.                        |
| Kraj                    | 2-literowy kod ISO (PL domyślnie).                                |
| Adres                   | Ulica, kod pocztowy, miasto.                                      |
| Rachunek bankowy (IBAN) | Używany do weryfikacji Białej Listy przy płatnościach.            |
| E-mail, telefon         | Dane kontaktowe.                                                  |
| Typ                     | `supplier` (dostawca), `customer` (odbiorca), `both` (obie role). |

Pole `taxId` w bazie to NIP dla kontrahentów polskich; dla unijnych może
zawierać numer VAT UE (np. `DE123456789`) — wtedy walidujemy go przez VIES.

## Automatyczne uzupełnianie z Białej Listy [#automatyczne-uzupełnianie-z-białej-listy]

Wpisując NIP w formularzu **Dodaj kontrahenta** i klikając ikonę ✨
(Sparkles) Numify odpytuje publiczne API Ministerstwa Finansów i uzupełnia:

* nazwę firmy,
* adres siedziby (ulica, kod, miasto),
* numer KRS (jeśli nadany),
* status VAT (czynny / zwolniony / niezarejestrowany),
* zarejestrowane rachunki bankowe.

Podstawą prawną wykazu jest <LegalRef act="VAT" art="96b" /> — Szef Krajowej
Administracji Skarbowej prowadzi elektroniczny wykaz podatników VAT, który
każdy przedsiębiorca może sprawdzić na wybrany dzień z okresu ostatnich 5 lat.

<ServiceRef path="src/lib/services/krs-lookup.ts">
  krs-lookup.ts
</ServiceRef>

### Fallbacki [#fallbacki]

1. **Biała Lista niedostępna** (np. awaria API MF) — pole pozostaje puste, pokazujemy toast z informacją. Nie blokujemy tworzenia kontrahenta.
2. **NIP nieznany** (firma w likwidacji, cudzoziemiec bez PL-NIP) — formularz pozwala wypełnić dane ręcznie.
3. **Kontrahent zagraniczny (UE)** — zamiast NIP podaje się pełny numer VAT UE; weryfikujemy go przez VIES (<ServiceRef path="src/lib/services/vies-validation.ts">vies-validation.ts</ServiceRef>).

## Weryfikacja rachunku bankowego [#weryfikacja-rachunku-bankowego]

Numify przechowuje IBAN kontrahenta, ale **nie sprawdza go automatycznie przy
każdej płatności** — to krok ręczny lub wykonywany w kontekście księgowania
płatności. Zobacz <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista">Biała Lista</FeatureRef>
dla pełnej procedury weryfikacji i konsekwencji zapłaty na rachunek
niezarejestrowany.

<ServiceRef path="src/lib/services/white-list.ts">
  white-list.ts
</ServiceRef>

Kluczowe progi:

* **≥ 15 000 zł (brutto)** w płatności do czynnego podatnika VAT — zapłata na rachunek spoza wykazu skutkuje ryzykiem NKUP oraz solidarną odpowiedzialnością za VAT (szczegóły → <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista">biala-lista</FeatureRef>).
* **Faktury z załącznika nr 15** — dodatkowo obowiązkowy MPP (<LegalRef act="VAT" art="106e" paragraph="1 pkt 18a" />).

## Kontrahenci UE i weryfikacja VIES [#kontrahenci-ue-i-weryfikacja-vies]

Dla firm spoza Polski, ale z UE, używamy **numeru VAT UE** (np. `DE123456789`,
`FR12345678901`). Walidacja następuje przez publiczny serwis VIES Komisji
Europejskiej i daje potwierdzenie, że numer jest aktywny w danym dniu.

To istotne dla dokumentowania **WDT / WNT** — zobacz
<FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue">VAT-UE</FeatureRef>
i <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt">WNT/WDT</FeatureRef>.

<ServiceRef path="src/lib/services/vies-validation.ts">
  vies-validation.ts
</ServiceRef>

## Automatyczne tworzenie przy imporcie faktury [#automatyczne-tworzenie-przy-imporcie-faktury]

Gdy prześlesz fakturę przez <FeatureRef slug="dokumenty">Dokumenty</FeatureRef>,
parser AI wyodrębnia NIP wystawcy i — jeśli nie ma jeszcze kontrahenta o tym
NIP — tworzy go automatycznie z danych z faktury. Dane z Białej Listy są
używane do uzupełnienia brakujących pól (adres, status VAT).

Dzięki temu rejestr **rośnie z użytkiem**, zamiast wymagać wypełniania
z góry.

{/* SCREENSHOT: formularz "Dodaj kontrahenta" z podświetlonym przyciskiem ✨ Wyszukaj po NIP */}

## Dezaktywacja vs usunięcie [#dezaktywacja-vs-usunięcie]

Kontrahent po utworzeniu **nie może zostać usunięty**, jeśli ma powiązane
dokumenty lub transakcje — to wymóg <LegalRef act="UoR" art="25" /> (ślad
rewizyjny — żaden zapis księgowy nie może „stracić" kontekstu, w którym
powstał).

Zamiast tego używa się flagi `isActive`. Nieaktywni kontrahenci:

* pozostają widoczni na historycznych dokumentach i fakturach,
* nie pojawiają się w domyślnych listach wyboru przy tworzeniu nowych transakcji,
* są wyszarzeni w widoku listy.

## Ograniczenia [#ograniczenia]

1. **Brak automatycznej synchronizacji** ze zmianami w Białej Liście — po utworzeniu kontrahenta dane nie są odświeżane cyklicznie. Jeśli kontrahent zmienił adres lub status VAT, trzeba odświeżyć dane ręcznie (wpisując NIP ponownie i klikając ✨).
2. **Brak historii zmian na poziomie kontrahenta** — jeśli zmienisz nazwę lub NIP, Numify nie wersjonuje tej zmiany. Dla audytu zmiany danych polegamy na globalnym `auditLog` repozytorium.
3. **Brak pełnego importu masowego** (CSV) w UI — jest na roadmapie; dziś masa kontrahentów tworzy się przez import faktur.
4. **Walidacja NIP** sprawdza tylko format (10 cyfr) — nie sumę kontrolną. Zamiast tego polegamy na Białej Liście jako źródle prawdy (nieistniejący NIP nie zwróci odpowiedzi).

## Rekomendowany workflow [#rekomendowany-workflow]

1. **Nie wypełniaj rejestru z góry.** Pozwól, by rósł w miarę przetwarzania dokumentów — to szybsze i obarczone mniejszym ryzykiem błędu.
2. **Przy pierwszej fakturze od nowego dostawcy** sprawdź, czy dane z Białej Listy są kompletne (IBAN, adres) — uzupełnij brakujące pola ręcznie.
3. **Dla płatności ≥ 15 000 zł** upewnij się, że IBAN w rejestrze kontrahentów zgadza się z wykazem — zobacz <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista">biała lista</FeatureRef>.
4. **Dla kontrahentów UE** wprowadź NIP z prefiksem kraju (`DE…`, `FR…`) i zweryfikuj przez VIES — wynik ma znaczenie dla <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/wnt-wdt">WNT/WDT</FeatureRef>.

## Powiązane [#powiązane]

* <FeatureRef slug="dokumenty">dokumenty</FeatureRef> — parser tworzy/łączy kontrahentów automatycznie.
* <FeatureRef slug="faktury">faktury</FeatureRef> — nabywca wystawianej faktury pobierany jest z rejestru.
* <FeatureRef slug="transakcje">transakcje</FeatureRef> — każda transakcja jest powiązana z kontrahentem.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/biala-lista">ustawa o VAT — Biała Lista</FeatureRef>.
* <FeatureRef slug="/docs/zgodnosc-z-prawem/ustawa-o-vat/vat-ue">ustawa o VAT — VAT-UE</FeatureRef>.


---

# Polityka rachunkowości
URL: https://numifyai.com/docs/korzystanie-z-numify/accounting-policy
Description: Generator szablonu polityki rachunkowości na podstawie ustawień spółki (rok obrotowy, metody wyceny, VAT, CIT, plan kont). Szablon wymaga przeglądu i zatwierdzenia przez zarząd — nie jest gotowym dokumentem.
Review status: numify-source
Updated: 2026-04-17



**Polityka rachunkowości** to obowiązkowa dokumentacja opisująca, jak
spółka prowadzi księgi — jaki stosuje rok obrotowy, metody wyceny,
plan kont i zasady ochrony danych. Numify generuje **szablon** tego
dokumentu na podstawie ustawień spółki.

<ComplianceDisclaimer />

{/* SCREENSHOT: ekran /accounting-policy — podgląd HTML dokumentu w iframe z przyciskami Drukuj i Pobierz */}

## Honest framing — co Numify robi, a czego nie [#honest-framing--co-numify-robi-a-czego-nie]

Generator polityki:

* ✅ Składa **szablon w języku polskim** na podstawie ustawień spółki (nazwa, NIP, adres, rok obrotowy, status VAT, stawka CIT, liczba kont w planie, ewidencja środków trwałych).
* ✅ Odwołuje się do odpowiednich artykułów UoR.
* ❌ **Nie zastępuje przeglądu i zatwierdzenia przez zarząd** — to obowiązek kierownika jednostki zgodnie z <LegalRef act="UoR" art="10" paragraph="2" />.
* ❌ **Nie uwzględnia specyfiki działalności spółki** (branża, umowy leasingu, rezerwy, instrumenty finansowe, działalność zagraniczna) — wymaga dostosowania.
* ❌ **Nie jest poradą prawną ani podatkową** — w niejednoznacznych obszarach skonsultuj się z księgowym lub doradcą podatkowym.

Szablon jest **punktem wyjścia**, nie gotowym dokumentem.

## Po co to w ogóle [#po-co-to-w-ogóle]

<LegalRef act="UoR" art="10" paragraph="1" /> wymaga, aby każda
jednostka posiadała **pisemną dokumentację polityki rachunkowości** w
języku polskim. Obejmuje ona co najmniej:

1. **Określenie roku obrotowego** i wchodzących w jego skład okresów sprawozdawczych.
2. **Metody wyceny aktywów i pasywów** oraz ustalania wyniku finansowego.
3. **Sposób prowadzenia ksiąg rachunkowych**, w tym:
   * zakładowy plan kont (wykaz kont księgi głównej, zasady klasyfikacji, powiązania z księgami pomocniczymi),
   * wykaz ksiąg rachunkowych i zbiorów danych,
   * opis systemu informatycznego (programy, algorytmy, ochrona danych).
4. **System ochrony danych i ich zbiorów** — dowodów księgowych, ksiąg i innych dokumentów.

Politykę ustala i aktualizuje **kierownik jednostki** w formie
pisemnej (<LegalRef act="UoR" art="10" paragraph="2" />). W spółce
z o.o. to zarząd — uchwałą.

## Co zawiera szablon generowany przez Numify [#co-zawiera-szablon-generowany-przez-numify]

<ServiceRef path="src/lib/services/accounting-policy.ts" tests="27" /> wywołuje
funkcję `generateAccountingPolicy(companyId)`, która zwraca gotowy
dokument HTML. Zawartość obejmuje:

| Sekcja               | Skąd dane                         | Elementy                                                                                     |
| -------------------- | --------------------------------- | -------------------------------------------------------------------------------------------- |
| Nagłówek             | `companies`                       | Nazwa, NIP, adres, data wygenerowania                                                        |
| Rok obrotowy         | `fiscalYearStartMonth`            | Miesiąc rozpoczęcia roku obrotowego, długość, okresy sprawozdawcze                           |
| Metody wyceny        | KSR + UoR rozdz. 4                | Środki trwałe, zapasy (FIFO/średnia ważona), rozrachunki, waluty obce                        |
| Plan kont            | `chartAccounts` (liczba)          | Odwołanie do zakładowego planu kont spółki (zobacz <FeatureRef slug="chart-of-accounts" />)  |
| VAT                  | `vatStatus`, `vatFilingFrequency` | Czynny VAT / zwolniony, miesięcznie / kwartalnie, deklaracje JPK\_V7                         |
| CIT                  | `citRate`                         | 19% / 9% (mały podatnik) / estoński CIT                                                      |
| Środki trwałe        | `fixedAssets`                     | Metody amortyzacji (patrz <FeatureRef slug="fixed-assets" />), próg jednorazowej amortyzacji |
| System informatyczny | stałe                             | Opis Numify jako systemu prowadzenia ksiąg (zbiory danych, ochrona, wersja)                  |
| Ochrona danych       | stałe                             | Kopie zapasowe, szyfrowanie, dostęp                                                          |

Szablon odwołuje się do konkretnych artykułów UoR dla każdej sekcji —
dzięki temu rewizor lub księgowy może łatwo zweryfikować zgodność z
prawem.

## Workflow — od szablonu do zatwierdzonej polityki [#workflow--od-szablonu-do-zatwierdzonej-polityki]

Rekomendowany proces:

1. **Ustaw prawidłowo dane spółki** — szczególnie `fiscalYearStartMonth`, `vatStatus`, `citRate`. Ustawienia te wpływają bezpośrednio na treść szablonu. Patrz <FeatureRef slug="fiscal-periods" /> i (wkrótce) `settings`.
2. **Wygeneruj szablon** — otwórz `/accounting-policy`. Numify pobierze dokument z `/api/financial-reports/accounting-policy`.
3. **Przejrzyj i dostosuj** — pobierz jako HTML (przycisk „Pobierz"), otwórz w edytorze tekstu, dopisz sekcje specyficzne dla spółki (leasingi, kredyty, rezerwy, instrumenty finansowe, konsolidacja jeśli dotyczy).
4. **Zatwierdzenie przez zarząd** — uchwała zarządu zatwierdzająca politykę na dany rok obrotowy. Uchwała + dokument polityki to komplet dokumentacji.
5. **Archiwizacja** — przechowaj podpisaną uchwałę i dokument polityki przez okres wymagany UoR (co najmniej 5 lat po roku obrotowym, którego dotyczą).

## Przyciski na ekranie `/accounting-policy` [#przyciski-na-ekranie-accounting-policy]

* **Drukuj** — wywołuje `window.print()` w iframe z dokumentem; można zapisać do PDF przez systemową drukarkę.
* **Pobierz** — ściąga plik `polityka-rachunkowosci.html`. Format HTML ułatwia edycję (każdy edytor tekstu otwiera HTML) i konwersję do PDF.

Generator nie przechowuje wersji historycznych — pobrany plik HTML to
**snapshot na moment wygenerowania**. Wersjonowanie leży po stronie
kierownika jednostki (np. dopisanie daty uchwały do nazwy pliku).

## Zmiana polityki w trakcie roku [#zmiana-polityki-w-trakcie-roku]

Politykę stosuje się w sposób ciągły (<LegalRef act="UoR" art="5" paragraph="1" />).
Zmiana w trakcie roku obrotowego jest dopuszczalna, ale wymaga:

* **uzasadnienia** (np. zmiana prawa, nowa działalność, błąd w poprzedniej polityce),
* **opisu skutków** zmiany w informacji dodatkowej do sprawozdania finansowego,
* **stosowania nowej polityki z mocą wsteczną** od początku roku obrotowego (jeśli dotyczy wyceny) — albo prospektywnie, zależnie od charakteru zmiany.

Numify nie wspiera automatycznej rewaluacji sald według nowej polityki
— po zmianie wymaga ręcznej korekty zapisów przez księgowego.

## Krajowe standardy rachunkowości (KSR) [#krajowe-standardy-rachunkowości-ksr]

<LegalRef act="UoR" art="10" paragraph="3" /> dopuszcza stosowanie
KSR w sprawach nieuregulowanych ustawą. Szablon Numify odwołuje się do
najczęściej stosowanych standardów:

* **KSR 7** — zmiany zasad rachunkowości, błędy lat ubiegłych,
* **KSR 11** — środki trwałe (patrz <FeatureRef slug="fixed-assets" />),
* **KSR 13** — koszty wytworzenia.

Spółka może też zadeklarować stosowanie MSR (Międzynarodowych
Standardów Rachunkowości) — wymaga to uchwały organu zatwierdzającego
(<LegalRef act="UoR" art="45" paragraph="1" />) i dla zwykłej spółki
z o.o. jest rzadkie.

## Powiązania z innymi funkcjami [#powiązania-z-innymi-funkcjami]

* <FeatureRef slug="chart-of-accounts">Plan kont</FeatureRef> — szablon odwołuje się do zakładowego planu kont spółki.
* <FeatureRef slug="fiscal-periods">Okresy fiskalne</FeatureRef> — rok obrotowy z polityki wyznacza strukturę okresów.
* <FeatureRef slug="opening-balance">Bilans otwarcia</FeatureRef> — wycena pozycji BO zależy od metod z polityki (np. kursy walut, amortyzacja).
* <FeatureRef slug="fixed-assets">Środki trwałe</FeatureRef> — metody i stawki amortyzacji opisane w polityce.