Скан УПД в 1С без ручного ввода: как связка OCR и ИИ-агента сняла с бухгалтера рутину

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

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

Почему «просто OCR» не сработал

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

Реальный поток это:

отсканированный счёт с перекосом в несколько градусов, потому что бумажку положили на стекло криво;
фото со смартфона менеджера, который получил документ прямо на встрече, у клиента в переговорке;
многостраничный УПД с таблицей номенклатуры на второй странице;
документы, где печать наложилась поверх КПП, и Tesseract читает «5504» как «S5O4».

Мы прогнали через прототип пару сотен реальных документов и увидели, что ИНН достаётся уверенно в лучшем случае у двух документов из трёх, КПП чуть чаще, расчётный счёт — примерно у каждого второго. Сумма с НДС читалась заметно лучше, но и там были свои чудеса: пробел внутри числа Tesseract превращал в запятую, и «1 250 000,00» становилось «1,250,000,00». Регулярка ломалась и отдавала мусор.

Мы попробовали накрутить препроцессинг: deskew через OpenCV, бинаризация Sauvola, попытка убрать печати по цветовым каналам. Точность подросла, но всё ещё была непригодной для прода. Каждый пятый документ пришлось бы править руками — а это значит, бухгалтер всё равно открывает каждый скан, читает его глазами, и вся автоматизация теряет смысл. Мы честно признались друг другу на планёрке, что тупиковая ветка, и пошли думать заново.

Второй подход: LLM как «читатель», а не «извлекатель»

Провал первого раунда научил простой вещи: OCR не умеет читать документ как документ. Он видит буквы, но не понимает, что «5504058620» рядом со словом «ИНН» — это ИНН, а «40702810900000012345» после «р/с» — расчётный счёт получателя, а не плательщика. Никакой регуляркой это не лечится, потому что порядок и разметка полей в реальных счетах пляшут как хотят.

Мы перестали пытаться извлекать поля регулярками. Вместо этого построили двухслойную схему — как раз ту, из которой обычно и вырастает нормальное ИИ-агентское решение:

Tesseract вытаскивает весь текст со страницы. Не поле по полю, а всё подряд, с сохранением примерной геометрии — то есть координат слов.
Полученный «сырой» текст плюс скриншот страницы уходят в GigaChat Pro со строгим промптом и жёсткой JSON Schema.

Ключевой момент — мы даём модели не только текст, но и визуальную структуру. GigaChat Pro в мультимодальном режиме видит, что в шапке — реквизиты поставщика, а в подвале — банковские реквизиты, что таблица номенклатуры разбита на колонки. Это то, чего Tesseract сам по себе не поймёт никогда.

Промпт короткий, без творчества. Формулировка примерно такая: «Извлеки реквизиты из документа. Если поле не читается однозначно, поставь null и укажи причину в поле uncertainty. Ничего не додумывай». JSON Schema с обязательными типами: ИНН — строка из 10 или 12 цифр, КПП — 9 цифр, расчётный счёт — 20 цифр, сумма — decimal.

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

Что происходит между PDF и 1С

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

ingest: PDF попадает в очередь через вебхук из почты. Многостраничные документы бьются на страницы, каждая идёт своим маршрутом.
ocr: pdf2image переводит страницу в PNG высокого разрешения, OpenCV делает deskew и denoise, Tesseract с русской моделью снимает текст с координатами.
extract: PNG плюс OCR-текст плюс промпт уходят в GigaChat Pro. Ответ — JSON, валидируется по схеме. Если валидация упала — документ попадает в очередь на ручную проверку, но не блокирует остальные, конвейер продолжает жить.
match: ИНН прогоняется через pgvector-индекс существующих контрагентов. Если совпадение по ИНН — обновляем карточку. Если ИНН новый, но название семантически близко к существующему («ООО Стройторг» и «ООО СтройТорг-Групп») — поднимаем флаг «возможный дубль» и просим менеджера подтвердить.

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

Обвязка вокруг GigaChat Pro стоит на нашем внутреннем прокси. У него есть неприятная особенность, о которую спотыкались несколько команд: жёсткий лимит 100 секунд на один HTTP-запрос. Если модель отвечает дольше — соединение рубится, и клиент получает таймаут вместо ответа. Поэтому запрос делится: сначала быстрая проверка, что документ вообще пригодный, потом основной вызов с картинкой. При таком делении в лимит укладываемся стабильно, и вся эта схема реально работает как локальный ИИ-агент внутри контура заказчика, без обращений к зарубежным облакам.

Что говорят люди, которые этим пользуются

Самая честная обратная связь пришла не от финдиректора, а от самой бухгалтерии. Первое, что мы услышали: «А точно ничего не додумывает?» Люди, которые всю жизнь сверяли реквизиты глазами, ИИ-агенту не доверяют по умолчанию, и это правильно. Мы показали, как работает арифметическая сверка сумм, и как в очередь на ручную проверку падают любые документы, где модель сомневается. Через пару недель тон поменялся: «Слушайте, а можно ещё акты сверки так же?»

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

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

Что не залетело и почему

Была идея скормить LLM сразу весь многостраничный PDF единым запросом. Красиво звучало, но разрушило точность: модель начинала путать поставщика и покупателя, если реквизиты обоих встречались на разных страницах. Разделение по страницам плюс явное указание «это первая страница УПД» в промпте вернуло качество на приемлемый уровень.

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

Была идея выкинуть Tesseract вообще и отдавать в GigaChat Pro только картинку. Работает, но медленнее и дороже — модель тратит токены на то, что Tesseract делает бесплатно и практически мгновенно. Гибрид оказался экономнее и по деньгам, и по времени отклика.

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

Что забирать из этой истории

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

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

Мы разрабатываем ИИ-агентов ровно из этой логики: делаем локально, внутри контура заказчика, на российских моделях, с обязательными проверками там, где ошибка стоит дорого. Никакой магии — просто аккуратная инженерия вокруг связки OCR, LLM и старой доброй арифметики.

А что вы делаете с потоком отсканированных первичных документов? Ручной ввод, RPA поверх 1С, свой ИИ-агент? Пишите — соберём отдельный обзор подходов, кто как выкручивается.