До 1 сентября осталось 5 месяцев: почему ваша транспортная логистика к этому не готова

TL;DR. С 1 сентября 2026 электронные перевозочные документы обязательны для всех грузоперевозок в РФ, штрафы до 3% годовой выручки. Главная проблема не в штрафах, а в том, что «просто подключить ЭПД» невозможно, если данные о маршрутах, водителях и ТС живут в Excel и WhatsApp. Ниже — почему, что делать и четыре грабли, на которые наступают первыми.

Раскрытие: мы делаем TMS (LEAD TMS FX, реестровая запись отечественного ПО №17542) и 16 апреля, послезавтра, проводим вебинар «Электронный документооборот в транспортной логистике». Если хотите живой разбор с Q&A — зарегистрироваться. Если хотите разбор текстом — читайте дальше, продающих вставок в середине не будет, финальный блок — одна строка-напоминание.

По данным ComNews, специализированные TMS-системы используют только 28% российских компаний. Остальные 72% работают в Excel, на самописном ПО или в учётных системах с минимальной автоматизацией. По нашим наблюдениям за клиентами, приходящими на внедрение, структура этих 72% выглядит примерно так: около 30% управляют перевозками в Excel, ещё 30% — на самописных решениях, 40% используют учётные системы с минимальным функционалом автоматизации транспортной логистики. И вот в эту конструкцию нужно «просто подключить ЭПД».

Что происходит 1 сентября 2026 года

С этой даты вступают в силу требования Федерального закона № 336-ФЗ: электронные транспортные накладные (ЭТрН) становятся обязательными, данные передаются через ГИС ЭПД.

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

Санкции:

• Индивидуальные предприниматели: от 3 000 до 10 000 ₽ за каждый документ

• Юридические лица: от 100 000 до 1 000 000 ₽

• При повторном нарушении: от 1 до 3% годовой выручки, минимум 1 000 000 ₽

По оценкам отрасли, переход на транспортный ЭДО занимает от двух до шести месяцев. До дедлайна остаётся пять. Арифметика простая.

Почему «просто подключить ЭПД» не получится

Технически подключить оператора ЭДО и начать формировать электронные накладные можно за пару недель. На практике всё упирается в одно: структурированные данные. Для ЭТрН нужны конкретные поля: маршрут, груз, водитель, транспортное средство, временные окна погрузки и разгрузки. И вот тут выясняется, что эти данные живут в пяти разных местах.

Начнём с планирования. Логист тратит 2-6 часов в день на ручное планирование: раскидывает заказы по машинам, прикидывает маршруты по Яндекс.Картам, записывает результат в Excel-таблицу. Утилизацию кузова по объёму и весу, товарное соседство, временные окна разгрузки в Excel физически не учесть. Ни API, ни структурированных данных: только формулы, ссылки между вкладками и комментарии к ячейкам, которые понятны одному человеку.

Дальше идут универсальные учётные платформы, которые перерастают задачу. За 20 лет работы в логистической автоматизации мы видели десятки проектов, где транспортный модуль дорабатывался на базе основной информационной системы предприятия под конкретные требования компании в течение длительного времени. Такой подход приводит к высокой зависимости от специалистов, которые занимаются обслуживанием внутреннего продукта, а также сильному отставанию от специализированных решений, доступных на рынке и развиваемых большими командами. К тому же, в определённый момент он экономически перестаёт себя оправдывать. Когда объём перевозок вырастает в разы, появляется сложная маршрутизация с учётом 20+ критериев, тендерный модуль, мобильное приложение для водителей, интеграция с GPS-трекингом. То, что изначально закрывалось аккуратными правками, превращается в многомесячный проект с собственным бэклогом и необходимостью привлечения всё новых и новых сотрудников. Специализированная TMS приходит с этими блоками «из коробки», и поддерживать их в своей кастомной сборке уже не приходится.

