FA(3) Schema: Which E-Invoice Fields Are Actually Mandatory

KSeF (Poland's national e-invoicing system) rejects an invoice in a fraction of a second when the seller's NIP (tax ID) or one of the required blocks is missing. That's the easy kind of error — you get a message and fix it. The dangerous kind is different: fields that look optional but become mandatory the moment a specific legal condition applies. KSeF doesn't check those. It accepts the file, assigns a number, and the problem surfaces only during a JPK_V7 (VAT ledger) audit.

Since 1 February 2026, the FA(3) logical structure is the only accepted invoice format in KSeF — it replaced FA(2). Under the current act, penalties under Article 106ni of the VAT Act apply from 1 January 2027. On 16 September 2026 the Ministry of Finance announced it will move them to 1 January 2028; that is a bill not yet passed, and it moves only the penalties, not the obligation to use KSeF. That makes now the practical window to get your data right, before the cost of a mistake stops being zero.

Below we break the schema into its three requirement levels and show which fields you must fill every time, which only conditionally, and which you don't need at all.

Three requirement levels — and why this isn't just terminology

The FA(3) schema is an XSD file published by Poland's Ministry of Finance in the Central Repository of Document Templates (namespace http://crd.gov.pl/wzor/2025/06/25/13775/). Every field carries one of three levels:

1. Mandatory — must be filled on every invoice. Missing it means KSeF rejects the file.

2. Optional (conditionally mandatory) — you must fill it, but only when a specific legal condition applies. KSeF does not verify whether the condition occurred — the responsibility sits with the taxpayer.

3. Facultative — entirely up to you. Omitting it has no consequences.

Level two causes the most trouble, because intuition says "optional field = I can skip it." In FA(3) that's false. The rate field for exempt sales, the split-payment marker, or the intra-EU supply flag are technically optional but legally required — and the KSeF validator won't stop you.

The four blocks KSeF rejects an invoice without

The FA(3) main schema is built from several top-level blocks. Four are required unconditionally on every invoice:

• Naglowek (header) — technical document data: form code (FA), form variant (3), creation timestamp.

• Podmiot1 (seller) — NIP and full name are mandatory. A missing seller NIP guarantees rejection.

• Podmiot2 (buyer) — the first trap lives here (see below).

• Fa — the central block with transaction data: issue date (P_1), invoice number (P_2), currency code, invoice type, VAT summaries, and line items.

A simplified skeleton shows how little it takes for an invoice to be technically valid:

<Faktura>
  <Naglowek>
    <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
    <WariantFormularza>3</WariantFormularza>
    <DataWytworzeniaFa>2026-06-21T10:00:00Z</DataWytworzeniaFa>
  </Naglowek>
  <Podmiot1>
    <DaneIdentyfikacyjne>
      <NIP>1234567890</NIP>
      <Nazwa>ITCompass Artem ...</Nazwa>
    </DaneIdentyfikacyjne>
    <Adres>
      <KodKraju>PL</KodKraju>
      <AdresL1>ul. Przykładowa 1</AdresL1>
      <AdresL2>00-001 Warszawa</AdresL2>
    </Adres>
  </Podmiot1>
  <Podmiot2>
    <DaneIdentyfikacyjne>
      <NIP>9876543210</NIP>
      <Nazwa>Client Sp. z o.o.</Nazwa>
    </DaneIdentyfikacyjne>
    <JST>2</JST>   <!-- even if N/A: you must enter 2 -->
    <GV>2</GV>     <!-- even if N/A: you must enter 2 -->
  </Podmiot2>
  <Fa>
    <KodWaluty>PLN</KodWaluty>
    <P_1>2026-06-21</P_1>
    <P_2>FV/06/2026</P_2>
    <P_13_1>1000.00</P_13_1>
    <P_14_1>230.00</P_14_1>
    <P_15>1230.00</P_15>
    <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>
    <RodzajFaktury>VAT</RodzajFaktury>
    <FaWiersz>
      <NrWierszaFa>1</NrWierszaFa>
      <P_7>Software development service</P_7>
      <P_11>1000.00</P_11>
      <P_12>23</P_12>
    </FaWiersz>
  </Fa>
</Faktura>

The skeleton is illustrative. Always take exact attribute names and field formats from the official XSD file.

A trap that's easy to miss: in Podmiot2, the JST (local government unit) and GV (VAT group) fields are mandatory. Even when the invoice has nothing to do with a local authority or a VAT group, you must enter 2 ("not applicable").

The invoice line: what really has to be in it

Inside the FaWiersz (line item) element, the schema requires only one field; two more are required by the VAT Act:

• NrWierszaFa — the line number; the only line field the XSD schema requires. Without it KSeF rejects the file.

• P_7 — name of the goods or service. Optional in the schema, but as a rule required by the VAT Act; the exception is correction invoices documenting bulk rebates for a whole period. The field takes up to 512 characters.

• P_12 — the VAT rate. Optional in the schema (in some cases under Article 106e of the VAT Act it may be omitted), but as a rule required by the Act, and when given it must be one of the allowed values, e.g. 23, 8, 5, zw, np I, 0 KR, 0 WDT.

A detail that confuses integrators: FaWiersz as a rule carries no per-line VAT amount. The tax amount lives in the document summary (P_13_x net and P_14_x VAT, by rate), with P_15 as the total amount due. The exception is P_11Vat, the tax amount on the line in the case of Article 106e(10) of the VAT Act. The P_6A field (per-line delivery date) is optional — you fill it only when individual lines have different sale dates. Fields like Indeks, GTIN, PKWiU, and CN are facultative.

Adnotacje: eight elements you can't skip

The Adnotacje (annotations) block is mandatory, and the schema requires eight elements in it — none may be left out. Five are "yes/no" flags (1 = yes, 2 = no). Three more are blocks that choose between "not applicable" (1) and a full version:

• P_16 — cash accounting

• P_17 — self-billing

• P_18 — reverse charge

• P_18A — split payment mechanism (MPP)

• Zwolnienie (exemption) — either P_19N = 1 (no exempt supplies), or P_19 = 1 with the legal basis in P_19A, P_19B or P_19C

• NoweSrodkiTransportu (new means of transport) — either P_22N = 1 (none supplied), or P_22 = 1 with a description of the vehicles

• P_23 — simplified procedure in triangular transactions

• PMarzy (margin scheme) — either P_PMarzyN = 1 (no margin procedure), or P_PMarzy = 1 with the type of procedure

In other words, even an ordinary sale needs five "2"s plus three "not applicable" markers (P_19N, P_22N and P_PMarzyN, each with the value 1). The full versions of those blocks (P_19 for exemption with its legal basis in P_19A/B/C, P_22 for new means of transport, P_PMarzy for the margin scheme) are filled only when the case applies.

"Optional" fields — the trap KSeF won't catch

This is the most important part. The following markings pass the schema in any form but are legally mandatory when their condition applies — and KSeF will accept the invoice without the right marking:

• P_18A = 1 for split payment. The obligation applies to invoices whose gross amount exceeds PLN 15,000 and that contain items from Annex 15 to the VAT Act (Article 108a). KSeF knows neither the threshold nor the subject — it won't check. Omitting the marker exposes the seller to tax sanctions.

• The 0 WDT rate for intra-EU supply of goods. An intra-EU supply is marked with the rate 0 WDT in P_12; the P_22 marker is only for new means of transport, not for every intra-EU supply. A rate that does not match the type of transaction doesn't block the file but corrupts the JPK_V7 ledger.

• P_19 + legal basis for exempt sales. The zw (exempt) rate alone isn't enough — the provision must go into P_19A (VAT Act), P_19B (EU Directive), or P_19C (other regulations).

• JST / GV in Podmiot2 — described above; the value 2 is always required.

The rule to remember: KSeF validates the technical correctness of the file, not the substantive correctness of the settlement. An accepted invoice does not mean "correctly accounted for."

Facultative fields — what you do NOT need to fill

Here many issuers overcorrect and fill in boxes no one requires — neither the VAT Act nor the XML schema. Omitting them never triggers a rejection:

• GTU codes (01–13) — only for designated groups of goods and services, not every invoice.

• PKWiU, CN, GTIN, Indeks — helpful for automation, but not required.

• DodatkowyOpis (up to 10,000 occurrences), Platnosc (payment), TerminPlatnosci (payment term), NrZamowienia (order number) — all facultative.

• StopkaFaktury (footer, up to 3 × 3,500 characters) — for registration data (KRS, REGON, share capital), branch hours, and the like.

Fill them when they genuinely help your counterparty or your bookkeeping — not "just in case."

Quick checklist before sending to KSeF

• Podmiot1: seller NIP and full name present.

• Podmiot2: buyer identified (NIP / EU VAT / no-ID for B2C), and JST and GV set (even to 2).

• Fa: P_1, P_2, currency code, and RodzajFaktury filled; P_15 matches the sum of P_13_x + P_14_x.

• FaWiersz: every line has NrWierszaFa (required by the schema), P_7 and P_12 (required by the VAT Act).

• Adnotacje: all eight elements are present — the five flags (P_16, P_17, P_18, P_18A, P_23) carry 1 or 2, and Zwolnienie, NoweSrodkiTransportu and PMarzy are filled (at least as P_19N, P_22N, P_PMarzyN).

• Legal conditions: split payment (P_18A=1), intra-EU supply (0 WDT rate), exemption (P_19 + basis) marked where they apply.

• Foreign currency: net/gross amounts may be in the currency, but VAT (P_14_xW) is always in PLN.

Conclusion

In FA(3), what matters isn't the field count but understanding the three requirement levels. Four mandatory blocks and a handful of line fields decide whether KSeF accepts the file at all. But it's the "optional" fields — split payment, intra-EU supply, exemption basis — that drive most audit problems, precisely because the system doesn't police them.

Biurko validates each invoice against the official XSD before sending, sets the required flags by default (including JST/GV and the annotations), and translates the 28 most common KSeF rejection codes into a readable message (the rest are shown as the Ministry's own text) instead of a raw error code. Instead of memorizing the XML structure, you fill a form and the system guards correctness. Try Biurko free for 14 days and issue your first FA(3) invoice with the schema checked before submission.

FAQ

Which FA(3) fields are absolutely mandatory? Four blocks are required unconditionally: Naglowek, Podmiot1 (with the seller's NIP and name), Podmiot2, and Fa. Within a line, the schema requires only the line number; the goods/service name (P_7) and the VAT rate (P_12) are required by the VAT Act, not by the schema. Without the blocks and fields the schema requires, KSeF rejects the file.

Does KSeF check whether I applied split payment? No. KSeF knows neither the threshold nor the transaction subject, so it doesn't verify the split-payment obligation. The schema always requires field P_18A, but the value 1 (split payment) is legally required when an invoice exceeds PLN 15,000 gross and contains items from Annex 15. The responsibility sits with the taxpayer.

What's the difference between optional and facultative fields? Optional fields become mandatory when a legal condition applies (e.g. the rate on an exempt sale) — omitting them risks sanctions. Facultative fields (GTU, PKWiU, footer, additional description) are entirely voluntary, and skipping them has no tax consequences.

Do I have to fill GTU codes on every invoice? No. GTU codes (01–13) apply only to designated groups of goods and services. For an ordinary sale of services or goods outside the list, the field stays empty and the invoice is fully valid.

Must a foreign-currency invoice show amounts in PLN? Partly. Net and gross amounts may be expressed in the foreign currency (KodWaluty ≠ PLN), but the VAT amount in field P_14_xW must always be converted to złoty, in line with Article 31a of the VAT Act.