ИИ для транспортных компаний: как сократить рутинную работу

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

Проблема транспортного документооборота редко сводится к одной неправильно заполненной накладной. Условия перевозки сначала появляются в письме, заявке или TMS, затем частично переносятся в транспортную накладную, а после доставки — в акт, УПД и учетную систему. Один и тот же рейс описывается несколькими документами, которые создают разные участники в разное время.

Из-за этого комплект может быть формально полным, но внутренне противоречивым. В заявке согласованы шесть паллет и температурный режим, в накладной указаны пять мест, а в акте нет замечаний. Или адрес доставки совпадает, но сумма в акте отличается от тарифа с учетом простоя. Ручная проверка таких цепочек требует не чтения отдельных файлов, а сопоставления реквизитов, событий и договорных условий. Именно на этом участке ИИ дает наиболее заметный практический эффект.

Что именно нужно сверять в транспортном комплекте

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

Транспортная накладная прежде всего подтверждает отношения по перевозке и события с грузом. Акт подтверждает приемку оказанной услуги, если такой порядок предусмотрен договором. Заявка описывает согласованные коммерческие и операционные условия. Поэтому статус «груз доставлен» сам по себе не доказывает правильность тарифа, а подписанный акт не устраняет противоречие в весе или количестве мест.

Для бухгалтерского учета дополнительно проверяются обязательные реквизиты первичного документа: наименование, дата, составитель, содержание факта хозяйственной жизни, натуральные или денежные измерители, ответственные лица и их подписи. Такой перечень установлен статьей 9 Федерального закона № 402-ФЗ «О бухгалтерском учете». Но наличие всех полей еще не означает, что сведения согласованы с остальным комплектом.

Как работает ИИ-проверка транспортных документов

Корпоративное решение обычно объединяет распознавание файлов, извлечение данных, программные проверки и языковую модель. Если использовать только универсальный чат с загруженными PDF, результат будет трудно воспроизвести, встроить в учетный процесс и проверить при споре.

Прием и классификация

Система получает документы из ЭДО, электронной почты, личного кабинета, мобильного приложения водителя или сетевой папки. Электронные XML-файлы читаются как структурированные данные. Для PDF, фотографий и сканов требуется OCR — оптическое распознавание текста.

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

Извлечение и нормализация данных

Из каждого документа выделяются участники, ИНН, номера и даты, адреса, номер автомобиля и прицепа, сведения о водителе, маршрут, наименование груза, масса, объем, количество мест, тариф и сумма. Значения приводятся к единому формату: «10 т», «10 000 кг» и «10000.00 kg» должны стать сопоставимыми данными с известной единицей измерения.

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

Сопоставление и применение правил

После извлечения система определяет, какие документы относятся к одному рейсу. Для связи используются номер заявки, дата, автомобиль, стороны, маршрут и другие устойчивые признаки. Если единственного идентификатора нет, применяется нечеткое сопоставление с порогом уверенности.

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

Итогом становится не общий ответ «есть ошибки», а отчет с привязкой к источнику:

> Заявка № 418: 12 грузовых мест. > Транспортная накладная: 11 мест. > Акт: приемка без замечаний. > Статус: существенное расхождение. Требуется проверить фактическую приемку и наличие отдельного акта о недостаче.

Такой результат можно проверить по оригиналам и передать конкретному сотруднику.

Какие расхождения система может выявить

ИИ-проверка охватывает три уровня: оформление документа, согласованность комплекта и соответствие учетным данным.

Формальный контроль обнаруживает отсутствующий ИНН, незаполненную дату, неподписанный документ, нечитаемую страницу или неверный формат файла. Для XML существует отдельная структурная проверка по XSD-схеме. Например, валидатор Диадока проверяет соответствие XML установленным форматам, но такая валидация не отвечает на вопрос, совпадает ли вес груза с заявкой или сумма акта с тарифом оператора.

Междокументная проверка находит различия в содержании:

