If your company operates in Poland, KSeF (Krajowy System e-Faktur, Poland's national e-invoicing system) is now the mandatory channel for B2B invoices. Rejections look harmless: the session response carries a three-digit code and a short Polish message. That message almost never names the field that actually failed.
The tax consequence is real. Under Article 106na(1) of the Polish VAT Act, a structured invoice counts as issued on the day it is sent to KSeF. If the first attempt bounced and the corrected file only landed the following month, the reporting period shifts with it.
This article maps the response codes to their concrete causes in the FA(3) file.
What codes KSeF returns for a single invoice
Per-invoice status is defined in the official KSeF 2.0 API specification. These are the terminal codes.
Code Meaning Is it an invoice content problem 200 Success, KSeF number assigned No 405 Processing cancelled due to a session error No 410 Invalid permission scope No, it is permissions 415 Invoice with attachment cannot be sent Partly 430 Invoice file verification error Yes 435 File decryption error No, transport layer 440 Duplicate invoice Yes 450 Invoice document semantics error Yes 500 Unknown error Report to the Ministry 550 Operation cancelled by the system Retry
The distinction matters: 430 is the file and schema layer, 450 covers business rules inside the document, and 440 is a conflict with data already held by the Ministry of Finance.
The 10 errors behind most rejections
1. Duplicate invoice number (code 440)
KSeF detects duplicates globally. The key is a combination of three values: seller tax ID (Podmiot1:NIP), invoice type (RodzajFaktury) and invoice number (P_2). Uniqueness is enforced for ten full years counted from the end of the year of issue.
The usual story: an integration timed out, assumed failure and retried with the same number, but the invoice was already in the system. The second variant hits groups where several branches invoice under one tax ID without an agreed numbering scheme.
2. XML encoding and file structure (code 430)
The technical requirements are strict. The file must be UTF-8 without a BOM (bytes 0xEF 0xBB 0xBF), must not contain XML processing instructions, and if a prolog is present it must not declare any encoding other than UTF-8. Discouraged Unicode characters from ranges such as [#x7F-#x84] and [#xFDD0-#xFDEF] are rejected outright.
A BOM is the classic failure when XML is generated on Windows. Control characters usually arrive with product names pasted from a spreadsheet or an inventory system.
3. Tax ID fails the pattern or the checksum
The TNrNIP type in the FA(3) schema enforces the pattern [1-9]((\d[1-9])|([1-9]\d))\d{7}. That means ten digits, no hyphens, no spaces and no PL prefix. A value like PL5252344078 fails at the schema level.
Separately, KSeF verifies the NIP checksum for Podmiot1, Podmiot2, Podmiot3 and PodmiotUpowazniony. That check runs in the production environment only, which is a common trap: the same file passes on test and fails in production.
4. Issue date in the future
The date in P_1 cannot be later than the moment KSeF accepts the document. It is enough for your system to stamp P_1 in local time while the gateway compares against UTC, and invoices created late on 31 January start arriving dated 1 February.
5. Malformed document header
The Naglowek block has fixed values. The kodSystemowy attribute must read exactly FA (3), with a space before the bracket. wersjaSchemy is 1-0E and WariantFormularza is 3. On top of that, DataWytworzeniaFa cannot be earlier than 2025-09-01T00:00:00Z.
That last constraint breaks old test suites and fixtures carried over from FA(2).
<Naglowek>
<KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
<WariantFormularza>3</WariantFormularza>
<DataWytworzeniaFa>2026-08-29T10:15:00Z</DataWytworzeniaFa>
</Naglowek>
6. Amounts in a format the schema rejects
The TKwotowy type carries the pattern -?([1-9]\d{0,15}|0)(\.\d{1,2})?. In practice that bans four things: comma decimal separators, thousand separators, more than two decimal places, and leading zeros.
Value in XML Result 1230.50 Valid 1230,50 Rejected 1 230.50 Rejected 1230.500 Rejected 01230.50 Rejected
Three decimal places are typically a symptom of systems that calculate unit prices at higher precision and copy them straight into value fields. Unit price has its own, more permissive type. Sales values do not.
7. Text fields over the length limit
The base character type in the schema allows 240 characters and is single-line. Company name takes 512, street 65, building number 9, unit number 10, postal code 8, city 56.
What usually breaks is a product name concatenated with its description, and an address where the whole address line was dropped into the street field.
8. Missing permissions in the sending context (code 410)
Sending an invoice requires the right to issue it in the context of that entity. Code 410 shows up when an accounting office has no permission granted for the client's tax ID, when a mandate expired, or when in self-billing the buyer lacks the right to issue on the seller's behalf.
This is not a file problem. Editing the XML will not help.
9. Invoice with an attachment in an interactive session (code 415)
Invoices with attachments may only be sent in batch mode, and the option has to be enabled in advance through the e-Urząd Skarbowy (e-Tax Office) service. The single exception is a technical correction of an offline invoice, which may travel through an interactive session.
10. Document semantics error (code 450)
Code 450 covers rules the schema alone cannot catch. Typical cases: a corrective invoice without a complete DaneFaKorygowanej block, a reference to a KSeF number that does not exist in the system, and inconsistent conditional blocks where a procedure marker is set but the fields that choice makes mandatory are left empty.
Worth remembering: KSeF does not audit the invoice substantively. It will not tell you whether the VAT rate suits the goods. It checks structural completeness and internal consistency.
What to do after a rejection
A rejected invoice has no KSeF number, so it is not a structured invoice and cannot be corrected. You fix the file and resend it under the same number.
A separate path exists for invoices issued in offline mode. If such an invoice already reached the customer with its QR codes and KSeF then rejected it for a technical reason, the Ministry provides a technical correction. You resend the corrected file with identical content, pointing hashOfCorrectedInvoice at the SHA-256 hash of the original rejected document. The system links the two, so the old QR code redirects the customer to the corrected invoice.
Two limits apply: a technical correction is not a way to change invoice content, and it does not solve permission problems.
Pre-send checklist
File saved as UTF-8 without BOM, with no XML processing instructions.
Header:
kodSystemowy="FA (3)",wersjaSchemy="1-0E",WariantFormularza=3,DataWytworzeniaFano earlier than 2025-09-01.Every tax ID as ten digits, no hyphens, no prefix, checksum valid.
P_1is not in the future relative to the send time.Amounts with a dot separator, at most two decimals, no leading zeros.
P_2not previously used for this tax ID and this invoice type.File under 1,000,000 bytes, or under 3,000,000 bytes with attachments.
Issuing permissions for that tax ID active and unexpired.
Local validation against the official XSD completed before sending.
Summary
Most KSeF rejections are not about misreading the law. They come from small format mismatches: a BOM, a comma instead of a dot, a hyphen in a tax ID, a retry after a timeout. Local validation against the FA(3) schema catches all of them before the document leaves your system.
Biurko validates generated XML against the official XSD before batch and offline sends, translates KSeF error codes into messages that point at the actual field, and keeps the full communication history with the Ministry on every invoice. Duplicates are recognised and linked to the original KSeF number rather than surfacing as a false failure.
Create a free account at biurko.io and see what sending to KSeF looks like when errors appear before submission rather than after it.
FAQ
What does KSeF code 440 mean? Duplicate invoice. The system already holds a document with the same combination of seller tax ID, invoice type and invoice number. Uniqueness is checked globally and enforced for ten full years from the end of the year of issue. Check whether your earlier attempt actually succeeded.
Can a KSeF-rejected invoice be corrected? No. A rejected invoice never received a KSeF number, so it is not a structured invoice and cannot be corrected. You fix the file and resend it. Offline invoices are the exception, with a dedicated technical correction path.
Why did the file pass on test and fail in production? Usually the tax ID checksum. KSeF verifies it in the production environment only. A fictitious NIP matching the pattern passes on test, and the identical file is rejected in production.
What is the difference between code 430 and 450? Code 430 is a file verification error: encoding, XML structure, schema mismatch. Code 450 is a semantics error, meaning business rules inside a structurally valid document, such as a correction missing complete data on the invoice being corrected.
Does KSeF check whether the VAT rates are correct? No. It verifies schema compliance, uniqueness, dates, tax IDs and permissions. Substantive accuracy of rates, amounts and counterparty data stays with the issuer. Acceptance by KSeF does not cure a substantive error.