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

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

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

Что делают OCR, NLP и IDP в одной цепочке

OCR распознаёт символы на изображении: скане счёта, акте, накладной, УПД, квитанции. На выходе получается текстовый слой с координатами слов и уровнем уверенности. Хороший OCR знает, что строка «1 248 900,00» может быть суммой, а «12.04.2026» похожа на дату. Но он не понимает смысл документа на уровне бухгалтерского процесса.

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

Подход Что получает бухгалтер Где хватает Где ломается
Только OCR Текст из скана Разовый поиск по PDF, архив Нет понимания, где итоговая сумма и кто контрагент
OCR плюс шаблоны Поля по координатам Повторяющиеся формы от одного поставщика Новый макет документа требует настройки
OCR плюс NLP Поля по смыслу текста Счета, акты, накладные разных форматов Нужны правила проверки спорных значений
IDP-пайплайн Поля, уверенность, ошибки, статус Поток документов в учёте Требует владельца процесса и тестовой выборки

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

Как извлекать сумму, дату и контрагента без хаоса

Я начинаю с карты полей. Для счёта это обычно номер, дата, продавец, покупатель, ИНН продавца, сумма к оплате, НДС, валюта, основание. Для акта добавляется период услуги, для накладной, табличная часть с позициями, количеством и единицами измерения. Если сразу пытаться забрать «всё», качество падает. Лучше сначала закрыть 6–8 полей, которые реально идут в учётную запись.

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

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

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

Пример промпта для извлечения реквизитов

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

Ты получаешь текст, распознанный из скана бухгалтерского документа.
Извлеки поля: тип документа, номер, дата составления, продавец, ИНН продавца, покупатель, ИНН покупателя, сумма к оплате, сумма НДС, валюта.
Верни JSON. Для каждого поля укажи value, confidence от 0 до 1, evidence, page.
Не подставляй значение, если оно не найдено в тексте. В таком случае value = null, confidence = 0.
Если есть несколько сумм, выбери сумму к оплате по фразам «Итого», «Всего к оплате», «К оплате».
Не используй дату договора как дату документа.

Для примера: в документе «Счёт № 458 от 12.04.2026» модель может вернуть дату 12.04.2026 с confidence 0.94, если рядом есть слово «от» и номер счёта. Если на той же странице есть строка «оплатить до 19.04.2026», дата оплаты должна попасть в комментарий как неиспользованная, а не в поле даты документа. Такой пример нужен в тестах, потому что он ловит типовую ошибку на раннем этапе.

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

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

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

Проверка Пример правила Что делать при ошибке
Формат ИНН: 10 или 12 цифр, дата: ДД.ММ.ГГГГ Отправить на ручную проверку
Арифметика Сумма без НДС + НДС = итог Показать расхождение в рублях
Справочник ИНН есть в карточке контрагента Предложить создать или выбрать контрагента
Дубликаты Номер, дата, ИНН и сумма уже встречались Заблокировать автопроведение
Роль даты Срок оплаты не равен дате документа Попросить подтверждение

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

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

Для контрагента я добавляю проверку на похожие названия. Если в справочнике есть «Ромашка Сервис» и «Ромашка-Сервис», автоматический выбор только по названию рискован. ИНН решает большую часть таких конфликтов. Когда ИНН не распознан, запись должна попасть в статус «требует уточнения», а не в автосоздание нового контрагента.

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

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

Я не советую начинать с автопроведения. Безопаснее первая версия, где система создаёт черновик, прикладывает исходный файл, показывает извлечённые поля и подсвечивает источник на странице. Бухгалтер видит, откуда взялась сумма, и принимает решение быстрее. Такой интерфейс уменьшает слепое доверие к модели. Это полезнее, чем красивый процент точности в презентации.

Для контроля качества собирают тестовый набор. В нём должны быть хорошие сканы, фото с телефона, документы с печатью поверх текста, многостраничные акты, счета с несколькими датами, накладные с таблицей. Для первого этапа хватит 100–300 документов разных типов, если они отражают реальный поток. Метрика должна считаться по полям: точность даты отдельно, суммы отдельно, контрагента отдельно. Общая точность «по документу» часто маскирует слабое поле.

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

Где нейросеть помогает бухгалтеру, а где нужны строгие правила

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

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

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

Типовые ошибки внедрения

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

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

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

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

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

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

Материал обновлён 3 июля 2026 года: акцент смещён с общего описания OCR на связку OCR, NLP, валидации и безопасного импорта. Главный критерий готовности простой: если система может показать источник каждого поля и объяснить причину отказа от автопроведения, её можно давать бухгалтеру в пилот. Если нет, это пока распознавалка текста, а не рабочий инструмент учёта.