Как автоматически извлекать данные из счетов, актов и договоров

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

Автоматическое извлечение данных из счетов, актов и договоров часто начинают с вопроса: «Какой OCR выбрать?» Это не тот вопрос, с которого стоит начинать. OCR умеет вернуть текст и координаты на странице, но бухгалтерии нужен не набор строк, а проверенный документ: с типом, контрагентом, номером, датой, суммой, валютой, НДС и понятным маршрутом дальше.

Поэтому рабочая AI-обработка документов — это конвейер из распознавания, классификации, извлечения, нормализации, проверок и контролируемой записи в учётную систему.

Что нужно доказать до следующего шага

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

Главное правило простое: уверенность распознавания помогает выбрать маршрут, но не заменяет бизнес-проверку. Даже поле с высокой уверенностью может содержать верно прочитанную, но недопустимую сумму или реквизит чужого контрагента.

Где появляется значение и кто его проверяет

Для меня такой шаг не завершён, пока его нельзя проверить по исходнику.

Представим обычный входящий счёт. Поставщик прислал PDF на общую почту. В письме может лежать один счёт, комплект «счёт + акт» или скан из нескольких документов, собранных в один файл. Сервис приёма сохраняет оригинал, вычисляет хеш и присваивает идентификатор обработки. Это нужно не только для аудита: хеш помогает остановить дубль до того, как он превратится во вторую заявку на оплату.

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

Для счёта важны продавец, покупатель, номер, дата, банковские реквизиты, позиции, итог, валюта и НДС. Для акта — период, основание, стороны, сумма и признаки подписания. Для договора — стороны, предмет, сроки, лимиты, условия оплаты и ссылки на приложения.

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

Подтверждённый пример · Staple AI. В кейсе Google Cloud компания описывает обработку разных типов документов с использованием OCR и последующего извлечения; в одном проекте сообщается о более чем миллионе документов за два дня. Для нашего сценария важен не масштаб сам по себе, а разделение слоёв: сначала оцифровка, затем понимание структуры и только после этого — бизнес-маршрут. Источник: Google Cloud ↗

OCR и документный workflow решают разные задачи

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

Разница хорошо видна на сумме «1 250 000,00». OCR может прочитать её без единой ошибки. Но workflow должен определить валюту, понять, включает ли сумма НДС, проверить арифметику строк, сопоставить значение с договорным лимитом и убедиться, что сумма относится именно к итоговой оплате, а не к справочному разделу. В договоре та же строка может быть лимитом ответственности, ценой этапа или штрафом — одинаковый текст имеет разный бизнес-смысл.

Я не считаю автоматический результат достаточным основанием сам по себе.

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

Сначала определить тип и границы документа

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

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

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

Извлекать поля нужно по схеме, а не списком догадок

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

Табличная часть требует отдельной схемы. Строка номенклатуры обычно включает наименование, единицу измерения, количество, цену, ставку НДС и сумму. Простая выгрузка текста часто теряет связь между колонками, особенно при переносе строк и многостраничных таблицах. Проверка «количество × цена = сумма» обнаруживает часть ошибок, но не исправляет неверно определённые границы строки. Поэтому полезно хранить координаты ячеек и показывать оператору именно спорную строку.

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

Проверка должна быть независимой от модели

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

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

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

Маршрутизация: три исхода вместо одного

После проверок документ получает не бинарный статус «распознан / не распознан», а один из трёх маршрутов. Первый — сквозная обработка: все обязательные поля извлечены, правила пройдены, риск низкий, создаётся черновик или выполняется заранее разрешённое действие. Второй — проверка конкретных исключений: сотрудник подтверждает два спорных поля, не перечитывая весь документ. Третий — остановка: файл повреждён, тип неизвестен, обнаружен дубль или нарушено критическое правило.

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

Что связывает документ с учётной системой

В производственной системе полезно разделить семь компонентов. Хранилище оригиналов отвечает за неизменность файлов и сроки хранения. Сервис приёма создаёт идентификаторы и отсекает дубли. Классификатор определяет тип и границы документа. Модуль извлечения возвращает поля и координаты. Слой нормализации и правил приводит значения к бизнес-формату. Очередь проверки обслуживает исключения. Интеграционный адаптер создаёт черновик в 1С, CRM или системе документооборота.

