Извлечение таблиц из PDF: как собрать чистые данные

Почему таблица из PDF расползается

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

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

Чаще всего таблица ломается из-за нескольких типовых вещей:

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

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

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

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

Как понять тип PDF

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

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

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

Перед запуском извлечения стоит быстро проверить несколько вещей:

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

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

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

Чем вытаскивать таблицу

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

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

• Копирование из PDF годится для быстрого теста, если файл цифровой, таблица небольшая, а колонки не разваливаются при вставке.
• Парсер по координатам хорошо работает на однотипных документах: повторяющихся отчетах, тарифных сетках, приложениях к договору с одинаковой версткой.
• OCR нужен для сканов и страниц, которые хранятся как картинка. Без него вы вообще не доберетесь до ячеек, но цифры и мелкий шрифт он путает чаще всего.
• LLM полезна на спорных местах, где нет явных границ, строки склеились, а в ячейках сидят примечания и сноски.

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

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

OCR и LLM особенно полезны на стыках страниц, где одна строка разрезана пополам. Но здесь нужен контроль: модель может "дописать" то, чего в документе нет. Поэтому лучше отправлять на доразбор только проблемные места, а не весь пакет PDF.

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

Порядок работы от файла к таблице

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

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

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

Полезно сохранять не только итоговую таблицу, но и служебные данные:

• номер страницы;
• координаты зоны таблицы;
• исходный текст ячейки до очистки;
• уверенность парсера или признак сомнительного чтения.

Дальше приведите значения к одному виду. Числа часто приходят как "1 250,00", "1250.00" и "1.250,00" в соседних файлах. Даты могут быть в формате "01.02.2025" или "2025-02-01". Валюту лучше хранить отдельно от суммы, чтобы "12 000 KZT" не жило в одном поле с числом. Шаг скучный, но без него данные плохо фильтруются, не считаются и не сверяются.

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

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

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

Как привести данные к одному виду

После извлечения таблиц из PDF сырые строки почти всегда похожи друг на друга, но не совпадают. Одна и та же цена может прийти как "10 000,50", "10.000,50" или "10000.50", а название услуги - как "Поддержка 24/7", "поддержка 24 7" или в две строки внутри одной ячейки.

Сначала склейте переносы там, где текст явно относится к одной ячейке. Если в тарифе строка "Абонентская\nплата" распалась на два куска, ее нужно собрать обратно до любых сравнений. Иначе таблица выглядит полной, но поиск дублей и группировка дают мусор.

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

Числа и обозначения

С числами нужна жесткая дисциплина. Выберите один формат и приводите к нему все значения: один десятичный разделитель, без пробелов внутри числа, без знаков валюты в том же поле. Если в одном документе встречаются "15,5%", "0.155" и "15.50 %", заранее решите, что вы храните - процент как текст для показа или число для расчетов.

Отдельно разберите НДС, валюты и диапазоны. "1000 KZT без НДС", "1 000 тг", "1000 тенге" и "1000 + 12%" - это разные случаи. Лучше держать цену, валюту и признак НДС в отдельных столбцах. Диапазоны вроде "от 100 до 500" или "1-10 пользователей" тоже не стоит оставлять одной строкой, если потом вы строите отчеты.

С единицами измерения ситуация такая же. "шт.", "штук", "ед.", "user/month" и "польз./мес." лучше свести к одному словарю. То же касается названий услуг. Если в приложении к договору и в ежемесячном инвойсе услуга называется чуть по-разному, нормализованный справочник синонимов заметно сокращает ручную сверку.

Обычно хватает пяти базовых правил:

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

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

Как проверять суммы и ловить расхождения

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

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

С НДС лучше работать отдельно. Храните три поля: сумма без налога, НДС и сумма с налогом. Тогда сразу видно, где документ смешал ставки, где парсер взял итог с НДС вместо базы и где 12% посчитались от уже увеличенной суммы.

Что обычно дает ошибку

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

Округление часто выглядит страшнее, чем есть на самом деле. Если строки дают 125 430,01, а итог раздела равен 125 430,00, это обычно допустимо. Но если разница доходит до 1-2 тенге и повторяется по нескольким разделам, почти всегда где-то сидит дубль или неверно распознанная цифра.

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

Для спорных строк задайте простой порог ручной проверки. Например, отправляйте на разбор все, где разница больше 0,5% или выше 100 тенге. Малые отклонения можно пометить как округление, а все, что выше порога, человек проверит за минуту.

На практике это выглядит просто. Если в приложении к договору есть пять тарифных строк по 20 000 тенге без НДС, итог без налога должен быть 100 000, НДС - 12 000, общий итог - 112 000. Любое другое число уже повод проверить строку, ставку или дубликат.

