--- title: "Rejestr VAT" 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." url: https://numifyai.com/docs/korzystanie-z-numify/vat-register review_status: internal updated: 2026-04-17 --- **Rejestr VAT** to dwuczęściowa ewidencja (sprzedaż + zakup) wymagana przez . 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. {/* 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] tworzy zapis w rejestrze, gdy transakcja przechodzi w stan zweryfikowany. Kluczowe pola: | Pole | Źródło | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `documentNumber` | `transaction.invoiceNumber` (lub fallback `TXN-`). | | `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 prawo do odliczenia powstaje w okresie powstania obowiązku podatkowego u sprzedawcy; 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** — 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. biała lista (strona w przygotowaniu). Dane z rejestru VAT są źródłem dla eksportu JPK\_V7M/V7K (generator ). Sam proces wysyłki pliku do Ministerstwa Finansów — zob. poradnik „Jak wysłać JPK\_V7" (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 : 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 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] 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. 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 . Kwoty VAT w rejestrze muszą się uzgadniać z saldami kont VAT w księdze głównej: * — VAT należny (strona Ma rośnie przy sprzedaży). * — 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 ( — 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] 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.