Overview
DaneIdentyfikacyjne is the identification block inside Podmiot2, the buyer of a FA(3) invoice. Unlike the seller, the buyer can be identified in several ways, and the XSD requires exactly one of them. The block also carries the buyer's name (Nazwa).
The four identification options
The buyer block accepts one of four branches:
- NIP — a Polish tax identification number.
- KodUE plus NrVatUE — an EU VAT identifier for a foreign EU customer: the two-letter country code plus the VAT number.
- KodKraju plus NrID — a non-Polish, non-EU tax identifier together with the country code that issued it.
- BrakID — value 1, used when the buyer has no tax identifier, for example a private individual in a B2C transaction.
Because the XSD models these as a choice, sending two branches at once fails validation. Nazwa (the buyer's name, up to 512 characters) is part of the same block and is always allowed.
Which one to pick
For a Polish business customer, send NIP. For a customer in another EU country, send KodUE and NrVatUE. For a customer outside the EU with a local tax identifier, send KodKraju and NrID. For a private individual with no tax identifier, send BrakID.
Note that NrID is a free-text identifier of up to 50 characters and must be accompanied by the two-letter KodKraju of the country that issued it. If you are not sure whether a buyer has a tax identifier, ask for it before issuing: choosing BrakID for a buyer who actually has a NIP can force a corrective invoice later.
What Notaly does
Notaly's API accepts the buyer identifier you send and writes it to the correct branch. The sandbox examples use a Polish buyer identified by NIP, because that is the simplest case to verify against the KSeF TEST environment.
Choosing the wrong branch is the most common buyer-identification error. If a customer gives you a Polish NIP, use NIP even when they also hold an EU VAT number; the KSeF schema expects one identifier, and the Polish NIP is the correct one for a domestic transaction. Verify the number before issuing, because a mistake after the fact usually means a corrective invoice.
A complete, valid FA(3) example appears below with a Polish buyer identified by NIP.
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Naglowek>
<KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
<WariantFormularza>3</WariantFormularza>
<DataWytworzeniaFa>2026-10-12T07:23:07Z</DataWytworzeniaFa>
<SystemInfo>einvoice-api</SystemInfo>
</Naglowek>
<Podmiot1>
<DaneIdentyfikacyjne><NIP>2745013933</NIP><Nazwa>Example Sp. z o.o. (FICTIONAL)</Nazwa></DaneIdentyfikacyjne>
<Adres><KodKraju>PL</KodKraju><AdresL1>ul. Testowa 1, 00-001 Warszawa</AdresL1></Adres>
</Podmiot1>
<Podmiot2>
<DaneIdentyfikacyjne><NIP>1234563218</NIP><Nazwa>Test Customer S.A. (FICTIONAL)</Nazwa></DaneIdentyfikacyjne>
<Adres><KodKraju>PL</KodKraju><AdresL1>ul. Probna 2, 30-001 Kraków</AdresL1></Adres>
<JST>2</JST>
<GV>2</GV>
</Podmiot2>
<Fa>
<KodWaluty>PLN</KodWaluty>
<P_1>2026-10-12</P_1>
<P_2>FV/2026/10/001</P_2>
<P_13_1>1000.00</P_13_1><P_14_1>230.00</P_14_1>
<P_13_2>301.00</P_13_2><P_14_2>24.08</P_14_2>
<P_15>1555.08</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>SaaS subscription - October</P_7>
<P_8A>pcs.</P_8A>
<P_8B>1</P_8B>
<P_9A>1000.00</P_9A>
<P_11>1000.00</P_11>
<P_12>23</P_12>
</FaWiersz>
<FaWiersz>
<NrWierszaFa>2</NrWierszaFa>
<P_7>Support</P_7>
<P_8A>hrs.</P_8A>
<P_8B>2</P_8B>
<P_9A>150.50</P_9A>
<P_11>301.00</P_11>
<P_12>8</P_12>
</FaWiersz>
</Fa>
</Faktura>Sources
Source: crd.gov.pl