Korekta, która cofa samą siebie. Cicha pułapka KSeF, o której nikt nie mówi

Korekty w KSeF na schemacie FA(3): dlaczego to trudniejsze, niż obsługuje większość programów

Od 1 lutego 2026 r. obowiązującym wzorem faktury ustrukturyzowanej jest struktura logiczna FA(3), która zastąpiła FA(2). Najwięksi podatnicy weszli w obowiązkowy KSeF właśnie tego dnia, pozostali dołączyli 1 kwietnia 2026 r. I choć dużo mówiło się o tym, że nowy system uprości życie, akurat w obszarze korekt stało się odwrotnie. Zniknęły dwa narzędzia, do których przez lata wszyscy przywykli: nota korygująca, czyli uchylony art. 106k ustawy o VAT, oraz możliwość anulowania faktury.

Raz wystawionej e-faktury nie da się już ani edytować, ani usunąć, ani cofnąć. Jedynym sposobem na naprawienie czegokolwiek, łącznie z drobnym błędem formalnym, jest faktura korygująca wystawiona przez sprzedawcę. To z pozoru niewinne przesunięcie odpowiedzialności otwiera w praktyce całą sieć zależności, których większość programów fakturowych po prostu nie ogarnia.

Bo KSeF razem ze schematem FA(3) pozwala na naprawdę dużo. Korekty łańcuchowe, korekty danych formalnych z wyraźnym rozdzieleniem stanu sprzed zmiany i po zmianie, korekty zbiorcze obejmujące dziesiątki tysięcy faktur, korekty rozbudowanej sekcji podmiotów trzecich. Kłopot polega na tym, że typowy program z rynku obsługuje zwykle tylko najprostszy scenariusz, czyli zmianę kwoty albo stawki VAT, a całą resztę albo upraszcza, albo generuje z błędnych danych. Rozłóżmy to na czynniki pierwsze.

Co właściwie zmienił schemat FA(3)

FA(3) to dokument XML o ściśle ułożonej hierarchii, opisany w pliku XSD opublikowanym przez Ministerstwo Finansów w Centralnym Repozytorium Wzorów Dokumentów. Pełną dokumentację i wzór znajdziesz też na rządowej stronie poświęconej strukturze logicznej FA(3). Zasada jest tu nieubłagana. Jeśli schemat przewiduje konkretne pole na daną informację, musi się ona znaleźć dokładnie w tym miejscu. Nie ma uniwersalnego pola uwag, do którego dałoby się wrzucić wszystko, co nie pasuje gdzie indziej.

Co nowego względem FA(2) warto zapamiętać? Pojawiły się załączniki strukturalne, dzięki którym faktura i załącznik jadą w jednym pliku XML (maksymalnie 3 MB, wysyłka wyłącznie w trybie wsadowym, po wcześniejszym zgłoszeniu w e-Urzędzie Skarbowym). Doszedł nowy typ kontrahenta, czyli pracownik, który porządkuje obsługę wydatków służbowych. Jest identyfikator płatności IPKSeF, pozwalający powiązać konkretną wpłatę z fakturą, na przykład przy bramkach płatności online. Lepiej obsłużono grupy VAT, jednostki samorządu terytorialnego oraz podmioty upoważnione do wystawiania faktur. Doszły też drobiazgi, które w praktyce cieszą: nazwa towaru wydłużona z 256 do 512 znaków, numer rachunku do 34 znaków, termin płatności podawany jako liczba dni. Wszystko to opisuje szczegółowo broszura informacyjna MF dotycząca FA(3).

Dla korekt kluczowy jest jeden szczegół. Faktura korygująca wystawiana po 1 lutego 2026 r. musi być w FA(3), nawet jeśli faktura pierwotna powstała jeszcze w FA(2) albo FA(1). To pierwsze miejsce, w którym programy się potykają, bo albo korygują w starym schemacie, albo nie potrafią przełożyć starych danych na nową strukturę.

Anatomia faktury korygującej w FA(3)

W węźle Fa korekta opisywana jest kilkoma polami, które razem decydują o jej poprawności i o tym, w którym okresie wpłynie na VAT. Warto je poznać po kolei, bo każde kryje osobną pułapkę.

RodzajFaktury, czyli jaki to typ korekty

