Rejestr VAT

Rejestr VAT to dwuczęściowa ewidencja (sprzedaż + zakup) wymagana przez Ustawa o VAT, art. 109 ust. 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.

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

src/lib/services/vat-register.ts tworzy zapis w rejestrze, gdy transakcja przechodzi w stan zweryfikowany. Kluczowe pola:

Idempotencja: jeśli vatEntry dla transakcji już istnieje, funkcja zwraca null i nie tworzy duplikatu.

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 Ustawa o VAT, art. 86 ust. 10 prawo do odliczenia powstaje w okresie powstania obowiązku podatkowego u sprzedawcy; Ustawa o VAT, art. 86 ust. 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 — Ustawa o VAT, art. 86 ust. 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)

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

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 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. biała lista (strona w przygotowaniu).

Dane z rejestru VAT są źródłem dla eksportu JPK_V7M/V7K (generator src/lib/services/jpk-vat-generator.ts). Sam proces wysyłki pliku do Ministerstwa Finansów — zob. poradnik „Jak wysłać JPK_V7" (w przygotowaniu).

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:

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)

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 UoR, art. 25 ust. 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 Ustawa o VAT, art. 86 ust. 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.

Wyłączenia z prawa do odliczenia (art. 88)

Ustawa o VAT, art. 88 ust. 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.

Ustawa o VAT, art. 88 ust. 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

Każdy vatEntry ma odpowiadający mu zapis w dzienniku (journal_entries), utworzony przez src/lib/services/auto-journal.ts15 ✓. Kwoty VAT w rejestrze muszą się uzgadniać z saldami kont VAT w księdze głównej:

• 220 — VAT należny (strona Ma rośnie przy sprzedaży).
• 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 (222 — jeśli istnieje w planie kont).

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

Ustawa o VAT, art. 109 ust. 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.