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?
Co jeśli zapomnę kodu SWIFT?
Czy termin płatności może być wcześniejszy niż data 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