Veryfi OCR API распознаёт чеки, счета, банковские выписки, банковские чеки и налоговые формы, извлекает реквизиты, суммы, налоги и товарные строки, а затем возвращает структурированные данные, OCR-текст, координаты полей и оценки уверенности. Через кабинет можно загрузить образец перетаскиванием, проверить результат рядом с изображением, исправить спорные значения и выгрузить отобранные документы, а через API — встроить тот же процесс в бухгалтерию, сервис расходов, программу лояльности или систему контроля мошенничества.

Рабочий цикл начинается с выбора подходящей модели документа и передачи файла, ссылки на файл либо данных в кодировке Base64. Сервис нормализует изображение, распознаёт текст, определяет тип документа, собирает поля в JSON и добавляет технические признаки: идентификатор, статус обработки, число страниц, предупреждения о качестве, вероятность отдельных значений и найденные дубликаты. Для проверки не требуется писать отдельный просмотрщик: в Inbox исходник, извлечённые поля, полный OCR-текст, JSON и история изменений доступны в одной карточке.

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

Как построен процесс распознавания документов

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

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

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

Кабинет API Hub и раздел Inbox

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

Кнопка добавления открывает область перетаскивания. Такой способ подходит для контрольных образцов, разовых проверок и подготовки эталонного набора, но не заменяет программную передачу в производственном потоке. Веб-загрузчик принимает более узкий набор форматов, чем API: для ручной проверки безопаснее использовать JPEG, PNG, PDF, HEIC или HEIF. Если документ в DOCX, XLSX, EML либо другом поддерживаемом API формате, его следует отправлять программно или предварительно привести к формату, который кабинет принимает явно.

Строка в Inbox открывается кнопкой View. В карточке исходная страница находится рядом с извлечёнными данными, поэтому оператор может сравнивать число с изображением, не переключаясь между окнами. Вкладки Data, Vendor, OCR Text, JSON, Logs или History показывают разные уровни результата: от редактируемых бизнес-полей до полного ответа и истории действий. Названия вкладок и состав полей зависят от выбранной модели документа и настроек представления.

Карточка документа: изображение, поля, OCR и JSON

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

Вкладка OCR Text показывает последовательный распознанный текст. Она нужна, когда требуемого реквизита нет среди готовых полей: разработчик может применить регулярное выражение, словарь или собственную модель к сырому тексту. Вкладка JSON важнее для интеграции, потому что именно её структура соответствует программному ответу. При отладке следует сравнивать визуализированное поле с одноимённым узлом JSON: кабинет может скрывать редко используемые атрибуты, тогда как ответ API содержит их полностью.

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

Поддерживаемые способы передачи файла

Обычная загрузка файла

Наиболее предсказуемый вариант — передать бинарный файл с его именем. Имя важно не только для журнала: корректное расширение помогает выбрать декодер, а понятное обозначение упрощает разбор ошибок. Для высокой нагрузки выгодно упаковывать бинарные данные в multipart-запрос или в ZIP там, где это предусмотрено моделью. Не следует сначала превращать изображение в Base64 без необходимости: строка становится больше исходного файла и требует дополнительного кодирования и декодирования.

Ссылка на файл

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

Base64 и набор ссылок

Base64 подходит для систем, где транспорт допускает только JSON, однако размер тела заметно растёт. Перед отправкой нужно удалить префикс Data URI, если документация конкретного метода ожидает чистую строку, и убедиться, что кодировка не содержит переносов, добавленных почтовым клиентом. Параметр file_urls позволяет собрать связанные страницы, но порядок ссылок должен соответствовать порядку страниц. Если страницы перепутаны, модель может неверно связать шапку счёта с итогом на последнем листе.

• Сохраняйте исходное имя и контрольную сумму до отправки — это упрощает поиск повторов и расследование расхождений.
• Не меняйте расширение без фактической конвертации: файл PNG с суффиксом JPG остаётся PNG и может быть отклонён декодером.
• Проверяйте Content-Type ответа хранилища; страница ошибки с кодом 200 не является изображением.
• Для многостраничных документов заранее считайте страницы и определяйте, нужна ли обработка всего файла.