Do wyboru są trzy znaczniki. KOR oznacza standardową korektę faktury podstawowej, a także uproszczonej, bo schemat FA(3) nie zna osobnego typu KOR_UPR i korektę faktury uproszczonej wystawia się właśnie jako zwykłą KOR. KOR_ZAL dotyczy korekty faktury zaliczkowej. KOR_ROZ obejmuje korektę faktury rozliczeniowej, czyli końcowej. Ten wybór nie jest kosmetyką, bo determinuje, które pozostałe pola struktury trzeba wypełnić. Pomyłka tutaj prowadzi na zupełnie inną gałąź walidacji.

TypKorekty, czyli moment ujęcia w VAT

To pole mówi, w którym okresie korekta wpływa na rozliczenie podatku. Ma trzy dopuszczalne wartości i to właśnie tutaj rodzi się najwięcej cichych błędów.

• Wartość 1 oznacza korektę w dacie ujęcia faktury pierwotnej, czyli skutek wstecz. Stosuje się ją przy błędzie, który istniał od samego początku, na przykład przy pomyłce rachunkowej. Mówiąc wprost: przyczyna była już w chwili wystawienia faktury pierwotnej.
• Wartość 2 oznacza korektę w dacie wystawienia faktury korygującej, czyli skutek na bieżąco. To najczęstszy przypadek, bo obejmuje rabaty, zwroty, obniżki i nowe zdarzenia gospodarcze, które powstały już po fakturze pierwotnej. Właśnie dlatego mnóstwo programów ma tę wartość zaszytą na stałe, i to jest źródło problemu, bo dla błędu pierwotnego powinno być 1, a nie 2.
• Wartość 3 oznacza korektę skutkującą w innej dacie, w tym sytuacje mieszane oraz takie, gdzie różne pozycje tej samej korekty mają różny moment ujęcia. Klasyczny przykład to jedna korekta, która jednocześnie poprawia błąd rachunkowy (do ujęcia wstecz) i dokumentuje zwrot części towaru (do ujęcia na bieżąco). Wtedy dla całości podaje się 3. Tu mieszczą się również korekty rozliczane według przepisów szczególnych, na przykład przy transakcjach wewnątrzwspólnotowych, eksporcie czy imporcie usług, a także część korekt in plus.

W praktyce wartość 3 bywa też wyborem awaryjnym, gdy wystawca nie jest pewny, która opcja jest właściwa. Już samo to pokazuje, jak nieoczywista potrafi być kwalifikacja momentu ujęcia. Program, który na każdą korektę wpisuje 2, w wielu przypadkach po prostu zafałszowuje okres rozliczeniowy VAT.

DaneFaKorygowanej, czyli do której faktury się odnosimy

Tu zaczyna się sedno sprawy. Element DaneFaKorygowanej identyfikuje korygowaną fakturę. Składają się na niego data wystawienia (DataWystFaKorygowanej), numer nadany przez podatnika (NrFaKorygowanej), znacznik i numer KSeF faktury korygowanej (NrKSeF, NrKSeFFaKorygowanej) oraz znacznik faktury wystawionej poza systemem. Dla dokumentów spoza KSeF służy osobny węzeł DaneFaKorygowanejPozaKSeF. Co istotne, ten element może wystąpić aż 50 000 razy, i to właśnie mechanizm korekt zbiorczych, do którego jeszcze wrócimy.

Podmiot1K i Podmiot2K, czyli stan sprzed zmiany

FA(3) udostępnia osobne sekcje na dane stron takie, jakie były na fakturze korygowanej. Podmiot1K przechowuje dane sprzedawcy z faktury korygowanej, na przykład te sprzed fuzji albo zmiany adresu, podczas gdy dane aktualne trafiają do Podmiot1. Analogicznie Podmiot2K przechowuje dane nabywcy z faktury korygowanej, a poprawne i aktualne idą do Podmiot2. Ta druga sekcja może wystąpić nawet 101 razy, więc da się poprawić dane wielu kontrahentów, jeśli pierwotna faktura obejmowała kilku nabywców. Jest jednak warunek: numer NIP w Podmiot2K musi być taki sam jak w Podmiot2 lub Podmiot3, ponieważ samego NIP nabywcy nie da się poprawić zwykłą korektą.

I to jest dokładnie ta część schematu, którą większość programów albo pomija, albo wypełnia automatem z bieżącej kartoteki kontrahenta zamiast z danych historycznych faktury korygowanej. Tu właśnie rodzi się główny kłopot.