1. Оригинал. Сохраняется без перезаписи; рядом — хеш, источник и права доступа.
2. Результат модели. Хранится отдельно от подтверждённых данных, с версией процессора.
3. Нормализованные поля. Имеют тип, единицы измерения и ссылку на исходный фрагмент.
4. Решение правил. Содержит код проверки, входные значения и причину результата.
5. Действие сотрудника. Фиксирует автора, время и исправленное значение.
6. Интеграция. Использует идемпотентный ключ, чтобы повтор запроса не создал дубль.
7. Аудит. Связывает весь путь одним идентификатором обработки.

Для интеграции с 1С подходят HTTP-сервисы, REST-интерфейс или другой механизм, предусмотренный конфигурацией и политикой компании. Важно не название протокола, а контракт: какие поля обязательны, кто имеет право создать объект, как вернуть ошибку и что происходит при повторной доставке. AI-сервису обычно достаточно права создавать черновик; проведение документа и изменение справочников оставляют отдельным ролям.

Официальная документация Google, AWS и Microsoft подтверждает, что сервисы документного анализа возвращают структуру, поля и оценки уверенности. Однако архитектуру подтверждения, справочники и правила проведения компания проектирует сама — облачный API не знает внутренних лимитов и регламентов. Google Document AI, Amazon Textract, Microsoft Learn.

Какие ошибки я бы проверил руками

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

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

Какие ошибки действительно важны

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

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

С какого типа документов я бы начал

1. Выберите один поток. Например, входящие счета от двадцати активных поставщиков. Не смешивайте на старте договоры, акты и произвольную переписку.
2. Опишите схему полей. Разделите обязательные, справочные и смысловые поля; для каждого укажите формат, источник истины и последствия ошибки.
3. Соберите обезличенную выборку. Включите разные шаблоны, плохие сканы, дубли, многостраничные таблицы и реальные исключения.
4. Зафиксируйте исходные показатели. Время обработки, долю ошибок, стоимость ручного труда и объём возвратов поставщику.
5. Запустите теневой режим. Система извлекает и проверяет данные, но сотрудник продолжает работать по старому процессу; результаты сравниваются.
6. Настройте очередь исключений. Сначала добейтесь удобной проверки полей, затем разрешайте сквозную обработку простых случаев.
7. Подключите 1С или другую систему через черновики. Используйте идемпотентный ключ и запретите автоматическое проведение до приёмки.
8. Расширяйте поток по сегментам. Новый тип документа, поставщик или действие получает отдельную проверку качества и критерий отката.

Вопросы, которые я задаю перед внедрением

Можно ли сразу автоматически проводить документы в 1С?

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

Какой порог уверенности считать достаточным?

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

Нужна ли своя модель для счетов и актов?

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

Что делать с договорами свободной формы?

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

Как не создать дубли при повторной отправке?

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

Критерии готовности производственного workflow

• Оригинал документа хранится неизменяемо и связан со всеми производными данными.
• Тип документа и границы страниц определяются до извлечения полей.
• Каждое критическое поле имеет значение, уверенность, исходный фрагмент и результаты проверок.
• Справочники и бизнес-правила проверяются независимо от модели.
• Очередь исключений показывает причину и позволяет исправить конкретное поле.
• Интеграция защищена от дублей и работает с минимально необходимыми правами.
• Версии модели, схемы и решения сотрудника сохраняются в аудите.
• Качество измеряется на реальном потоке по типам документов и цене ошибки.

Источники и связанные материалы

Технические возможности извлечения, классификации, геометрии и оценки уверенности сверены с официальной документацией Google Document AI, Amazon Textract и Azure Document Intelligence. Варианты интеграции с учётной системой — по материалам платформы 1С:Предприятие. Конкретные пороги и правила в статье являются проектными рекомендациями: их нужно проверять на документах и регламентах вашей компании.

Продолжить тему: как передавать данные из PDF в 1С с подтверждением сотрудника · как сравнивать договор, счёт и акт между собой.

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