Как обработать 1000 сканов договоров в Excel

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

Я часто вижу одну и ту же ловушку: команда берёт папку со сканами, запускает распознавание, получает текстовый «фарш» и пытается сразу выгрузить его в Excel. На 20 документах это ещё терпимо. На 1000 сканов, особенно если в каждом 2–6 страниц, ручная проверка быстро превращается в отдельный проект. У Excel есть предел 1 048 576 строк и 16 384 столбца на лист, но настоящая проблема почти всегда раньше: ИНН должен содержать 10 или 12 цифр, КПП ровно 9, БИК ровно 9, расчётный счёт 20. Если эти признаки не проверять автоматически, таблица выглядит заполненной, а бухгалтерия всё равно возвращает её на исправление.

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

С чего начинается обработка 1000 сканов?

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

Для печатного текста на листе A4 обычно хватает 300 dpi: такой лист даёт примерно 2480 × 3508 пикселей. При 150 dpi мелкие цифры в БИК, ИНН и датах чаще слипаются, особенно если документ пришёл из мессенджера. У серых сканов полезно выравнивать фон, у фотографий с телефона, исправлять перспективу. Если лист снят под углом 15–25 градусов, OCR часто путает «1», «7» и «/» в датах.

Я разбиваю входную папку на партии по 100–200 файлов. Так проще повторить обработку после изменения правил и не пересобирать весь массив из 1000 документов. На этом этапе уже нужна таблица учёта: имя файла, номер страницы, контроль качества, статус OCR, статус проверки, причина отказа. Без такой таблицы через 2 дня невозможно понять, почему 37 документов ушли в ручную очередь.

Полезная схема потока выглядит так:

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

Как распознать текст на фото и сканах без потери цифр?

OCR должен возвращать не только текст, а координаты блоков и показатель уверенности, иначе 1000 сканов нельзя проверить системно. Я закладываю порог 85 из 100 для реквизитов и отправляю ниже этого уровня в ручную очередь.

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

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

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

Как извлечь из договора нужные поля?

Извлечение нужно строить вокруг фиксированной схемы из 10–20 полей, а не вокруг всего текста договора. Для типового реестра обычно хватает номера договора, даты, стороны, ИНН, КПП, БИК, расчётного счёта, суммы, валюты, НДС и статуса проверки.

Есть 2 основных подхода. Первый, регулярные выражения и правила: они хорошо находят ИНН, БИК, даты, номера счетов. Второй, языковая модель: она помогает понять, какая из 5 найденных сумм является ценой договора, а какая относится к штрафу, авансу или приложению. На 1000 сканов я не выбираю один подход. Я соединяю оба: правила дают кандидатов, модель выбирает смысловой вариант, валидатор проверяет цифры.

Условный пример: если в договоре есть фразы «цена договора составляет 1 240 000,00 руб.» и «пеня 0,1% за каждый день просрочки», правило найдёт 2 числовых фрагмента, а модель должна связать нужную сумму с полем «цена договора». Затем проверка типов приведёт сумму к числу 1240000.00, а процент 0,1 не попадёт в денежное поле.

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

Как находить ошибки в реквизитах и суммах?

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

Форматная проверка самая дешёвая. ИНН юридического лица состоит из 10 цифр, ИНН физического лица или ИП, из 12. ОГРН содержит 13 цифр, ОГРНИП, 15. Если OCR распознал ИНН как «77О1234567», буква «О» должна стать подозрением, потому что в реквизите допустимы цифры. Если дата получилась «32.01.2026», её нельзя исправлять молча, нужна ручная проверка.

Контрольная логика сложнее, но именно она спасает от красивых неверных таблиц. Для ИНН и ОГРН существуют контрольные разряды, по ним можно вычислить, похож ли номер на настоящий. Для сумм проверяются разделители: в русских документах запятая часто отделяет копейки, а пробел разделяет тысячи. Строка «1 250 000,50» должна стать числом 1250000.50, а не текстом. В Excel это различие критично: текстовая сумма не участвует в сводной таблице и сортируется иначе.

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

