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

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

Внутри книги слева расположены разделы Overview, Uploads, Accounts, Transactions, Index, Income и Detect Signals. Центральная область меняется от списка файлов и предпросмотра страниц до таблицы транзакций, графиков баланса, расчёта дохода и панели проверки подлинности. Верхняя строка показывает идентификаторы книги, число загрузок и документов, время создания и изменения, а также команды Upload, Export, Share, Activity log и Comments, если они разрешены для организации.

Как устроен рабочий экран

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

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

Навигация зависит от включённых модулей. У одних организаций видны только загрузка и извлечение данных, у других добавляются Accounts, Transactions, Income, Detect Signals, Ocrolus Intelligence, Inspect или инструменты передачи книг партнёрам. Отсутствующая вкладка обычно означает не ошибку браузера, а то, что функция не активирована для учётной записи или выбранного сценария. Перед поиском неисправности стоит проверить права пользователя и состав доступных продуктов.

Создание книги и организация документов

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

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

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

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

Поддерживаемые файлы и подготовка PDF

Через окно загрузки Dashboard принимаются PDF и распространённые растровые изображения: JPEG, PNG, GIF, TIF и BMP. В интерфейсе для одной загрузки указан предел 200 МБ. Конкретные ограничения могут зависеть от договора и выбранного потока, поэтому при работе с крупными пакетами полезно ориентироваться на подсказку в загрузчике и документацию своей организации. Для API файлы передаются как multipart/form-data, а известный тип документа можно указать выбранным методом загрузки.

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

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

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

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

Instant, Complete и Classify

Выбор обработки определяет, какие этапы пройдёт книга. Instant выполняет автоматическую обработку без участия проверяющего и предназначен для быстрого получения результата по поддерживаемым типам документов. Complete начинает с автоматизации, а при необходимости добавляет проверку человеком. Classify сначала определяет типы и границы документов, позволяя позже повысить отдельные материалы до Capture, Instant или Complete, если требуются извлечённые поля и аналитика.

Instant удобен для первичного решения, когда важна скорость и заранее известно, что формы поддерживаются. После загрузки нужно проверить статус каждого документа, а не только общий статус книги. В одной книге часть файлов может завершиться успешно, а часть получить Rejected: Instant not supported или Rejected: Invalid document. Успешные результаты можно использовать сразу, а неподдерживаемые документы повысить до Complete на уровне книги или конкретного файла.

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

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

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

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

У книги и документов есть независимые статусы. На уровне книги Verifying означает, что проверка продолжается, а Verification complete может появляться и у созданной книги без добавленных документов. Поэтому завершённый статус нельзя трактовать как подтверждение полноты пакета. Нужно сравнить количество загрузок, документов и ожидаемых периодов, затем открыть Uploads и проверить каждую строку.

В Uploads рядом с файлом показывается значок состояния. Completed означает завершённую обработку; Completed with Detect signals found сообщает, что данные получены, но обнаружены сигналы, требующие оценки; Rejected указывает на отказ; Processing — на продолжающуюся работу. Подсказка при наведении расшифровывает значок. Если файл долго остаётся в Processing, полезно сверить время загрузки, состояние вебхуков и наличие системных сообщений, прежде чем отправлять копию.

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

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

Классификация и извлечение данных

Classify определяет тип страницы и группирует листы в документы. Платформа поддерживает более 2100 типов, включая банковские выписки, расчётные листки, налоговые декларации, W-2, ипотечные заявления, удостоверяющие документы и специализированные формы. Наличие типа в общем каталоге не гарантирует одинаковый набор полей во всех сценариях: состав Capture зависит от конкретного продукта, формы, года и настроек организации.

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

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

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

Book Overview: сводка по заявке

Overview собирает ключевые показатели в одном экране. В верхней полосе видны общие суммы кредитных поступлений и платежей, средний дневной остаток, коэффициент покрытия долга, число NSF и овердрафтов. Рядом выводятся источники финтех-кредитов и merchant cash advance. Эти карточки дают направление проверки, но каждая метрика должна раскрываться до операций или счетов, на которых она основана.