Форматы, размер и качество исходника

Для чеков и счетов API принимает распространённые изображения, PDF, архивы и ряд офисных или текстовых форматов. В документации перечислены JPEG, PNG, GIF, BMP, WEBP, AVIF, HEIC, HEIF, PDF, ZIP, TXT, HTML, HTM, EML, OFD, RTF, ODT, DOC, DOCX, XLS, XLSX и CSV. Доступность отдельных типов может зависеть от метода и настроек аккаунта, поэтому формат следует проверять именно в справке выбранной модели, а не по общему списку.

Общий практический предел размера для документных методов составляет 20 МБ, минимальный размер — около четверти килобайта. Если файл превышает лимит, лучше не ухудшать все страницы агрессивным JPEG-сжатием. Сначала удаляют пустые листы, разделяют пакет на логические документы, уменьшают чрезмерное разрешение сканера и только затем меняют качество. Для счетов с мелким шрифтом чрезмерное уменьшение разрешения опаснее, чем умеренное сжатие.

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

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

Аутентификация и безопасное хранение ключей

Для программного запроса используются идентификатор клиента, имя пользователя и API-ключ. Идентификатор передаётся отдельным заголовком, а имя пользователя и ключ образуют значение заголовка авторизации. Секрет клиента применяется для подписи HMAC-SHA256, когда интеграции требуется дополнительная проверка целостности. Подпись ограничена по времени, поэтому часы сервера должны быть синхронизированы, а повторная отправка старого запроса не должна бесконечно использовать прежнюю подпись.

Ключи нельзя помещать в мобильное приложение, JavaScript страницы, публичный репозиторий или журнал ошибок. Безопасная архитектура выглядит так: клиент передаёт файл вашему серверу, сервер проверяет пользователя и размер, затем обращается к Veryfi из закрытой сети. Если нужен прямой захват в мобильном приложении, для него предусмотрен отдельный SDK и собственная схема ключей; обычный секрет API не должен оказаться в установочном пакете.

В кабинете доступ к ключам следует оставлять только администраторам. Ротация проводится до запуска и далее по внутреннему графику, а старый ключ отзывается после переключения всех экземпляров приложения. Чтобы не прерывать обработку, интеграция временно поддерживает два секрета: новый применяется для исходящих запросов, старый остаётся только на период развёртывания. Факт ротации фиксируется в журнале, но сами значения ключей туда не записываются.

1. Создайте отдельные учётные данные для разработки и производственной среды.
2. Храните секреты в менеджере ключей, а не в файле конфигурации рядом с кодом.
3. Ограничьте чтение секретов сервисной учётной записью процесса обработки.
4. Маскируйте заголовок авторизации в трассировке HTTP и системах наблюдаемости.
5. После утечки немедленно отзовите ключ и проверьте журнал использования по времени и адресу отправителя.

Интерактивная документация и проверка запроса

В разделе API Docs можно выбрать операцию, увидеть обязательные параметры и переключить пример между Python, PHP, Java и cURL. Интерактивный режим полезен для первого запроса: он показывает точное тело, заголовки и ответ, а разработчик сразу понимает, какие поля относятся к выбранной модели. Перед копированием примера в проект нужно заменить демонстрационные значения, убрать жёстко заданные пути и добавить обработку тайм-аута, повторов и ошибок.

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

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

Структура ответа и обязательная проверка JSON

Ответ содержит идентификатор документа, статус, распознанные поля, массив строк, OCR-текст, сведения о страницах и служебный блок. Поля могут быть строкой, числом, логическим значением, объектом или массивом. Интеграция должна терпимо относиться к null и отсутствующим узлам: на чеке без чаевых поле tip закономерно пустое, а на счёте без срока оплаты может отсутствовать due_date. Преобразование null в ноль способно исказить отчётность.

Числовые значения следует хранить в десятичном типе, а не в двоичной плавающей точке. Для денег важно сохранить валюту и исходную строку. Значение 1,234 может означать одну целую двести тридцать четыре тысячных или тысячу двести тридцать четыре — интерпретация зависит от страны и печатного формата. Veryfi нормализует число, но бизнес-правило должно проверить, согласуется ли оно с общей валютой и суммой документа.

