Meridian Apparel — это бренд товаров массового спроса среднего размера, который закупает продукцию на зарубежных фабриках в нескольких регионах. Два-три аналитика по закупкам сверяют каждый входящий счет поставщика с открытой базой PO компании и мастер-списком поставщиков, прежде чем данные попадают в финансовые и складские системы. Ошибки в главной рабочей книге напрямую отражаются в пакетах отчетности, которые просматривает CFO.
Разрывы по страницам, объединенные ячейки и скрытые номера PO незаметно ломали главный файл
В каждом ежемесячном цикле команда обрабатывала десятки счетов, содержащих до 50 строковых позиций, — они поступали в виде сканированных PDF, нативных цифровых файлов и Excel-книг с макетами на основе объединенных ячеек. Консолидация была почти полностью ручной: открыть каждый счет, визуально разобрать, вручную ввести каждую строку.
Три типа сбоев усиливали друг друга. Разрывы по страницам создавали осиротевшие SKU с нулевыми количествами — записи выглядели завершенными, но были структурно повреждены. Объединенные шаблоны поставщиков в Excel порождали пустые строки, которые аналитики заполняли непоследовательно. Поставщики, прячущие ссылки на PO в текстовых заголовках — "Re: Your order 45992-A" — вызывали флаги несоответствия PO и отдельные циклы исправления. Арифметическая сверка ловила примерно 90% ошибок OCR в разорванных строках, но только после того, как ввод данных уже был завершен. Сезонный рывок по подключению трех-пяти новых фабрик и инициатива финансового отдела по сокращению сроков оплаты с net-45 до net-30 сломали неформальную модель масштабирования: теперь партии счетов должны были проходить проверку за один рабочий день.
Energent.ai стала сквозным конвейером консолидации
Команда оценила расширенный набор Excel-макросов и отдельное точечное OCR-решение. Оба подхода рассматривали загрузку и валидацию как разрозненные этапы; ни один не мог сверять извлеченные значения с мастер-списком поставщиков или открытой базой PO. Energent.ai обработала весь конвейер в рамках одной агентной сессии:
- Маршрутизировала каждый документ по наличию текстового слоя — нативные PDF обрабатывались напрямую, сканированные PDF — через vision extraction — устраняя смещение координат
- Извлекала строковые позиции через разрывы страниц, ориентируясь на заголовки таблиц, а не на границы страниц
- Заполняла вперед столбцы с объединенными ячейками — название фабрики, код модели, номер PO — чтобы соответствовать намерению поставщика
- Восстанавливала скрытые номера PO с помощью regex по всему текстовому блоку, помечая восстановленные значения флагом
source: text_recovery - Выполняла двухэтапную валидацию до добавления: Phase 1 нормализовал даты и числовые поля; Phase 2 сверял мастер-список поставщиков, валидировал открытые PO и выполнял арифметические проверки на уровне строки и счета
- Стадила исключения по коду сбоя —
vendor_unmatched,math_fail,po_not_found,confidence_below_85pct— на отдельной вкладке, не затрагивая валидированные данные
Никакого кастомного OCR-конвейера. Никакого отдельного скрипта валидации. Никакого хрупкого набора макросов, который нужно поддерживать.
Валидация переместилась выше этапа добавления в главный файл
- Порог уверенности 85%. Записи ниже порога никогда не попадают в главный файл — они оказываются на промежуточной вкладке с прикрепленной причиной сбоя.
- Проверки арифметики до, а не после. Сверка на уровне строки и счета выполняется как часть автоматизированного конвейера, ловя ~90% ошибок в разорванных строках до того, как они портят рабочую книгу.
- Маршрутизация, не зависящая от формата. Сканированные PDF, нативные PDF и Excel-книги проходят в одной и той же сессии; тип документа определяет путь извлечения, а не решение аналитика.
- Аннотированная очередь исключений. Каждая помеченная запись содержит конкретный код сбоя, заменяя неформальные точечные исправления приоритизированным списком на проверку.
Два-три аналитик-дня на партию сократились до проверки только исключений
- Партии из десяти счетов, содержащих по 30–50 строковых позиций каждая, ранее требовали двух-трех аналитик-дней; теперь сквозная обработка выполняет все записи, прошедшие сверку Phase 2, без участия аналитика
- Нормализация заполнения вперед и восстановление PO по regex устранили два класса тихих ошибок извлечения во всех форматах шаблонов поставщиков
- Помеченная промежуточная вкладка — каждое исключение с конкретным кодом сбоя — заменила неформальный процесс исправления на понятную, действенную очередь
"Что изменилось, так это то, что мы перестали воспринимать валидацию как нечто, что происходит после ввода данных. Исключения попадают на промежуточную вкладку уже с указанной причиной — мы точно знаем, что исправить и почему, прежде чем к этому прикасаться." — Priya Sharma, Руководитель операций по закупкам в Meridian Apparel