Распознавание документов с AI: как автоматизировать обработку счетов, актов и договоров
Как работает интеллектуальная обработка документов: распознавание, извлечение полей языковыми моделями, проверка по правилам и учётной системе, очередь ручной проверки, метрики точности, защита от поддельных счетов и порядок внедрения.
В бухгалтерии, закупках, логистике и юридическом отделе значительная часть рабочего дня уходит на одно и то же: открыть документ, найти в нём нужные поля, перенести их в учётную систему, сверить с другим документом. Счета поставщиков, акты, товарные накладные, договоры, доверенности, заявления клиентов, путевые листы. Каждый документ обрабатывается за минуты, но их тысячи в месяц, и ошибка при переносе суммы или реквизитов потом стоит часов разбирательств. Интеллектуальная обработка документов — сочетание распознавания текста, извлечения данных языковыми моделями, проверки по правилам и интеграции с учётными системами — позволяет автоматизировать этот поток. Ниже — как устроена такая система, какие документы поддаются автоматизации легко, а какие нет, как организовать проверку человеком, как измерять качество и в каком порядке внедрять. Что именно автоматизируется Обработка документа состоит из нескольких операций, и автоматизировать можно каждую по отдельности. Приём. Документы приходят по почте, через электронный документооборот, загружаются в личном кабинете, сканируются в офисе, фотографируются на телефон. Классификация. Определение типа документа: счёт, акт, накладная, договор, претензия. Распознавание. Получение текста из скана или фотографии. Извлечение данных. Поставщик, ИНН, номер и дата документа, сумма, НДС, позиции с количеством и ценой, сроки, условия. Проверка. Сверка извлечённых данных с учётной системой, договором, заказом, правилами. Передача. Создание документа в учётной системе, запуск согласования, архивирование. Экономия времени появляется не на одном этапе, а когда вся цепочка работает без ручного переноса, а человек подключается только к документам, где система не уверена или нашла расхождение. Как устроена система Распознавание текста Для документов с текстовым слоем — электронных PDF, файлов из документооборота — распознавание не нужно: текст извлекается напрямую. Для сканов и фотографий используется оптическое распознавание символов. Современные модели хорошо справляются с печатным текстом, но качество зависит от исходника: разрешение, наклон, тени на фотографии, печати поверх текста, мелкий шрифт в таблицах. Отдельная задача — сохранение структуры. Для счёта недостаточно получить набор строк: нужно понимать, что это таблица, какие столбцы и какая сумма относится к какой позиции. Извлечение данных: шаблоны и модели Шаблонный подход. Для каждого вида документа описывается, где на странице находится нужное поле. Работает точно для однотипных документов из одного источника — например, собственных бланков. Ломается, когда поставщиков сотни и у каждого своя форма счёта. Языковые модели. Модель получает текст документа и описание того, какие поля нужно извлечь, и находит их независимо от расположения на странице. Хорошо справляется с разнообразием форм, но может ошибаться в деталях и должна проверяться. Мультимодальные модели. Работают с изображением документа напрямую, учитывая и текст, и визуальную структуру: таблицы, выделения, расположение подписи и печати. На практике их комбинируют: для частых стандартных форм — шаблоны или специально настроенные модели, для остального потока — языковые модели с обязательной проверкой. Проверка по правилам Самая недооценённая часть. Извлечённые данные проверяются не только на правдоподобие, но и на согласованность: сумма позиций равна итоговой сумме, НДС посчитан верно; ИНН имеет корректную контрольную сумму и совпадает с контрагентом в учётной системе; номер и дата документа не совпадают с уже загруженным — защита от дублей; цены соответствуют договору или заказу, количество — принятому на складе; реквизиты банка получателя совпадают с известными для этого контрагента — защита от мошеннических счетов с подменёнными реквизитами. Правила ловят ошибки распознавания и ошибки в самих документах. Второе часто оказывается даже ценнее: система замечает расхождения, которые человек при ручной обработке пропускал. Оценка уверенности Для каждого извлечённого поля система определяет, насколько она уверена в результате. Уверенность складывается из оценки модели распознавания, согласованности с правилами и совпадения с данными учётной системы. Документы, где все ключевые поля извлечены уверенно и прошли проверки, уходят дальше автоматически. Остальные направляются человеку. Интерфейс проверки Сотрудник видит документ рядом с извлечёнными данными, поля с низкой уверенностью и найденные расхождения подсвечены. Исправление занимает секунды, а не минуты, потому что человек проверяет и правит, а не набирает с нуля. Исправления сохраняются и используются для улучшения системы. Путь одного счёта: от письма до учётной системы Чтобы понять, как части системы работают вместе, проследим за одним документом — счётом поставщика, пришедшим на общий почтовый ящик бухгалтерии. 1. Приём Система забирает письмо, сохраняет вложения и отделяет документы от подписей, логотипов и прочих изображений. Если в одном PDF несколько документов подряд — например, счёт и акт, — они разделяются по страницам. 2. Классификация Модель определяет, что первая страница — счёт на оплату. Для счёта применяется свой набор полей и правил, для акта — другой. 3. Извлечение Из документа извлекаются: наименование и ИНН поставщика, КПП, банковские реквизиты, номер и дата счёта, позиции с количеством, ценой и суммой, ставка и сумма НДС, итог к оплате, срок оплаты, ссылка на договор, если она есть. У каждого поля — оценка уверенности. 4. Сопоставление По ИНН и КПП находится контрагент в учётной системе. По номеру договора или составу позиций — заказ поставщику. Проверяется, не загружался ли уже счёт с тем же номером и датой от этого поставщика. 5. Проверки Сумма позиций сходится с итогом, НДС посчитан верно, цены совпадают с заказом, банковские реквизиты совпадают с теми, что уже есть в карточке контрагента. Допустим, всё сходится, кроме одного: расчётный счёт в документе отличается от известного. 6. Решение Несмотря на высокую уверенность во всех полях, изменённые реквизиты — правило обязательной ручной проверки. Документ уходит в очередь с пометкой «новые банковские реквизиты». Если бы реквизиты совпали, счёт был бы создан в учётной системе автоматически. 7. Проверка человеком Бухгалтер видит скан, заполненные поля и подсвеченное расхождение. Он связывается с поставщиком по известному контакту — не по телефону из письма — и подтверждает смену банка. После подтверждения реквизиты в карточке контрагента обновляются, счёт уходит дальше. 8. Передача в учёт и согласование В учётной системе создаётся документ с приложенным сканом, связанный с заказом. Запускается маршрут согласования оплаты по правилам компании. Весь путь — что извлечено, что проверено, кто и когда подтвердил — записан в журнал. В этом сценарии человек потратил время только на то, что действительно требует решения, — и именно на то место, где при ручной обработке ошибка или мошенничество чаще всего проходят незамеченными. Какие документы автоматизируются легче Хорошо поддаются Первичные учётные документы: счета, акты, товарные накладные, универсальные передаточные документы. Набор полей стандартный, правила проверки понятны, объём большой. Документы из электронного документооборота. Часть данных уже структурирована, и задача сводится к сверке и маршрутизации. Однотипные заявления и анкеты от клиентов с известным набором полей. Документы, удостоверяющие данные: паспорта, свидетельства, выписки — при наличии оснований обработки персональных данных. Требуют больше работы Договоры. Извлечение реквизитов простое, а вот понимание условий — сроков, ответственности, порядка расторжения, нестандартных оговорок — требует более сложного анализа и почти всегда проверки юристом. Рукописные документы. Распознавание рукописного текста заметно менее надёжно, особенно для цифр. Сложные таблицы на несколько страниц с объединёнными ячейками и переносами. Низкокачественные фотографии с тенями, бликами и перспективой. Анализ договоров Отдельный класс задач — не перенос данных, а помощь в анализе содержания: найти в договоре условия, отличающиеся от типовой формы компании, выделить риски, проверить наличие обязательных пунктов, сравнить редакции. Здесь языковые модели полезны как ассистент, который готовит сводку и указывает на места для внимания, но решение и ответственность остаются за юристом. Если нужно отвечать на вопросы по большому массиву договоров и внутренних документов, подход близок к тому, что мы описывали в статье о RAG-системах . Как измерять качество Точность на уровне полей Доля правильно извлечённых значений для каждого поля отдельно. Средняя точность по всем полям скрывает проблемы: система может отлично извлекать номер и дату и ошибаться в сумме НДС — а именно она важна. Доля автоматической обработки Сколько документов проходит путь от приёма до учётной системы без участия человека. Это главная метрика экономического эффекта, но её нельзя рассматривать отдельно от точности: увеличить автоматическую обработку, снизив порог уверенности, легко, но ценой ошибок, которые попадут в учёт. Ошибки, прошедшие без проверки Самая важная метрика качества — доля документов, ушедших автоматически и оказавшихся с ошибкой. Её измеряют выборочной ручной проверкой уже обработанных документов. Цель — чтобы она была не выше, чем доля ошибок при ручной обработке до внедрения. Время обработки Среднее время от поступления документа до его отражения в учётной системе и время ручной проверки одного документа из очереди. Эталонный набор Как и в любой системе на моделях, качество измеряется на зафиксированном наборе документов с правильными значениями полей. Набор должен отражать реальный поток: разные поставщики, качество сканов, редкие формы. Каждое изменение — новая модель, другие правила, другой порог уверенности — проверяется на этом наборе до выкладки. Безопасность и данные Где обрабатываются документы. Первичные документы содержат коммерческую информацию, договоры — условия сделок, заявления клиентов — персональные данные. Отправка таких документов во внешние облачные модели требует оценки рисков и правовых оснований. Альтернативы — российские облачные сервисы или развёртывание моделей в контуре компании. Персональные данные. Паспортные данные и сведения о клиентах обрабатываются по требованиям 152-ФЗ, включая хранение на территории России и ограничение доступа. Доступ. Сотрудник очереди проверки видит только документы своего участка. Журнал. Фиксируется, что извлекла система, что исправил человек, кто и когда подтвердил передачу в учёт. Это нужно и для аудита, и для улучшения модели. Защита от мошенничества. Автоматизация не должна создавать путь, по которому поддельный счёт с подменёнными реквизитами уходит в оплату без проверки. Правило «новые или изменённые реквизиты — всегда на ручную проверку» стоит закладывать с первого дня. Интеграция с учётными системами Ценность обработки документов определяется тем, что происходит после извлечения данных. Типовые варианты: создание документа поступления или счёта в учётной системе с заполненными полями и приложенным сканом; сопоставление с заказом поставщику и приходом на склад — так называемая трёхсторонняя сверка; запуск маршрута согласования оплаты; обновление карточки контрагента при изменении реквизитов — только после подтверждения человеком; архивирование с индексацией по извлечённым полям для поиска. Проектировать интеграцию стоит по тем же принципам, что и любой обмен с учётной системой: главная система для каждого объекта, защита от дублей, очередь и журнал. Подробно — в статье об интеграции CRM и 1С . Порядок внедрения Выбрать поток. Один тип документов с большим объёмом и понятными правилами — чаще всего входящие счета и акты поставщиков. Измерить исходное состояние. Сколько документов в месяц, сколько времени уходит на один, сколько ошибок находится при сверках, как долго документ идёт до учёта. Собрать эталонный набор. Несколько сотен реальных документов из потока с правильными значениями полей. Сделать прототип и измерить точность по полям на эталонном наборе. На этом этапе