Jak uniknąć podwójnego opodatkowania przy awarii KSeF?

Co się dzieje z VAT-em, gdy KSeF leży

Mechanizm powstania podwójnego obciążenia podatkowego wynika z desynchronizacji lokalnych systemów finansowo-księgowych z centralnym repozytorium Ministerstwa Finansów. Powszechnym mitem jest założenie, że system centralny automatycznie zweryfikuje i wyeliminuje powielone rekordy przesłane po awarii. Przykładowo, firma X sp. z o.o. wystawiła 120 faktur offline w dniach 3–5 marca 2026 r. z powodu przerwy technicznej na bramce Ministerstwa Finansów. Po przywróceniu sprawności systemu 6 marca, faktury zostały przesłane do KSeF, a 7 marca fiskus pobrał dane do weryfikacji. W efekcie w pozycji 20 deklaracji VAT-7 za marzec mogą pojawić się dwa zestawy dokumentów, jeśli system ERP błędnie zaklasyfikuje fakturę offline jako odrębny byt od faktury ustrukturyzowanej z nadanym numerem identyfikacyjnym. Stosowanie kodu procedury 17 wymaga precyzyjnego przypisania statusu do każdego dokumentu.

Należy zauważyć, że KSeF przechowuje faktury przez okres 10 lat, jednak mechanizm ten nie obejmuje automatycznego kasowania danych wysłanych w trybie offline po ich późniejszym uploadzie, jeśli numery referencyjne nie są identyczne. Duplikaty są zazwyczaj wykrywane dopiero na etapie kontroli skarbowej lub weryfikacji krzyżowej JPK, co wiąże się z koniecznością zapłaty zaległości wraz z odsetkami za zwłokę. Poniższa tabela prezentuje przykładowy przebieg zdarzeń prowadzący do wystąpienia błędu w rozliczeniach fikcyjnej firmy X sp. z o.o.

W celu szybkiej identyfikacji potencjalnych duplikatów w systemach ERP, zaleca się przeprowadzenie weryfikacji bazy danych przy użyciu zapytania SQL. Skrypt ten pozwala na wykrycie powtarzających się numerów faktur w tabeli przeznaczonej do raportowania JPK. Wykrycie wyników większych od zera jednoznacznie wskazuje na błąd, który musi zostać naprawiony przed zatwierdzeniem deklaracji miesięcznej lub kwartalnej.

SELECT numer_faktury, COUNT() FROM jpk_v7_positions GROUP BY numer_faktury HAVING COUNT()>1;

Dla zachowania pełnej zgodności z przepisami, wskazane jest wykonanie eksportu plików XML z trybu offline niezwłocznie po przywróceniu dostępności systemu i porównanie ich z własną bazą rekordów. Samodzielna weryfikacja JPK_V7 przed wysyłką stanowi kluczowy element kontroli wewnętrznej, minimalizujący ryzyko sporu z organami administracji skarbowej.

Procedura SAFE: jak zapobiec podwójnemu VAT w 4 krokach

Zapewnienie integralności danych w okresie awarii Krajowego Systemu e-Faktur wymaga wdrożenia ustrukturyzowanej procedury SAFE (Secure Automated Factoring Environment). Pierwszym krokiem jest precyzyjne oznaczanie dokumentów wygenerowanych poza systemem. W polu KSeF_ReferenceNumber wpisz prefix OFF_2026_ przed właściwym numerem faktury. System ERP większości podmiotów gospodarczych przyjmie takie oznaczenie bez konieczności modyfikacji schematu XSD, co ułatwia późniejszą filtrację dokumentów.

Drugi etap procedury koncentruje się na blokadzie niekontrolowanego przesyłu danych. W systemie SAP przejdź do transakcji SPRO, a następnie wybierz ścieżkę: Logistyka → KSeF → Auto Upload. Odznacz parametr 'Active', zapisz zmiany i wyjdź z ustawień. Działanie to zapobiega masowemu wysyłaniu faktur, które mogłyby zostać zdublowane w bazie danych KSeF po nagłym przywróceniu komunikacji z serwerami rządowymi. Przechowywanie zrzutu ekranu z odznaczonego modułu auto-uploadu stanowi istotny dowód w procesie compliance.

