KSeF code 450: “Błąd weryfikacji semantyki dokumentu faktury”

What KSeF returns

In the KSeF API 2.9.0 specification, invoice status 450 has a fixed description, “Błąd weryfikacji semantyki dokumentu faktury” (invoice document semantics verification error). What exactly is wrong goes in the details field of that same status. The Ministry of Finance does not publish a list of those messages, so there is no table saying “450 always means this one problem”.

What exists are cases the Ministry checks in the tests of its own ksef-client-csharp library, where it expects exactly code 450:

• issue date P_1 set to tomorrow in Polish time, because KSeF reads P_1 in the Warsaw time zone and refuses a date later than the moment it receives the invoice;
• DataWytworzeniaFa earlier than 2025-09-01T00:00:00Z, the lower limit of that field in the FA(3) 1-0E schema.

What you see in Odoo

Invoices reach KSeF through Odoo's l10n_pl_edi module, which exists in Odoo 18, 19 and 20. When KSeF answers, it sets “KSeF Status” to Rejected and writes a message in the invoice history:

From the KSeF answer Odoo reads the code, the description and the KSeF number. It does not store the details field (it only appends KSeF's description for code 500), so Odoo alone cannot tell you which part of the invoice failed.

Where to get the reason

The details text comes in KSeF's answer to the invoice status request. When you send from Odoo, you need someone who can read it from the API, or a check of the FA(3) file before sending. Odoo 18, 19 and 20 ship a copy of the FA(3) schema inside the module, but outside the tests nothing uses it: the file goes to KSeF without being validated against the schema.

Odoo does watch two things. It will not send an invoice dated after today in the user's time zone (“The move was skipped because it is future-dated”). And it fills DataWytworzeniaFa with the moment the file is generated, in UTC, so the 2025 limit should not come from an invoice issued in Odoo.

How to send it again

1. Find the reason in details, or check the FA(3) file against the schema.
2. Fix the data in Odoo: date, customer, lines.
3. Reset the invoice to draft. For a rejected invoice Odoo clears its KSeF status, number, reference and session.
4. Confirm it and send it again with the “by KSeF (e-Faktura)” option. Odoo only sends invoices without a KSeF status, so without step 3 nothing goes out.

With our module

Poland KSeF 2.0 Validator does not send invoices to KSeF. With the FlexigoTech Cloud subscription, if you click “Validate FA(3) (FlexigoTech Cloud)” before sending the invoice, it validates the FA(3) file against the 1-0E schema and lists each error as a line “[error] XSD (path)”: where in the file, without the message text, up to 100 errors. The result does not stop l10n_pl_edi from sending: a “Not valid” invoice goes out anyway if you send it. It cannot catch what KSeF only checks on its side, such as P_1 against the time of receipt. Once l10n_pl_edi sends the invoice, the earlier validation turns Expired and the module checks the file KSeF actually received. On Odoo 17 it validates the FA(3) file uploaded to the invoice.

Keep reading