Даты также требуют контекста. Нормализованная дата удобна для базы, но короткая запись 03/04/26 неоднозначна. Подсказка страны и сведения о поставщике помогают выбрать порядок, однако критичные процессы должны сопоставлять дату с периодом операции, датой загрузки и допустимым окном. Счёт из будущего или чек двухлетней давности может быть распознан верно, но нарушать правила компании.

Временные ссылки на изображение или миниатюру предназначены для кратковременного просмотра и могут истекать примерно через четверть часа. Их нельзя сохранять как постоянный путь в карточке своей системы. Если нужен долговременный доступ, исходный файл хранится в вашем защищённом хранилище, а ссылка Veryfi используется только при немедленном контроле ответа.

Поля чеков и счетов

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

Финансовый блок включает промежуточную сумму, скидку, налог, доставку, чаевые, итог, валюту и сведения об оплате. Контрольная формула зависит от документа: итог может равняться subtotal минус discount плюс tax, shipping и tip, но округление, депозит, возврат, сервисный сбор и несколько ставок налога создают исключения. Правило должно допускать небольшую погрешность округления и отправлять заметные расхождения на проверку.

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

Документный тип помогает маршрутизации, но не должен быть единственным сигналом. Кассовый чек, гостиничный фолио, инвойс и purchase order могут содержать похожие слова. Если тип влияет на проводку или оплату, добавляют проверку обязательных полей: для счёта ожидается номер и сторона-получатель, для чека — способ оплаты и итог, для заказа — номер PO и перечень заказанных позиций.

Товарные строки и контроль итогов

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

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

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

В счетах с многострочными позициями важно сохранять порядок. Описание услуги может занимать две строки, а количество и сумма находиться только на последней. Если данные используются для двух- или трёхстороннего сопоставления с заказом и приёмкой, сравнивают не только сумму, но и единицу измерения, артикул, количество, налоговый режим и допустимое отклонение цены.

Координаты полей и оценки уверенности

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

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

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

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

Синхронная и асинхронная обработка

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

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

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

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

PDF, многостраничные файлы и разделение пакета

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

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

Перед разделением полезно определить границы бизнес-документа. Один счёт может состоять из титульной страницы и приложений; механическое деление по каждой странице разрушит связь шапки и строк. В тестовом наборе должны быть одностраничные чеки, двухстраничные счета, смешанные пакеты, пустые листы, обороты и страницы с рекламой. Приёмочный тест проверяет не только число полученных частей, но и правильный порядок страниц внутри каждой части.

Защищённый паролем PDF, повреждённая таблица xref или встроенный нестандартный шрифт могут вызвать ошибку ещё до OCR. Такой файл следует валидировать локально: открыть, пересохранить в стандартный PDF и убедиться, что страницы визуально не изменились. Растеризация каждой страницы помогает обойти проблемы структуры, но удаляет текстовый слой и увеличивает размер, поэтому используется как резервный путь.

Теги, категории и собственные поля

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

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

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

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

Исправление результата и обучение на примерах

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

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

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

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

Accuracy Reports: измерение точности на своей выборке

Инструмент Accuracy Reports находится в разделе Analytics. Сначала создаётся baseline — набор документов, где все проверяемые значения вручную подтверждены. Документы удобно пометить единым тегом, затем отфильтровать в Inbox. Перед добавлением в отчёт каждое поле, которое будет измеряться, должно быть исправлено до эталонного значения; иначе отчёт сравнит модель с ошибочным правильным ответом.

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

Команда Run Trial повторно обрабатывает эталонный набор и сравнивает результат с ground truth. В сводке видны совпадения и расхождения, а подробный режим показывает извлечённое и ожидаемое значение. Неправильное поле нужно открыть вместе с исходной страницей: причина может быть в качестве изображения, неоднозначной подписи, необычном формате или ошибке эталона.