Карточка Revenue vs expense показывает общую выручку и расходы, долю крупнейших контрагентов и средний дневной денежный поток. Высокая концентрация на одном источнике поступлений может быть нормальной для бизнеса с крупным заказчиком, однако её следует сопоставить с договором, сезонностью и устойчивостью клиента. Нулевая сумма расходов не всегда означает идеальную экономику: возможно, расходные операции ещё не получили нужные теги или в книге отсутствует часть счетов.

Виджет Industry выводит четырёхзначный код NAICS и описание вида деятельности. Если классификация неверна, уполномоченный аналитик может выбрать Change Industry, а после ручного изменения — вернуть Reset to System Assigned. Переопределение влияет на сравнение с отраслевыми ориентирами, поэтому его нужно документировать. Нельзя выбирать более выгодную отрасль только для улучшения относительных показателей.

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

Раздел Accounts и графики денежных потоков

Accounts агрегирует сведения по счетам и периодам. В правой части обычно видны отрасль, краткие показатели денежного потока и крупнейшие контрагенты по доходам и расходам. Основная область содержит интерактивные графики Balance History, Revenue vs Expense и Summary by Transaction Tag. Изменения тегов и признака Revenue в таблице Transactions пересчитывают эти визуализации.

Balance History показывает остаток по дням, неделям или месяцам. Дневной масштаб помогает увидеть краткие провалы ликвидности, недельный сглаживает шум, а месячный подходит для оценки общего тренда. Скачок в конце месяца может быть обычным поступлением выручки, переводом между собственными счетами или кредитными средствами; график сам по себе не объясняет природу движения, поэтому точку нужно раскрыть до операций.

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

Summary by Transaction Tag показывает выбранные категории во времени. Он полезен для анализа кредитных платежей, возвратов, азартных операций, криптовалютных переводов, фонда оплаты труда и других групп, доступных организации. Теги можно сочетать с периодом Daily, Weekly или Monthly. При интерпретации нужно учитывать, что одна операция может иметь несколько тегов, поэтому суммы по категориям не всегда складываются в общий оборот без пересечений.

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

Таблица Transactions

Transactions — рабочая таблица всех операций книги. Базовые столбцы содержат дату, описание и сумму; дополнительные — переключатель Revenue, теги, счёт, контрагента, комментарий и звёздочку. Столбцы Date и Amount можно сортировать. Фильтр All под заголовком столбца ограничивает значения, а скрытие ненужной колонки освобождает место для остальных полей.

Над таблицей находятся вкладки All, Revenue, Credits, Debits и Starred. Они задают первый слой отбора и сочетаются с другими фильтрами. Поле Search by name or description фильтрует и предлагает совпадения по мере ввода. Это удобно для поиска конкретного контрагента, платёжного сервиса или повторяющегося описания, но сокращённые банковские дескрипторы могут отличаться между месяцами, поэтому иногда требуется несколько вариантов запроса.

Фильтр Date поддерживает операторы Between и Equals. Between выбирает интервал между начальной и конечной датой, Equals — конкретный день. Фильтр Tags умеет Match all и Match any: первый оставляет операции, содержащие все выбранные теги, второй — хотя бы один. Модальное окно Filters позволяет сочетать условия по Amount, Revenue, Counterparty, Date, Account и Description; условия соединяются логикой AND.

Фильтр суммы работает по абсолютному значению. Это означает, что запрос по величине может совпасть как с поступлением, так и со списанием той же суммы. Чтобы разделить направления, нужно добавить условие или использовать вкладки Credits и Debits. Значок с числом на кнопке Filters показывает количество активных условий. Clear all сбрасывает их, Apply filters применяет, Cancel закрывает окно без изменения выдачи.

Щелчок по строке открывает Capture Details. В панели видны описание, теги, участие в Revenue, документ, счёт, дата и сумма, а также изображение исходной страницы с подсветкой строки. Это центральный инструмент проверки спорной операции: аналитик видит одновременно интерпретацию и доказательство. Если подсветка указывает на другую строку или сумма считывается из соседнего столбца, нужно зарегистрировать проблему и не компенсировать её произвольным тегом.

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

