Код ГИС в накладной: почему письмо ФНС не заменяет условие договора

ФНС выпустила разъяснения по заполнению электронных перевозочных документов, если в грузе есть товары, учитываемые в государственных информационных системах. Для юриста это повод проверить, не превратилась ли техническая настройка программы в юридическое условие, которое стороны не согласовывали в договоре. Прежде чем спорить о наличии или отсутствии запятой в строке, нужно установить реальное основание требования: применимую норму закона, договорный порядок или техническое правило обмена.

Основой для разбора служит письмо ФНС от 22.09.2026 № ЕА-36-26/8426@, опубликованное 23 октября, а сообщение на сайте ведомство датировало 02.11.2026. Важно различать эти даты: новость от 2 ноября не является новым нормативным актом с собственной датой вступления в силу. В письме описан порядок отражения кодов систем (ЕГАИС, ГИС МТ, ФГИС ВетИС, ФГИС лесного комплекса, ФГИС «Зерно», ФГИС «Северный завоз») и идентификаторов учётных единиц. Для электронной транспортной накладной коды нескольких систем разделяются запятой без пробелов. При этом для электронного путевого листа ведомство описало отдельный порядок использования информационного поля, поэтому переносить настройки из накладной простым копированием рискованно.

В сообщении от 02.11.2026 ФНС прямо оговаривает: рекомендации не предполагают обязательного отражения соответствующих сведений, а лишь разъясняют возможности заполнения в утверждённых форматах. Это оговорка, а не освобождение от всех требований к перевозке. Нельзя только на основании этого письма объявить незаполненный реквизит нарушением новой всеобщей обязанности. Однако и ссылаться на рекомендательный характер, чтобы не исполнять требования к конкретному товару, тоже неверно. Поэтому при разборе конкретной поставки нужно сначала выяснить, какие сведения нужны для этого груза, и только затем определять, в каком элементе файла их передавать.

Договорный спор возникает, когда стороны согласовали обмен сведениями детальнее, чем описывает общая новость ведомства. Формула «документ не принимается, оплата не производится» требует особого внимания. Даже если требование передать сведения согласовано, из этого нельзя автоматически вывести любое последствие их отсутствия. Для оценки отказа придётся проверять конкретное условие, обстоятельства исполнения и применимые нормы.

Не стоит смешивать технический отказ оператора с отказом контрагента исполнить договор. В споре важно сохранить исходный файл, сообщения оператора, время отправки и переписку об исправлении. Эти доказательства позволят восстановить, какие данные были переданы и что именно препятствовало обмену.

Перед следующей отправкой стоит проверить основание каждого требования: что нужно по правилам для товара, что предусмотрено договором и что проверяет программа. Нужно определить источник идентификаторов — кто получает сведения из системы и кто отвечает за их связь с партией. Также следует протестировать сценарии обмена для накладной и путевого листа отдельно, особенно если систем несколько, и зафиксировать рабочий порядок исправления ошибок и уведомления участников. Их смысл — убрать разрыв между юридическим основанием, данными о грузе и настройками электронного обмена до момента отправки.