Skip to main content
FA(3) · schema 1-0E

Dates in FA(3): P_1, P_6 and DataWytworzeniaFa

An FA(3) invoice carries three dates with rules set by the schema or by KSeF: the issue date, the delivery date and the moment the file was generated. The schema limits the range of each, and KSeF adds its own rule for the issue date; breaking any of them ends in status 450.

FlexigoTech · Editor in charge: Víctor Gómez · Updated 5 November 2026

Key facts

Module
KSeF 2.0
Versions
Odoo 17, 18, 19 and 20
Checked
in the module's source code, version 17.0 and 20.0 · against the sources linked at the end
Reading time
2 min

Where a date error comes from

When a date falls outside the schema's range or outside KSeF's rule, the invoice gets status 450, “Błąd weryfikacji semantyki dokumentu faktury” (invoice document semantics verification error). The Ministry of Finance checks two such cases in the tests of its library: P_1 set to tomorrow in Polish time, and a DataWytworzeniaFa from before 2025-09-01.

FA(3) dates card: P_1, P_6 and DataWytworzeniaFa
The three dates of an FA(3) invoice and their limits in the 1-0E schema.

The three dates and their rules

P_1
“Data wystawienia, z zastrzeżeniem art. 106na ust. 1 ustawy” (date of issue). Type TDataT, “Data zdarzenia w okresie od 2006-01-01 do 2050-01-01” (a date between 2006-01-01 and 2050-01-01). KSeF adds: it cannot be later than the date the document is received by the system, counted in Polish time.
P_6
Date of delivery of goods or completion of the service, when it is shared by all lines and differs from the issue date. Same TDataT type.
DataWytworzeniaFa
“Data i czas wytworzenia faktury” (date and time the invoice was generated), from 2025-09-01T00:00:00Z to 2050-01-01T23:59:59Z.
OkresFa
The period the invoice covers, with P_6_Od and P_6_Do, instead of a single P_6 date.

How Odoo fills them

FA(3) fieldOdoo 18, 19 and 20
P_1The invoice date.
P_6The delivery date, only when set and different from the invoice date.
DataWytworzeniaFaThe moment the file is generated, in UTC.
OkresFaNot filled; the template only has a “TO-CHECK” comment.

Before sending, Odoo skips an invoice dated after today: “The move was skipped because it is future-dated”. It counts “today” in the user's time zone, while KSeF counts it in Warsaw. When the user works in a time zone ahead of Poland, an invoice with the user's today can still be tomorrow in Poland and come back with 450. The Ministry's test flags the same thing the other way round: between 00:00 and 02:00 CET/CEST, “tomorrow in UTC” can be today in Poland.

Odoo 17 has no l10n_pl_edi: the date is set by the program that creates the FA(3) file.

Diagram: how Odoo 20 fills the FA(3) dates and what the schema and KSeF require
Diagram based on the FA(3) template of Odoo 20, the FA(3) 1-0E schema and the KSeF documentation; struck-through items are what Odoo does not write.

What to do with a 450 caused by a date

  1. Check the invoice date: it cannot be later than the day of sending in Poland.
  2. Check the time zone of the user who sends the invoices, in their preferences in Odoo.
  3. If the service ran over a period, remember Odoo will not write OkresFa; only the delivery date ends up on the invoice.
  4. Reset the invoice to draft, fix the date, confirm it and send it again.

Our module, Poland KSeF 2.0 Validator, validates the file against the FA(3) schema with the FlexigoTech Cloud subscription, so it catches a P_1, P_6 or DataWytworzeniaFa outside the schema's ranges. It cannot check P_1 against the moment KSeF receives it, because only KSeF applies that rule. On Odoo 17 it validates the file uploaded to the invoice.

Keep reading

KSeF code 450: “Błąd weryfikacji semantyki dokumentu faktury”KSeF code 450 means the FA(3) invoice was rejected after its content was checked. Where the real reason is, what Odoo 18, 19 and 20 do not show and how to send it again.The buyer in FA(3): identifier, JST and GV in Podmiot2The buyer in the FA(3) 1-0E schema: NIP, EU VAT number, other tax ID or BrakID, plus JST and GV. The NIP checksum in KSeF and what Odoo 18-20 write.KSeF exceptions when sending an invoice: 21405, 21180, 21184 and the restKSeF exceptions when sending an invoice: 21405, 21001, 21155, 21166, 21167, 21173, 21180, 21184, 21402 and 21403. What they mean and how Odoo 18-20 show them.
Checked in the module's source code (version 17.0 and 20.0) and the linked sources

Sources