Корректировка тегов и расчёта выручки

Алгоритм обогащает операции тегами, однако кредитная политика может требовать уточнения. Тег можно добавить или снять непосредственно в ячейке через Edit tag либо в Capture Details. Для нескольких строк используют Bulk Action: Add tag, Remove tag, Include in revenue, Exclude in revenue и Export Selected. Групповое действие экономит время, но перед применением следует проверить, что фильтр не захватил лишние операции.

Переключатель Revenue определяет, входит ли операция в расчёт дохода. Включение используется для настоящей выручки, выключение — для переводов между собственными счетами, возвратов капитала, кредитных поступлений и других движений, которые не являются операционным доходом. Изменение отражается в Accounts, Book Overview и выгрузках. Поэтому правку нужно делать до формирования итогового отчёта, а не после копирования цифр в кредитное заключение.

Одна операция может сочетать несколько смыслов: депозит, внешний источник, merchant service и revenue. Теги не заменяют друг друга, а описывают разные стороны движения. При создании пользовательских тегов нужно избегать дублей системных категорий и заранее определить назначение. Если две команды используют Loan Payment и Debt Service для одного явления, отчёты по портфелю будут несопоставимы.

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

Export Selected создаёт XLSX с выбранными операциями. Такой файл удобен для внутреннего списка исключений или передачи риск-команде. Он не заменяет полный SMB Analytics, где есть агрегированные показатели, счётные вкладки и разрезы по периодам. При передаче выборочного файла нужно описать критерий отбора, иначе получатель может принять неполный набор за все операции клиента.

Экспорт аналитики

Меню Export предлагает отчёты, доступные конкретному сценарию. Для малого бизнеса SMB Analytics в формате XLSX содержит сводку книги, сведения по счетам, транзакции и теги. Для ипотечного анализа Bank Statement Income формирует расчёт дохода, а Income Data может экспортироваться в PDF. Графики Accounts отдельно выгружаются в PNG и CSV. Набор пунктов зависит от включённых модулей и типа обработанных документов.

В SMB Analytics первая вкладка объединяет показатели всех счетов и периодов. Метрики сгруппированы по остаткам, NSF, овердрафтам, долгу, выручке, расходам и пользовательским тегам. Следующие вкладки относятся к отдельным банковским счетам и содержат периоды выписок, средние остатки, движение средств и месячные значения. Такой формат позволяет начать со сводки и затем проверить источник каждого показателя.

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

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

Большие книги обрабатываются асинхронно. Для API Book Summary асинхронный режим обязателен после 100 000 транзакций, а книги свыше 1 000 000 транзакций отклоняются. Интеграция должна принять идентификатор задания, опрашивать его статус и получать результат после завершения, а не держать один запрос открытым. Ошибка 425 означает, что аналитика ещё рассчитывается, и требует повторной проверки позже.

Bank Statement Income Calculator

BSIC предназначен для расчёта дохода по банковским выпискам в ипотечных сценариях. В Dashboard можно редактировать факторы, видеть мгновенный пересчёт, проверять пропущенные выписки, NSF и овердрафты, находить крупные депозиты, объединять несколько счетов и формировать итоговый PDF. Это уменьшает зависимость от ручных формул в Excel, но не отменяет проверку правил инвестора и состава документов.

Ключевые входы включают Expense Factor, долю владения бизнесом, порог крупного депозита и тип счёта Business или Personal. Expense Factor применяется к депозитам для оценки дохода после расходов. Business Ownership уменьшает относимую к заёмщику долю дохода. Порог крупного депозита можно задавать как процент выбранной базы или фиксированную сумму с точностью до центов.

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

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

Отчёт формируется через Export либо из действий книги. В зависимости от процесса доступны XLSX и однокнопочный PDF с итогами, согласованными с требованиями инвестора. Перед передачей отчёта нужно убедиться, что учтены все счета и месяцы, правильно указан тип счёта, применена доля владения и объяснены крупные депозиты. Автоматически найденный флаг — повод для проверки, а не готовое кредитное решение.

Detect и проверка подлинности

