Sending an ESF is a chain of several links: your accounting software (or personal account in the ESF IS), the electronic digital signature, the internet channel, and the state document-reception service itself. A failure in any of these links stops the entire chain. The good news is that the vast majority of such failures are typical and can be resolved using a clear algorithm — without contacting support, or with a quick request if the problem is on the service side.
In this article, we will examine why an ESF may fail to send, how to localize the cause, and what to do step by step so that the document goes through and deadlines are not missed.
Who this concerns
The problem is relevant for everyone who is obliged to, or voluntarily issues, electronic invoices:
- VAT payers — issuing an ESF is mandatory for them;
- participants in the turnover of goods** subject to ESF requirements (including goods from the lists and marked/traceable products);
- companies and sole proprietors (IP) that issue an ESF at the buyer's request or as part of public procurement;
- accountants and operators working both through the ESF IS web account and through accounting systems (for example, 1C configurations with an exchange module).
Those with a large flow of documents and tight period-closing deadlines are especially sensitive to failures: a single "stuck" ESF can delay settlements with the counterparty and their VAT deduction on their side.
Why an ESF fails to send: the main causes
It is convenient to divide the causes into several groups — this helps to quickly narrow down the search.
1. Problems with the electronic digital signature (EDS). The most common category. The certificate has expired, was revoked, the wrong key was selected (for example, an individual's key instead of the organization's key), the system time on the computer has drifted, or NCALayer or the required modules and root certificates are not installed. A signature that "worked yesterday" may not be accepted today precisely because of an expired validity period.
2. Errors in the document itself. The system checks the ESF against format-logical rules. Mandatory details are not filled in, an incorrect BIN/IIN of the counterparty, a mismatch of goods codes, dates, amounts or rates, missing marking/traceability data, broken numbering. Such a document is rejected with the error text, and it needs to be corrected rather than resent as is.
3. Technical and network causes. No stable internet, blocking by the antivirus or firewall, browser problems (outdated version, disabled plugins), an overflowing cache, a failure on the local server or in the accounting system's exchange module.
4. Problems on the service side. Scheduled or emergency maintenance, system overload on peak days (end of month, reporting dates). In this case, the error occurs for all users simultaneously, and the solution is to wait for recovery rather than change your settings.
5. Organizational restrictions. The absence or inactive status of the taxpayer, an unregistered operator/user, the lack of the necessary rights for the employee whose signature is used to send.
What to do: a step-by-step breakdown
Proceed from simple to complex — that way you won't waste time reconfiguring where the failure is temporary.
Step 1. Read the error text. The system almost always indicates the cause: "certificate validity period expired," "invalid format," "mandatory field not filled in." This is the main guide. If the error is about the document — go to step 4; if about the signature — to step 3.
Step 2. Check whether it is a global failure. Ask colleagues and professional communities whether others' ESFs are being sent. Check the news and notifications section on the portal. If the problem is widespread — it is maintenance or service overload; record the time of your attempts (screenshots with the date) and retry sending later.
Step 3. Sort out the EDS. Make sure the selected key is exactly the organization's (or authorized person's), the certificate's validity period has not expired, and the system date and time on the computer are correct. Update or reinstall the cryptographic provider, install the current root certificates. If the signature has expired or been revoked, issue a new one at a certification authority and reinstall it.
Step 4. Correct the document. Using the format-logical error text, find the problematic field: the parties' details, goods codes, dates, amounts, marking data. Correct it and retry sending. If the document is issued from an accounting system, check that the reference books (counterparties, item catalog, codes) are up to date.
Step 5. Check the equipment. Update the browser, clear the cache, temporarily disable conflicting extensions, check the internet connection, add the portal and the exchange module to the antivirus/firewall exceptions. When working through 1C or another system, restart the exchange session and check the operator account settings.
Step 6. Contact support. If the document still does not go through after corrections, contact the technical support service serving your company. Prepare the ESF number and date, the exact error text, screenshots, and information about the program version — this will speed up the resolution.
How to prevent recurrence and not miss deadlines
Prevention saves more time than handling emergencies. Practical habits:
- Monitor the validity period of the EDS and renew the signature in advance, not on the last day before issuance.
- Regularly update the cryptographic provider, browser, and accounting system (the ESF exchange module) to comply with the service's current requirements.
- Keep reference books in order: correct BIN/IIN of counterparties, up-to-date goods codes, marking and traceability data.
- Do not postpone issuance to the final dates. During reporting peaks, the service is more heavily loaded, and there is almost no time left to correct errors.
- Keep evidence of sending attempts (screenshots with the date/time and error text) — they will be useful if the failure was on the service side and the deadline formally passed.
For ESF issuance deadlines, rely on the current legislative requirements and the tax authority's clarifications for your situation — the exact calendar limits depend on the type of transaction and the taxpayer's status, so they should be checked against official sources rather than from memory.
Frequently asked questions
Why is the ESF stuck in the "Sending" status and not changing status? — Most often this is a temporary connection failure or service overload. Check the internet, wait for the status to update, and, if necessary, retry sending later; if the status does not change for a long time — contact support with the document number.
The system says the certificate is invalid, although the signature worked before. — Most likely, the EDS validity period has expired, the system time has drifted, or the wrong key was selected. Check the date on the computer, make sure you are using the organization's key, and if the period has expired — issue and install a new signature.
The document is rejected with a format-logical error — what should I do? — This is an error in the content of the ESF. Read the message text, find the indicated field (details, codes, amounts, dates, marking data), correct it, and send again. Resending without correction will not help.
All my colleagues' ESFs are also failing to send — is this my problem? — No. A widespread failure indicates maintenance or service overload. There is no need to change anything in your settings: record the time of your attempts and retry sending after the system's operation is restored.
What should I do if the issuance deadline formally passed due to a service failure? — Keep evidence that the failure was on the system side (screenshots with the date and error text) and send the document immediately after recovery. In a disputed situation, these materials will help confirm that the delay was not your fault.