Дальше вступает в игру дублирование данных между системами. Заявки на перевозку хранятся в 1С, маршруты в Excel, статус доставки в WhatsApp, факт прибытия фиксируется по звонку диспетчеру. Мы называем это «синдром пяти окон»: логист одновременно работает в пяти приложениях, и ни одно из них не является источником правды. Чтобы сформировать ЭТрН, нужно собрать данные из всех пяти вручную, каждый раз, на каждый рейс.

Параллельно существует ещё один контур, который никак не привязан к документам. Это водители. Изменение маршрута происходит по звонку. Подтверждение доставки прилетает фоткой в мессенджер (и теряется через неделю). Причина отказа клиента в лучшем случае звучит в голосовом сообщении. Если GPS-мониторинг подключён, он живёт отдельно (Wialon, Автограф), и данные оттуда никак не связаны с заявками. А для ЭПД нужны точные данные о прибытии, убытии и статусе груза, привязанные к конкретной накладной. Их просто негде взять.

И последнее (и самое тяжёлое). Всё это держится на одном человеке. Логист знает, кому нельзя везти после 14:00, у какого водителя через неделю заканчивается медсправка, какой клиент требует звонок за час до приезда. Эти правила нигде не записаны, они в голове Сергея (или Алексея, или Натальи, в каждой компании свой незаменимый логист). Заболел — отдел встал. Уволился — месяц хаоса. И именно в его голове лежат те самые данные, которые должны были бы автоматически подтягиваться в электронную накладную.

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

Кейс: когда объёмы переросли возможности универсальной платформы

Крупный российский производитель электротехники. Транспортный отдел вырос на доработанном модуле на базе 1С. Несколько лет это решение успешно закрывало задачи компании. С ростом парка и числа отгрузок требования изменились: потребовались автоматическая маршрутизация с учётом товарного соседства, тендерный модуль, мобильное приложение для водителей, интеграция с GPS.

При обработке большого объёма данных кастомизированный модуль начинал конкурировать за ресурсы с другими контурами учётной системы, и нагрузка ощущалась не только в транспортном отделе.

Сотрудникам транспортного отдела приходилось параллельно работать в Excel и 1С, дублируя одни и те же операции. Внесение маршрутов в WMS занимало больше пяти часов рабочего времени в день. Информирование складов — вручную. Выбор между собственной доставкой и транспортной компанией — на глазок, без расчёта.

Вариантов было два: продолжать наращивать функциональность модуля в учётной системе или перейти на специализированную TMS, в которой маршрутизация, тендеры и мобильные приложения входят в ядро, а не дорисовываются сверху. Компания выбрала второй путь, с сохранением интеграции с 1С на уровне обмена данными. В целевой конфигурации система должна обрабатывать от 700 заявок в день.

Контур, который разворачивается в проекте:

• Управление заявками и цепями поставки. Приём заявок от смежных отделов и контрагентов, учёт грузов, привязка к клиентским договорам. Вместо Excel-таблиц и переписки в мессенджерах.

• Формирование рейсов. Автоматическая сборка заданий на перевозку с учётом утилизации кузова, товарного соседства и временных окон. Раньше на ручную раскладку маршрутов уходило больше пяти часов рабочего времени в день.

• Мониторинг рейсов. Контроль статуса в реальном времени, план/факт по пробегу, расходу топлива и времени на точке.

• Личный кабинет перевозчика. Наёмные перевозчики получают задания, подтверждают готовность, отчитываются по выполнению. Без звонков и пересылки сканов.

• Биллинг. Автоматический расчёт стоимости услуг перевозчиков и клиентов, сверка актов, подготовка к закрытию периода.

• Отчёты. Сквозная аналитика по рейсам, водителям, клиентам, маршрутам. Данные собираются из системы, а не руками из разных источников.

• Мобильное приложение для водителей. Маршрут, контакты и изменения видны в телефоне. Факт доставки фиксируется с фото и временной меткой.

• Импортонезависимость. LEAD TMS FX работает на Linux/PostgreSQL, доступ через браузер без установки на рабочие станции. Система включена в реестр отечественного ПО (реестровая запись №17542 от 17.05.2023).

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

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

Какие данные TMS автоматически подставляет в титулы ЭТрН

