KSeF

Page 1 of 3

• 

  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

  KSeF archiving and retention: what to keep for 10 years

  The legal invoice in KSeF is the structured FA(3) XML, and the UPO together with the KSeF number are your proof that it was accepted. KSeF keeps the structured invoices it stores for 10 years, so you can retrieve them while your access lasts; locally you should archive the XML, the UPO number and the KSeF number together. Treat the PDF as a readable copy for people, not as the document of record.

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

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

  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

• 

  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.

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

• 

  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.

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

  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