Detect анализирует документ на признаки изменения и несоответствия. В расширенном варианте используются модели Ocrolus, цифровая криминалистика Resistant AI и слой Authenticity Status. Результат включает Authenticity Score от 0 до 100, статус High, Medium или Low, коды причин, флаги с уровнем серьёзности и визуализации участков, где обнаружены аномалии.

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

В Dashboard центральная панель показывает документ и доступные визуализации, справа раскрываются детали сигналов и Captured Data, слева — общее число сигналов по книге. При нескольких визуализациях появляются миниатюры. Наведение на выделенный фрагмент объясняет, какое поле или текст считается изменённым. Крестик возвращает к Book Overview, а сворачивание панели освобождает место для страницы.

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

Reason codes делают результат пригодным для аудита. Код содержит идентификатор, уверенность и понятное описание причины. Флаг дополнительно указывает severity, влияние на балл, объяснение и источник обнаружения. В кредитной политике лучше привязывать действие к типу и серьёзности сигнала: запрос оригинала, независимая банковская проверка, ручная сверка или эскалация во fraud-команду.

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

Ocrolus Intelligence и контекст по заёмщику

Ocrolus Intelligence добавляет контекст к текущей заявке малого бизнеса. Модуль Loan inquiries показывает предыдущие обращения, их частоту и давность. Credit shopping events группирует связанные запросы, чтобы повторная отправка через брокера не считалась множеством независимых потребностей в кредите. Benchmarking сравнивает выручку, расходы и финтех-активность с обезличенными организациями той же отрасли.

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

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

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

Ипотечные сценарии и анализ дохода

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

Inspect сравнивает данные документов с заявлением 1003, выявляет несовпадения имён, адресов и сведений о кредите, показывает нераскрытые счета или работодателей и отмечает недостающие подтверждения. Среди риск-сигналов могут быть крупные депозиты, удержания из зарплаты, неуказанные долги и сервисы buy-now-pay-later. Найденное несоответствие превращается в условие для проверки, а не автоматически исправляет заявление.

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

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

Сценарий анализа малого бизнеса

Типичный процесс начинается с создания книги по заявке и загрузки банковских выписок за требуемый период. После обработки аналитик проверяет, что представлены все счета и месяцы, затем открывает Overview для быстрой оценки выручки, расходов, долга, NSF, овердрафтов и концентрации контрагентов. Любой необычный показатель раскрывается через Accounts или Transactions.

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

Detect проверяют параллельно с содержанием. Низкий Authenticity Score, признаки скриншота или изменения текста требуют оригинала и независимого подтверждения. Затем Intelligence может показать частые кредитные запросы и положение бизнеса относительно отрасли. Эти сигналы объединяют с данными анкеты и внешними источниками, а не используют изолированно.

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

API и автоматизация процесса

API повторяет базовую модель Dashboard: сначала создаётся Book, затем в неё загружаются документы, отслеживаются статусы, извлекаются формы и транзакции, запрашиваются аналитические результаты и сигналы Detect. Ответы передаются в JSON, файлы — через multipart/form-data. Разработчику нужно хранить UUID книги и документов, потому что имена не гарантируют уникальность и могут меняться.

Аутентификация использует OAuth 2.0 с потоком client credentials. В Dashboard создают Client ID и Client Secret, скачивают JSON и сохраняют секрет до закрытия окна: позднее чувствительные данные не показываются. Приложение получает access token и передаёт его в последующих запросах, а после истечения запрашивает новый. Секрет нельзя помещать в браузерный код, журналы или общедоступный репозиторий.

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

События лучше получать через организационные webhooks. Конечная точка должна быстро отвечать 200 OK, помещать событие в очередь и обрабатывать его идемпотентно. Повторное уведомление не должно создавать вторую заявку или повторно экспортировать один результат. Для критичных этапов полезен резервный опрос статуса, если webhook временно недоступен.

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

Ошибки следует разделять на постоянные и временные. Invalid PDF, отсутствие обязательного параметра, неверный идентификатор книги и отсутствие прав требуют исправления запроса. Ошибка ожидания аналитики или временная недоступность допускают повтор с задержкой. Безусловный быстрый retry опасен: он создаёт нагрузку и может многократно загрузить один файл. Идемпотентность и контроль контрольной суммы обязательны.

