Автоматическое извлечение данных из счетов, актов и накладных строится на связке OCR, NLP, правил проверки и аккуратной интеграции с учетной системой.

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

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

Из чего состоит задача извлечения данных

В типовом документе нас интересуют не все слова подряд. Чаще нужны 3–10 полей: сумма, дата, контрагент, номер документа, ИНН, КПП, валюта, ставка НДС, назначение платежа. Чем меньше целевых полей на первом этапе, тем быстрее получается рабочий прототип.

Я обычно делю задачу на четыре слоя:

  1. Распознавание текста. Скан, PDF или фотография проходят через OCR. На выходе появляется текст с координатами строк и слов.
  2. Выделение кандидатов. Система ищет фрагменты, похожие на дату, сумму и название организации.
  3. Нормализация. Дата приводится к формату ISO, сумма к числу с валютой, контрагент к записи из справочника.
  4. Проверка и запись. Данные сверяются с правилами, после чего попадают в учетную систему или очередь ручной проверки.

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

Как OCR готовит документ к извлечению

OCR не «понимает» документ. Он распознаёт символы и, при хорошем движке, отдаёт координаты блоков. Для счёта это критично: сумма часто стоит справа внизу, дата рядом с номером, реквизиты контрагента в шапке или подвале.

Перед распознаванием документ лучше привести к стабильному виду:

  • выровнять наклон страницы;
  • убрать сильный шум и тени;
  • повысить контраст;
  • разделить многостраничный PDF на страницы;
  • сохранить координаты слов, строк и таблиц.

Практическая оценка: ручная обработка 40–60 однотипных документов в день легко съедает несколько часов, если менеджер открывает файл, ищет поля, копирует значения и сверяет справочник контрагентов. Модельный кейс: при 60 документах в день и среднем времени ручного ввода 5 минут на документ получается 300 минут, то есть 5 часов операционной работы за смену. Автоматизация не всегда убирает весь ручной труд, но способна оставить человеку только спорные документы.

Где подключается NLP

После OCR мы получаем текст, но текст ещё грязный. В нём могут быть переносы, ошибки распознавания, разные варианты написания и служебные фразы. NLP нужен, чтобы превратить текст в сущности.

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

Поле Что ищем в тексте Как нормализуем Частая ошибка
Сумма Число рядом со словами «итого», «к оплате», «всего» Копейки, валюта, знак дробной части Берётся сумма без НДС вместо итоговой
Дата Строки рядом с номером документа или шапкой ГГГГ-ММ-ДД День и месяц меняются местами
Контрагент Название, ИНН, КПП, банковские реквизиты Сопоставление со справочником OCR путает буквы в названии
Номер Последовательность после слов «№», «номер», «счёт» Исходная строка без лишних пробелов Номер договора принимается за номер счёта

В проектах с нейросетями промпт и схема ответа решают половину задачи. Если просить «найди данные», результат будет гулять. Если задать JSON-схему с полями, допустимыми форматами и правилом «если не уверен, верни null», качество контроля растёт. О том, как формулировать такие инструкции, я подробно писал в материале про практику промптинга для нейросетей.

Схема пайплайна: от файла до учетной системы

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

  1. Приём файла. Документ приходит из почты, личного кабинета, папки обмена или формы загрузки.
  2. Классификация. Система определяет тип: счёт, акт, накладная, договор, прочее.
  3. OCR. Изображение или PDF превращается в текст с координатами.
  4. Извлечение сущностей. NLP-модуль возвращает сумму, дату, контрагента и дополнительные поля.
  5. Валидация. Правила проверяют формат, диапазон, совпадение с реестрами и справочниками.
  6. Очередь исключений. Спорные документы уходят на ручную проверку.
  7. Запись. Подтверждённые данные передаются через API, CSV-импорт или коннектор.

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

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

Как проверять ошибки извлечения

Проверка не сводится к вопросу «нашли поле или нет». Нужны правила, которые отсеивают правдоподобную ерунду.

Для суммы я использую такие проверки:

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

Для даты полезны другие ограничения. Дата документа не должна быть сильно в будущем. Дата закрывающего документа обычно попадает в отчетный период. Если документ пришёл в январе, а OCR распознал «2094-01-12», это кандидат на ручную проверку.

