Как ИИ читает сканы и переносит данные в учётку

Стендфирст: разбираю практическую схему обработки сканов, от загрузки файла до записи суммы, даты и контрагента в учётной системе.

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

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

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

Где ИИ реально помогает в обработке сканов

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

Классический OCR распознаёт символы. Языковая модель или специализированный извлекатель помогает понять, что именно означает найденный текст. Например, строка «15.04.2026» может быть датой договора, датой счёта или сроком оплаты. Сама цифра ещё не решает задачу. Нужно учитывать расположение на странице, соседние слова, формат документа и бизнес-правила.

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

В документах критерии жёстче. Ошибка в одном символе ИНН или в копейках суммы может увести документ не туда. Поэтому автоматизация должна считать не только найденное значение, а ещё и уверенность распознавания, источник поля на странице и результат сверки со справочником.

Пошаговый конвейер: от скана до записи в учёте

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

На первом шаге решается скучная, но критичная задача: не пускать мусор дальше. Если в поток попали фотографии с бликами, обрезанные страницы или сканы в 70 dpi, качество распознавания резко падает. Для бухгалтерских документов обычно целятся хотя бы в 200–300 dpi. Для мелкого шрифта и печатей лучше 300 dpi, потому что OCR должен различать точки, запятые, номера и дробные значения.

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

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

Как система находит сумму, дату и контрагента

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

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

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

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

Условный пример: документ «Счёт № 184 от 12.03.2026» содержит 5 дат, 27 денежных значений и 2 блока реквизитов, поэтому система должна выбрать дату рядом с номером счёта, итоговую сумму рядом со строкой «Всего к оплате» и контрагента по ИНН из блока поставщика. Такой пример хорошо показывает, почему простого OCR мало.

Проверка ошибок: без неё автоматизация быстро теряет доверие

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

Минимальный набор проверок выглядит так:

1. Форматные проверки: дата существует, сумма положительная, ИНН содержит нужное количество цифр.
2. Арифметика: сумма без налога плюс налог равна итогу, строки табличной части сходятся с общей суммой.
3. Справочники: контрагент найден, договор активен, валюта разрешена, организация-получатель совпадает.
4. Дубликаты: тот же номер, дата, сумма и контрагент уже были загружены.
5. Уверенность OCR: поля с низкой уверенностью не проходят без просмотра.

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

Компания из сферы оптовой торговли, ~150 сотрудников, при обработке входящих документов обычно смотрит на долю документов, прошедших без ручной правки, долю ошибок после импорта и среднее время разбора исключения. Эти показатели полезнее абстрактной «точности OCR», потому что они связаны с нагрузкой бухгалтерии.

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

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

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

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

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

Где нужен человек

Полностью убрать человека из обработки первички редко получается на старте. Человек нужен там, где документ повреждён, правило конфликтует со справочником или сумма выглядит верно математически, но подозрительно по бизнес-контексту.

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

Условный пример: если из 1 000 входящих документов 720 проходят автоматическую проверку, 230 требуют уточнения справочника, а 50 попадают в технический брак из-за качества скана, главная точка роста не в модели, а в дисциплине загрузки и справочниках. Такой разбор помогает не тратить бюджет на тонкую настройку там, где достаточно настроить правила приёма файлов.

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

Что сравнить перед выбором подхода

Сравнивать нужно не «ИИ против ручного ввода», а варианты архитектуры. У каждого подхода есть цена поддержки и граница применимости.

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

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

Как тестировать качество перед запуском

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

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

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

Операционно я бы запустил пилот так: один тип документа, один маршрут импорта, журнал всех исключений, еженедельный разбор ошибок. Через 3–4 недели уже видно, какие проблемы системные. Если большинство ошибок связано с двумя поставщиками, дешевле настроить их шаблоны или правила, чем перестраивать весь конвейер.

Итог: что бы я сделал на вашем месте

Я бы не начинал с покупки «системы для всего документооборота». Сначала выбрал бы один поток, например входящие счета от регулярных поставщиков. Затем описал бы поля, правила проверки, справочники и маршрут исключений. После этого собрал бы тестовый набор документов и отдельно померил качество OCR, извлечения суммы, даты, контрагента и импорта.

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

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