Invoice rejected by KSeF? Common errors and how to fix them

A technically successful response to a submission request does not yet mean that KSeF has accepted the invoice. Status 100 means accepted for further processing, status 150 means processing is underway, and only status 200 confirms invoice success.

A rejected document receives neither a KSeF number nor a UPO and is not issued in KSeF. Read the error code, description and details first. Only then correct P_1, the FA(3) XML, permissions, encryption or another indicated cause.

The shortest safe procedure is to check the status, preserve the response and submitted XML, rule out an earlier success, correct the source of the error, validate the new file, submit it again and monitor it until the KSeF number and UPO are available.

You see a message after submission but have no KSeF number or UPO. Do not immediately submit the invoice again. The endpoint may accept the request, encrypted file and metadata before invoice processing has finished.

Statuses 100 and 150 are neither rejection nor final success. Continue checking the same invoice instead of creating another submission.

Interpret error codes together with the description, details and extensions fields. The code identifies the problem category, while the response details point to the specific cause.

Do not resubmit a document merely because UPO is not visible yet. Check the status and KSeF number first.

A session or invoice reference number tracks a technical operation. It is not a KSeF number. The KSeF number identifies an invoice accepted by the system, while UPO is the official receipt available after positive processing.

The invoice status may include the KSeF number, its assignment date and a UPO download address. These values result from invoice success, not from merely starting a submission.

If verification is negative, KSeF assigns no number. The document was not issued in KSeF, so its data may be corrected and submitted again as an original invoice rather than a correction.

P_1 contains the issue date declared by the issuer. Compare it with the actual date on which the document was submitted to KSeF. Three relationships lead to three different outcomes.

Rejection example: the file is submitted on June 2, 2026, but P_1 contains June 3, 2026. A future date causes the XML to be rejected at the gateway.

Offline24 example: P_1 contains June 2, 2026, and the invoice is submitted on June 3, 2026. An earlier P_1 does not automatically cause rejection. The document is treated as issued in offline24 mode.

FA(3) has been the applicable structured invoice format since February 1, 2026. KSeF compares the submitted XML with the declared XSD structure. A missing required field, invalid value format, wrong data type, incorrect element order or incompatible schema may cause rejection.

Code 430 indicates an invoice file verification error. Code 450 indicates a semantic verification error. Read the response details, correct the source data and generate the XML again.

KSeF validation has limits. The Polish Ministry of Finance states that the system does not verify invoice calculations and does not reject an invoice solely because VAT was calculated incorrectly from the net amount. Acceptance therefore does not confirm full accounting, tax or business correctness.

Being able to authenticate in KSeF does not automatically grant the right to issue invoices in every context. Protected API resources require an access token, and submitting a standard invoice requires the permission identified as InvoiceWrite.

Code 410 indicates an invalid invoice permission scope. Check whether the session was opened for the correct taxpayer, whether the token or session is valid, who is submitting the document and whether that person or entity may issue invoices in the selected context.

Editing the XML will not solve an access problem. Correct the authentication or permission configuration first, then submit the substantively unchanged document again.

Code 440 means that KSeF identified a duplicate invoice. The response may contain originalSessionReferenceNumber and originalKsefNumber, which lead to the original session and previously assigned KSeF number.

Find the referenced invoice, check its status and retrieve UPO. Do not generate a new document or change the invoice number merely to bypass duplicate detection.

Official sources confirm code 440 and the API response data, but they do not provide a sufficient basis for publishing the detailed duplicate-detection algorithm. Base the decision on the API result and evidence of the earlier success.

1. Keep the session reference, invoice reference, exact operation time and submitted XML.

2. Retrieve the status of the specific invoice. Do not rely only on confirmation that the endpoint accepted the request.

3. Read code, description, details and extensions. Save the complete response because a shortened UI message may omit diagnostic information.

4. Assign the error to a category: P_1 date, FA(3) or XSD, semantics, permissions, encryption, attachment, duplicate or technical problem.

5. Check whether the document already has a KSeF number before every resubmission.

6. Correct the source data rather than only editing the final XML text, so the system does not generate the same error again.

If the invoice did not receive a KSeF number, correct the source data or access. Generate a new FA(3) XML, verify its structure, open a valid session and submit the document again.

Monitor the invoice until it reaches a final status. Statuses 100 and 150 require further waiting. An error requires another diagnosis. Treat the process as complete only after status 200, assignment of the KSeF number and availability of UPO.

If the document already has a KSeF number, do not edit it or submit a corrected version as the same invoice. The accepted document remains in the system and errors are corrected under the rules for corrective invoices.

Before creating another submission, complete the entire control list. Most importantly, rule out the possibility that the earlier operation succeeded even though your application has not displayed UPO yet.

A local validator can identify technical XML problems before submission, but it does not replace KSeF business validation, confirm system acceptance or guarantee full tax correctness.

This guide diagnoses a specific rejection. The full process is explained in Sending invoices to KSeF, while UPO in KSeF explains the confirmation available after success.

The document structure is covered in XML and the FA(3) format in KSeF. If the invoice already has a KSeF number, follow Corrective invoices in KSeF.

After an error, do not start by editing random fields. Establish the final status, preserve the full API response, rule out an earlier success and correct the source system.

Check the new XML structure, permissions and P_1, then submit it in a valid session and monitor it until status 200, the KSeF number and UPO. If a KSeF number already exists, issue a correction instead of resubmitting.

Recommended guides: Sending invoices to KSeF, UPO in KSeF, XML and FA(3) and Corrective invoices in KSeF.