FA(3)

Page 1 of 1

• 

  FA(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.

  Tomek·Oct 12, 2026·3 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.

  Tomek·Oct 12, 2026·3 min read

• 

  KSeF

  FA(2) to FA(3): what changes when you migrate

  FA(3) is the current structured invoice schema for KSeF, and migrating from the earlier FA(2) structure is a field re-mapping exercise, not just a rename of the root element. In FA(3) the invoice data — including P_6 (the delivery or service date), the Podmiot1/Podmiot2 party blocks and the FaWiersz line items — lives inside the Fa element, separate from the form header (Nagłówek). Re-check every field position against the current XSD rather than assuming FA(2) positions still apply.

  Tomek·Oct 12, 2026·3 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.

  Tomek·Oct 12, 2026·2 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.

  Tomek·Oct 12, 2026·3 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.

  Tomek·Oct 12, 2026·3 min read

• 

  KSeF

  KSeF UPO and invoice status: what happens after you send

  The UPO (Urzędowe Poświadczenie Odbioru) is the official proof of receipt that KSeF returns when it accepts a submitted FA(3) invoice. After you send an invoice it moves through a short status cycle — submitted, then accepted or rejected — and the UPO is the confirmation you archive as evidence. Reading that status correctly lets you automate retries and tell customers exactly where their invoice stands.

  Tomek·Oct 12, 2026·2 min read

• 

  KSeF

  VAT rates in KSeF: 23%, 8%, 5% and 0%

  The four VAT rates Notaly's e-invoicing API accepts are 23%, 8%, 5% and 0%, one rate per invoice line. The 7% rate, exemptions (zw) and reverse charge (odwrotne obciążenie, oo) are not supported today, so a line using one of them fails Notaly's validation with a 422 before it reaches KSeF.

  Tomek·Oct 12, 2026·3 min read