Учётные данные, роли и аудит

API Credentials открываются через Account & Settings. При создании задают описание, скачивают JSON и затем подтверждают добавление. Описание должно указывать приложение и среду, например LOS production, а не test, чтобы при расследовании было понятно происхождение вызова. Разные среды и интеграции должны иметь отдельные пары ключей.

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

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

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

Widget и получение документов от клиента

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

Plaid Client ID и Production Client Secret вводятся в настройках Embedded Widget, а затем можно включить Connect to Bank. Ключи не следует передавать по электронной почте или хранить в текстовой инструкции. При смене среды, владельца или признаках утечки их обновляют. После изменения нужно провести тестовую сессию и убедиться, что данные попадают в правильную организацию и книгу.

Цифровые банковские данные и загруженные PDF могут использоваться совместно. Docs-to-Digital сравнивает операции из выписки и Plaid, показывает несовпадения и формирует показатели серьёзности. В Excel-выгрузке доступны сравнительные метрики, критические расхождения, распределение по severity и детальный список операций с причиной, источником и связанным идентификатором.

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

Передача книги и совместная работа

Encore позволяет передать профиль денежного потока доверенному партнёру. Отправитель открывает Book Overview, нажимает Share, выбирает получателя из разрешённого списка и при необходимости добавляет Shared Book label — внешний номер сделки или возможности. Получатель получает копию профиля, а отправитель отслеживает состояние в разделе Shared by you.

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

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

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

Типовые ошибки и способы исправления

Проблема	Практическое действие
Файл отклонён как invalid PDF	Открыть все страницы, проверить пароль и повреждение, повторно экспортировать из доверенного источника без печати в изображения.
Instant not supported	Повысить конкретный документ до Complete либо изменить поток книги, если дополнительная обработка нужна всему пакету.
Книга долго находится в Processing	Проверить время, статус отдельных документов, уведомления и журнал; не загружать дубликат до исключения сбоя.
Вкладка Detect отсутствует	Проверить доступ организации и роль пользователя; запросить включение модуля у ответственного администратора.
Метрика не изменилась после правки	Убедиться, что изменены правильные операции, снять фильтры, дождаться пересчёта и обновить страницу.
Выручка заметно завышена	Найти внутренние переводы, кредитные поступления и возвраты, выключить Revenue и проверить месячные суммы.
В книге пропущен месяц	Сверить диапазоны в Bank Accounts, запросить недостающую выписку и дождаться обработки перед экспортом.
График не совпадает с Excel	Проверить время экспорта и последующие правки; сформировать новый отчёт после завершения пересчёта.
API возвращает 403	Проверить токен, организацию, права и принадлежность книги; не подменять UUID названием.
API возвращает 425	Аналитика ещё рассчитывается; повторить запрос с задержкой или дождаться webhook.
Повторно созданы документы	Добавить идемпотентность, хранить UUID и контрольные суммы, обрабатывать повторные webhook без дублирования.
Сигнал Detect кажется ложным	Сохранить оригинал, проверить код причины и визуализацию, запросить независимое подтверждение и передать пример поддержке.

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

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

Практические ограничения

Ocrolus не предназначен для ручного редактирования страниц PDF, перестановки листов, добавления текста, подписей или аннотаций как в обычном PDF-редакторе. Документ здесь является источником данных и доказательством. Для исправления структуры исходного файла используют отдельный редактор до загрузки, сохраняя оригинал и не маскируя изменения.

Доступ строится вокруг организации, договора и ролей. Пользователь не получает полный набор функций только после регистрации: Instant, Complete, Detect, Intelligence, BSIC, Inspect, Widget, Encore и интеграции включаются по сценарию. Из-за этого инструкции коллеги или скриншот из документации могут показывать вкладку, которой нет в конкретной учётной записи.

