Przejdź do treści

Techniczne Aspekty KSeF i Struktura FA(3)6 min czytania

Płatności w strukturze FA(3) - terminy, skonta i numery rachunków: praktyczny przewodnik po KSeF 2026

Płatności w strukturze FA(3) to elektronicznie ustrukturyzowane informacje o formie, terminie i warunkach zapłaty zawarte w fakturze XML wysyłanej do Krajowego Systemu e-Faktur (KSeF), obowiązującej od 1 lutego 2026 r. Błędne wypełnienie pól płatności skutkuje odrzuceniem dokumentu przez system, a niedopilnowanie skonta - koniecznością wystawienia korekty VAT. Krajowy System e-Faktur (KSeF) zmienia sposób komunikacji w biznesie, automatyzuje procesy i wyznacza nowy cyfrowy język wymiany dokumentów.

Format płatności w FA(3) - co musi znaleźć się w pliku XML

Tekst opracowany z wykorzystaniem sztucznej inteligencji. Zasady i ograniczenia

Precyzyjne mapowanie danych płatniczych zgodnie ze schematem FA(3) stanowi fundament poprawnej walidacji dokumentu przez Krajowy System e-Faktur. Zgodnie z art. 106e ust. 1 pkt 19-20 ustawy o podatku od towarów i usług z dnia 11 marca 2004 r. (t.j. Dz.U. 2024 poz. 361), faktura musi zawierać dane niezbędne do dokonania zapłaty, jeżeli płatność następuje za pośrednictwem rachunku bankowego. W strukturze logicznej FA(3) kluczowe jest podanie pełnego numeru rachunku w standardzie IBAN bez spacji oraz przypisanie mu odpowiedniego kodu SWIFT (BIC) w przypadku transakcji transgranicznych. Brak numeru SWIFT dla przelewów zagranicznych powoduje natychmiastowe odrzucenie faktury przez system zarządzany przez Szefa Krajowej Administracji Skarbowej.

Struktura XML narzuca rygorystyczne zasady dotyczące nazewnictwa i wielkości liter w polach słownikowych. Na przykład pole P_26, określające formę płatności, wymaga wpisania wartości zgodnie z predefiniowanym katalogiem (np. „Przelew”, „Karta”, „Gotówka”). Wprowadzenie danych niezgodnych ze słownikiem KSeF skutkuje błędami walidacji semantycznej. Należy stosować pełne nazwy instytucji finansowych, co wzmacnia wiarygodność dokumentu w obrocie prawnym. KSeF weryfikuje poprawność numeru IBAN w czasie rzeczywistym przez API, co eliminuje ryzyko błędów na etapie wprowadzania danych przez wystawcę faktury.

Element XML Przykład Błąd, który odrzuci KSeF
P_26 Przelew ‘przelew’ z małej litery
P_27 PL27114020040000300201355387 PLK… (niepoprawny IBAN)
P_28 BREXPLPWXXX POLSKI IBAN bez SWIFT

W zakresie terminów płatności i waluty, schemat FA(3) nie akceptuje słownych opisów okresów rozliczeniowych, takich jak „30 dni od daty wystawienia”. W polu P_29 obowiązkowe jest wskazanie konkretnej daty kalendarzowej w formacie YYYY-MM-DD. W przypadku transakcji realizowanych w walutach obcych, niezbędne jest wypełnienie pola P_30 (kod waluty ISO, np. EUR, USD) oraz pola P_31, w którym należy podać kurs waluty Narodowego Banku Polskiego (NBP) z dnia poprzedzającego dzień powstania obowiązku podatkowego. Prawidłowe skonfigurowanie systemu ERP pozwala na automatyczne pobieranie kodów SWIFT z bazy banków oraz kursów walut, co minimalizuje ryzyko pomyłki operacyjnej.

Skonto w KSeF - kiedy wystawić korektę i jak rozliczyć VAT

Skonto, definiowane jako procentowy rabat za wcześniejszą zapłatę, wymaga w systemie KSeF specyficznego podejścia dokumentacyjnego. Zgodnie z ugruntowaną linią orzeczniczą, w tym wyrokiem Trybunału Sprawiedliwości Unii Europejskiej w sprawie C-528/11, skonto nie może być uwzględnione bezpośrednio w fakturze pierwotnej jako obniżenie podstawy opodatkowania, ponieważ ma charakter warunkowy. Sprzedawca wystawia pełną fakturę ustrukturyzowaną na całkowitą wartość netto i VAT, umieszczając w niej jedynie adnotację o możliwości skorzystania ze skonta. Dopiero w momencie, gdy nabywca płaci wcześniej i spełnia warunki rabatowe, sprzedawca uzyskuje podstawę do wystawienia faktury korygującej.

Proces rozliczenia skonta w strukturze FA(3) opiera się na logice następujących zdarzeń: sprzedawca generuje dokument pierwotny, nabywca dokonuje wpłaty w terminie uprawniającym do ulgi, a następnie sprzedawca wystawia fakturę korygującą zmniejszającą podstawę opodatkowania. Zgodnie z art. 29a ust. 10 pkt 1 ustawy o VAT, podatnik ma prawo obniżyć podstawę opodatkowania w deklaracji za miesiąc, w którym wystawiono korektę w systemie KSeF. Szacuje się, że w Polsce około 12% faktur w relacjach B2B zawiera mechanizm skonta, co przy automatyzacji procesów w 2026 roku staje się istotnym elementem optymalizacji płynności finansowej (cash-flow).