Электронная транспортная накладная это не один файл, а комплекс титулов (T1–T8), каждый со своим набором обязательных полей. В ручном режиме каждый титул заполняется оператором, и каждое поле превращается в потенциальную ошибку. Если данные уже лежат в TMS, большая часть титулов формируется автоматически.

Что получает бизнес: титулы T1, T5 и T7–T8 формируются без участия логиста — система вытягивает поля из карточек контрагентов, ТС, водителей и маршрутов. Титулы T2, T3 и T4 заполняются действиями в мобильном приложении — водитель делает отметку о приёме/сдаче, фото фиксируется автоматически. Ручной работы остаётся минимум, а риск расхождения между «что в документе» и «что по факту» сводится к нулю.

Четыре грабли, на которые наступают первыми

Подключение ЭПД всегда сочетает технологическую и человеческую часть. По опыту первых внедрений, первыми «взрываются» одни и те же четыре точки.

Цена опечатки. Бумажный документ можно переписать, перечеркнуть, подклеить исправление. С электронным так не получится. Чтобы исправить ошибку, нужно формально отозвать титул, сформировать новый, снова подписать УКЭП, повторно отправить контрагенту. Стоимость одной опечатки, замеченной через неделю, превращается в отдельный процесс с участием трёх сторон. Поэтому на первых неделях важно ловить ошибки в момент формирования, а не на выходе.

УКЭП у всех участников перевозки. ЭТрН это многосторонний документ. Если у одной из сторон нет действующей электронной подписи, операция физически не завершится. Часто это выясняется уже в процессе первого рейса: водитель может подписать, а вот у стороннего грузополучателя не готова МЧД, не оформлен УКЭП, нет мобильного приложения. Аудит УКЭП по ключевым контрагентам стоит делать на этапе пилота, а не на старте боевой эксплуатации.

Мелкие перевозчики тянут переход дольше остальных. Крупные логисты и собственные автопарки переходят на ЭПД относительно быстро: у них есть ИТ-отдел, бюджет и процедуры. А вот сторонние перевозчики с парком 3–10 машин часто не торопятся. Им УКЭП и мобильные приложения кажутся избыточными, они «подождут до последнего». Если 30% ваших перевозок закрывают такие партнёры, надо закладывать время на их вовлечение, вплоть до помощи с подбором тарифа у оператора ЭДО.

Синхронизация сторон в реальном времени. ЭПД технически устроен так, что все участники перевозки работают с документом параллельно: грузоотправитель формирует, перевозчик подписывает T2, грузополучатель T3. Если одна из сторон «зависла» (не открывает уведомления, ждёт пятницу, не подписала МЧД), весь рейс висит в статусе «в процессе». Типичный вопрос первых месяцев звучит не «как сформировать», а «как заставить всех действовать одновременно». Здесь спасает только дисциплина регламентов и понятный механизм эскалации.

Пять вопросов, которые стоит задать себе до 1 сентября

Не нужно внедрять TMS, чтобы понять, есть ли проблема. Достаточно честно ответить:

1. Где хранятся данные о маршрутах, водителях и транспорте? Если в одной системе, хорошо. Если в пяти, это не «рабочий процесс», это технический долг.

2. Сколько часов в день логист тратит на планирование рейсов? Если больше часа на 30+ заказов, вы переплачиваете за ручной труд. Автоматическая маршрутизация с учётом 20+ критериев (грузоподъёмность, объём, временные окна, пробки, товарное соседство) делает это за минуты.

3. Можете ли вы прямо сейчас назвать себестоимость вчерашнего рейса? Если нет, вы не знаете, какие рейсы убыточны.

4. Что произойдёт, если главный логист уйдёт в отпуск на месяц? Если ответ «будет тяжело», знания не оцифрованы, а значит, и в ЭТрН подставлять нечего.

5. Есть ли у учётной системы API для интеграции с оператором ЭДО? Если нет, подключение ЭПД превращается из «задачи для ИТ-отдела» в «проект по перестройке процессов».

Два «нет» из пяти означают, что проблема не в ЭПД. ЭПД просто сделает её видимой для налоговой.