• другой грузоотправитель, получатель или перевозчик;
• несовпадение адресов погрузки и выгрузки;
• замена автомобиля или водителя без отражения изменения;
• различия в весе, объеме, количестве мест или номенклатуре;
• дата акта раньше фактической доставки;
• отсутствие накладной, акта либо обязательного приложения;
• тариф, не соответствующий заявке;
• простой или дополнительная точка в акте без основания;
• повторный документ или попытка дважды предъявить один рейс к оплате.

Третий уровень связывает документы с TMS, ERP или 1С. Система проверяет, существует ли заказ, не закрыт ли он ранее, совпадает ли контрагент, отражена ли операция и есть ли полный комплект для оплаты. Проверенный документ целесообразно создавать в учетной системе как черновик. Автоматическое проведение без контроля допустимо только для хорошо формализованных сценариев с подтвержденной точностью и понятным механизмом отмены.

Как система определяет критичность расхождения

Не каждое различие является ошибкой. «ООО ТрансЛогистик» и «ТрансЛогистик, ООО» могут обозначать одного перевозчика, если совпадает ИНН. Вес нетто и вес брутто нельзя считать противоречием без учета типа показателя. Замена машины может быть согласованным событием рейса, а не нарушением.

Поэтому правила проверки нужно разделять по последствиям.

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

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

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

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

Что изменилось после перехода на электронные перевозочные документы

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

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

Кроме того, единый рейс может включать документы из разных контуров. ЭТрН находится в электронном перевозочном документообороте, УПД поступает через ЭДО, заявка хранится в TMS, а фотография поврежденной упаковки — в мобильном приложении. Задача корпоративной проверки состоит в том, чтобы связать эти сведения, а не создать еще один изолированный архив.

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

Как внедрить проверку без дорогостоящей ошибки

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

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

Качество оценивают отдельно по каждому этапу:

• правильно ли определен тип документа;
• насколько точно извлечены критичные поля;
• верно ли документы объединены в рейс;
• сколько реальных расхождений найдено;
• сколько ложных предупреждений приходится разбирать сотруднику;
• можно ли восстановить основание каждого вывода.

Одна усредненная «точность ИИ» мало что говорит о пригодности решения. Ошибка в распознавании примечания и ошибка в сумме акта имеют разные последствия. Для суммы, веса, количества мест, ИНН и номера рейса следует устанавливать отдельные требования и обязательную проверку при низкой уверенности.

После пилота систему подключают к TMS, ERP, 1С, ЭДО и архиву. Интеграция должна сохранять исходный файл, извлеченные значения, примененные правила, версию модели и решение сотрудника. Такой журнал позволяет разбирать ошибки и доказывать, почему документ был остановлен или пропущен.

Наша компания Полигант разрабатывает корпоративные решения, которые принимают заявки, накладные и акты, сопоставляют их с данными TMS, ERP или 1С и передают сотрудникам только спорные комплекты. Проект можно выстроить с оплатой за согласованный результат — например, за достигнутый уровень автоматической обработки или снижение объема ручных операций. Метрики, контрольная выборка и порядок приемки фиксируются до разработки, чтобы результат можно было проверить на документах заказчика.

Где заканчивается автоматизация и остается ответственность человека

ИИ должен сокращать объем механической сверки, а не маскировать неопределенность. Если документ плохо читается, рейс нельзя однозначно определить или два источника противоречат друг другу, правильное действие системы — остановить автоматический сценарий и показать причину.

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

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

Частые вопросы

Может ли ИИ полностью заменить бухгалтера или логиста при проверке документов?

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

Нужен ли ИИ, если транспортные накладные уже электронные?

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

Можно ли проверять фотографии накладных от водителей?

Можно, однако качество результата зависит от освещения, резкости, угла съемки и полноты кадра. Система должна автоматически отклонять нечитаемые изображения и запрашивать повторную съемку до того, как водитель покинет точку выгрузки.

Что происходит, если ИИ не уверен в распознанном значении?

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

Безопасно ли передавать транспортные документы в публичную нейросеть?

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

С чего начать внедрение?

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