OCR + LLM для проверки первички: как мы автоматизировали валидацию 500 документов в месяц и что из этого вышло

Проверка одной накладной занимает 2–4 минуты. При потоке в 500 документов в месяц это 25–30 часов чистой ручной работы — и каждая пропущенная ошибка в реквизитах грозит доначислениями от ФНС. Связка OCR + LLM уже сегодня закрывает до 80% этой рутины.

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

Зачем вообще LLM, если есть ABBYY

Классический OCR для бухгалтерии существует давно. ABBYY FineReader, Tesseract, облачные API — всё это умеет извлекать текст из сканов. Но распознать текст и понять документ — разные задачи.

Шаблонный подход ломается, когда:

• Поле «ИНН» подписано как «ИНН/КПП покупателя»
• Таблица с товарами разбита на две страницы
• Контрагент использует собственный бланк с нестандартной структурой
• Печать наложена на текст реквизитов

LLM обрабатывает контекст и понимает структуру документа, даже если она отклоняется от типового бланка. Это принципиальное отличие от regex-правил и шаблонов.

Архитектура пайплайна: три этапа

Этап 1. OCR-распознавание

Извлечение текста и структуры из скана или фотографии. Лучшие результаты на российских документах показывают модели на базе Transformer-архитектуры:

• PaddleOCR v4 — open-source, хорошо работает с кириллицей, поддерживает layout analysis
• Microsoft TrOCR — учитывает контекст, не просто символы, а поля документа
• EasyOCR — проще в настройке, но уступает по точности на сложных документах

Точность на печатном тексте накладных — 95–98%. На рукописных элементах — существенно ниже.

Этап 2. Структурирование данных через LLM

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

Пример промпта для структурирования:

Важно: temperature=0 — для детерминированности. Один и тот же документ должен давать одинаковый результат.

Этап 3. Валидация по правилам 402-ФЗ

После извлечения данных — автоматическая проверка. Часть правил проще реализовать детерминированным кодом, а не через LLM:

А вот кросс-валидацию между связанными документами (счёт-фактура ↔ накладная ↔ акт) эффективнее делать через LLM — слишком много вариаций в формулировках наименований товаров и услуг.

Чек-лист автоматической проверки

Что проверяется по требованиям 402-ФЗ:

Проверка	Метод	Точность
Обязательные реквизиты (наименование, дата, субъект)	LLM + правила	94–97%
Формат и контрольная сумма ИНН	Детерминированный код	100%
Актуальность ИНН/КПП в ЕГРЮЛ	API ФНС	100%
Арифметика (суммы, НДС)	Детерминированный код	100%
Корректность ставок НДС (0%, 10%, 20%)	Правила + LLM для контекста	96–98%
Кросс-валидация связанных документов	LLM	85–90%

Классификация операций: автоматическая корреспонденция счетов

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

На практике модель корректно классифицирует 70–85% типовых операций. Оставшиеся 15–30% — нестандартные случаи, которые требуют решения бухгалтера.

RAG для нормативной базы

Третий сценарий — поиск по Налоговому кодексу, разъяснениям Минфина, письмам ФНС. Бухгалтер задаёт вопрос на естественном языке, RAG-система находит релевантные статьи и формирует ответ со ссылками.

Технически это стандартный RAG-пайплайн:

1. Индексация нормативных документов с chunk-размером 500–800 токенов
2. Embedding-модель (например, intfloat/multilingual-e5-large для русского языка)
3. Векторный поиск по запросу
4. LLM генерирует ответ на основе найденных фрагментов

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

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

Рукописные элементы

Печатный текст — 95–98% точности. Рукописные подписи, заметки на полях, исправления — зона риска. PaddleOCR v4 справляется с аккуратным почерком, но каракули главбуха на полях УПД остаются нерешённой задачей.

Печати и штампы

Круглая печать, наложенная на текст, снижает точность области перекрытия до 60–70%. Решение — предобработка изображения (удаление цветных слоёв), но это усложняет пайплайн.

Нестандартные бланки

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

Галлюцинации LLM

Самый опасный момент. Если LLM не нашла значение поля в документе, она может его «придумать» — подставить правдоподобный ИНН или дату. Mitigation: валидация через детерминированные правила (контрольная сумма ИНН, проверка по ЕГРЮЛ) и explicit instruction в промпте возвращать null для ненайденных полей.

Когда автоматизация окупается: грубый расчёт

Параметр	Значение
Документов в месяц	500
Время ручной проверки	3 мин / документ
Итого ручной работы	25 часов / месяц
Автоматизировано (80%)	20 часов / месяц
Стоимость часа бухгалтера (Москва)	800–1 200 ₽
Экономия в месяц	16 000–24 000 ₽
Стоимость API (OCR + LLM, ~500 документов)	3 000–7 000 ₽
Чистая экономия в месяц	10 000–20 000 ₽

При потоке от 500 документов экономия заметна, но не драматична. Реальный ROI появляется при масштабе 2000+ документов или когда цена ошибки высока — например, в компаниях с частыми налоговыми проверками.

Дополнительный фактор — снижение рисков. Средний размер доначислений по выездной проверке ФНС в 2023 году — более 60 млн рублей. Автоматическая валидация первички не гарантирует защиту от доначислений, но снижает вероятность ошибок в документах, которые могут стать основанием для претензий.

Итого

Связка OCR + LLM для бухгалтерии — не серебряная пуля, но рабочий инструмент для конкретных задач. Проверка первички автоматизируется на 80%, классификация проводок — на 70–85%, поиск по нормативке через RAG работает, но требует актуального индекса.

Главное ограничение — не технологии, а процессы. Автоматизация работает, когда есть чёткий пайплайн: скан → OCR → LLM → валидация → отчёт. Без выстроенного процесса даже лучшая модель не поможет.

Если у вас 500+ документов в месяц и ошибки в первичке — реальная боль, связка OCR + LLM уже готова к пилоту. Начните с одного типа документа (например, входящие накладные), замерьте точность и решите, стоит ли масштабировать.

---

Подписывайтесь на наш канал: @vibelogia

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram