OCR и NLP в бухгалтерии: данные из сканов в 2026
Автоматическое извлечение данных из первички работает хорошо, когда OCR, NLP и бухгалтерские проверки собраны в один управляемый контур.
Я часто вижу одну и ту же проблему: бухгалтерия уже получает документы в электронном виде, но всё равно тратит время так, будто на столе лежит бумажная папка. Счёт приходит PDF-файлом, акт присылают сканом, накладную фотографируют на телефон, затем человек вручную переносит сумму, дату, номер и контрагента в учётную систему. На одном документе это занимает 1–3 минуты, на 300 документах в месяц превращается в отдельный участок работы.
OCR сам по себе решает только часть задачи. Он превращает картинку в текст, но не понимает, где именно находится сумма к оплате, почему дата отгрузки отличается от даты документа и какой из пяти найденных ИНН относится к продавцу. Для этого нужен второй слой, NLP, то есть обработка естественного языка. Третий слой, самый бухгалтерский, проверяет результат: сходятся ли суммы, похож ли ИНН на реальный, нет ли дубля по номеру и контрагенту.
Если вы только начинаете выстраивать работу с такими сценариями, полезно сначала разобраться, как нейросети помогают в рабочих процессах без хаоса, а затем переходить к конкретной схеме для документов.
Что делает OCR, а что остаётся за NLP
OCR отвечает за распознавание символов на изображении. На входе может быть скан, фотография, PDF с картинками внутри или смешанный документ, где часть текста уже выделяется мышью, а часть встроена как изображение. На выходе появляется текстовый слой: строки, координаты слов, иногда таблицы и блоки.
Для бухгалтерии голого текста мало. В счёте может быть несколько дат: дата выставления, дата оплаты, дата договора, дата доставки. В акте может быть сумма без НДС, сумма НДС и итоговая сумма. В накладной встречаются грузоотправитель, грузополучатель, поставщик и покупатель. OCR честно найдёт все эти фрагменты. Выбор нужного поля делает NLP-слой.
NLP работает с контекстом. Он ищет не просто число «125 400,00», а число рядом с признаками «Итого», «Всего к оплате», «Сумма документа». Он отличает ИНН поставщика от ИНН покупателя по соседним словам и структуре документа. Когда макет меняется, правила вида «бери третью строку справа» ломаются, а контекстный анализ сохраняет шанс на верный результат.
Здесь помогает тот же принцип, что и при подготовке текстовых задач для нейросетей: чем яснее описана цель, формат ответа и критерии проверки, тем стабильнее результат. Я подробно разбирал это в материале про формулирование запросов для нейросетей, и для OCR-сценариев логика почти та же, только вместо черновика текста мы просим структурированные поля.
Типовой конвейер обработки документа
Рабочий контур обычно состоит из шести этапов. Их лучше проектировать отдельно, иначе ошибки сливаются в одну мутную проблему «система неправильно распознала документ».
- Приём файла. Система получает PDF, JPG, PNG или TIFF, фиксирует источник, время загрузки и тип документа, если он известен.
- Предобработка изображения. Файл выравнивается, убирается шум, повышается контраст, страницы разделяются, повёрнутые листы разворачиваются.
- OCR. Из изображения извлекаются строки, слова и координаты. Для таблиц сохраняется расположение ячеек, если распознаватель это поддерживает.
- Классификация. Документ относится к типу: счёт, акт, накладная, УПД, чек, договорное приложение.
- NLP-извлечение. Модель выбирает нужные сущности: дату, сумму, валюту, контрагента, ИНН, КПП, номер документа.
- Проверка и запись. Результат проходит бизнес-правила, затем передаётся в учётную систему через файл обмена, API или промежуточную очередь.
| Этап | Что проверять | Частая ошибка | Как снижать риск |
|---|---|---|---|
| Предобработка | Наклон, размытость, обрезанные края | OCR путает «8» и «В» | Порог качества изображения до распознавания |
| OCR | Текст и координаты | Строки таблицы склеиваются | Хранить координаты слов, а не только плоский текст |
| NLP | Сумма, дата, контрагент | Берётся сумма без НДС вместо итога | Искать поле по контексту и соседним словам |
| Валидация | ИНН, НДС, дубли | Документ попадает в учёт дважды | Проверка по номеру, дате, сумме и контрагенту |
| Запись | Формат обмена | Поле не проходит справочник | Сверка с карточкой контрагента до проводки |
Для примера: если в архиве 1 000 сканов за квартал и ручной ввод одного документа занимает 2 минуты, только перенос полей даёт около 33 часов механической работы. Автоматизация не убирает контроль полностью, но переводит большую часть времени из набора текста в проверку исключений.
Как извлечь сумму, дату и контрагента без ловушек
Сумма кажется простым полем, пока не попадается счёт с авансом, скидкой, доставкой и НДС. Я обычно разделяю минимум четыре значения: сумма строк, сумма без НДС, НДС, итог к оплате. Для учёта часто нужен именно итог, но для проверки полезны все четыре. Если итог не равен сумме без НДС плюс НДС с допустимым округлением в 1 копейку, документ уходит на ручную проверку.
Дата требует такого же разделения. В первичке встречаются дата документа, дата оказания услуги, дата оплаты, дата договора и дата печати. При извлечении лучше возвращать тип даты вместе со значением: «дата документа: 12.03.2026», «дата договора: 01.02.2026». Тогда правило записи не угадывает смысл по одному числу.
Контрагент сложнее суммы и даты, потому что название может писаться по-разному. В одном документе компания указана как полное юридическое лицо, в другом как сокращённое название, в третьем виден только ИНН. Надёжнее связывать контрагента через ИНН и КПП, а название использовать как дополнительный признак. Для индивидуального предпринимателя КПП не будет, и это нормальный случай, а не ошибка.
Модельный кейс: компания из сферы оптовой торговли, ~50 сотрудников, обрабатывает 600 входящих документов в месяц и заводит правило «автозапись только при совпадении ИНН, итоговой суммы и даты документа». При таком подходе спорные документы не исчезают в системе молча, а попадают в очередь проверки с причиной: «не найден контрагент», «расхождение суммы», «возможный дубль».
Проверки, без которых автоматизация опасна
Главная ошибка при запуске OCR-проекта, доверять первому успешному распознаванию. Документ мог распознаться красиво, но неверно. Символ «0» похож на «О», запятая в сумме может потеряться, номер счёта может слиться с датой. Поэтому я закладываю проверки до записи в учёт.
Минимальный набор выглядит так:
- формат даты, например ДД.ММ.ГГГГ, плюс запрет будущей даты, если бизнес-процесс этого не допускает;
- проверка ИНН по длине и контрольным разрядам для российских организаций и ИП;
- сверка КПП, когда он есть в карточке контрагента;
- арифметика НДС и итога с учётом округления;
- поиск дубля по связке «контрагент, номер, дата, сумма»;
- проверка валюты, если учёт ведётся в нескольких валютах;
- контроль уверенности OCR и NLP, ниже порога документ уходит человеку.
Порог уверенности лучше задавать по типам документов. Для счёта от постоянного поставщика можно разрешить автозапись при высокой уверенности и совпадении справочника. Для нового контрагента безопаснее требовать подтверждение. УПД с несколькими страницами и табличной частью стоит проверять строже, чем простой счёт на одну услугу.
Если команда уже использует нейросети для текстовых задач, ей проще принять идею «человек проверяет результат, а не печатает всё заново». Похожий переход описан в статье про нейросеть для генерации текста и проверку результата: ценность появляется там, где есть понятный критерий качества.
Как заносить данные в учётную систему
Передача в учётную систему должна быть отдельным этапом, а не продолжением распознавания. OCR и NLP извлекли поля. Валидатор проверил их. Затем слой интеграции решает, что делать дальше: создать черновик документа, заполнить карточку входящего счёта, добавить файл-основание, поставить статус «требует проверки» или отправить запись на согласование.
В простом варианте используется файл обмена: CSV, XML или другой формат, который принимает учётная система. В более зрелой схеме применяется API. Между ними часто ставят очередь: распознанный документ ждёт записи, а при ошибке не теряется, а получает статус и текст причины. Это удобно для разбора инцидентов. Например, если справочник контрагентов не содержит ИНН, интеграция должна вернуть понятное сообщение, а не записывать контрагента как новую неизвестную организацию.
Я бы не начинал с полной автопроводки. Первый этап, заполнение черновика и подсветка полей, которые распознаны уверенно. Второй, автозапись простых документов от известных поставщиков. Третий, расширение на сложные формы и новые типы первички. Такой порядок снижает риск бухгалтерских ошибок и даёт материал для обучения правил на реальных документах.
Для бытовых и офисных задач люди часто ждут от чат-бота мгновенного ответа, но в учётном контуре важнее трассировка: откуда взялось поле, какой фрагмент документа его подтвердил, какие проверки пройдены. Разница между простым помощником и рабочим процессом хорошо видна в материале про нейросети и чат-боты для повседневных задач.
Где уместна языковая модель
Языковая модель полезна там, где правила становятся слишком хрупкими: разные макеты поставщиков, произвольные формулировки, смешанные документы, нестандартные подписи к суммам. Ей можно дать текст OCR, координаты блоков и схему ответа. Например: вернуть JSON с полями «document_type», «date», «total_amount», «supplier_inn», «supplier_name», «confidence», «evidence_text».
При этом модель не должна быть единственным судьёй. Хорошая схема просит её указать фрагмент-основание для каждого поля. Если сумма извлечена из строки «Итого к оплате 48 700,00», это основание сохраняется. Если модель не нашла явного подтверждения, поле остаётся пустым или получает низкую уверенность. Пустое поле лучше уверенной выдумки.
В SoftChat можно работать с текстовыми диалогами, выбирать модель для конкретного разговора и использовать шаблоны промптов для повторяемых задач. Это удобно на этапе проектирования: можно отработать формулировку задания для извлечения полей на обезличенных фрагментах текста, не приписывая чату роль бухгалтерской интеграции. Для постоянного промышленного контура всё равно понадобится отдельная система приёма файлов, OCR, валидатор и связка с учётной базой.
Метрики качества: что измерять до масштабирования
Оценивать такой проект по фразе «распознаёт нормально» нельзя. Нужны метрики по каждому полю. Для суммы считают точность итогового значения, для даты, долю верно определённых типов дат, для контрагента, совпадение ИНН и карточки справочника. Отдельно измеряют долю документов, которые ушли в автозапись, и долю документов, где человек исправил результат.
Условный пример: на тестовой выборке из 200 документов система верно извлекла итоговую сумму в 188 случаях, дату документа в 181 случае и ИНН поставщика в 193 случаях. Это не значит, что контур готов к автозаписи всех документов. Нужно посмотреть, какие 12 ошибок по сумме случились: плохой скан, редкий макет, таблица на второй странице или неверное определение итога. После такого разбора улучшают предобработку, правила или промпт.
Я предпочитаю запускать пилот на 100–300 документах одного типа. Меньше 100 часто не показывает разнообразие поставщиков. Больше 300 на старте затягивает разбор ошибок. После пилота появляется карта проблем: какие документы можно пускать автоматически, какие требуют подтверждения, какие пока лучше оставить в ручном процессе.
Как я бы запускал такой проект
Я начал бы с одного типа документа, например входящих счетов от постоянных поставщиков. Сначала собрал бы 100 обезличенных файлов, сохранил бы эталонные значения суммы, даты, ИНН и номера. Затем настроил бы предобработку, OCR, извлечение полей и проверки. Только после сравнения с эталоном стал бы обсуждать запись в учётную систему.
Моё правило простое: автозапись разрешается лишь там, где система может объяснить каждое поле и пройти проверку справочников. Всё остальное отправляется в очередь человеку. Так бухгалтер не превращается в оператора ввода, но сохраняет контроль над деньгами, налоговыми полями и первичными документами.
Хороший OCR-проект не начинается с обещания «убрать бухгалтерию из процесса». Он начинается с честной инвентаризации документов, понятного порога качества и списка ошибок, которые нельзя пропустить. Тогда автоматизация переносит рутину на машину, а человеку оставляет решения, где нужен профессиональный взгляд.