Problem łańcucha korekt, czyli dlaczego druga korekta cofa pierwszą

Najpoważniejsza pułapka FA(3) nie wynika z samego schematu, tylko ze zderzenia przepisów z tym, jak programy budują dokumenty.

Zacznijmy od strony prawnej. Zgodnie z interpretacją indywidualną Dyrektora Krajowej Informacji Skarbowej o sygnaturze 0114-KDIP1-2.4012.360.2025.1.RST z 15 lipca 2025 r. oraz z art. 106j ust. 2 ustawy o VAT, fakturę korygującą wystawia się zawsze do faktury pierwotnej, a nigdy do poprzedniej korekty. Nie istnieje coś takiego jak korekta korekty. Niezależnie od tego, czy jest to pierwsza, czy piąta korekta tej samej transakcji, w elemencie DaneFaKorygowanej podaje się numer KSeF faktury pierwotnej, a nie numery wcześniejszych korekt. Co ważne, KSeF w żaden sposób nie ogranicza liczby korekt do jednej faktury. Pełną treść tej i innych interpretacji można sprawdzić w rządowej bazie EUREKA prowadzonej przez Ministerstwo Finansów.

I tu właśnie jest pies pogrzebany. Skoro każda kolejna korekta odwołuje się do faktury pierwotnej, to wiele programów generuje jej zawartość z danych źródłowych tej pierwotnej faktury. A jeśli wcześniejsza korekta zmieniła coś, co nie wpływa na VAT, na przykład nazwę nabywcy albo nazwę ulicy w jego adresie, to ta zmiana żyje wyłącznie w pierwszej korekcie. Druga korekta, zbudowana na danych pierwotnych, znów wstawi starą, błędną ulicę.

Prześledźmy to na prostym przykładzie. Faktura pierwotna wskazuje nabywcę z adresem „ul. Kwiatowa 5”. Pierwsza korekta, czysto formalna, poprawia adres na „ul. Kwiatowa 15”. W sekcji Podmiot2K widnieje stan z faktury pierwotnej, czyli „Kwiatowa 5”, a w sekcji Podmiot2 stan poprawny, czyli „Kwiatowa 15”. Na ten moment wszystko gra. Miesiąc później udzielamy rabatu i wystawiamy drugą korektę, tym razem kwotową. Program generuje ją z faktury pierwotnej, więc do Podmiot2 i Podmiot2K znów podstawia „Kwiatową 5”. Faktyczny, aktualny stan dokumentacji rozjeżdża się z tym, co już raz poprawiliśmy.

W sensie ściśle prawnym każda z tych korekt odnosi się do faktury pierwotnej i sama w sobie jest poprawna. Ale dla odbiorcy i dla obrazu całej transakcji powstaje bałagan, bo w obiegu krążą dwa różne adresy, a najnowszy dokument pokazuje ten błędny. Dobrze zaprojektowany system powinien utrzymywać bieżący, skumulowany stan faktury, czyli efekt wszystkich dotychczasowych korekt, i przy wystawianiu kolejnej przenosić do niej już naniesione zmiany formalne, mimo że referencja formalnie wskazuje fakturę pierwotną. Większość programów tego nie robi i traktuje każdą korektę jak niezależny strzał z danych źródłowych. Dokładnie to samo dotyczy Podmiot1K, bo jeśli sprzedawca w międzyczasie zmienił dane, a kolejne korekty powstają z pierwotnego stanu, łatwo o rozjazd między rejestrem a ostatnią korektą.

Korekta danych formalnych a korekta do zera, czyli łatwo pomylić tryb

KSeF różnicuje sposób naprawy w zależności od tego, czego dotyczy błąd, i to różnicowanie bywa źle wdrożone w oprogramowaniu.

Przy zmianie lub błędzie danych opisowych, gdy NIP jest poprawny, a chodzi o nazwę albo adres, postępujemy spokojnie. Dla sprzedawcy aktualne dane idą do Podmiot1, a stan z faktury korygowanej do Podmiot1K. Dla nabywcy poprawne dane trafiają do Podmiot2, a stan z faktury korygowanej do Podmiot2K. To zwykła korekta danych, bez wpływu na VAT.

