12 most common FA(3) validation errors

An FA(3) invoice most often fails validation because of a wrong namespace, element order, missing fields, NIP and date formats, too many decimal places, a P_12 rate, or incomplete Adnotacje. Each of the 12 errors below has a cause and XML you can copy.

Validation messages are opaque. Instead of "missing invoice number" you get something like Element 'P_6': This element is not expected. Expected is ( P_2 ). If your invoicing software generates the XML itself, it should catch most of these. The explanations help when you integrate with KSeF (Krajowy System e-Faktur, Poland's national e-invoicing system) through the API, write a custom exporter, or want to know why an invoice was rejected. The examples are based on the FA(3) schema in force since 1 February 2026.

FA(3) Information Sheet — Ministry of Finance

1. Missing or wrong namespace

The <Faktura> element must carry the FA(3) namespace. Without it the validator does not recognise the file as an FA(3) invoice: it reports a single error on Faktura and checks nothing else in the file. The usual causes are a template from the internet that uses FA(2), an omitted xmlns attribute, or a typo in the URI (2025/06/25/13775 is easy to get wrong). A namespace from templates predating February 2026 is almost certainly outdated, because FA(2) stopped applying on 31 January 2026.

<!-- ❌ No namespace -->
<Faktura>
  ...
</Faktura>
<!-- ❌ Old FA(2) namespace, invalid since 1 February 2026 -->
<Faktura xmlns="http://crd.gov.pl/wzor/2023/06/29/12648/">...</Faktura>
<!-- ✅ Correct FA(3) namespace -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  ...
</Faktura>

More about this error: Wrong namespace in the invoice: xmlns for FA(3).

2. Wrong element order

The schema uses xs:sequence, so element order is mandatory. Podmiot2 placed before Podmiot1 rejects the whole file. Software normally keeps the order, but manual edits and custom exports break it.

At the top level: Naglowek → Podmiot1 → Podmiot2 → [Podmiot3] → [PodmiotUpowazniony] → Fa (including FaWiersz) → [Stopka] → [Zalacznik]. Elements in brackets are optional, but if present they have a fixed place. FaWiersz sits inside Fa, not next to it.

<!-- ❌ Podmiot2 before Podmiot1 -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  <Naglowek>...</Naglowek>
  <Podmiot2>...</Podmiot2>
  <Podmiot1>...</Podmiot1>
  <Fa>...</Fa>
</Faktura>
<!-- ✅ Correct order -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  <Naglowek>...</Naglowek>
  <Podmiot1>...</Podmiot1>
  <Podmiot2>...</Podmiot2>
  <Fa>...</Fa>
</Faktura>

The same rule applies inside Naglowek (KodFormularza → WariantFormularza → DataWytworzeniaFa), Podmiot1, Podmiot2 and Fa. The full order is in the FA(3) XSD schema.

More about this error: Element in the wrong place in FA(3) invoice XML.

3. Missing required elements

FA(3) has dozens of mandatory fields at different levels, and the validator names the missing one. The easiest to forget are WariantFormularza, KodWaluty, P_15 and RodzajFaktury. The minimum:

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

<!-- ❌ Missing WariantFormularza -->
<Naglowek>
  <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
  <DataWytworzeniaFa>2026-09-15T10:00:00Z</DataWytworzeniaFa>
</Naglowek>
<!-- ✅ All required fields in Naglowek -->
<Naglowek>
  <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
  <WariantFormularza>3</WariantFormularza>
  <DataWytworzeniaFa>2026-09-15T10:00:00Z</DataWytworzeniaFa>
</Naglowek>

More about this error: Missing required field in FA(3) invoice XML.

4. Wrong NIP format

The schema requires exactly 10 digits with no separators. 123-456-78-90 and PL 1234567890 are both wrong. The PL prefix never goes in the NIP field. The seller gives it separately in PrefiksPodatnika (Podmiot1) when it is required (e.g. for an intra-Community supply). A Polish buyer in Podmiot2 is identified by NIP alone; KodUE and NrVatUE are for the EU VAT number of a buyer from another member state.

<!-- ❌ Hyphens in NIP -->
<NIP>123-456-78-90</NIP>
<!-- ❌ Country prefix in NIP -->
<NIP>PL1234567890</NIP>
<!-- ✅ 10 digits, no separators -->
<NIP>1234567890</NIP>

A Polish buyer's NIP must go in the NIP field of Podmiot2/DaneIdentyfikacyjne, not in NrVatUE or NrID. In the wrong field the invoice will not be delivered correctly in KSeF.

More about this error: Invalid field value: NIP.

5. Wrong date format

The Polish 15.09.2026 instead of 2026-09-15 is the most common slip. The second is mixing up date fields (P_1) with the date-time field (DataWytworzeniaFa). Date fields (P_1, P_6, P_6A and others) take YYYY-MM-DD. DataWytworzeniaFa takes YYYY-MM-DDTHH:MM:SS. The MF information sheet gives an example in UTC, with Z at the end, but the schema also accepts a value without a time zone or with an offset (+02:00).

<!-- ❌ Polish date format -->
<P_1>15.09.2026</P_1>
<!-- ❌ Date and time in a date-only field -->
<P_1>2026-09-15T10:00:00Z</P_1>
<!-- ✅ Correct date -->
<P_1>2026-09-15</P_1>
<!-- ❌ Space instead of T, no seconds -->
<DataWytworzeniaFa>2026-09-15 10:00</DataWytworzeniaFa>
<!-- ✅ Date and time in UTC, with Z at the end -->
<DataWytworzeniaFa>2026-09-15T10:00:00Z</DataWytworzeniaFa>

More about this error: Invalid field value: date format.

6. Too many decimal places

ERPs and spreadsheets store numbers at full precision (123.456789), and the excess ends up in the XML on export. Round to:

amounts (P_11, P_13_x, P_14_x, P_15): max 2 places,
quantities (P_8B): max 6 places,
unit prices (P_9A, P_9B): max 8 places.

The decimal separator is always a dot. A comma or a space as a thousands separator is not allowed.

<!-- ❌ 3 decimal places in P_15 (max 2) -->
<P_15>123.123</P_15>
<!-- ✅ Correct, 2 places -->
<P_15>123.12</P_15>
<!-- ❌ 7 places in quantity P_8B (max 6) -->
<P_8B>1.1234567</P_8B>
<!-- ✅ Correct, 6 places -->
<P_8B>1.123456</P_8B>
<!-- ❌ Comma as decimal separator -->
<P_15>123,45</P_15>
<!-- ❌ Space as thousands separator -->
<P_15>1 234.56</P_15>
<!-- ✅ Dot only, no separators -->
<P_15>1234.56</P_15>

More about this error: Invalid field value: too many decimal places.

7. Missing Podmiot2, JST and GV

JST and GV did not exist in FA(2), so an export based on an old template does not generate them. The schema always requires them, even when the value is 2 (not applicable). Add them at the end of Podmiot2, after Adres and any optional fields.

JST = 1: the invoice concerns a subordinate local government unit; 2: not applicable.
GV = 1: the invoice concerns a VAT group member; 2: not applicable.

<!-- ❌ Missing JST and 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>
<!-- ✅ With JST and 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>

More about this error: Missing JST and GV in Podmiot2: what to enter.

8. Wrong VAT rate in P_12

P_12 accepts only values from the FA(3) catalogue, and they are case- and space-sensitive. A bare 0 does not exist, you must give a variant (0 KR, 0 WDT, 0 EX), the space in 0 KR is mandatory, and zw is lowercase.

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

<!-- ❌ Bare 0, no variant -->
<P_12>0</P_12>
<!-- ✅ Domestic 0% rate -->
<P_12>0 KR</P_12>
<!-- ❌ Percent sign -->
<P_12>23%</P_12>
<!-- ✅ No percent sign -->
<P_12>23</P_12>
<!-- ❌ Uppercase -->
<P_12>ZW</P_12>
<!-- ✅ Lowercase -->
<P_12>zw</P_12>
<!-- ❌ Missing space -->
<P_12>0KR</P_12>
<!-- ✅ With space -->
<P_12>0 KR</P_12>

The value oo (reverse charge) applies only to domestic transactions. For invoices to foreign buyers who account for VAT in their own country, use np I or np II.

MF FA(3) information brochure, description of field P_12 and its values

More about this error: Invalid VAT rate in P_12: allowed values.

9. Wrong identification of a foreign buyer

FA(3) identifies the buyer differently depending on the country:

Poland: the NIP field (10 digits, no prefix),
EU: KodUE + NrVatUE (country code separate, VAT number without prefix),
outside the EU: KodKraju + NrID.

A common mistake is putting the country code inside the VAT number (DE123456789 in NrVatUE). KodKraju in DaneIdentyfikacyjne is about tax identification, and KodKraju in Adres is about the address. They are two separate fields.

<!-- ❌ Country prefix in VAT number -->
<DaneIdentyfikacyjne>
  <NrVatUE>DE123456789</NrVatUE>
  <Nazwa>Deutsche Firma GmbH</Nazwa>
</DaneIdentyfikacyjne>
<!-- ✅ EU buyer: country code in a separate field -->
<DaneIdentyfikacyjne>
  <KodUE>DE</KodUE>
  <NrVatUE>123456789</NrVatUE>
  <Nazwa>Deutsche Firma GmbH</Nazwa>
</DaneIdentyfikacyjne>
<!-- ✅ Non-EU buyer -->
<DaneIdentyfikacyjne>
  <KodKraju>US</KodKraju>
  <NrID>12-3456789</NrID>
  <Nazwa>American Corp</Nazwa>
</DaneIdentyfikacyjne>

10. P_15 doesn't match the totals

P_15 (total amount due) must equal the sum of the net amounts (P_13_x) and the tax (P_14_x). The usual culprit is rounding (tax of 22.9977 rounded to 22.99 instead of 23.00) or a skipped P_13_x field, such as P_13_6_1 for the 0% rate.

Formula: P_15 = sum of all P_13_x + sum of all P_14_x, that is P_13_1 to P_13_11 and P_14_1 to P_14_5. Fields P_13_6_1 to P_13_11 (0% rate, exempt, reverse charge) have no matching P_14_x, but their net amounts count towards P_15.

<!-- ❌ P_15 doesn't match the sum -->
<P_13_1>1000.00</P_13_1>
<P_14_1>230.00</P_14_1>
<P_15>1200.00</P_15>
<!-- ✅ Correct sum: 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>
<!-- ✅ Mixed rates: 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>

The ksefuj.to validator tolerates a difference of up to 0.01 PLN when comparing totals.

More about this error: VAT calculation error: P_14 or P_15 is wrong.

11. Incomplete Adnotacje

The name suggests notes, but Adnotacje is a mandatory section with eight fields, each of which needs a value. Three (Zwolnienie, NoweSrodkiTransportu, PMarzy) need nested elements even when the answer is "no". The order is mandatory too: P_16 → P_17 → P_18 → P_18A → Zwolnienie → NoweSrodkiTransportu → P_23 → PMarzy.

For a standard VAT invoice the block below works as a template unchanged:

<!-- ❌ Incomplete Adnotacje -->
<Adnotacje>
  <P_16>2</P_16>
  <P_17>2</P_17>
</Adnotacje>
<!-- ✅ Complete Adnotacje (standard invoice) -->
<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 and OkresFa

Three fields, three uses:

P_6 (in Fa): the delivery or service date, common to all lines,
P_6A (in FaWiersz): the date for a specific line, when lines have different dates,
OkresFa (in Fa): a billing period (for example a September subscription), with P_6_Od and P_6_Do.

In Fa, P_6 and OkresFa are mutually exclusive (xs:choice in the XSD). The ban on combining P_6 with P_6A is a separate semantic rule. OkresFa can appear together with P_6A, because it does not conflict with it at any level of the schema.

<!-- ❌ P_6 and P_6A at the same time -->
<Fa>
  <P_6>2026-09-15</P_6>
  ...
</Fa>
<FaWiersz>
  <NrWierszaFa>1</NrWierszaFa>
  <P_6A>2026-09-14</P_6A>
  ...
</FaWiersz>
<!-- ✅ Option A: common delivery date (P_6 in Fa, no P_6A) -->
<Fa>
  <P_6>2026-09-15</P_6>
  ...
</Fa>
<FaWiersz>
  <NrWierszaFa>1</NrWierszaFa>
  ...
</FaWiersz>
<!-- ✅ Option B: per-line dates (P_6A in FaWiersz, no 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>
<!-- ✅ Option C: billing period (OkresFa instead of 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 is not P_1. P_1 is the invoice issue date and is always mandatory. P_6 is the delivery or service date, often the same as P_1 but with a different legal meaning.

Next step

You can drop a failing file into ksefuj.to and the validator will point to each of the problems above; the file never leaves your browser. If you're just starting, begin with the first invoice guide, and when migrating from the old format, with the differences between FA(2) and FA(3).

Errors outside this list have their own pages too, such as XML is not well-formed or invalid bank account number.

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