AI-извлечение данных из накладных и актов: LayoutLM, TrOCR, валидация

Извлечение данных из накладных: где ломается ручной ввод

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

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

Цена проявляется не сразу: возникает задержка проведения документов, потому что расхождение с первичкой поставщика нужно сначала найти. Потом — сторнирование, повторное согласование, переписка и повторный запрос копии. Чем позже ошибка всплыла, тем дороже её исправление.

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

Что даёт автоматизация ввода первичных документов

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

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

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

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

Режимы обработки: пакетный, потоковый и гибридный

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

Сравнение схем

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

Этапы внедрения: от аудита документов до передачи

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

1. Аудит потока документов. Смотрим, какие формы накладных и актов приходят, из каких каналов и какие реквизиты нужны дальше. На выходе — перечень форм и полей с приоритетом: что извлекаем автоматически, что уходит на проверку человеку.

2. Схема прохождения документа. Фиксируем маршрут: приём, распознавание, разметка полей, проверка, выгрузка в учётную систему, архив оригинала. Для каждого шага определяем, что происходит при ошибке и куда документ уходит на ручной разбор.

3. Настройка правил сопоставления. Поля привязываем к реквизитам учётной системы — номер, дата, сумма, контрагент, номенклатура. Задаём нормализацию разных написаний и форматов, а также порог уверенности, ниже которого документ не проходит автоматически.

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

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

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

Артефакты внедрения: схемы, правила, регламенты

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

• Схема маршрутов документа — весь путь накладной от входного канала до архива: где идёт распознавание, где документ ждёт оператора, по какому условию уходит на доразбор, а по какому возвращается поставщику.
• Профили обработки форм — отдельная настройка под каждый тип акта, накладной и корректировочного документа: перечень извлекаемых полей, обязательные реквизиты, порог уверенности, при котором строка принимается без человека.
• Правила доступа к документам — роли, разграничение по подразделениям и контрагентам, сроки хранения коммерческой тайны и персональных данных, журналирование каждого открытия и выгрузки.
• Инструкция операторам — что делать при низкой уверенности, как исправить поле, как пометить незнакомый шаблон, куда смотреть при расхождении сумм между документом и заказом.
• Регламент разбора исключений — классы сбоев (нечитаемый скан, нестандартная форма, расхождение с договором), ответственный на каждый класс, срок реакции и порядок возврата документа в автоматический поток.
• Словарь полей и справочников — сопоставление реквизитов из документов с вашей учётной системой, чтобы новые поставщики не ломали разбор.
• Контрольная выборка документов — обезличенный набор примеров с ожидаемыми значениями: по нему проверяется корректность любого изменения профиля.

Всё оформляем в вашей системе хранения, с версиями и историей правок, чтобы передача не превращалась в восстановление по переписке.

Кейс снабжения: сроки обработки до и после внедрения

Разберём кейс обработки накладных на участке расчётов с поставщиками. Это поток первички от нескольких сотен контрагентов, у каждого свой шаблон, порядок колонок и оформление, — через операторов проходило порядка 12 000 документов в месяц.

До внедрения

Каждый документ заводили в учётную систему вручную: сверяли реквизиты с договором, проверяли суммы и ставку налога, искали расхождения глазами. На один документ уходило 6–8 минут, а к закрытию периода поток вырастал вдвое — очередь закрывали переработками. Ошибки ввода всплывали уже на сверке, когда расхождение с первичкой поставщика приходилось разбирать с контрагентом и возвращать правку в учёт повторно.

После: контроль по исключениям

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

Срок обработки одного документа сократился с нескольких часов до минут, партия закрывается в день поступления. Доля ручных правок упала с 18% до 3%, расхождения с первичкой поставщика ловятся на входе, а не на сверке по периоду. Нагрузка на операторов сместилась с ввода на контроль по исключениям: тот же объём участок закрывает силами трёх человек вместо восьми.

Как проверить качество извлечённых данных до запуска?

Сравниваем не «распознался документ или нет», а каждое поле отдельно: ИНН, номер, дату, сумму без налога, итог, наименование позиции. Значения перед сравнением нормализуются, поэтому «1 234,56» и «1234.56» — одно и то же, и метрика не врёт там, где система права.

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

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

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

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

Ограничения распознавания и частые технические вопросы

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

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

Как проходит подключение к учётной системе?

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

Кто отвечает за ошибку в реквизитах?

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

Обсудим задачу: объём документов, источники, роли

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

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

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