The electronic invoice (ESF) is stuck in the status "In queue for sending": what is happening and how to act
An electronic invoice (ESF) that is stuck in the status "In queue for sending" is one of the most common and simultaneously most frustrating situations for an accountant. The document seems to be generated, signed, and sent — but in the information system, it does not move: it does not change to "Delivered," "Processed," or, even more so, to a status confirming receipt by the recipient. In practice, this status almost always indicates an issue with the exchange between the accounting software and the electronic invoice system (web application), rather than an error with the document itself. Let's break it down auditor-style: first, the nature of the status, then typical reasons, followed by the verification procedure, and finally, the caveats to keep in mind.
What the status "In queue for sending" means
Essentially, this is an intermediate, transport state. It indicates that the ESF has already left the stage of filling out and signing and has been placed in the queue for transmission to the external system, but confirmation of its actual delivery has not yet been received. The key conclusion to draw immediately is that the presence of such a status does not mean that the document has been accepted and registered. Until the system returns a confirming status, it is premature to consider the issuance completed. This is important for assessing tax risks: the obligation to issue an ESF is considered fulfilled when the document has actually been processed on the side of the electronic invoice system, not when it is queued in your software.
Typical reasons for being stuck
In my experience, ESFs stuck in the queue are almost always explained by one of the following groups of reasons.
1. Issues on the side of the electronic invoice system service. The portal may be unavailable due to technical work, increased load (especially at the end of reporting periods when everyone is issuing documents simultaneously), or a temporary failure. In this case, documents accumulate in the queue for all users and are sent automatically as soon as the service is restored. This is the most common reason, and it is beyond your control.
2. Connection issues on the user's side. Lack of or unstable internet, blocking of outgoing connections by the corporate firewall or antivirus, proxy server, network restrictions of the organization — all of this prevents the accounting software from reaching the service, and the document remains in the queue.
3. Issues with the electronic signature. An expired digital signature certificate, a revoked or not yet activated key, a signature issued not for the correct person or with the wrong authority — these are common reasons why the sending does not complete. Sometimes the document is signed locally, but the signature does not pass verification on the service side.
4. Exchange settings in the accounting software. Incorrectly specified connection parameters to the service, outdated configuration or platform version, unexecuted synchronization, disabled scheduled exchange — all of this leaves documents "hanging."
5. The state of the document or the counterparty. Sometimes the reason lies in the data: unfilled mandatory details, incorrect information about the recipient, issues with the counterparty's status in the system. In this case, the document may not proceed further in the queue until the issue is resolved.
Verification procedure: from simple to complex
The auditing principle is to move from the most likely and least labor-intensive to the complex. I recommend the following sequence.
Step 1. Ensure that the problem is not widespread. Check if documents are stuck only for you or for all users in the organization; are other ESFs being sent at all. If everything is stuck at once — it is highly likely that this is a service-side issue, and it is wiser to wait, periodically initiating a resend. It is useful to check the availability of the electronic invoice system portal directly through the browser.
Step 2. Check the connection and signature. Ensure that there is stable internet, that the digital signature certificate is valid and not revoked, and that you are signing with the key registered for the organization. An expired certificate is a very common "silent" reason.
Step 3. Check the exchange settings in the program. Look at the connection parameters to the ESF service, the relevance of the configuration and platform version, and the status of scheduled exchange tasks. If necessary, perform the exchange manually and check the service messages — often the error text is visible there, which immediately indicates the reason.
Step 4. Open the document itself and the exchange log. Many accounting solutions maintain a log or protocol of sending, where the result of the last attempt and the service's refusal text for a specific ESF can be seen. This is the most informative source: do not guess, but read what the system actually returned.
Step 5. Check on the portal. Log into the web application of the electronic invoice system and see if this document is there and in what state it is. Sometimes, the status in the accounting program is still "In queue," while on the ESF portal it has already been accepted — in this case, you just need to wait for the status synchronization, rather than issuing the document again.
Special caution: do not create duplicates
This is perhaps the main caveat. When faced with a stuck document, an accountant under pressure of deadlines often starts issuing the ESF anew. As a result, when the service is restored, both copies are sent, and the counterparty ends up with duplicates. Before reissuing, always check on the portal whether the original document has been sent. Resending the same document (using the "Send again" button) and issuing a new document are different actions; the first is safe, the second creates a duplicate.
When to wait and when to act
If the reason is external (the service is unavailable, technical work is ongoing, peak load) — the correct tactic is to wait with periodic resending; the queue will clear itself. If the delay is caused by your side (signature, settings, document data) — waiting will not change anything, and you need to eliminate the cause. Distinguishing one from the other is precisely what the exchange log and checking the widespread nature of the problem help with.
The issue of deadlines and responsibility
I want to emphasize something that is often forgotten. The issuance of an ESF is limited by the deadlines established by the tax legislation of the Republic of Kazakhstan, and a technical failure does not automatically relieve the obligation to issue the document. If the electronic invoice system service was officially unavailable, the procedure and consequences for deadlines are determined by established rules and clarifications from the authorized body. Therefore, in the case of prolonged failures, it makes sense to document the fact of unavailability (screenshots, time, error messages) — this is your evidence base in case of questions. I do not recommend relying on verbal assessments of deadlines and penalties: refer to the current norms and official clarifications at the time of the event, as they change periodically.
Prevention
To reduce the likelihood of this situation recurring, it is useful to: monitor the validity period of the digital signature in advance and renew the certificate before it expires; keep the version of the accounting configuration and platform up to date; avoid postponing the issuance of ESFs to the last day of the period when the load on the service is maximum; set up regular automatic exchanges and periodically review the log for unfinished sends; check the completeness of document details and the accuracy of counterparty data before sending.
In summary
The status "In queue for sending" is not a death sentence for the document, but a signal that the exchange with the electronic invoice system is not yet complete. In the overwhelming majority of cases, the reason lies either on the service side (in which case waiting and resending helps) or in the signature, connection, or exchange settings (in which case the cause needs to be addressed based on the exchange log). The main safety rule — before reissuing the document, ensure on the portal that the original ESF has indeed not been sent, to avoid duplicates. And remember: the obligation is considered fulfilled upon the actual receipt of the document by the system, not upon its queuing, so ensure that each ESF reaches a confirming status and keep track of the issuance deadlines established by law.