Inaczej jest przy błędnym NIP nabywcy. Tu standardowa korekta danych nie jest dopuszczalna, bo KSeF nie pozwala podmienić NIP w ramach tej samej faktury. Trzeba wystawić korektę do zera do dokumentu z błędnym NIP, czyli wyzerować wartości pierwotnej faktury, a następnie wystawić nową fakturę pierwotną z prawidłowym NIP. To procedura dwukrokowa, której wiele programów nie odróżnia od zwykłej korekty danych. A konsekwencje bywają poważne, bo błędna obsługa może doprowadzić do tego, że organ uzna dokument za drugą fakturę i zażąda zapłaty VAT po raz drugi. Rozróżnienie „to błąd opisowy, więc koryguję” kontra „to NIP, więc zeruję i wystawiam nową fakturę” musi być świadomą decyzją wystawcy, bo KSeF nie zdejmuje z nikogo obowiązku należytej staranności.

Podmiot3, czyli tam, gdzie robi się naprawdę gęsto

Sekcja Podmiot3 reprezentuje wszystkich pozostałych uczestników faktury i może wystąpić nawet 100 razy w jednym dokumencie. Struktura jest zbliżona do Podmiot2, z dodatkowym polem IDWew, łączącym NIP z wewnętrznym identyfikatorem, oraz z polem Rola. Przewidziano jedenaście ról, a wśród nich faktora nabywającego wierzytelność w faktoringu, odbiorcę będącego zakładem lub oddziałem z własnym IDWew, podmiot pierwotny przy sukcesji i połączeniach spółek, dodatkowego nabywcę z możliwością podania procentowego udziału, wystawcę faktury w imieniu podatnika, dokonującego płatności w miejsce nabywcy, jednostkę podrzędną JST w roli wystawcy albo odbiorcy oraz członka grupy VAT również w roli wystawcy albo odbiorcy. Gdy żadna z tych ról nie pasuje, zamiast pola Rola wypełnia się RolaInna wraz z OpisRoli, co pozwala obsłużyć umowy trójstronne, barter czy złożone refakturowania. Sposób wypełniania tej sekcji opisuje wspomniana wcześniej broszura MF oraz rządowa strona o fakturze ustrukturyzowanej.

Skala komplikacji rośnie lawinowo, gdy podmiotów trzecich jest wielu, na przykład kilku współfaktorów albo kilku dodatkowych nabywców z różnymi udziałami, i do tego trzeba ich skorygować. Pojawia się tu kilka konkretnych problemów.

Po pierwsze, korekta przy wielu Podmiot3. Nie ma już jednego, prostego odbiorcy, tylko kilkudziesięciu uczestników, każdy z własną rolą i ewentualnym udziałem procentowym. Program musi wiedzieć, którego z nich koryguje i jak odwzorować stan sprzed zmiany. Większość systemów obsługuje co najwyżej jeden albo dwa podmioty trzecie.

Po drugie, wcześniejsze korekty Podmiot3. Wraca tu problem łańcucha. Jeśli udział procentowy dodatkowego nabywcy albo IDWew oddziału był już raz korygowany, kolejna korekta generowana z faktury pierwotnej znów może podstawić nieaktualne dane.

Po trzecie, zmienna interpretacja, jak w ogóle korygować Podmiot3. Początkowo Dyrektor KIS stał na stanowisku restrykcyjnym i twierdził, że każdy błąd w danych identyfikacyjnych podmiotów na fakturze, w tym w Podmiot3, wymaga korekty do zera i nowej faktury. Po skardze podatnika stanowisko złagodzono. Tryb do zera pozostaje zasadny przy błędach dotyczących nabywcy, czyli Podmiot2, natomiast dla danych odbiorcy w Podmiot3 dopuszczono podejście mniej formalistyczne. Problem w tym, że to przesuwa cały ciężar na prawidłowe rozróżnienie, czy dany podmiot jest nabywcą, czy odbiorcą. Błędna ocena oznacza zastosowanie niewłaściwego trybu korekty i realne ryzyko w rozliczeniu VAT. Treść obu interpretacji znajdziesz w bazie EUREKA.

