Извлечение таблиц из документов: как сохранить структуру строк и столбцов

Почему извлечение таблиц из документов — отдельная инженерная задача

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

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

Именно поэтому извлечение табличных данных мы рассматриваем как часть более широкой темы распознавание документов, а не как побочный эффект OCR. Для банка или страховой цена ошибки здесь измеряется не опечаткой, а неверной проводкой.

Что ломает табличную структуру в казахстанских документах

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

Второе — форматы чисел. Суммы в тенге пишут по-разному: с пробелом-разделителем разрядов, с неразрывным пробелом, с запятой или точкой в дробной части, иногда с постфиксом «тг» прямо в ячейке. Без нормализации 1 250 000,00 и 1250000 воспринимаются как разные значения, и контроль итогов по колонке не сходится. ИИН и БИН добавляют свою специфику: это строго двенадцатизначные коды, которые нельзя округлять, переносить в экспоненту или терять ведущие нули, а сканер легко путает ноль с буквой О и единицу с латинской I.

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

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

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

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

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

Сверка кодов, сумм и выгрузка в 1С

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

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

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

Изолированное развёртывание в контуре клиента

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

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

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

Хотите увидеть распознавание на своих документах? Посмотрите что умеет ZoomApps или сразу напишите нам в WhatsApp — покажем на демо.