12 najczęstszych błędów walidacji FA(3)

Faktura FA(3) najczęściej wpada na walidacji przez zły namespace, kolejność elementów, brakujące pola, format NIP i dat, nadmiarowe miejsca po przecinku, stawkę w P_12 albo niekompletne Adnotacje. Każdy z 12 błędów poniżej ma przyczynę i poprawkę w XML do skopiowania.

Komunikaty walidacji bywają hermetyczne. Zamiast „brakuje numeru faktury" zobaczysz na przykład Element 'P_6': This element is not expected. Expected is ( P_2 ). Jeśli program do fakturowania generuje XML sam, większość tych błędów wyłapie za Ciebie. Te opisy przydadzą się, gdy integrujesz KSeF przez API, piszesz własny eksport albo chcesz zrozumieć, dlaczego faktura wróciła. Przykłady opierają się na schemacie FA(3) obowiązującym od 1 lutego 2026 roku.

Broszura informacyjna FA(3) — Ministerstwo Finansów

1. Brak lub zły namespace

Element <Faktura> musi zawierać namespace FA(3). Bez niego walidator nie rozpozna pliku jako faktury FA(3): zgłosi jeden błąd przy elemencie Faktura i nie sprawdzi reszty pliku. Przyczyna to zwykle szablon z internetu z FA(2), pominięty atrybut xmlns albo literówka w adresie (2025/06/25/13775 łatwo przekręcić). Namespace z szablonów sprzed lutego 2026 jest prawie na pewno nieaktualny, bo FA(2) przestał obowiązywać 31 stycznia 2026.

<!-- ❌ Brak namespace -->
<Faktura>
  ...
</Faktura>
<!-- ❌ Stary namespace FA(2), nieważny od 1 lutego 2026 -->
<Faktura xmlns="http://crd.gov.pl/wzor/2023/06/29/12648/">...</Faktura>
<!-- ✅ Poprawny namespace FA(3) -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  ...
</Faktura>

Więcej o tym błędzie: Zły namespace w fakturze: xmlns dla FA(3).

2. Zła kolejność elementów

Schemat używa xs:sequence, więc kolejność elementów jest obowiązkowa. Przestawione Podmiot2 przed Podmiot1 odrzuca cały plik. Program zwykle trzyma kolejność, ale ręczne edycje i własne eksporty ją psują.

Na najwyższym poziomie: Naglowek → Podmiot1 → Podmiot2 → [Podmiot3] → [PodmiotUpowazniony] → Fa (w tym FaWiersz) → [Stopka] → [Zalacznik]. Elementy w nawiasach są opcjonalne, ale jeśli występują, mają swoje miejsce. FaWiersz jest wewnątrz Fa, nie obok.

<!-- ❌ Podmiot2 przed Podmiot1 -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  <Naglowek>...</Naglowek>
  <Podmiot2>...</Podmiot2>
  <Podmiot1>...</Podmiot1>
  <Fa>...</Fa>
</Faktura>
<!-- ✅ Poprawna kolejność -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  <Naglowek>...</Naglowek>
  <Podmiot1>...</Podmiot1>
  <Podmiot2>...</Podmiot2>
  <Fa>...</Fa>
</Faktura>

Ta sama zasada dotyczy wnętrza Naglowek (KodFormularza → WariantFormularza → DataWytworzeniaFa), Podmiot1, Podmiot2 i Fa. Pełną kolejność podaje schemat XSD FA(3).

Więcej o tym błędzie: Element w złym miejscu w XML faktury FA(3).

3. Brak wymaganych elementów

FA(3) ma kilkadziesiąt pól obowiązkowych na różnych poziomach, a walidator wskaże, którego brakuje. Najłatwiej pominąć WariantFormularza, KodWaluty, P_15 i RodzajFaktury. Minimum:

Naglowek: KodFormularza (z atrybutami kodSystemowy="FA (3)" i wersjaSchemy="1-0E"), WariantFormularza, DataWytworzeniaFa
Podmiot1/DaneIdentyfikacyjne: NIP, Nazwa
Podmiot1/Adres: KodKraju, AdresL1
Podmiot2/DaneIdentyfikacyjne: NIP (lub KodUE + NrVatUE, lub KodKraju + NrID), Nazwa
Podmiot2: JST, GV
Fa: KodWaluty, P_1, P_2, P_15, Adnotacje, RodzajFaktury

<!-- ❌ Brak WariantFormularza -->
<Naglowek>
  <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
  <DataWytworzeniaFa>2026-09-15T10:00:00Z</DataWytworzeniaFa>
</Naglowek>
<!-- ✅ Komplet wymaganych pól w Naglowek -->
<Naglowek>
  <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
  <WariantFormularza>3</WariantFormularza>
  <DataWytworzeniaFa>2026-09-15T10:00:00Z</DataWytworzeniaFa>