Как выгрузить данные в Excel так, чтобы ими можно было пользоваться?

Excel-выгрузка должна содержать сырые значения, очищенные значения и статус проверки, иначе таблица превращается в чёрный ящик. Для 1000 договоров я обычно делаю 1 основную строку на договор и отдельный лист ошибок с 5–8 техническими колонками.

Минимальный набор колонок для основной таблицы: идентификатор файла, номер страницы, номер договора, дата, контрагент, ИНН, КПП, БИК, расчётный счёт, сумма, валюта, НДС, статус, ссылка на фрагмент или координаты. Если в договоре 2 стороны, лучше явно хранить «наша сторона» и «контрагент», а не одну колонку «сторона». Это уменьшает путаницу при объединении с бухгалтерской базой.

Я не советую сразу перезаписывать спорные значения исправленными. Надёжнее держать 3 поля: raw_value, normalized_value, validation_status. Например, raw_value равен «1 25О 000,00», где OCR принял ноль за букву, normalized_value пустой, validation_status равен «сомнение OCR». Такая строка не потеряется при фильтрации.

Формат .xlsx удобен для бухгалтера, потому что сохраняет типы данных, ширину колонок, фильтры и несколько листов. CSV проще для обмена между системами, но у него есть риск с кодировкой, разделителем и ведущими нулями. БИК может начинаться с нуля, а Excel иногда превращает такие значения в число и удаляет первый символ. Поэтому реквизиты лучше хранить как текстовые поля, даже если они состоят из цифр.

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

Где в этом процессе помогает нейросеть, а где нужны правила?

Нейросеть полезна там, где нужно понять смысл фрагмента, а правила нужны там, где есть точный формат из 9, 10, 12, 13, 15 или 20 цифр. На массиве из 1000 договоров я не доверяю итоговую сумму одной модели без проверки арифметики и статуса уверенности.

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

Сравнение подходов помогает выбрать архитектуру:

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

Как организовать ручную проверку без перепечатывания всего массива?

Ручная проверка должна касаться 5–15% спорных полей, а не всех 1000 документов целиком. Для этого каждая строка получает статус: «чисто», «сомнение OCR», «конфликт полей», «нет обязательного поля», «нужен просмотр изображения».

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

Условный пример: в партии из 1000 сканов система пометила 120 строк как спорные, из них 70 из-за низкой уверенности OCR ниже 85, 30 из-за конфликта суммы цифрами и прописью, 20 из-за отсутствующего КПП. Такой отчёт сразу показывает, что проблема не одна: часть решается повторным сканированием, часть, настройкой извлечения, часть, уточнением бизнес-правил.

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

Какой план внедрения я бы выбрал?

Я бы не начинал с 1000 файлов сразу: сначала взял бы 50 сканов, добился точности правил на реквизитах и только потом масштабировал поток партиями по 200 документов. Такой пилот обычно показывает 80% проблем: плохие фото, разные шаблоны договоров, дубли, нестандартные суммы, пустые приложения.

Мой порядок действий такой. Сначала описать схему Excel: 12–20 колонок, тип каждого поля, обязательность, допустимые статусы. Затем собрать эталонную выборку из 50 документов: хорошие сканы, плохие фото, договоры с приложениями, документы на 2 стороны, файлы с печатями. После этого настроить OCR с координатами и уверенностью, извлечение кандидатов, валидаторы реквизитов, журнал ошибок. Только на следующем шаге запускать 1000 сканов.

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

Хороший результат в такой задаче, это не «нейросеть всё поняла». Хороший результат, это таблица, где каждая ячейка имеет происхождение, статус и понятный способ проверки. Тогда Excel перестаёт быть копией хаоса из папки со сканами и становится рабочим реестром договоров.