Интерфейс и документация используют английские названия полей и статусов. Для русскоязычной команды стоит подготовить внутренний словарь: Book, Upload, Revenue, NSF, Overdraft, Counterparty, Authenticity Score, Complete и другие термины. Автоматический перевод браузера может исказить банковские дескрипторы и названия тегов, поэтому рабочие значения лучше оставлять без перевода.

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

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

Сравнение Ocrolus с аналогами

Программа	Лучше подходит для	Главное ограничение
Ocrolus	Кредитный анализ выписок, дохода и подлинности	Нужен доступ к корпоративным модулям
Rossum	Почтовые и документные процессы с очередями проверки	Нет готовой кредитной аналитики
ABBYY Vantage	Корпоративное извлечение и настраиваемые навыки	Требует проектирования и обучения навыков
Google Document AI	Облачные процессоры и интеграции в Google Cloud	Нужна настройка проекта и процессоров
Amazon Textract	Извлечение текста, форм и таблиц в AWS	Нет готовых расчётов денежного потока
Nanonets	Настраиваемые модели и workflow для документов	Нужно обучать и контролировать модели

Ocrolus стоит выбирать кредиторам, которым нужны не только распознанные поля, но и готовые денежные потоки, теги транзакций, расчёт дохода, отраслевой контекст и проверка подлинности в одной книге. Rossum лучше подходит для управляемой очереди входящих документов и ручной валидации разных бизнес-процессов. ABBYY Vantage полезен организациям, готовым проектировать собственные навыки извлечения. Google Document AI и Amazon Textract удобны разработчикам, уже работающим в соответствующем облаке. Nanonets подходит командам, которым важна настройка собственных моделей и автоматизаций.

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

Контрольный список перед решением

• Все заявленные банковские счета присутствуют в книге.
• Диапазоны выписок непрерывны и охватывают требуемый период.
• Каждый документ имеет завершённый или объяснённый статус.
• Необработанные и UNKNOWN-страницы проверены вручную.
• Внутренние переводы и кредитные поступления исключены из Revenue.
• Крупные депозиты имеют подтверждённое происхождение.
• Теги долга, NSF, овердрафтов и возвратов проверены.
• Графики Accounts пересчитались после последних правок.
• Сигналы Detect рассмотрены вместе с кодами причин.
• Ручное изменение отрасли или дохода снабжено объяснением.
• Экспорт сформирован после завершения всех изменений.
• В решении сохранены UUID книги и время формирования отчёта.

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

Частые вопросы

Можно ли загрузить один PDF с несколькими формами?

Да. Смешанный документ классифицируется по страницам и разбивается на формы. После обработки нужно проверить границы и UNKNOWN-страницы.

Что делать, если Instant не распознал документ?

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

Почему сумма депозитов выше выручки?

Депозиты включают все поступления, в том числе переводы, кредиты и возвраты. Revenue учитывает только операции, включённые в доход.

Можно ли исправить тег операции?

Да. Теги меняются в ячейке, Capture Details или массовым действием. Правка отражается в аналитике и новых выгрузках.

Где увидеть исходную строку выписки?

Нужно открыть транзакцию. Панель Capture Details показывает страницу и подсвечивает соответствующую строку.

Почему нет вкладки Detect?

Она появляется только при активированном модуле и подходящих правах. Следует проверить настройки организации.

Высокий Authenticity Score гарантирует подлинность?

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

Как выгрузить график?

В Accounts у визуализации есть Export с вариантами PNG для изображения и CSV для данных.

Когда использовать BSIC?

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

Можно ли работать только через API?

Да. API создаёт книги, принимает документы, возвращает данные и аналитику. Dashboard остаётся удобным для ручной проверки исключений.

Как избежать повторной загрузки?

Хранить UUID, контрольную сумму и собственный идентификатор операции, а повторные webhook обрабатывать идемпотентно.

Почему экспорт отличается от экрана?

Экспорт является снимком. После новых файлов или правок нужно дождаться пересчёта и сформировать его заново.

Как выстроить устойчивый процесс

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

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

Интеграцию строят вокруг событий и идентификаторов. LOS создаёт книгу, сохраняет UUID, отправляет документы, получает webhook, проверяет статус и забирает результаты. Все шаги пишутся в журнал с корреляционным идентификатором. Ручная работа в Dashboard должна быть видна системе-источнику: как минимум экспорт и финальное решение связываются с той же заявкой.