</Naglowek>

Więcej o tym błędzie: Brak wymaganego pola w XML faktury FA(3).

4. Zły format NIP

Schemat wymaga dokładnie 10 cyfr bez separatorów. Zapisy 123-456-78-90 i PL 1234567890 są błędne. Prefiks PL nie trafia do pola NIP. Sprzedawca podaje go osobno w PrefiksPodatnika (Podmiot1), gdy jest wymagany (np. przy WDT). Polskiego nabywcę w Podmiot2 identyfikuje sam NIP; pola KodUE i NrVatUE służą do numeru VAT UE nabywcy z innego kraju.

<!-- ❌ Myślniki w NIP -->
<NIP>123-456-78-90</NIP>
<!-- ❌ Prefiks kraju w NIP -->
<NIP>PL1234567890</NIP>
<!-- ✅ 10 cyfr, bez separatorów -->
<NIP>1234567890</NIP>

NIP polskiego nabywcy musi trafić do pola NIP w Podmiot2/DaneIdentyfikacyjne, nie do NrVatUE ani NrID. W złym polu faktura nie zostanie poprawnie doręczona w KSeF.

Więcej o tym błędzie: Nieprawidłowa wartość pola: NIP.

5. Zły format daty

Polskie 15.09.2026 zamiast 2026-09-15 to najczęstsza pomyłka. Druga: pomylenie pól daty (P_1) z polem daty i czasu (DataWytworzeniaFa). Pola daty (P_1, P_6, P_6A i inne) przyjmują RRRR-MM-DD. DataWytworzeniaFa przyjmuje RRRR-MM-DDTHH:MM:SS. Broszura podaje przykład w czasie UTC, z literą Z na końcu, ale schemat przyjmie też zapis bez strefy czasowej albo z przesunięciem (+02:00).

<!-- ❌ Polski format daty -->
<P_1>15.09.2026</P_1>
<!-- ❌ Data i czas w polu, które przyjmuje tylko datę -->
<P_1>2026-09-15T10:00:00Z</P_1>
<!-- ✅ Poprawna data -->
<P_1>2026-09-15</P_1>
<!-- ❌ Spacja zamiast T, brak sekund -->
<DataWytworzeniaFa>2026-09-15 10:00</DataWytworzeniaFa>
<!-- ✅ Data i czas w UTC, z Z na końcu -->
<DataWytworzeniaFa>2026-09-15T10:00:00Z</DataWytworzeniaFa>

Więcej o tym błędzie: Nieprawidłowa wartość pola: format daty.

6. Zbyt wiele miejsc po przecinku

ERP i arkusze trzymają liczby z pełną precyzją (123.456789), a przy eksporcie nadmiar trafia do XML. Zaokrąglij:

kwoty (P_11, P_13_x, P_14_x, P_15): maks. 2 miejsca,
ilości (P_8B): maks. 6 miejsc,
ceny jednostkowe (P_9A, P_9B): maks. 8 miejsc.

Separator dziesiętny to zawsze kropka. Przecinek ani spacja jako separator tysięcy nie są dopuszczalne.

<!-- ❌ 3 miejsca po przecinku w P_15 (maks. 2) -->
<P_15>123.123</P_15>
<!-- ✅ Poprawnie, 2 miejsca -->
<P_15>123.12</P_15>
<!-- ❌ 7 miejsc w ilości P_8B (maks. 6) -->
<P_8B>1.1234567</P_8B>
<!-- ✅ Poprawnie, 6 miejsc -->
<P_8B>1.123456</P_8B>
<!-- ❌ Przecinek jako separator dziesiętny -->
<P_15>123,45</P_15>
<!-- ❌ Spacja jako separator tysięcy -->
<P_15>1 234.56</P_15>
<!-- ✅ Tylko kropka, bez separatorów -->
<P_15>1234.56</P_15>

Więcej o tym błędzie: Nieprawidłowa wartość pola: za dużo miejsc po przecinku.

7. Brak Podmiot2, JST i GV

W FA(2) pól JST i GV nie było, więc eksport oparty na starym szablonie ich nie generuje. Schemat wymaga ich zawsze, nawet gdy wartość to 2 (nie dotyczy). Dodaj je na końcu Podmiot2, po Adres i ewentualnych polach opcjonalnych.

JST = 1: faktura dotyczy jednostki podrzędnej samorządu terytorialnego; 2: nie dotyczy.
GV = 1: faktura dotyczy członka grupy VAT; 2: nie dotyczy.

<!-- ❌ Brak JST i GV -->
<Podmiot2>
  <DaneIdentyfikacyjne>
    <NIP>9876543210</NIP>
    <Nazwa>Firma Nabywcy</Nazwa>
  </DaneIdentyfikacyjne>
  <Adres>
    <KodKraju>PL</KodKraju>
    <AdresL1>ul. Testowa 1, 00-001 Warszawa</AdresL1>
  </Adres>