Trzeci krok to selektywny upload brakujących dokumentów, realizujący logikę trójki semantycznej: Upload-brak-duplikat. Podczas generowania pliku zbiorczego do wysyłki, system musi zostać zaprogramowany tak, aby identyfikował prefiksy offline. Jeśli numer zaczyna się od OFF_2026_, pomijasz go w pliku upload.xml, o ile faktura została już wprowadzona do obrotu prawnego w formie wizualizacji z kodem QR. Poprawna realizacja tego etapu gwarantuje, że każda transakcja zostanie ujęta w systemie MF dokładnie jeden raz.

Czwarty i ostatni krok to terminowe złożenie ewentualnej korekty deklaracji. Korektę JPK_V7 należy złożyć do 25. dnia miesiąca następującego po wystąpieniu awarii, co pozwala na uniknięcie odsetek za zwłokę. W polu uzasadnienia korekty należy wpisać: 'Kod przyczyny korekty: 1 – błąd systemowy'. Według danych z 2025 r., systemy SAP, Comarch XL oraz Insert Raks obsługują już natywnie pole ReferenceNumber po instalacji aktualizacji systemowych, co znacząco automatyzuje powyższy proces.

Checklista dla prezesa: 7 punktów na wypadek blackoutu KSeF

Zarządzanie ryzykiem na poziomie zarządu wymaga świadomości kosztów wynikających z błędów w raportowaniu VAT. Każdy dzień zwłoki z korektą uchybień poawaryjnych generuje odsetki w wysokości 8% w skali roku od nadwyżki podatku należnego. Dla przedsiębiorstwa o miesięcznym obrocie rzędu 1 mln zł, błąd skutkujący podwójnym ujęciem podatku oznacza koszt rzędu 219 zł dziennie samych odsetek, nie licząc potencjalnych sankcji karnoskarbowych.

1. Dyspozycja wstrzymania automatycznego uploadu – podpisuje CFO.
2. Uruchomienie procedury wystawiania faktur offline z kodem QR – kosztuje 0 zł (w ramach istniejącego systemu).
3. Powołanie zespołu ds. weryfikacji integralności plików XML – termin: 2 godziny od stwierdzenia awarii.
4. Zatwierdzenie tymczasowego schematu numeracji dokumentów z prefiksem technicznym.
5. Monitoring komunikatów Ministerstwa Finansów o statusie HTTP 503 – odpowiada dział IT.
6. Weryfikacja poprawności JPK_V7 przed zatwierdzeniem wysyłki do 25. dnia miesiąca.
7. Archiwizacja logów systemowych jako dowodu niedostępności platformy – termin przechowywania: 6 lat.

Od 1 stycznia 2027 r., po zakończeniu okresu przejściowego dla najmniejszych podatników, fiskus zyska uprawnienie do nakładania kar pieniężnych do 100% kwoty VAT błędnie zadeklarowanego, zgodnie z art. 112f ustawy o VAT. Poniższa tabela przedstawia analizę ryzyka finansowego w zależności od podjętych działań naprawczych, bazując na wytycznych Rządowego Centrum Legislacji.

Warto podkreślić, że czynny żal złożony po 25. dniu miesiąca chroni jedynie przed odpowiedzialnością karną skarbową, natomiast nie zwalnia podatnika z obowiązku zapłaty odsetek. W związku z tym, każda firma powinna zdefiniować i przetestować procedury postępowania na wypadek awarii, zamieszczając stosowną checklistę w wewnętrznej sieci intranet w formacie PDF.

FAQ – najczęstsze pytania po awarii KSeF

Przygotowanie organizacji do obsługi sytuacji kryzysowych w KSeF powinno obejmować regularne testy generowanych plików XML, zarówno we własnym środowisku walidacyjnym, jak i w piaskownicy Ministerstwa Finansów. Zapewnienie ciągłości operacyjnej przy jednoczesnym zachowaniu dyscypliny podatkowej jest możliwe jedynie poprzez ścisłą współpracę działów IT, księgowości oraz zarządu.