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

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

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

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

02Типовой ROI

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

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

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

03Стек — обсуждается под клиента

Конкретный набор моделей, OCR-движков и интеграций — закрытая часть проекта, под клиента. На уровне принципа: использую проверенные российские и зарубежные движки, под compliance требованиям — приватные/on-premise варианты. Архитектура: OCR + структурирующая LLM + жёсткая валидация по справочникам + ручная очередь для жёлтых/красных кейсов.

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

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

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

05Точки риска

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

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

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

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

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