Szczególnie wrażliwe są jednostki samorządu terytorialnego. Przy błędzie w oznaczeniu odbiorcy będącego jednostką podrzędną JST organ wskazał konieczność korekty do zera i nowej faktury, rozliczanej wstecz, ponieważ przyczyna istniała już w chwili wystawienia. Co ciekawe, sam organ przyznał, że taki sposób postępowania wynika z uwarunkowań systemowych KSeF, a nie wprost z przepisu. To odwraca dotychczasową logikę, w której to przepis, a nie możliwości oprogramowania, wyznaczał sposób działania podatnika. Krótko mówiąc, Podmiot3 to dziś prawdopodobnie najbardziej niedoceniany obszar wdrożeń: bogaty w schemacie, ubogi w implementacjach.

Korekty zbiorcze i masowe, czyli wielka możliwość i wielka pułapka

FA(3) dopuszcza fakturę korygującą obejmującą wiele faktur pierwotnych. Element DaneFaKorygowanej może powtórzyć się aż 50 000 razy, a w korekcie zbiorczej trzeba wskazać osobno dane każdej korygowanej faktury, czyli datę, numer oraz, tam gdzie dotyczy, numer KSeF. Można przy tym mieszać faktury z KSeF i spoza systemu. Dla rabatów okresowych obejmujących wszystkie dostawy z danego okresu wolno pominąć nazwy i rodzaje towarów, a do określenia okresu służy pole OkresFaKorygowanej, które przyjmuje zarówno zakres dat, jak i opis tekstowy. Korektę zbiorczą da się wystawić zarówno in minus, jak i in plus.

Korzyść jest oczywista, bo zamiast tysięcy dokumentów powstaje jeden. Ale ryzyka rosną proporcjonalnie do skali. Trzeba pamiętać o kilku rzeczach.

• KSeF nie weryfikuje arytmetyki. System sprawdza zgodność ze schematem, ale nie liczy. Przyjmie korektę z błędnie wyliczonym VAT albo z niespójnym podsumowaniem. Przy 50 000 pozycji jeden błąd mapowania mnoży się masowo, więc kontrola matematyczna musi leżeć po stronie wystawcy.
• Każdą fakturę trzeba wymienić z osobna. Element identyfikujący faktury korygowane jest obowiązkowy dla poprawności schematu, więc nie da się skorygować całego okresu bez wyliczenia każdej faktury. To wymaga, żeby program rzetelnie wyciągnął komplet dokumentów źródłowych.
• Łańcuch korekt w skali masowej. Jeśli część faktur w paczce była już wcześniej korygowana, każda z nich i tak musi odwoływać się do swojej faktury pierwotnej, a nie do wcześniejszej korekty. I znów wraca problem aktualności danych formalnych przy generowaniu z danych źródłowych, tyle że pomnożony przez liczbę dokumentów.
• Rozliczenie in minus. Od 1 lutego 2026 r. korektę zmniejszającą rozlicza się w VAT w momencie nadania jej numeru KSeF, bez czekania na potwierdzenie odbioru. To ułatwienie dokumentacyjne nie znosi jednak wymogu posiadania podstawy biznesowej obniżki, czyli uzgodnienia i spełnienia warunków zgodnie z art. 29a ust. 13 ustawy o VAT. Program, który automatyzuje wysyłkę, nie zwalnia z tej oceny.

Dlaczego programy robią tylko podstawy i co z tego wynika

Zbierzmy to w jeden obraz. KSeF na schemacie FA(3) udostępnia bardzo rozbudowany aparat korygowania: trzy typy momentu ujęcia, osobne sekcje stanu sprzed zmiany dla sprzedawcy i nabywcy, do 101 powtórzeń danych nabywcy, do 100 podmiotów trzecich w jedenastu rolach, korekty zbiorcze do 50 000 faktur, a nawet mieszane daty ujęcia w obrębie jednej korekty. To wszystko zostało zaprojektowane pod realną złożoność gospodarczą, czyli faktoring, sukcesje, grupy VAT, JST, rabaty retro i sprzedaż udziałową.

Tymczasem typowe wdrożenie na rynku obsługuje wąski rdzeń: zmianę kwoty, ilości, stawki VAT i ewentualnie korektę do zera. Dzieje się tak, bo te scenariusze pokrywają większość codziennych przypadków i są najprostsze do zmapowania. Cała reszta, czyli Podmiot1K i Podmiot2K z danymi historycznymi, wielu Podmiot3 z rolami, świadomy wybór TypKorekty oraz utrzymywanie skumulowanego stanu faktury między korektami, bywa pomijana, upraszczana albo wypełniana automatem z bieżącej kartoteki.

