Overview
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.
Where FA(3) puts the fields
The FA(3) document has one root element, Faktura, which contains Nagłówek and Fa. Nagłówek holds only the form metadata — form code, variant, creation timestamp and system info. The invoice data you actually care about sits in Fa: P_1 (issue date), P_2 (invoice number), P_6 (the date the goods or service were delivered or rendered) and P_15 (total amount due, VAT included), along with the parties and the line items.
P_6: the delivery or service date
P_6 is the date the sale actually happened — delivery of goods or completion of the service — which can differ from P_1, the issue date. When you migrate, make sure your source field maps onto P_6 and not onto a neighbouring date field, because the two dates mean different things and KSeF validates them separately.
Podmiot1 and Podmiot2: structured parties
The seller is Podmiot1 and the buyer is Podmiot2, both inside Fa. Each carries its own identification block (the tax identification number, NIP) plus name and address. Migration is the moment to normalise this data: a seller NIP that does not match your authenticated context, or a malformed buyer NIP, is the kind of error that fails validation before the invoice is useful.
FaWiersz: the line items
Invoice lines live in FaWiersz inside Fa. A line carries the item name (P_7), the unit and quantity (P_8A and P_8B), the unit net price (P_9A), the line net value (P_11) and the VAT rate (P_12). Map your items onto these fields and let the totals be computed from the lines, so the sums stay consistent.
How Notaly handles the migration
Notaly takes your JSON, maps the seller, buyer and items onto the FA(3) structure, validates the result against the official XSD and submits it to KSeF. That removes the riskiest part of migrating — hand-maintaining the XML — so you send the data and Notaly produces the correct FA(3) document.
FAQ
Is FA(3) just FA(2) renamed? No. The structure changed: in FA(3) the invoice data sits in the Fa element, separate from the form header Nagłówek. Re-map fields rather than assume positions carry over.
Where do P_1, P_2, P_6 and P_15 live? All four are inside the Fa element, not in the Nagłówek form header.
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: www.podatki.gov.pl