Пример с тарифами из приложения к договору

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

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

Раздел: Услуги

| Услуга                                     | Объем | Ставка | Итого   |
|--------------------------------------------|-------|--------|---------|
| Канал передачи данных                      | 2     | 120000 | 240000  |
| для резервной площадки                     |       |        |         |
| Техническая поддержка 24/7                 | 1     | 180000 | 180000  |
| Выделенный IP-адрес                        | 12    | 30000  | 360000  |
| Итого по разделу                           |       |        | 780000  |

Примечание: Все ставки указаны в KZT без НДС.

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

Дальше идет нормализация. Числа приводят к одному виду: убирают пробелы, меняют запятую на точку, если она есть, и сохраняют сумму как число. Валюту KZT ставят всем строкам раздела из примечания, а не ждут, что она появится в каждой ячейке.

Проверка сумм тут очень простая и потому полезная. Нужно пересчитать каждую строку и затем сверить итог по разделу:

• 2 x 120000 = 240000
• 1 x 180000 = 180000
• 12 x 30000 = 360000
• Сумма строк = 780000

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

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

Где чаще всего ошибаются

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

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

Ошибки часто прячутся в мелочах. Минус перед числом пропадает чаще, чем кажется. Разделитель тысяч тоже теряют регулярно: 120 000 превращается в 120000, а иногда и в 120.000, если парсер перепутал формат. Для отчета это уже другая цифра, а для тарифа из приложения к договору - другой смысл.

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

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

Короткий список типовых сбоев полезно держать под рукой:

• OCR распознал текст, но сломал границы столбцов;
• минус, пробел в тысячах или запятая в дробной части исчезли;
• две строки слиплись после переноса описания;
• сноска изменила ставку, а парсер ее не учел;
• редактор исправил таблицу вручную и затер исходник.

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

Проблемы редко начинаются с большого сбоя. Обычно все портят мелкие потери: один минус, одна сноска, одна склеенная строка. Потом именно они ломают проверку сумм в отчетах.

Быстрые проверки перед выгрузкой

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

Проверка перед экспортом

• Просмотрите столбцы целиком. Если в середине колонки появились пустые ячейки, проверьте, не съехали ли значения вправо или влево.
• Откройте несколько числовых столбцов и попробуйте отсортировать их или посчитать сумму. Если "1 250,00" ведет себя как текст, дальше сломаются фильтры, формулы и сводные таблицы.
• Сведите промежуточные итоги с цифрами в документе. Сначала по разделам, потом по всему файлу. Расхождение даже на 0,01 часто указывает на неверный разделитель, потерянный минус или пропущенную строку.
• Пометьте спорные строки сразу. Метка "проверить вручную" лучше, чем тихая ошибка в финальной выгрузке.
• Сохраните след к источнику: номер страницы, имя файла и небольшую вырезку исходной таблицы.

Отдельно проверьте единый формат дат и валют. Если одна часть таблицы хранит дату как "10.02.2024", а другая как "2024-02-10", сортировка и объединение пойдут криво. С валютой та же история: "тенге", "KZT" и символ валюты лучше привести к одному виду до выгрузки, а не после.

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

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

Что делать дальше, если документов много

Когда PDF становится не десять, а двести в неделю, ручная правка ломает весь процесс. В этот момент нужен не "еще один скрипт", а простой поток, где каждый файл проходит один и тот же путь и не теряется между папками, письмами и Excel.

Обычно рабочая схема выглядит так:

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

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

Если смешать эти типы в одном сценарии, ошибки быстро накапливаются. Чистый PDF чаще ломается из-за объединенных ячеек, а скан - из-за одной плохо прочитанной цифры, которая меняет итог на весь лист.

Журнал ошибок

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

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

Если вы подключаете LLM, не отправляйте ей весь документ без разбора. Гораздо лучше отдавать только спорные фрагменты: заголовок таблицы, одну проблемную строку или блок, где нужно разделить столбцы. Для такого слоя удобен единый шлюз вроде AI Router: можно гонять проверки через один OpenAI-совместимый endpoint и не менять существующие SDK и код. Для команд в Казахстане бывает полезно и то, что у airouter.kz есть хранение данных внутри страны и аудит-логи.

С чего начать пилот

Начните с 50-100 документов, а не со всего архива. Возьмите 3-4 самых частых типа: ежемесячные отчеты, приложения с тарифами, табличные приложения к договору. Этого хватит, чтобы понять, какой процент файлов проходит без правки и где без человека пока не обойтись.

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