Распознавание накладных, ТТН, УПД

01Бизнес-задача

В экспедиции и 3PL ежедневный поток первичных документов от водителей и контрагентов — это часы ручного ввода. Операторы переписывают номера накладных, ставки, веса, реквизиты в WMS/TMS/1С. Каждая ошибка — правка задним числом через 2 дня и недовольный бухгалтер. Полностью переделывать пакет документов приходится на 5–8% накладных.

ИИ снимает 95%+ полей с типовых форм: программа читает текст, нейросеть приводит его к единой структуре, сопоставление со справочниками контрагентов идёт автоматически. Оператор получает форму с распознанными полями: «зелёные» — уверенно, «жёлтые» — под проверку, «красные» — не уверен, посмотрите. Время на накладную — 30–60 секунд против 4–6 минут вручную.

02Типовой ROI

Параметры расчёта:

• Поток первичных документов — от 200 в день для значимой экономики
• Среднее время на накладную вручную — 4–6 минут
• Время после внедрения — 30–60 секунд на проверку
• Точность распознавания на печатных формах — 95–98%, на рукописных вставках — 80–88%
• Доля документов, требующих ручного вмешательства — 5–15% (зависит от качества сканов)

Второй эффект помимо часов — меньше правок задним числом в учётной системе. Меньше «выезжающих» бухгалтеров и меньше споров с контрагентами по ставкам.

03На чём собрано — обсуждается под клиента

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

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

04Что нужно на старте

• 500–1000 исторических накладных разного качества (сканы, фото, ксероксы) — чтобы настроить распознавание и ИИ
• Справочники контрагентов и услуг с актуальными реквизитами для сопоставления
• API-доступ к WMS/TMS или 1С для записи распознанных документов
• Регламент по «жёлтым» документам — что делает оператор, на каких порогах переход к ручному вводу
• Чек-лист контроля качества — какие поля критичны (номер, дата, сумма, реквизиты), какие нет
• Ответственный за справочники — без обновляемого каталога контрагентов ИИ будет ошибаться на новых перевозчиках

05Точки риска

1. Низкое качество сканов. Фото из кабины КАМАЗа в темноте даёт точность 60–70% против заявленных 95%. Защита: на пилоте замерить на реальном потоке. Если качество критично — обязать водителей снимать по шаблону с рамкой либо обновить парк сканеров на терминалах.
2. Новые контрагенты не в справочнике. ИИ ставит «жёлтый» статус и перегружает очередь оператора. Защита: быстрое занесение новых контрагентов из системы, авто-предложение карточки на согласование.
3. Ошибки в реквизитах при автозагрузке в 1С. Бухгалтер видит «не своих» контрагентов и теряет доверие. Защита: строгая сверка ИНН по ФНС/ЕГРЮЛ перед записью, любая непроверяемая комбинация — в очередь оператора.
4. «Зелёный» статус ≠ «правильно». ИИ уверен в неверной цифре, оператор пропускает. Защита: выборочная сверка зелёных случаев (1–2% наугад), замер реальной точности раз в неделю.
5. Юридически значимые подписи и печати. ИИ не проверяет подписи — это не его задача. Защита: на критичных документах (договоры, акты приёмки) отдельный контроль живым сотрудником, ИИ не заменяет визуальную проверку.

06Анти-сценарий

• Меньше 100 документов в день. Внедрение не окупится — экономия часов слишком мала для покрытия операционных расходов.
• Полный ЭДО уже работает. Если 80%+ потока — электронные документы с готовой структурой (СБИС, Контур.Диадок и пр.), сценарий теряет смысл. Лучше подключить к ЭДО оставшихся контрагентов.
• Хаос в справочниках. Если контрагенты в разных системах не связаны между собой, сначала унифицируйте справочники, потом внедряйте распознавание. Без этого ИИ будет ошибаться в 30%+ случаев.
• Очень узкая специализация на нестандартных формах. Например, перевозка наливных опасных грузов с уникальными перевозчиками — слишком мало однотипных документов, чтобы настроить ИИ.
• Парк сканеров и качество фото неисправимы. Если водители физически не могут сделать читаемый снимок — никакая модель не поможет.

07Связанные сценарии

• AI-чат поддержки по трекингу — пара по архитектуре: распознанные документы дают чистые данные, чтобы чат отвечал «где мой груз».
• Автоматизация переписки по дебиторке — после автоматизации ввода накладных следующий узел — расчёты с клиентами.