С контрагентом сложнее. Название может быть написано с кавычками, сокращениями, строчными буквами, переносами. Поэтому лучше опираться на ИНН и КПП, а не на строку названия. Если реквизиты отсутствуют, можно применять нечёткое сопоставление со справочником, но с порогом уверенности. Ниже порога запись не должна автоматически попадать в учетную систему.

Гипотетический пример: документ «Счёт № 418» содержит три суммы, 12 000,00 ₽, 2 400,00 ₽ и 14 400,00 ₽, поэтому система выбирает строку рядом с «к оплате» и сверяет её с суммой прописью. Если пропись распознана плохо, поле получает статус «нужна проверка», а не записывается молча.

Разметка данных и обучение экстрактора

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

Для разметки нужны понятные инструкции. Например:

  • суммой считать итог к оплате, а не сумму без налога;
  • датой считать дату документа, а не дату договора или оплаты;
  • контрагентом считать поставщика, если документ входящий;
  • при нескольких совпадениях выбирать поле с максимальной бизнес-значимостью;
  • если поле не найдено, ставить пустое значение, а не угадывать.

Минимальный набор для пилота может включать 100–300 документов одного типа. Этого часто хватает, чтобы увидеть основные ошибки OCR, различия шаблонов и проблемные поля. Для промышленного контура объём разметки растёт вместе с числом типов документов, поставщиков и языков.

JSON-схема результата

Хороший экстрактор возвращает не текстовый пересказ, а структурированный объект. Так его проще проверять, хранить и отправлять дальше.

{
  "document_type": "invoice",
  "document_number": "418",
  "document_date": "2026-02-14",
  "counterparty": {
    "name": "ООО Ромашка",
    "inn": "7700000000",
    "kpp": "770001001"
  },
  "total_amount": {
    "value": 14400.00,
    "currency": "RUB",
    "confidence": 0.91
  },
  "validation_status": "needs_review",
  "warnings": [
    "Сумма прописью распознана частично"
  ]
}

В реальном контуре я добавляю к каждому полю источник: номер страницы, координаты блока, фрагмент исходного текста. Это сильно ускоряет ручную проверку. Менеджер видит не абстрактную ошибку, а конкретное место в документе.

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

Как заносить данные в учетную систему

После извлечения есть два безопасных режима записи.

Первый режим, полуавтоматический. Система показывает карточку документа с найденными полями, подсветкой источников и предупреждениями. Человек подтверждает результат. Такой вариант подходит для пилота, когда качество ещё измеряется и правила меняются каждую неделю.

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

Условный пример: компания из сферы оптовой торговли, ~80 сотрудников, обрабатывает 70 входящих счетов в день и переводит в ручную проверку только документы с пустым ИНН, несколькими итоговыми суммами или уверенностью ниже заданного порога. При среднем времени ручного ввода 4–6 минут на документ автоматизация снимает с менеджера до нескольких часов повторяемой работы в день, но оставляет контроль там, где цена ошибки выше.

Метрики качества: что считать успехом

Одна общая точность по всем документам мало что говорит. Для бизнеса важнее качество по полям.

Смотрите отдельно:

  • точность извлечения суммы;
  • точность даты документа;
  • точность сопоставления контрагента со справочником;
  • долю документов без ручной проверки;
  • долю ошибок после записи;
  • среднее время обработки одного документа.

Для суммы допустимая ошибка почти всегда ниже, чем для названия. Если система перепутала «ООО Альфа» и «ООО Альфа Сервис», это неприятно. Если она записала 140 000 вместо 14 000, последствия могут быть дороже. Поэтому автоматическую запись лучше разрешать по набору условий, а не по одному усреднённому баллу уверенности.

Где нейросеть помогает редактору процесса

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

В SoftChat для такой работы удобно вести отдельные диалоги, использовать историю бесед внутри организации, сохранять контекст обсуждения и получать ответы в виде таблиц или кода. В чате есть подсказки продолжения после ответа, а черновик запроса можно улучшить перед отправкой через действие «Улучшить запрос». Это помогает не начинать каждый раз с пустого листа, когда вы проектируете правила, проверяете структуру или формулируете инструкцию для разметчиков.

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

Что бы я сделал на вашем месте

Я бы не начинал с покупки тяжёлой платформы и обещания «автоматизировать все документы». Сначала взял бы один тип, например входящие счета, и зафиксировал 5–7 полей. Затем собрал бы выборку документов за месяц, отметил бы разные шаблоны поставщиков и описал правила проверки.

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

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