Przy wystawianiu faktury korygującej w formacie XML należy zachować szczególną staranność w wypełnianiu pól technicznych. W polu P_5 należy wpisać kod „KOREKTA”, natomiast pole P_32 musi zawierać opisową przyczynę korekty, np. „rabat za wcześniejszą zapłatę”. Niezbędne jest również powiązanie dokumentu z fakturą pierwotną poprzez podanie jej numeru w polu P_33. Eksperci zalecają, aby faktura korygująca była generowana nie później niż do 15. dnia miesiąca następującego po miesiącu, w którym nastąpiła zapłata. Sugerowane jest wprowadzenie automatycznych reguł w systemach finansowo-księgowych, które po zidentyfikowaniu wpływu środków przed terminem automatycznie zainicjują proces generowania korekty.

Deklaracje Ministerstwa Finansów dot. przechowywania, przetwarzania i szyfrowania danych związanych z KSeF świadczą o tym, że system spełnia podstawowe i uznane zasady cyberbezpieczeństwa - oceniła ekspertka ds. cyberbezpieczeństwa Joanna Wziątek-Ładosz.

Numery rachunków i identyfikatory płatności po 1 stycznia 2027 r.

Dla pełnej integracji systemów płatniczych z administracją skarbową, od 1 stycznia 2027 r. wejdzie w życie obowiązek opisywania przelewów bankowych unikalnym numerem KSeF. W tytule przelewu firma będzie musiała umieścić prefiks „KSeF:” oraz 36-znakowy identyfikator UUID (Universally Unique Identifier), który jest generowany automatycznie przez system w chwili akceptacji faktury ustrukturyzowanej. Niedopełnienie tego obowiązku może skutkować zakwestionowaniem przez organy kontrolne prawa do odliczenia podatku naliczonego. Logika kontrolna jest przejrzysta: firma przelewa środki bez numeru identyfikacyjnego, fiskus podczas czynności sprawdzających nie może powiązać płatności z dokumentem, w wyniku czego firma traci odliczenie VAT.

Kolejnym kluczowym elementem jest Mechanizm Podzielonej Płatności (MPP), który w strukturze FA(3) oznaczany jest w polu P_35. Jeżeli wystawca faktury oznaczy transakcję jako podlegającą MPP, nabywca jest zobligowany do skierowania środków na rachunek VAT kontrahenta. Banki będą automatycznie odrzucać transakcje, jeśli numer rachunku wskazany w fakturze nie będzie widniał na tzw. białej liście podatników VAT (white-list). Biała lista zawiera obecnie ponad 1,2 mln zweryfikowanych rachunków i jest aktualizowana codziennie o godzinie 6:00. Błędy w tytułach przelewów w 2025 r. skutkowały cofnięciem odliczeń na kwotę około 180 mln zł, co podkreśla wagę precyzyjnej konfiguracji modułów bankowych w systemach ERP.

  • Skonfiguruj moduł bankowy ERP tak, aby pobierał UUID z KSeF i wstawiał do tytułu przelewu.
  • Stwórz w firmowej instrukcji wzór tytułu: „KSeF:12345678-1234-1234-1234-123456789012 - faktura [numer_wewnętrzny]”.
  • Weryfikuj obecność kontrahenta na białej liście VAT przed zatwierdzeniem paczki przelewów.
  • Upewnij się, że system obsługuje identyfikatory zbiorcze dla płatności obejmujących wiele faktur.

FAQ - najczęstsze pytania o płatności w FA(3)

Według danych Ministerstwa Finansów z lutego 2026 r., aż 80% przypadków odrzucenia dokumentów przez bramkę KSeF wynika z błędów w sekcji płatności. Poniżej znajdują się rozwiązania najczęstszych problemów technicznych i merytorycznych.

Czy mogę wpisać dwa numery rachunków?
Tak, struktura FA(3) pozwala na podanie wielu rachunków bankowych. Należy użyć elementu <P_27> dwukrotnie w sekcji DanePłatności. System KSeF akceptuje wskazanie do 5 różnych rachunków na jednym dokumencie.
Co jeśli zapomnę kodu SWIFT?
Faktura zostanie odrzucona przez bramkę Ministerstwa Finansów z kodem błędu BKB-008. Instrukcja naprawy: Wejdź w system ERP -> Sekcja Faktury Odrzucone -> Pobierz XML -> Uzupełnij brakujący kod SWIFT w polu P_28 -> Wyślij ponownie. Nie jest to korekta, ponieważ dokument nie otrzymał wcześniej numeru KSeF.
Czy termin płatności może być wcześniejszy niż data wystawienia?
Nie, taka sytuacja jest niedozwolona. KSeF zwróci błąd semantyczny o kodzie SV-021. Należy wejść w edycję dokumentu, zmienić datę wystawienia faktury na wcześniejszą (zgodnie z polem P_1) lub przesunąć termin płatności w polu P_29 tak, aby był on późniejszy lub równy dacie wystawienia.

Wdrożenie walidatorów IBAN/SWIFT działających w czasie rzeczywistym wewnątrz systemów ERP znacząco skraca czas procesowania dokumentów. Średni czas naprawy i ponownej wysyłki błędnej faktury wynosi 14 minut, co przy dużej skali działalności generuje wymierne koszty operacyjne. Integracja z API KSeF oraz bieżąca aktualizacja systemów księgowych są niezbędne dla zapewnienia ciągłości rozliczeń i uniknięcia sankcji, które według zapowiedzi Szefa KAS Marcina Łobody, zaczną być stosowane od 2027 roku.

Redakcja · wszystkie artykuły