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 a VAT rate 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). The grace period, during which no penalties apply for system-related errors, ends on 31 December 2026. Sanctions begin on 1 January 2027. 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>FA</KodFormularza>
    <WariantFormularza>3</WariantFormularza>
    <DataWytworzeniaFa>2026-06-21T10:00:00Z</DataWytworzeniaFa>
  </Naglowek>
  <Podmiot1>
    <DaneIdentyfikacyjne>
      <NIP>1234567890</NIP>
      <Nazwa>ITCompass Artem ...</Nazwa>
    </DaneIdentyfikacyjne>
    <Adres>...</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>
      <P_23>2</P_23>
    </Adnotacje>
    <RodzajFaktury>VAT</RodzajFaktury>
    <FaWiersz>
      <NrWierszaFa>1</NrWierszaFa>
      <P_7>Software development service</P_7>
      <P_12>23</P_12>
      <P_11>1000.00</P_11>
    </FaWiersz>
  </Fa>
</Faktura>

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

An FA(3) novelty 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"). This is a frequent cause of rejection during first migrations from FA(2).

The invoice line: what really has to be in it

Inside the FaWiersz (line item) element, only three things are mandatory:

• NrWierszaFa — the line number.

• P_7 — name of the goods or service. Mandatory as a rule; the exception is correction invoices documenting bulk rebates for a whole period. In FA(3) the field limit was extended from 256 to 512 characters.

• P_12 — the VAT rate. KSeF rejects the line without it.

A detail that confuses integrators: FaWiersz carries no per-line VAT amount. The tax amount lives only in the document summary (P_13_x net and P_14_x VAT, by rate), with P_15 as the total amount due. 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: five flags you can't skip

The Adnotacje (annotations) block is mandatory, and it contains five "yes/no" flags (1 = yes, 2 = no) that must always be set — you cannot leave them out:

• P_16 — cash accounting

• P_17 — self-billing

• P_18 — reverse charge

• P_18A — split payment mechanism (MPP)

• P_23 — simplified procedure in triangular transactions

In other words, even an ordinary sale needs five "2"s. The remaining annotation fields (e.g. P_19 for exemption with its legal basis in P_19A/B/C, P_22 for intra-EU supply) are filled conditionally.

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

This is the most important part. The following fields are technically optional but legally mandatory when their condition applies — and KSeF will accept the invoice without them:

• P_18A = 1 for split payment. The obligation applies to transactions ≥ PLN 15,000 gross involving goods 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.

• P_22 = 1 for intra-EU supply of goods. The 0 WDT rate and the annotation must be consistent; a mismatch doesn't block the file but corrupts the JPK_VAT 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, P_7, and P_12.

• Adnotacje: the five flags (P_16, P_17, P_18, P_18A, P_23) carry 1 or 2.

• Legal conditions: split payment (P_18A=1), intra-EU supply (P_22=1), 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 any KSeF rejection into a readable message 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 without the rejection risk.

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 line number, the goods/service name (P_7), and the VAT rate (P_12) are mandatory. Without them 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. Field P_18A is technically optional but legally required when a transaction exceeds PLN 15,000 gross involving Annex 15 goods. 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.