Контроль качества измеряют на уровне исключений: доля UNKNOWN-страниц, число повышений Instant в Complete, частота ручных тегов, расхождения между цифровыми и PDF-данными, ложные и подтверждённые сигналы Detect, время до готового решения. Такие показатели показывают реальную пользу и проблемные места лучше, чем средняя скорость распознавания без учёта исправлений.

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

Команды книги и безопасные действия

В верхней части книги команда Upload открывает добавление файлов, а стрелка рядом показывает дополнительные действия. В зависимости от состояния и прав там могут быть Rename Book, Convert Book, Manage Sharing и Delete Book. Эти команды затрагивают весь набор, поэтому перед применением нужно убедиться, что открыта правильная заявка. Название и UUID в заголовке следует сверять особенно при работе в нескольких вкладках браузера.

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

Боковая навигация и связь разделов

Uploads показывает физические файлы и статусы, Accounts — агрегированные показатели по счетам, Transactions — отдельные движения, Index — классифицированные документы и поля, Income — расчёты дохода, Detect Signals — признаки цифрового вмешательства. Переходы между ними не создают новые данные: это разные представления одного набора. Поэтому несоответствие между вкладками обычно связано с фильтром, временем пересчёта или разным уровнем агрегации.

Начинать проверку удобно с Uploads и полноты пакета, затем переходить к Overview, Accounts и Transactions. Если сразу смотреть только итоговую выручку, можно пропустить отсутствующий месяц или неверно классифицированный файл. Detect лучше оценивать до финального экспорта, чтобы запрос оригинала или независимая проверка не возникли после принятого решения.

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

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

Обновление обработки отдельного документа

Кнопка Process with позволяет повысить выбранный документ, не меняя базовый тип всей книги. В окне отображается доступный вариант и пояснение, например Complete с классификацией и захватом через human in the loop. Это полезно, когда автоматический поток справился с большинством выписок, а один файл имеет сложную вёрстку, плохое качество или неподдерживаемую форму.

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

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

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

Метрики денежных потоков и их проверка

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

Debt Coverage Ratio сопоставляет денежный результат после расходов и долговые платежи. Интерпретация зависит от того, какие операции получили теги Revenue, Expense и Debt. Кредитное поступление, ошибочно включённое в выручку, увеличивает числитель, а нераспознанный платёж по займу уменьшает знаменатель. Поэтому экстремально высокий коэффициент — повод раскрыть операции, а не основание немедленного одобрения.

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

Loan proceeds и loan payments помогают оценить существующую долговую нагрузку. Поступление от кредитора не является операционной выручкой, а списание в пользу кредитора не всегда полностью относится к основному долгу: описание может включать комиссию или агрегированный платёж. Теги и контрагент дают направление, но спорные движения следует подтверждать договором или графиком.

Управление тегами как справочником

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

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

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

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

Полнота пакета и контроль периодов

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

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

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

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

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

Проектирование API-интеграции без потери данных

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

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

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

Статусы следует отображать пользователю понятными этапами: принято, классифицируется, извлекаются данные, проверяется, обработка завершена, требуется действие, отклонено. Простая надпись ошибка без кода и документа заставляет сотрудника искать проблему в Dashboard. Хороший интерфейс показывает UUID, тип ошибки и безопасное рекомендуемое действие.

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

Секреты OAuth хранятся в менеджере секретов, а не в конфигурационном файле рядом с кодом. Доступ к ним получает только сервис, который запрашивает токен. Журналы должны маскировать Authorization и Client Secret. При ротации новая пара сначала проходит тест в нужной среде, затем разворачивается, и лишь после этого старая отзывается.

Итоговый рабочий принцип

Ocrolus приносит наибольшую пользу, когда команда рассматривает книгу не как папку файлов, а как связанную модель доказательств. Uploads подтверждает состав, Index — классификацию, Capture — извлечённые поля, Transactions — движение денег, Accounts и Overview — агрегаты, Detect — целостность, а Export — зафиксированный результат.

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