Overview
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.
The root: Faktura, Nagłówek and Fa
The document opens with the Faktura element. Nagłówek holds the form metadata — KodFormularza, WariantFormularza, DataWytworzeniaFa and SystemInfo — not the invoice figures. The invoice-level fields you normally think of first, P_1 (issue date) and P_2 (invoice number), live in the Fa element together with the parties and the line items, not scattered across the document.
Podmiot1 and Podmiot2: the parties
Podmiot1 is the seller and Podmiot2 is the buyer, both inside the Fa element. Each block holds the party's identifiers and address: the tax identification number (NIP) under the identification data, the name, and the address. Keeping the seller NIP and buyer NIP clean is the most common way to avoid a rejected invoice, because the identifiers must match what KSeF expects in the authenticated context.
FaWiersz: the line items
The invoice lines live in FaWiersz, inside Fa. A line carries the item name (P_7), the unit and quantity (P_8A and P_8B) and the net unit price, which feed the line and invoice totals. The totals are grouped by VAT rate, and the rate-specific details belong to the official field references rather than to this structural overview.
Why the structure matters
The FA(3) schema is strict: an invoice that does not validate against the XSD is rejected, and KSeF reports it as not correctly processed in the invoice status. That is why generating the XML from a validated library or an API is safer than assembling it by string concatenation. A small mistake in element order or a missing identifier stops the whole submission.
How Notaly handles it
Notaly takes your JSON, maps the seller, buyer and lines onto the FA(3) structure, validates the result against the official XSD and submits it to KSeF. You never manipulate Nagłówek, Fa, Podmiot or FaWiersz directly; you provide the data and receive the KSeF number and UPO back.
FAQ
What are the main parts of a FA(3) invoice? The root element is Faktura, which contains Nagłówek (form metadata) and Fa (the invoice data: Podmiot1 for the seller, Podmiot2 for the buyer, and the FaWiersz line items).
Which field is the invoice number? P_2 is the invoice number and P_1 is the issue date, both in the Fa element.
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