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

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

Я смотрю на OCR и NLP как на конвейер, где каждый этап снижает риск следующего. OCR переводит изображение или PDF в текст. NLP помогает понять, какие фрагменты этого текста являются суммой, датой, номером документа, ИНН, КПП, названием контрагента и назначением платежа. Валидация проверяет логику: сумма с НДС должна сходиться с итогом, дата не должна быть позже даты загрузки на год, а ИНН должен проходить контрольную проверку. Только после этого данные стоит отправлять в учётную систему через API, файл обмена или промежуточную очередь.

Что изменилось в обновлённой версии

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

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

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

Как выглядит конвейер OCR плюс NLP

Базовая схема состоит из 6 шагов. Сначала файл приводят к пригодному виду: выравнивают страницу, убирают шум, повышают контраст, разделяют многостраничный PDF на страницы. Для сканов обычно берут разрешение 300 DPI. Для фото с телефона критичны тени, перекосы и сжатие, потому что символы «8», «В» и «З» начинают путаться чаще.

Затем OCR извлекает текст и координаты блоков. Координаты нужны не меньше самого текста. В счётах и актах смысл часто задаётся расположением: сумма рядом со словом «Итого», дата рядом с номером, реквизиты продавца в верхней части, покупателя ниже или в отдельном блоке. Если оставить только сплошной текст, модель теряет часть подсказок.

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

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

Какие поля стоит извлекать первыми

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

Условный пример: в счёте «№ 48 от 17.06.2026» сумма «125 400,00 ₽» может встретиться 3 раза, в строке оплаты, в итогах и в тексте «в том числе НДС». Без правил модель может выбрать сумму НДС вместо общей суммы. Проверка должна сравнить кандидатов и отдать приоритет полю рядом с «Всего к оплате» или «Итого к оплате».

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

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

Проверка ошибок: где автоматизация чаще всего ломается

Самая частая ошибка, выбор похожего поля. В документе есть дата счёта, дата договора, дата оплаты и дата печати формы. Если нужна дата первичного документа, правило должно прямо запрещать брать дату из банковских реквизитов или футера. Вторая частая ошибка, неверная нормализация суммы. Форматы «1 250,50», «1.250,50» и «1250-50» встречаются в разных выгрузках и сканах. Перед записью в систему значение нужно привести к единому числовому формату.

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

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

Гипотетический пример: если из 1 000 входящих документов 6% требуют ручной проверки, оператор разбирает 60 документов, а не весь поток. При средней ручной обработке 2–4 минуты на документ это уже заметная экономия времени. Такая оценка не заменяет пилот, но помогает посчитать порядок выгоды до разработки интеграции.

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

После извлечения и проверки данные нужно передать дальше. Здесь есть 3 рабочих варианта. Первый, API учётной системы. Он удобен, если нужно создавать документы сразу со статусами, комментариями и ссылкой на оригинальный файл. Второй, обмен через XML, JSON или CSV. Он проще на старте, но хуже подходит для сложных ошибок. Третий, очередь задач: распознанный документ попадает в промежуточный сервис, где его подтверждает оператор или правило автопроводки.

Я не советую сразу включать полную автозапись для всех документов. Безопаснее начать с режима «черновик плюс подтверждение». Система заполняет поля, подсвечивает уверенность и показывает фрагмент оригинала, откуда взято значение. Оператор проверяет только сомнительные места. После накопления статистики можно разрешить автоматическую запись для документов с высокой уверенностью, например когда все обязательные поля заполнены, ИНН прошёл проверку, а контрагент найден в справочнике.

Для интеграции с 1С, ERP или CRM заранее определяют статусы: «распознано», «требует проверки», «дубликат», «ошибка справочника», «загружено». Эти статусы экономят время поддержки. Если документ не попал в учёт, команда видит причину, а не ищет файл в почте, папке обмена и журнале ошибок.

Где здесь помогают языковые модели

Языковая модель полезна там, где документ не укладывается в жёсткий шаблон. Она может понять, что «оплата по договору», «основание» и «ссылка на договор» относятся к одной смысловой зоне. Она лучше обычного шаблона справляется с переносами строк, нестандартными формами и смешанными описаниями услуг. Но модель не должна быть единственным судьёй перед записью в учёт.

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

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

Минимальный пилот на 2 недели

Пилот лучше строить на реальном наборе документов, но без обещания полной автоматизации. Достаточно взять 100–300 обезличенных файлов одного типа: счета, акты или УПД. Для каждого файла вручную заполняют эталон: дата, номер, сумма, ИНН, контрагент. Потом прогоняют конвейер и считают точность по каждому полю отдельно. Общая точность «документ распознан» слишком грубая. Если сумма верна в 98% случаев, а контрагент в 82%, улучшать нужно справочник и правила сопоставления, а не весь OCR.

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

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

Заключение, что изменилось после обновления

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

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