Skip to main content
FA(3) · schema 1-0E

The buyer in FA(3): identifier, JST and GV in Podmiot2

The Podmiot2 section says who you invoice. The FA(3) schema gives four ways to write the buyer's identifier and two mandatory markers, JST and GV, and in production KSeF also checks the NIP checksum. Odoo picks the identifier on its own and always writes both markers the same way.

FlexigoTech · Editor in charge: Víctor Gómez · Updated 5 November 2026

Key facts

Module
KSeF 2.0
Versions
Odoo 17, 18, 19 and 20
Checked
in the module's source code, version 20.0 · against the sources linked at the end
Reading time
3 min

Four ways to identify the buyer

FA(3) elementDescription in the schemaWhen to use it
NIP“Identyfikator podatkowy NIP” (NIP tax ID)Buyer with a Polish NIP.
KodUE + NrVatUE“Numer Identyfikacyjny VAT kontrahenta UE” (EU VAT number of the counterparty)Buyer with a VAT number from another EU country, in the cases set by the VAT act.
KodKraju + NrID“Identyfikator podatkowy inny” (other tax ID)Another tax identifier, for example from outside the EU.
BrakID“Podmiot nie posiada identyfikatora podatkowego lub identyfikator nie występuje na fakturze: 1- tak” (no tax ID, or none on the invoice)Consumer or buyer without an identifier.

The schema only checks the NIP format: 10 digits following the TNrNIP pattern. It does not check the checksum. KSeF does, but only in production, for Podmiot1, Podmiot2, Podmiot3 and PodmiotUpowazniony. In the test environment the header X-KSeF-Feature: subject-identifier-validation turns that validation on. The documentation does not say which code KSeF uses to reject a wrong checksum.

FA(3) Podmiot2 section card
The buyer identifier elements and the JST and GV markers from the 1-0E schema.

The JST and GV markers

Both are mandatory in Podmiot2 and take the value 1 or 2:

  • JST, “Znacznik jednostki podrzędnej JST.” (local government subordinate unit marker): 1 when the invoice concerns a subordinate unit of a local government; then Podmiot3 must be filled with role 8 and the unit's NIP or internal ID;
  • GV, “Znacznik członka grupy VAT.” (VAT group member marker): 1 when the invoice concerns a member of a VAT group; then Podmiot3 with role 10;
  • 2 in either means the invoice does not concern them.

What Odoo 18, 19 and 20 write

Odoo picks the identifier from the customer's VAT number. A Polish NIP goes to NIP. Odoo only writes KodUE and NrVatUE for special transactions, those with the tax tags OSS_Base, OSS_Tax, Triangular Sale, K_21 or K_12; any other foreign number goes to KodKraju and NrID. A customer without a VAT number gets BrakID 1.

Odoo always writes JST and GV as 2. So an invoice for a subordinate unit of a local government, or for a VAT group member, cannot be marked from Odoo the way the schema requires, and it will not reach that unit through Podmiot3.

Diagram: what Odoo 20 writes in Podmiot2 and what the schema and KSeF require
Diagram based on the FA(3) template of Odoo 20, the FA(3) 1-0E schema and the KSeF documentation; struck-through items are what Odoo does not write.

What to check before sending

  1. The customer's VAT number: a Polish NIP with or without the PL prefix (without it, Odoo takes the country from the customer record), with a correct checksum.
  2. For an EU customer: whether the invoice really should carry KodUE and NrVatUE, that is, whether the lines have the right tax.
  3. For public-sector customers: whether the invoice should reach a subordinate unit; Odoo will not write that.

Does our module check the buyer's NIP?

Partly. When you use “Mark ready for KSeF upload”, Poland KSeF 2.0 Validator computes the Polish NIP checksum of the customer and, if it does not match, reports “Partner NIP invalid” and leaves the invoice in “Manual action required”: it does not move to “Ready to upload to KSeF”. It applies the checksum to any VAT number, foreign ones included, and a foreign number almost never passes it, so for a customer with a VAT number from another country the invoice stays there even when the number is correct. The FlexigoTech Cloud validation checks the file against the schema, that is, the format, without the checksum.

Keep reading

Dates in FA(3): P_1, P_6 and DataWytworzeniaFaDate rules in the FA(3) 1-0E schema and in KSeF: P_1 in Polish time, P_6, DataWytworzeniaFa from 2025-09-01. When they give 450 and how Odoo 18-20 fill them.KSeF codes 410 and 415: seller permissions and attachmentsKSeF 410 “Nieprawidłowy zakres uprawnień” and 415 for invoices with attachments: what triggers them in the Ministry's tests and what to check in Odoo 18-20.KSeF code 450: “Błąd weryfikacji semantyki dokumentu faktury”KSeF code 450 means the FA(3) invoice was rejected after its content was checked. Where the real reason is, what Odoo 18, 19 and 20 do not show and how to send it again.
Checked in the module's source code (version 20.0) and the linked sources

Sources