Skutki dla podatnika są zupełnie konkretne. Korekty formalne, takie jak adres czy nazwa, generowane z danych źródłowych potrafią odbić wcześniejsze poprawki i stworzyć niespójny obieg dokumentów. Zaszyty na stałe TypKorekty o wartości 2 zafałszowuje okres rozliczenia VAT przy błędach pierwotnych, które powinny mieć wartość 1. Mylenie korekty danych z trybem do zera przy NIP grozi rozpoznaniem drugiej faktury i podwójnym VAT. Błędna kwalifikacja, czy mamy do czynienia z nabywcą, czy z odbiorcą przy Podmiot3, prowadzi do niewłaściwego trybu i ryzyka w VAT. A przy korektach masowych brak kontroli arytmetyki po stronie wystawcy mnoży błędy, których system po prostu nie wyłapie.

Lista kontrolna przed wyborem albo wdrożeniem programu

Jeśli oceniasz własny system fakturowy pod kątem korekt w FA(3), sprawdź, czy radzi sobie z poniższymi sytuacjami.

1. Potrafi wystawić korektę w FA(3) do faktury pierwotnej, która powstała jeszcze w FA(2) albo FA(1).
2. Pozwala świadomie ustawić TypKorekty o wartości 1, 2 lub 3, zamiast wpisywać na stałe 2.
3. Utrzymuje skumulowany, bieżący stan faktury i przenosi naniesione wcześniej zmiany formalne do kolejnych korekt, mimo że referencja zawsze wskazuje fakturę pierwotną.
4. Poprawnie wypełnia Podmiot1K i Podmiot2K danymi z faktury korygowanej, a nie z aktualnej kartoteki.
5. Odróżnia korektę danych opisowych od trybu do zera przy błędnym NIP.
6. Obsługuje wiele podmiotów w sekcji Podmiot3 wraz z rolami i ich korektami, w tym udziały procentowe oraz IDWew.
7. Radzi sobie z korektą zbiorczą, czyli z wyliczeniem każdej faktury, mieszaniem dokumentów z KSeF i spoza systemu oraz kontrolą arytmetyki po stronie wystawcy.
8. Prawidłowo kwalifikuje przypadki JST i grup VAT.

Na koniec

Korekty w KSeF tylko z pozoru są łatwiejsze niż dawniej. Zniknęła nota korygująca i anulowanie, a w zamian dostaliśmy jeden, ale za to bardzo bogaty instrument, czyli fakturę korygującą w FA(3), którą przepisy każą zawsze wiązać z fakturą pierwotną, a nie z poprzednią korektą. To prawne wymaganie, zderzone ze sposobem, w jaki programy budują dokumenty z danych źródłowych, tworzy realny problem łańcucha korekt, bo zmiany formalne nie propagują się do kolejnych dokumentów. Dołóżmy do tego rozbudowaną sekcję Podmiot3 z jedenastoma rolami i niejednolitą interpretacją, korekty zbiorcze do 50 000 faktur bez kontroli arytmetyki po stronie systemu oraz konieczność świadomego wyboru momentu ujęcia w VAT. Okazuje się, że podstawowa korekta kwoty, którą obsługuje większość programów, to zaledwie wierzchołek góry lodowej.

KSeF umożliwia bardzo dużo, a to dużo bywa właśnie najbardziej problematyczne. Nie dlatego, że schemat jest wadliwy, tylko dlatego, że rynek oprogramowania w większości zatrzymał się na najprostszym scenariuszu. Świadomość pełnej mapy korekt jest dziś realną przewagą, bo pozwala wybrać narzędzie, które obsłuży prawdziwe przypadki, i w porę wyłapać te, w których trzeba zadziałać ręcznie, zanim zrobi to za nas urząd.

Materiał ma charakter informacyjny i analityczny, nie stanowi porady podatkowej. Stan na czerwiec 2026 r. Interpretacje indywidualne, między innymi 0114-KDIP1-2.4012.360.2025.1.RST oraz 0113-KDIPT1-3.4012.1091.2025, wiążą wyłącznie w sprawach, w których je wydano. Ich pełną treść można sprawdzić w bazie EUREKA, a oficjalną dokumentację schematu na stronie KSeF Ministerstwa Finansów. W konkretnej sytuacji warto potwierdzić kwalifikację z doradcą podatkowym.