</Podmiot2>
<!-- ✅ Z JST i GV -->
<Podmiot2>
  <DaneIdentyfikacyjne>
    <NIP>9876543210</NIP>
    <Nazwa>Firma Nabywcy</Nazwa>
  </DaneIdentyfikacyjne>
  <Adres>
    <KodKraju>PL</KodKraju>
    <AdresL1>ul. Testowa 1, 00-001 Warszawa</AdresL1>
  </Adres>
  <JST>2</JST>
  <GV>2</GV>
</Podmiot2>

Więcej o tym błędzie: Brak JST i GV w Podmiot2: co wpisać w FA(3).

8. Zła stawka VAT w P_12

P_12 przyjmuje tylko wartości z katalogu FA(3), wrażliwe na wielkość liter i spacje. Samo 0 nie istnieje, trzeba podać wariant (0 KR, 0 WDT, 0 EX), spacja w 0 KR jest obowiązkowa, a zw pisze się małymi literami.

Dozwolone: 23, 22, 8, 7, 5, 4, 3, 0 KR, 0 WDT, 0 EX, zw, oo, np I, np II.

<!-- ❌ Samo 0, brak wariantu -->
<P_12>0</P_12>
<!-- ✅ Stawka 0% krajowa -->
<P_12>0 KR</P_12>
<!-- ❌ Znak procentu -->
<P_12>23%</P_12>
<!-- ✅ Bez znaku procentu -->
<P_12>23</P_12>
<!-- ❌ Wielkie litery -->
<P_12>ZW</P_12>
<!-- ✅ Małe litery -->
<P_12>zw</P_12>
<!-- ❌ Brak spacji -->
<P_12>0KR</P_12>
<!-- ✅ Ze spacją -->
<P_12>0 KR</P_12>

Wartość oo (odwrotne obciążenie) dotyczy wyłącznie transakcji krajowych. Przy fakturach dla nabywców zagranicznych, gdy nabywca rozlicza VAT w swoim kraju, użyj np I lub np II.

Broszura informacyjna FA(3), opis pola P_12 (stawki podatku)

Więcej o tym błędzie: Nieprawidłowa stawka VAT w P_12: co wpisać.

9. Zła identyfikacja zagranicznego nabywcy

FA(3) identyfikuje nabywcę inaczej zależnie od kraju:

Polska: pole NIP (10 cyfr, bez prefiksu),
UE: KodUE + NrVatUE (kod kraju osobno, numer VAT bez prefiksu),
poza UE: KodKraju + NrID.

Częsty błąd to kod kraju wewnątrz numeru VAT (DE123456789 w NrVatUE). KodKraju w DaneIdentyfikacyjne dotyczy identyfikacji podatkowej, a KodKraju w Adres adresu. To dwa osobne pola.

<!-- ❌ Prefiks kraju w numerze VAT -->
<DaneIdentyfikacyjne>
  <NrVatUE>DE123456789</NrVatUE>
  <Nazwa>Deutsche Firma GmbH</Nazwa>
</DaneIdentyfikacyjne>
<!-- ✅ Nabywca z UE: kod kraju w osobnym polu -->
<DaneIdentyfikacyjne>
  <KodUE>DE</KodUE>
  <NrVatUE>123456789</NrVatUE>
  <Nazwa>Deutsche Firma GmbH</Nazwa>
</DaneIdentyfikacyjne>
<!-- ✅ Nabywca spoza UE -->
<DaneIdentyfikacyjne>
  <KodKraju>US</KodKraju>
  <NrID>12-3456789</NrID>
  <Nazwa>American Corp</Nazwa>
</DaneIdentyfikacyjne>

10. P_15 nie zgadza się z sumami

P_15 (kwota należności ogółem) musi równać się sumie kwot netto (P_13_x) i podatku (P_14_x). Najczęściej winne jest zaokrąglanie (podatek 22.9977 zaokrąglony do 22.99 zamiast 23.00) albo pominięte pole P_13_x, np. P_13_6_1 dla stawki 0%.

Formuła: P_15 = suma wszystkich P_13_x + suma wszystkich P_14_x, czyli P_13_1 do P_13_11 i P_14_1 do P_14_5. Pola P_13_6_1 do P_13_11 (stawka 0%, zwolnione, odwrotne obciążenie) nie mają odpowiadających P_14_x, ale ich kwoty netto wliczają się do P_15.

