--- title: "ESF is rejected by the server: data does not match SNT" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-23 canonical: https://buhgpt.kz/suraqtar/esf-otklonyaetsya-serverom-dannye-ne-sovpadayut-s-snt-en source: BuhGPT --- # ESF is rejected by the server: data does not match SNT > **TL;DR:** If an ESF (electronic invoice) is rejected by the server with an error about data mismatch with the SNT (accompanying waybill for goods), the problem can be solved by checking the required field directly through the IS ESF website. Most often the system "complains" about the " --- If an ESF (electronic invoice) is rejected by the server with an error about data mismatch with the SNT (accompanying waybill for goods), the problem can be solved by checking the required field directly through the IS ESF website. Most often the system "complains" about the "name per declaration" field: it is enough to take the correct value from the ESF created on the website based on the same SNT, transfer it to 1C, and resend the document. After this, the invoice data fully matches the data of the accompanying waybill for goods, and the ESF is successfully accepted. Why the "data does not match SNT" error occurs When issuing an ESF for goods for which an SNT was previously drawn up, the IS ESF automatically compares the key details of the invoice with the data of the linked accompanying waybill. If at least one controlled field differs, the server rejects the document. This is a protective mechanism: it prevents the information about the movement of goods from diverging between the two electronic forms. The discrepancy is usually technical in nature and is due to the fact that 1C:Accounting for Kazakhstan and the IS ESF generate or pull up individual values differently — primarily the name of the goods per declaration (according to customs declaration data / information on origin). The wording automatically substituted in 1C may differ from the one recorded in the SNT and "expected" by the server — for example, in word order, characters, or abbreviations. For the system, this is already a mismatch. Step-by-step correction procedure - Open the IS ESF website (taxpayer's cabinet) and create there an ESF based on the required SNT. Creation "based on" guarantees that the fields will be pulled specifically from the waybill data. - Open the ESF created on the website and find the field "name per declaration" — this is the field the system usually complains about upon rejection. - Copy the actual value of this field from the web version of the ESF. - Go to the ESF document in 1C and paste the copied value into the corresponding field, replacing the previous one. - Resend the ESF from 1C. With this approach, the ESF is successfully sent and accepted by the server, since the data in the invoice begins to fully match the data in the SNT. The draft that you created on the website only for verification does not need to be sent — it serves as the source of the reference value. How to make sure the issue is specifically in this field Before correcting the data, you should read the text of the error that the server returns upon rejection. The protocol (status) of the ESF usually indicates the specific detail and the nature of the discrepancy. If the message refers to the name per declaration, the method described above applies directly. If the server points to a different detail, the logic remains the same: you need to find the reference value of the problematic field in the web ESF created based on the SNT and bring the value in 1C into line with it. - Compare not only the name text, but also the presence of extra spaces, quotation marks, Latin/Cyrillic characters — visually they may look identical, but differ for the server. - Check that you are comparing the line for exactly the item (the position) that the error points to. - Make sure the ESF in 1C is linked to the same SNT as the web version. How to avoid repeating the error To prevent discrepancies from arising in subsequent invoicing, put in order the item reference catalog and the data pulled into the ESF: - Maintain a correct and stable name per declaration in the item card (data on the origin of goods, GTD/declaration), so that 1C substitutes the same value in both the SNT and the ESF. - Issue the ESF based on the SNT rather than "from scratch" — this way the details are inherited and diverge less. - After 1C configuration updates, check how the linked fields of the SNT and ESF are generated. - If the item is traceable and is accounted for via SNT, get into the habit of checking disputed positions before sending, rather than after rejection. Typical mistakes - Correcting the name "by eye," manually entering the usual version, instead of copying the reference from the web ESF created based on the SNT. As a result, the data again does not match. - Ignoring the text of the rejection protocol and trying to resend the document unchanged. - Copying a value with extra spaces or cutting off part of the string — the server still sees a mismatch. - Comparing the wrong item line or linking the ESF to the wrong SNT. - Sending by mistake the technical draft ESF created on the website only for verification, instead of the document from 1C (or vice versa — duplicating the ESF). What to check - The exact text of the error in the ESF status: which specific detail the server points to. - The match of the "name per declaration" field in 1C and in the web ESF created based on the same SNT — character by character. - The correctness of linking the ESF to the required SNT and the correspondence of the compared item lines. - The absence of extra spaces and foreign characters in the copied value. - That after the correction and resending, the ESF received the status "delivered/accepted," and the technical draft on the website was not sent as a separate document. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_