How to check invoice status in KSeF after submission?

Invoice status in KSeF shows whether a document is still being processed, has ended successfully, or needs error diagnostics. The fact that an invoice was submitted is not enough to treat it as accepted.

Statuses 100 and 150 are transitional states, 200 means invoice success, and error statuses require reading the details before any resubmission. Do not confuse a technically successful HTTP response with the invoice status stored in the document status field.

Session status, invoice reference number, KSeF number and UPO are different parts of the same process. Only their combination tells you whether to wait, download confirmation or diagnose rejection.

After sending XML, check the status of the same invoice or session, do not automatically submit a second version, save the KSeF number and UPO when the invoice succeeds, and read the error code, description and response details before making the next decision.

The invoice was sent to KSeF, but you do not know whether it has already been accepted, is still being processed or was rejected. This guide walks through the decisions after submission, from transitional status to KSeF number, UPO or error diagnostics.

After submission, there should be both a technical and business trace. If you only have a general sent message, you do not yet have full control over the process.

The minimum data set is the session reference number, invoice reference number, the seller invoice number from the invoice number field, seller tax ID, submission date, status, possible KSeF number and UPO information. These elements let you return to the same operation instead of guessing whether the document needs to be sent again.

Session status describes the state of the sending container. Invoice status describes a specific document inside that session. A reference number lets you return to the technical operation, but it is not the KSeF number.

In an interactive session, you can track a single document sent within the session. In a batch session or when multiple invoices are involved, you also need to check how many documents were processed correctly, how many were rejected and what statuses individual invoices have.

The KSeF number appears only after the invoice has been accepted. If you only see a reference number, you are still tracking the operation, not confirming document acceptance.

The key rule after submission is simple: monitor a transitional status, archive a success and diagnose an error. There is no single button or single code that replaces checking invoice status.

The table below is a practical decision map. It does not replace the full API documentation, but it helps avoid the most common mistakes after XML submission.

If the invoice status is 100 or 150, the basic reaction is to continue monitoring the same submission. Do not internally publish that the invoice has already been accepted, but do not automatically treat it as rejected either.

If the invoice status is 200, move to the KSeF number, acceptance date and UPO. This is the stage of organizing confirmations, not looking for the cause of an error.

If the status indicates an error, you are not looking for UPO. You read the code, description, details and possible duplicate data. Only then decide whether to correct data, fix permissions, find the original submission or repeat the technical operation.

Do not treat session status as automatic confirmation that every document succeeded. Sessions and invoices have separate control levels. Especially with packages, you need to check counters for correctly and incorrectly processed invoices and the list of documents in the session.

In practice, it is not enough to check whether the session is processed. You need to determine which invoices in that session succeeded, which have errors and which identifiers must be saved. This protects you from a situation where the package looks handled, but a single invoice still needs correction.

Missing UPO is not a diagnosis on its own. For statuses 100 and 150, UPO is not yet the target point because the invoice still has no final result.

For status 200, check the KSeF number, generated UPO download link, link expiry time and the tool through which the document was submitted. The UPO download link is part of the status response and may require querying the status again if the link has expired.

If the problem is missing visible confirmation, go to the guide Missing UPO in KSeF. This article focuses on status after submission, not the full UPO recovery procedure.

Resubmission makes sense only after establishing what happened to the previous operation. If you do not know whether the document already received a KSeF number or whether the API indicated a duplicate, a second submission can only make the event trace harder to interpret.

For status 440, first find the original session and original KSeF number if they were returned. For XML, semantics or permission errors, fix the source of the problem, not only the final file.

The detailed diagnostic procedure is covered in Invoice rejected by KSeF.

In a user workflow, start with the right entity. Select the correct seller tax ID or company context, because a status read in the wrong entity will not explain the real submission.

Then find the invoice by seller invoice number, date, counterparty, reference number or KSeF number if it has already been assigned. Check the document status, not only the status of the last action in the interface.

If the invoice succeeded, save the KSeF number and download UPO in the tool that handled the submission. If the status indicates an error, read the details. Button names are not listed here as definitive because application interfaces and manuals can change.

In an API integration, status is checked in stages. First you establish the session, then the documents in the session, and only after a specific invoice succeeds do you move to UPO. UPO does not replace status. It is the next step after confirmed success.

Typical control paths include the session list, details of a specific session, invoice list in a session, details of a specific invoice and rejected invoice list.

The integration should save at least the session reference number, invoice reference number, status, KSeF number, acceptance date, errors and UPO information. Without this data, later handling of complaints, duplicates or missing confirmation becomes manual.

In KSeFGPT, post-submission status is meant to be readable for someone who does not want to analyze a raw API response. After handling submission, the app helps you see whether the document was passed to KSeF, what status it has, whether a KSeF number appeared and whether UPO is available for the handled document.

This distinction matters: KSeFGPT organizes statuses and confirmations for invoices sent through the app. Do not assume that the tool will retrieve UPO for every invoice that was previously sent by another ERP or another integration. In that case, look for confirmation in the system that performed the submission, in the KSeF Taxpayer Application or in your own API integration.

In practice, this means one work trace: invoice, status, KSeF number and confirmation are linked in the same context. That makes it easier to distinguish a processed document from an accepted one, and an error from a missing visible UPO.

The most common errors do not come from one difficult code. They come from mixing layers: HTTP, session, invoice, reference number, KSeF number and UPO.

After sending an invoice to KSeF, work in a fixed sequence: check status, check identifiers, decide whether to wait, download UPO or diagnose an error. Do not start with resubmission and do not archive only the reference number as proof of acceptance.

If you need the full process, start with Sending invoices to KSeF. After success status, go to UPO in KSeF. When confirmation is not visible, use the guide Missing UPO in KSeF. For a document error, go to Invoice rejected by KSeF.