<!-- ❌ P_15 nie zgadza się z sumą -->
<P_13_1>1000.00</P_13_1>
<P_14_1>230.00</P_14_1>
<P_15>1200.00</P_15>
<!-- ✅ Poprawna suma: 1000 + 230 = 1230 -->
<P_13_1>1000.00</P_13_1>
<P_14_1>230.00</P_14_1>
<P_15>1230.00</P_15>
<!-- ✅ Mieszane stawki: 100 + 23 + 200 + 16 = 339 -->
<P_13_1>100.00</P_13_1>
<P_14_1>23.00</P_14_1>
<P_13_2>200.00</P_13_2>
<P_14_2>16.00</P_14_2>
<P_15>339.00</P_15>

Walidator ksefuj.to toleruje różnicę do 1 grosza (0.01) przy porównywaniu sum.

Więcej o tym błędzie: Błąd kalkulacji VAT: P_14 lub P_15 się nie zgadza.

11. Niekompletne Adnotacje

Nazwa sugeruje notatki, ale Adnotacje to obowiązkowa sekcja z ośmioma polami, z których każde musi mieć wartość. Trzy (Zwolnienie, NoweSrodkiTransportu, PMarzy) wymagają zagnieżdżonych elementów nawet wtedy, gdy odpowiedź brzmi „nie". Kolejność też jest obowiązkowa: P_16 → P_17 → P_18 → P_18A → Zwolnienie → NoweSrodkiTransportu → P_23 → PMarzy.

Dla standardowej faktury VAT poniższy blok działa jako szablon bez zmian:

<!-- ❌ Niekompletne Adnotacje -->
<Adnotacje>
  <P_16>2</P_16>
  <P_17>2</P_17>
</Adnotacje>
<!-- ✅ Kompletne Adnotacje (standardowa faktura) -->
<Adnotacje>
  <P_16>2</P_16>
  <P_17>2</P_17>
  <P_18>2</P_18>
  <P_18A>2</P_18A>
  <Zwolnienie><P_19N>1</P_19N></Zwolnienie>
  <NoweSrodkiTransportu><P_22N>1</P_22N></NoweSrodkiTransportu>
  <P_23>2</P_23>
  <PMarzy><P_PMarzyN>1</P_PMarzyN></PMarzy>
</Adnotacje>

12. P_6, P_6A i OkresFa

Trzy pola, trzy zastosowania:

P_6 (w Fa): data dostawy lub wykonania usługi, wspólna dla wszystkich wierszy,
P_6A (w FaWiersz): data dla konkretnego wiersza, gdy wiersze mają różne daty,
OkresFa (w Fa): okres rozliczeniowy (np. abonament za wrzesień), z polami P_6_Od i P_6_Do.

W Fa pole P_6 i element OkresFa wykluczają się (xs:choice w XSD). Zakaz łączenia P_6 z P_6A to osobna reguła semantyczna. OkresFa może natomiast wystąpić razem z P_6A, bo nie koliduje z nim na żadnym poziomie schematu.

<!-- ❌ P_6 i P_6A jednocześnie -->
<Fa>
  <P_6>2026-09-15</P_6>
  ...
</Fa>
<FaWiersz>
  <NrWierszaFa>1</NrWierszaFa>
  <P_6A>2026-09-14</P_6A>
  ...
</FaWiersz>
<!-- ✅ Opcja A: wspólna data dostawy (P_6 w Fa, bez P_6A) -->
<Fa>
  <P_6>2026-09-15</P_6>
  ...
</Fa>
<FaWiersz>
  <NrWierszaFa>1</NrWierszaFa>
  ...
</FaWiersz>
<!-- ✅ Opcja B: daty per wiersz (P_6A w FaWiersz, bez P_6) -->
<Fa>...</Fa>
<FaWiersz>
  <NrWierszaFa>1</NrWierszaFa>
  <P_6A>2026-09-14</P_6A>
  ...
</FaWiersz>
<FaWiersz>
  <NrWierszaFa>2</NrWierszaFa>
  <P_6A>2026-09-15</P_6A>
  ...
</FaWiersz>
<!-- ✅ Opcja C: okres rozliczeniowy (OkresFa zamiast P_6) -->
<Fa>
  <OkresFa>
    <P_6_Od>2026-09-01</P_6_Od>
    <P_6_Do>2026-09-30</P_6_Do>
  </OkresFa>
  ...
</Fa>

P_6 to nie P_1. P_1 to data wystawienia faktury i jest obowiązkowa zawsze. P_6 to data dostawy lub wykonania usługi, często taka sama jak P_1, ale o innym znaczeniu prawnym.

Co dalej

Plik z błędem możesz wrzucić na ksefuj.to, a walidator wskaże każdy z powyższych problemów po polsku; plik nie opuszcza przeglądarki. Jeśli dopiero zaczynasz, zacznij od poradnika po pierwszej fakturze, a przy migracji ze starego formatu od różnic FA(2) i FA(3).

Błędy spoza tej listy też mają osobne opisy, np. XML nie jest poprawnie sformatowany albo błędny numer rachunku bankowego.

Schemat XSD FA(3) — crd.gov.pl