Для устойчивой метрики рекомендуется 50–100 проверенных документов, хотя начальный тест можно провести на 5–20. Максимальный объём одного baseline ограничен, поэтому крупные коллекции делят по типу, языку, поставщику или проблемному полю. Выборка должна отражать реальный поток: сто идеальных чеков одного магазина дадут высокий процент, который ничего не говорит о разнообразном производственном наборе.

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

Поставщики и нормализация реквизитов

Во вкладке Vendor можно выбрать существующего поставщика, изменить адрес и тип либо добавить новую запись. Такое редактирование помогает объединить документы одной организации, но требует правил дедупликации. Совпадение только по названию ненадёжно: филиалы сети, франчайзи и юридические лица могут печатать одинаковый бренд. Приоритетными ключами служат налоговый номер, полный адрес, банковские реквизиты и внутренний идентификатор контрагента.

Нормализованное название удобно для аналитики, а напечатанное — для аудита. Сохраняйте оба. Если система автоматически заменит ACME STORE #154 на Acme, номер филиала исчезнет, хотя он может определять центр затрат. Внешний справочник должен связывать нормализованную сущность с конкретной торговой точкой, не уничтожая исходную строку.

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

Дубликаты и повторная подача

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

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

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

Контроль мошенничества и качества документа

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

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

Некоторые сигналы устройства доступны только при захвате через Veryfi Lens, потому что серверный файл не содержит контекста камеры и сессии. Если документ пришёл по электронной почте или ссылке, отсутствие device-сигнала не означает, что проверка пройдена; данных для него просто нет. В правилах нужно различать сигнал отрицательный и сигнал не рассчитан.

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

Другие модели документов

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

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

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

Налоговые формы содержат фиксированные поля, однако качество зависит от года бланка, копии, заполнения и страны. Нельзя автоматически переносить налоговый идентификатор в платёжную систему без проверки формата и прав доступа. Визитные карточки, напротив, дают имя, должность, компанию, телефон и электронную почту; здесь важнее нормализация контактов и поиск дублей, чем финансовая арифметика.

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

Экспорт, аналитика и передача данных дальше

Раздел Exports создаёт выгрузку по выбранному разделу и периоду. Пользователь задаёт даты, формат CSV или Excel и дополнительные фильтры по поставщику, категории, сумме либо другим доступным полям. Выгрузка подходит для проверки и миграции, но производственная интеграция не должна зависеть от ручного нажатия: для непрерывного потока данные забираются по API или передаются вебхуком.

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

Аналитика объёма показывает использование по периодам и помогает заметить резкий рост. Всплеск может означать успешную кампанию, повторную отправку очереди или утечку ключа. Метрики следует сопоставлять с числом уникальных внешних идентификаторов и дубликатов. Один документ, отправленный десять раз после тайм-аута, не должен считаться десятью полезными операциями.

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

Команда, роли и рабочие пространства

Участников добавляют в рабочее пространство и назначают роли. Администратор управляет ключами и настройками, оператор проверяет документы, аналитик работает с отчётами, а разработчик исследует ответы. Минимальные права снижают риск случайного удаления и утечки секретов. Особенно важно отделить возможность видеть документ от возможности видеть ключи: оператору OCR обычно не требуется доступ к учётным данным API.

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

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

Практическая интеграция на Python, JavaScript и других языках

Официальные библиотеки доступны для Python, Node.js и JavaScript, Java, PHP, Ruby, Go и .NET/C#. SDK сокращает настройку заголовков и сериализацию ответа, но не отменяет архитектурные решения: очередь, тайм-аут, повтор, секреты, схема базы и обработка null остаются задачей приложения. Перед обновлением библиотеки тестируют контрактный набор документов и читают изменения зависимостей.

В Python обработчик обычно принимает путь или байты, передаёт категории и дополнительные параметры, затем получает словарь. Сразу после ответа полезно проверить статус, идентификатор и предупреждения, а уже потом обращаться к total и line_items. Попытка взять вложенный ключ без проверки приводит к исключению на документе, где поле отсутствует. Для чисел применяют Decimal, для дат — явный разбор нормализованной строки.

