Blog

Notaly blog

Practical answers on KSeF, FA(3) and e-invoicing in Poland.

Latest postFA(3)

FA(3): what the KSeF invoice format actually is

FA(3) is the structured XML format that Poland's KSeF system uses to represent an e-invoice, defined by an official schema (XSD) published by the Ministry of Finance. It is not a printable document like a PDF — it is machine-readable data that encodes the seller, the buyer, the line items, the totals and the VAT fields. In practice you generate the XML from your invoice data and validate it against the schema, rather than writing it by hand.

TomekOct 12, 20263 min read

FA(3)
FA(3) XML structure: Nagłówek, Fa, Podmiot1/2 and FaWiersz

A KSeF FA(3) invoice is one structured XML document whose root element is Faktura. Nagłówek carries the form metadata (form code, variant, creation timestamp and system info), while the invoice data — the issue date P_1, invoice number P_2, the parties (Podmiot1 for the seller, Podmiot2 for the buyer) and the line items (FaWiersz) — lives in the Fa element. You do not need to write this XML by hand — an API such as Notaly's builds it from a plain JSON payload.

TomekOct 12, 20263 min read
Deadlines
KSeF deadlines: who must switch and when

KSeF (Krajowy System e-Faktur) is Poland's national e-invoicing system, and the obligation to issue structured invoices applies to active VAT taxpayers in a phased way: when a company must switch depends on its size under the schedule published by the Ministry of Finance. The rollout has been postponed more than once, so confirm the date that applies to you against the current official schedule before acting. What does not change is the technical requirement — once your obligation applies, B2B invoices must be issued as structured FA(3) XML with a KSeF number and a UPO.

TomekOct 12, 20263 min read
KSeF
KSeF error codes: how to read a rejected invoice

KSeF reports problems as exception codes in the response body alongside an HTTP status, and the code — not the HTTP number alone — tells you what actually failed. Common causes are an invalid authentication challenge, an invalid certificate, or an invoice that fails the FA(3) schema and is then reported as not correctly processed. Read the Polish description against the official KSeF code table instead of guessing, because the same numeric code can mean different things in different endpoints.

TomekOct 12, 20263 min read
FA(3)
Correction invoice (faktura korygująca) in KSeF: how it is structured

In KSeF, a correction invoice (faktura korygująca) is a new FA(3) document that references the invoice it corrects through fields such as NrKSeFFaKorygowanej (the KSeF number of the corrected invoice) and PrzyczynaKorekty (the reason for the correction). You do not edit the original invoice; you send a correcting document that points back to it. Whether a correction is required, and how the VAT difference is settled, is a tax decision for your accountant — the FA(3) format only describes the structure.

TomekOct 12, 20262 min read
Integrations
KSeF integration: build it yourself or use an API?

Building a KSeF integration yourself means generating FA(3) XML, authenticating to KSeF, sending encrypted invoices and polling their status; using a KSeF API means you send plain JSON and the provider owns the rest. For most SaaS and e-commerce teams, an API like Notaly is faster and cheaper to ship and maintain. Build your own only if you already run a full e-invoicing stack and need maximum control.

TomekOct 12, 20263 min read
KSeF
KSeF invoice numbering: avoid duplicate FA(3) documents (P_2)

P_2 is the invoice number field in the Fa element of an FA(3) document, and it must uniquely identify a single invoice you issue. Use a stable, sequential scheme and never reuse a number, or KSeF can reject the document as a duplicate.

TomekOct 12, 20263 min read
Guides
Switching to KSeF: a practical migration checklist

Moving to KSeF is a data-and-process change, not just an API swap: you need clean party identifiers, an invoice mapping that produces valid FA(3), an authentication method, and a TEST run before production. Working through that short checklist in the sandbox turns the eventual go-live into a configuration change rather than a first attempt.

TomekOct 12, 20263 min read
KSeF
KSeF offline mode: the two QR codes (KOD I and KOD II)

KSeF offline mode is the Ministry of Finance's contingency for invoicing while the platform is unreachable, and in KSeF 2.0 an offline invoice carries two QR codes: KOD I and KOD II. KOD I is the verification link generated by the issuer from the SHA-256 of the invoice XML and shows "OFFLINE" in place of the KSeF number until acceptance; KOD II is the issuer's verification QR signed with a KSeF certificate of type Offline and labelled CERTYFIKAT. The document must still be submitted to KSeF afterwards, within the window set by the Ministry.

TomekOct 12, 20263 min read
FA(3)
Seller and buyer NIP in KSeF: getting the parties right

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.

TomekOct 12, 20263 min read
KSeF
The KSeF invoice PDF and QR code: KOD I vs KOD II

When an invoice is accepted, KSeF returns the UPO (official proof of receipt) and the KSeF number; the readable PDF is a visualisation Notaly generates from the FA(3) data, carrying the official KOD I QR. KOD I and KOD II are two different codes, not two states of one: KOD I is the verification link built by the issuer from the SHA-256 of the XML, and KOD II is the issuer's verification QR, signed with a KSeF certificate of type Offline, added only on an offline invoice.

TomekOct 12, 20263 min read
KSeF
KSeF readiness checklist for small businesses

Readiness for KSeF means having your party data, invoice fields, authentication method and a tested flow in place before your obligation applies. Work through a short checklist — buyer and seller NIPs, FA(3) field mapping, token authentication and a TEST run — so the switch is mechanical rather than a scramble.

TomekOct 12, 20263 min read