Overview
The seller and buyer tax identifiers are the most common cause of a rejected FA(3) invoice: the seller NIP must match the authenticated KSeF context, and the buyer NIP must be a valid Polish tax identification number. In the FA(3) schema the seller is Podmiot1 and the buyer is Podmiot2, and each party carries its NIP inside its identification block.
Podmiot1 and Podmiot2
The FA(3) invoice is one structured XML document whose parties are the seller (Podmiot1) and the buyer (Podmiot2). Each block holds the party's identifiers — the tax identification number (NIP) — together with its name and address. Keeping these two blocks clean is the cheapest way to avoid a rejection, because a party identifier error stops the whole submission before anything else is considered.
The seller NIP must match the session
The seller is the taxpayer authenticated to KSeF. When you send an invoice inside a session, the seller NIP in the document must match that authenticated context. A mismatch means the document does not line up with the identity that opened the session, and KSeF rejects it. This is why sandbox and production use different credentials: the seller NIP in your test data must match the sandbox's authenticated seller.
Validating the buyer NIP
The buyer NIP is your counterparty's Polish tax identification number. A missing, malformed or non-existent NIP is a common cause of a party-related rejection, so validate it before submission rather than discovering the problem in the KSeF response. The buyer NIP does not need to authenticate anything — it identifies the customer — but it must be a real, correctly formatted identifier.
Common rejection causes
Most party rejections fall into three buckets: the seller NIP does not match the authenticated session, the buyer NIP is missing or malformed, or an identifier is placed in the wrong block. Read the error code in the KSeF response, fix the specific identifier, and resubmit — do not guess by editing several fields at once.
How Notaly helps
Notaly maps the seller and buyer onto the FA(3) structure for you and validates the payload against its own rules before it reaches KSeF — including the seller NIP against the authenticated context. That means a party error surfaces as a clear validation message on your side, not as a cryptic rejection from the platform.
FAQ
Which party is Podmiot1 in FA(3)? Podmiot1 is the seller and Podmiot2 is the buyer. Each holds its NIP under its identification block.
Why does the seller NIP have to match the session? The seller is the taxpayer authenticated to KSeF, so the document's seller NIP must match that authenticated context.
Disclaimer
Notaly is not a tax, accounting or legal advisor. This article is general information, not tax advice, and may be outdated. You are responsible for your own VAT compliance; confirm with a qualified accountant where required.
Sources
Source: crd.gov.pl