В Node.js важно не блокировать цикл событий чтением больших файлов синхронно. Поток загружается асинхронно, а ограничитель параллельности удерживает число запросов в пределах разрешённой частоты. При вебхуке подпись проверяют по необработанному телу запроса до JSON-разбора, если схема подписи требует точных байтов.

В Java и .NET следует настроить повторное использование HTTP-клиента. Создание нового соединения для каждого документа расходует сокеты и ухудшает задержку. DTO ответа должны допускать новые поля: строгая десериализация, падающая на неизвестном узле, делает интеграцию хрупкой. Неизвестные атрибуты сохраняют или игнорируют безопасно, а обязательные контролируют собственной валидацией.

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

Ограничение частоты и производительность

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

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

Время обработки измеряют от приёма файла до готовности валидированного результата, а не только длительность HTTP. В асинхронном потоке отдельно фиксируют ожидание очереди, распознавание, доставку вебхука и внутреннюю проверку. Такой разрез показывает, где возникла задержка. Если API отвечает быстро, а документ час лежит в вашей очереди, увеличение лимита внешнего сервиса не поможет.

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

Ошибки API и порядок устранения

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

Код 429 означает превышение частоты или квоты. Решение — уменьшить параллельность, поставить запросы в очередь и повторить позже. Увеличение тайм-аута не помогает, потому что запрос отклонён до обработки. Если 429 появляется при низкой видимой нагрузке, ищут другие экземпляры приложения и повторы вебхуков, которые используют тот же клиентский лимит.

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

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

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

Проверка качества перед автоматическим действием

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

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

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

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

Типовые рабочие сценарии

Автоматизация кредиторской задолженности

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

Расходы сотрудников

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

Программа лояльности

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

Страховые и гарантийные обращения

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

Анализ банковских выписок

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

Сравнение Veryfi OCR API с аналогами

Выбор решения зависит не от общего слова OCR, а от требуемого результата. Veryfi ориентирован на готовые финансовые поля, товарные строки, кабинет проверки и сигналы риска. Крупные облачные платформы дают широкий набор процессоров и тесную связь со своей инфраструктурой. PDF Commander решает другую часть задачи: пользователь вручную распознаёт и редактирует PDF, но не получает серверный JSON-конвейер для массовой автоматизации.

Программа	Лучше подходит для	Главное ограничение
Veryfi OCR API	Чеков, счетов, строк товаров и проверки риска в готовом документном потоке	Файл до 20 МБ и необходимость интеграции
Google Cloud Document AI	Проектов в Google Cloud с разными предобученными и пользовательскими процессорами	Лимиты страниц зависят от процессора и режима
Amazon Textract	Извлечения текста, таблиц, форм и расходов в инфраструктуре AWS	Синхронный PDF ограничен одной страницей
Azure AI Document Intelligence	Счетов, чеков и пользовательских моделей в экосистеме Microsoft Azure	Нужны ресурс Azure и настройка модели
Mindee	Разработчиков, которым нужны готовые парсеры документов и простые API-вызовы	Покрытие полей различается по модели
PDF Commander	Ручного OCR, просмотра, исправления и сборки PDF на рабочем компьютере	Нет API структурированного извлечения

Veryfi стоит выбирать, когда основной поток состоит из финансовых документов, нужны готовые реквизиты и позиции, а операторы будут проверять спорные случаи в Inbox. Google Document AI удобен команде, уже использующей Google Cloud и желающей комбинировать несколько процессоров или дообучать их. Amazon Textract логичен внутри AWS, особенно для таблиц и форм, но синхронная работа с многостраничными PDF требует иной архитектуры. Azure подходит проектам на Microsoft, где важны предобученные и пользовательские модели. Mindee разумен для компактной интеграции с конкретными парсерами. PDF Commander лучше для человека, которому нужно открыть, распознать и отредактировать сам PDF без построения серверного конвейера.

Когда Veryfi не решает задачу целиком

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

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

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

Ограничение размера 20 МБ требует подготовки крупных сканов. Многотомные архивы, строительные чертежи и сотни страниц не следует передавать одним запросом. Их разбивают на логические документы, выбирают профильную модель и контролируют порядок. Если задача состоит в полнотекстовом поиске по огромному архиву, понадобятся индекс, хранилище и поисковый движок поверх OCR.

