Переход на ЭТрН с 1 сентября 2026 года: что изменится и как подготовиться бизнесу

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

Для бизнеса это означает, что вопрос уже не сводится к тому, «нужна ли нам ЭТрН». Если компания участвует в перевозке грузов наемным транспортом, ей нужно понять, какие документы она формирует, какие подписывает, в какой роли выступает и как будет взаимодействовать с контрагентами и оператором ИС ЭПД. Даже если компания сама ничего не отправляет, а только принимает груз, ее роль в электронном обмене может оставаться обязательной. Например, ФНС отдельно отмечает, что получатель подписывает титул 3 электронной транспортной накладной, подтверждая приемку груза.

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

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

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

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

Главная практическая трудность в том, что внедрение ЭТрН — это не только вопрос формата XML и выбора оператора. Официальный алгоритм ФНС начинается с анализа процессов, ролей, контрагентов, подписи и тестирования. Это хороший индикатор: регулятор сам показывает, что проблема находится прежде всего в организации процесса.

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

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

Вторая ошибка — считать, что все решается прямым подключением к ГИС ЭПД.
Это неверно: Минтранс прямо разъясняет, что юридические и физические лица напрямую к ГИС ЭПД не подключаются; взаимодействие идет через оператора ИС ЭПД. Если этот момент не понят с самого начала, проект быстро уходит в неверную архитектуру.

Третья ошибка — недооценить требования к подписям и полномочиям. Если документы подписывают сотрудники, а не руководитель или ИП, нужен корректный сценарий с КЭП физлица и машиночитаемой доверенностью. Отдельно нужно учесть, какие подписи применимы для разных ролей и систем. Ошибка здесь приводит не просто к неудобству, а к остановке обмена.

Четвертая ошибка — не готовить контрагентов и не тестировать обмен заранее. Официальный алгоритм ФНС отдельно выделяет приглашение контрагентов, пилотный запуск и поэтапное масштабирование. Это значит, что надежный переход — не «включение функции в один день», а управляемый проект с тестовым контуром.

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

Шаг второй — определить целевую схему электронного обмена. Здесь нужно выбрать оператора ИС ЭПД и понять, как компания будет работать с документами: через веб-интерфейс, мобильный сценарий, модуль оператора или интеграцию с собственной системой или воспользоваться готовой TMS с настроенной интеграцией с ИС ЭПД.

ФНС прямо пишет, что операторы предлагают разные варианты решений, включая веб-версии, модули для учетных систем, API-интеграцию и мобильные приложения.

Шаг третий — разобрать подписи и полномочия. Если документы подписывает руководитель компании или ИП, используется квалифицированная подпись. Если подпись ставит сотрудник, нужно заранее выстроить сценарий с КЭП физлица и МЧД. На этом этапе лучше сразу определить все роли, чтобы не столкнуться с блокировкой обмена уже после запуска.

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

Шаг пятый — подключить контрагентов и провести пилот. Лучше выбрать один или несколько маршрутов, ограниченный пул участников и реальный сценарий перевозки, а затем проверить весь цикл: создание, подписание, обмен, приемку, исправления и архив. ФНС рекомендует именно такой подход — сначала пилот и выявление слабых мест, потом постепенное масштабирование.

Шаг шестой — обучить персонал и закрепить регламенты. Нужно, чтобы логистика, ИТ, операционный блок и сотрудники, которые фактически работают с документами, одинаково понимали новую схему. Иначе формально внедренная система останется «бумажным» проектом, который держится на одном-двух специалистах. Обучение персонала как отдельный этап также прямо присутствует в официальном алгоритме ФНС.

Переход на ЭТрН затрагивает не только документооборот. Он требует пересмотреть роли участников, порядок работы с данными, взаимодействие с перевозчиками и интеграцию с корпоративными системами. Если решать задачу точечно, компания рискует сохранить ручные операции, разрывы между системами и ошибки в документах.

IT Vectura помогает встроить ЭТрН в единый процесс управления перевозками. Команда изучает текущую модель логистики, выявляет проблемные участки и формирует целевой ИТ-контур с учётом требований электронного перевозочного документооборота.

Продукт IT Vectura TMS — охватывает все этапы перевозки: формирование транспортного заказа, определения способа перевозки, планирование рейсов по плечам, взаимодействие с участниками и исполнителями перевозочного процесса (Грузоотправитель, Перевозчик, Экспедитор, Водитель, Грузополучатель, Плательщик), работу с электронными перевозочными документами и контроль их статусов, расчет и согласование взаиморасчетов.

За счёт открытого API и интеграционных возможностей систему можно связать с существующим корпоративным контуром.

В части ЭДО для это позволяет не создавать отдельный изолированный процесс, а включить электронные документы в ежедневную работу логистов и других участников перевозки.

В результате компания получает не просто инструмент для выполнения новых требований, а более управляемый транспортный процесс: с понятными ролями, прозрачными статусами, едиными правилами работы и меньшей зависимостью от ручных действий.

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

Если вы уже понимаете, что переход на ЭТрН упрется не только в документ, но и в процессы, роли, интеграции и контрагентов, имеет смысл обсудить это как проект заранее. IT Vectura развивает решения для автоматизации логистики и TMS-контуров, а значит разговор можно строить не вокруг «еще одного файла XML», а вокруг рабочей модели перевозок и ее цифровой реализации.