BORNLI / о разработке по делу
Проверка счетов перевозчиков с AI
Извлечь данные из счёта недостаточно. Свяжите строку с рейсом, тарифом и подтверждением доплаты, а спорное решение оставьте финансовому контролёру.
Где полезен AI?
AI-проверку счетов перевозчиков разумно начать с одной операции: сопоставить строку счёта с рейсом и договорным тарифом, собрать доказательства спорной доплаты и передать решение контролёру. Извлечение текста не подтверждает, что услуга оказана или сумма подлежит оплате.
В публикации от 10 июля 2024 года Navia описывает работу с Raft: обработку AP-счетов и проверку извлечённых данных по существующим записям. Это опыт Navia, не проект BORNLI и не независимый аудит. Датированного окна измерения и отдельной российской выборки в статье нет; её результаты нельзя обещать нашему пилоту.
Что приходит на проверку?
Модельный сценарий BORNLI. Счёт S-711 v1 относится к рейсу R-204: перевозка 48 000 ₽ и ожидание 6 000 ₽, всего 54 000 ₽. Это условные итоговые суммы, без отдельного налогового расчёта. Перевозчик, документы и тариф вымышлены.
Сначала сохранить исходный файл и версию, затем предложить связь с рейсом. Если номер неоднозначен или найден другой перевозчик, сверку остановить до выбора человеком. Не связывать документы только по похожей сумме.

Как проверить доплату?
Условный тариф задаёт 1 500 ₽ за час после двух бесплатных часов. Отметки 10:00–15:00 дают пять часов всего, три платных часа и 4 500 ₽. Расхождение со строкой счёта — 1 500 ₽.
AI может извлечь отметки и предложить подходящий пункт. Сам расчёт выполняется утверждённым правилом. Если договор иначе определяет округление, начало ожидания или бесплатное время, контролёр сначала выбирает применимое условие. Без подтверждающего документа система показывает «Нет основания», а не придумывает время.

Кто разрешает расхождение?
Контролёр проверяет отметки и запрашивает корректировку. В модели поступает S-711 v2 на 52 500 ₽. Версия v1 сохраняется рядом; интерфейс не исправляет исходный счёт от имени перевозчика.
Новая версия требует повторной проверки изменённых строк. Если контролёр принимает исходную доплату, нужно сохранить основание и полномочие. Эта концепция не даёт юридического заключения по спору и не отправляет настоящие сообщения.

Что делать после потери ответа?
Для передачи согласованной версии используется операция F-711-v2. Если ответ учёта потерян, статус — «Результат неизвестен». Повтор сначала ищет результат по тому же ключу; при подтверждённом AP-319 второй документ создавать нельзя.
В рабочей системе этот контроль нужно реализовать в адаптере и проверить на реальном API. Экран концепции сам по себе не доказывает надёжность интеграции.

Какой результат можно назвать честно?
Итог модели: S-711 v2 связан с записью AP-319, исходная версия сохранена, платёж не выполнен. Разница 1 500 ₽ — арифметика условного документа, а не достигнутая экономия BORNLI.

Пилот ограничьте одним типом перевозок и утверждёнными тарифами. Измеряйте время сверки, долю исправленных полей, неподтверждённые доплаты и дубли на сопоставимых документах. Проверьте повтор счёта, новую версию, отсутствие отметки и недоступность учёта.
Если задача относится к обычным закупочным документам, начните с проверки счетов поставщиков. Если меняется задание водителю — с приложения транспортной компании. Для оценки этой автоматизации нужны обезличенные счёт, рейс, тариф и один спорный пример.
От ручной работы к понятному процессу
Разберём один процесс вашего бизнеса.
Опишите, что сотрудники делают вручную и какими системами пользуются. Уточним входные данные, контроль человеком и границы пилота. Состав работ и стоимость согласуем до старта.
Разобрать мой процесс ↗