Чек-лист запуска в рабочем контуре

1. Определите типы документов и обязательные поля для каждого процесса.
2. Соберите обезличенный набор хороших, средних и пограничных образцов.
3. Проверьте форматы, размер, число страниц и качество до отправки.
4. Создайте раздельные ключи и вебхуки для тестовой и рабочей среды.
5. Сохраните внешний идентификатор, хэш файла и параметры каждого запроса.
6. Настройте очередь, ограничение параллельности и повтор с задержкой.
7. Проверьте JSON-схему, null, типы денег и неоднозначные даты.
8. Добавьте арифметическую сверку, справочник поставщиков и поиск дублей.
9. Определите пороги уверенности отдельно для суммы, даты, реквизитов и строк.
10. Настройте сигналы риска и действие для каждого уровня, а не один общий запрет.
11. Сделайте интерфейс ручной проверки с исходником и координатами поля.
12. Зафиксируйте baseline и регулярно запускайте Accuracy Reports.
13. Ограничьте права команды и закройте доступ операторов к API-ключам.
14. Настройте метрики задержки, ошибок, 429, повторов и доли ручной проверки.
15. Документируйте восстановление после недоступности API и потерянного вебхука.

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

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

Практические ответы на частые проблемы

Документ виден в Inbox, но приложение считает запрос неудачным

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

В кабинете поле есть, а в коде оно пустое

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

Сумма распознана, но товарные строки отсутствуют

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

PDF принят, но обработаны не все страницы

Сравните число страниц исходника с блоком meta и параметром max_pages_to_process. Увеличьте предел в допустимых рамках или разделите файл. Если внутри несколько независимых чеков и счетов, примените PDF Splitter, а не пытайтесь извлечь всё как один документ. Проверьте, не являются ли последние страницы приложениями без нужных полей.

Результат постоянно попадает в дубликаты

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

Оценка уверенности высокая, но значение неверно

Это систематическая ошибка, а не случайная неуверенность. Добавьте бизнес-проверку, исправьте значение в эталоне и включите пример в Accuracy Report. Если ошибка повторяется у одного поставщика, соберите несколько документов с тем же макетом. Высокая уверенность не должна обходить контрольную формулу суммы, справочник реквизитов и проверку даты.

Каналы поступления и организация входящей очереди

Документы могут появляться в Inbox после вызова API, загрузки через кабинет, захвата с помощью Lens, отправки по электронной почте или работы связанного сценария. Для оператора все они выглядят как единая очередь, но для диагностики канал нужно сохранять отдельно. Если один и тот же счёт пришёл из почты и от мобильного пользователя, поиск дубликатов обнаружит сходство, а метка канала объяснит, почему возникли две подачи.

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

Почтовый канал требует отдельной защиты. Вложения следует фильтровать по отправителю, типу, размеру и наличию вредоносного содержимого до передачи в распознавание. Текст письма и встроенные логотипы не должны случайно стать самостоятельными документами. Для каждого вложения сохраняют Message-ID, адрес отправителя и имя файла; эти данные помогают найти повторную пересылку и связать счёт с перепиской.

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

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

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

Панель точности и интерпретация показателей

Панель Data Extraction Performance сводит метрики по извлечённым полям и помогает увидеть разницу между общим результатом и отдельными атрибутами. Высокая точность названия поставщика не компенсирует низкую точность итоговой суммы, если именно сумма запускает выплату. Показатели следует группировать по влиянию на процесс: критичные финансовые поля, идентификаторы, строки товаров и вспомогательная аналитика.

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

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

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

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

Итоговая схема надёжной работы

Надёжный процесс начинается не с отправки файла, а с определения того, какое решение должно быть принято по результату. Veryfi даёт структурированные реквизиты, позиции, OCR-текст, координаты, оценки уверенности, дубликаты и сигналы риска. Приложение связывает их с исходником и внешним идентификатором, проверяет арифметику и справочники, а затем либо продолжает автоматический маршрут, либо показывает оператору конкретные спорные места.

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

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