Как ИИ распознаёт сканы для учётной системы
Разбираю практический контур: от загрузки скана до проверки суммы, даты, контрагента и записи в бухгалтерию без ручного ввода.
Скан счёта, акта или чека редко выглядит идеально. На нём бывают тени от сгиба, печати поверх текста, повёрнутые страницы, разные форматы дат, строки с НДС, скидками и доставкой. Простое распознавание текста решает только часть задачи. Бухгалтерии нужен не текстовый слой из PDF, а проверенные поля: сумма, дата, ИНН, контрагент, номер документа, ставка налога, валюта, статус дубля.
Я бы смотрел на такую автоматизацию как на конвейер из нескольких этапов. Сначала система приводит файл в читаемый вид. Затем распознаёт текст. После этого нейросеть или связка правил выделяет нужные сущности. Дальше идут проверки, маршрут согласования и запись в учётную систему через коннектор, API или готовый модуль обмена. Вручную остаётся разбор спорных документов, где уверенность модели низкая или данные не сходятся.
Если вы только подступаетесь к теме, полезно сначала понять, где нейросети дают выигрыш в рутинных задачах. Я уже разбирал это шире в статье про нейросети и чат-боты для повседневных процессов, а здесь сфокусируюсь на бухгалтерском сценарии.
Что происходит со сканом после загрузки
Рабочий процесс начинается не с нейросети, а с качества входного файла. Для документов формата А4 обычно хватает 300 dpi, серого или цветного режима, PDF, TIFF, PNG или JPEG. Если скан сделан телефоном, системе нужно выровнять перспективу, убрать лишние поля, повернуть страницу, повысить контраст и отделить фон от текста.
Дальше включается OCR, распознавание символов. Его задача, превратить изображение в текстовые блоки с координатами. Координаты нужны, потому что бухгалтерский документ читается не как сплошной абзац. В счёте сумма часто стоит в правом нижнем блоке, ИНН — рядом с реквизитами, дата — в шапке, номенклатура — в таблице. Если потерять расположение, модель начинает путать итоговую сумму с ценой одной строки.
Затем слой извлечения данных связывает фрагменты текста с полями учёта. Он ищет не просто слово «дата», а значение в нужном контексте. Например, рядом с «Счёт № 145 от 12.03.2026» дата документа одна, а рядом с «Оплатить до 17.03.2026» другая. В бухгалтерской записи эти даты попадают в разные поля.
Какие поля извлекать из счёта, акта и чека
Набор полей зависит от типа документа. Для авансового отчёта нужны одни атрибуты, для входящего счёта другие, для акта третьи. На пилоте я не советую начинать со всех документов сразу. Лучше взять 2–3 наиболее массовых формы и описать их как карточки данных.
| Тип данных | Пример поля | Проверка | Что делать при сомнении |
|---|---|---|---|
| Реквизиты документа | номер, дата, тип | дата не позже текущей, номер не пустой | отправить на ручное подтверждение |
| Деньги | сумма без налога, налог, итог | строки таблицы сходятся с итогом | подсветить расхождение по строкам |
| Контрагент | название, ИНН, КПП | ИНН имеет корректную длину и контрольные цифры | предложить ближайшую карточку поставщика |
| Товары и услуги | номенклатура, количество, цена | количество × цена = сумма строки | оставить строку в очереди проверки |
| Маршрут учёта | статья затрат, подразделение, проект | поле есть в справочнике | попросить выбрать значение из списка |
Для примера: если в документе написано «Итого к оплате 118 000,00», а строки дают 100 000,00 плюс 20 000,00 налога, система должна поднять флаг, потому что итог не сходится на 2 000,00. Это не задача распознавания символов. Это проверка арифметики и бизнес-логики.
С извлечением текстовых сущностей помогает грамотная формулировка задания модели. Вместо просьбы «найди всё полезное» я задаю схему результата: дата в формате ДД.ММ.ГГГГ, сумма числом с двумя знаками после запятой, валюта отдельным полем, ИНН только цифрами. Подробный разбор принципа есть в материале про правильные запросы к нейросетям.
Как система находит ошибки до записи в учёт
Автоматическая запись без проверки выглядит заманчиво, но в бухгалтерии это риск. Один неверно распознанный ноль меняет платёж, налоговую базу или остаток по контрагенту. Поэтому зрелый контур всегда считает уровень уверенности по каждому полю и по документу целиком.
Я использую такую логику. Если поле распознано уверенно, прошло форматную проверку и совпало со справочником, оно идёт дальше без участия человека. Если есть конфликт, документ попадает в очередь верификации. Конфликтом может быть ИНН из 9 цифр вместо 10 или 12, дата из будущего периода, дубль номера у того же поставщика, итоговая сумма, которая не равна сумме строк.
Условный пример: компания из сферы оптовой торговли, ~120 сотрудников, запускает обработку 4 типов входящих документов и ставит порог ручной проверки на уровне 0,85 по критичным полям. В ручную очередь попадают документы с размытыми печатями, таблицами на две страницы и расхождением итогов. Это нормальный режим пилота, потому что цель первого этапа, найти слабые места процесса, а не убрать человека из всех операций за неделю.
Отдельная проверка нужна для дублей. Система сравнивает контрагента, номер, дату, сумму и тип документа. Два файла могут называться по-разному, например «scan_001.pdf» и «счёт март.pdf», но внутри окажется один и тот же счёт. Для бухгалтерии такой дубль опаснее, чем пустое поле: пустое поле заметят, а повторную запись можно не увидеть до сверки.
Настройка без кода: из чего собрать контур
Без кода не значит без архитектуры. Обычно контур состоит из папки или формы загрузки, модуля распознавания, правила извлечения полей, проверки справочников, очереди согласования и записи в учётную систему. Код заменяют визуальные сценарии, готовые коннекторы и таблицы правил.
Типовой порядок такой:
- Выбрать один поток документов. Например, входящие счета от поставщиков.
- Собрать 50–100 образцов: чистые PDF, фото с телефона, сканы с печатями, многостраничные документы.
- Описать обязательные поля и допустимые форматы.
- Настроить распознавание и извлечение в тестовом контуре.
- Подключить проверку ИНН, суммы, даты, дублей и справочников.
- Завести очередь ручного подтверждения для спорных документов.
- Только после теста включать запись в рабочую учётную базу.
Для примера: в сценарии без кода бухгалтер загружает PDF в общую папку, конструктор запускает распознавание, результат попадает в таблицу проверки, а после подтверждения создаётся черновик документа в учётной системе. На первом этапе лучше создавать именно черновик. Автоматическая проводка без верификации уместна позже, когда накоплена статистика по ошибкам.
Если в команде нет единого процесса работы с нейросетями, автоматизация быстро превращается в набор разрозненных экспериментов. Для такой подготовки полезен материал о том, как внедрять нейросети в рабочие процессы: там проще увидеть, где нужен регламент, владелец процесса и контроль качества.
Где здесь помогает SoftChat, а где нужен отдельный контур
SoftChat не надо превращать в бухгалтерский OCR-модуль, если задача состоит в загрузке скана и записи проводки. Для такого сценария нужен специализированный контур распознавания, проверки и интеграции с учётной системой. Зато чат полезен на подготовительном участке: сформулировать правила извлечения полей, сравнить варианты сценария, написать текст регламента, разобрать ошибки в промптах, подготовить инструкции для бухгалтеров.
В SoftChat можно вести диалог с нейросетью, переключать модель в рамках разговора, использовать историю диалогов, промпт-шаблоны и подключать сохранённого ассистента к открытому чату. В настройках чата доступны параметры ответа вроде креативности и длины, а результат можно оформить в Markdown, таблицу или документ. Это удобно, когда команда проектирует процесс и хочет сохранить решения, а не держать их в переписке между сотрудниками.
Например, я бы завёл отдельный чат под регламент обработки входящих счетов и отдельный ассистентский сценарий под проверку формулировок: какие поля обязательны, какие ошибки считать критичными, что отправлять в ручную очередь. Если нужен общий контекст по текстовым задачам, можно опереться на статью про нейросеть для генерации и проверки текста, потому что регламенты, шаблоны писем и инструкции тоже требуют структуры.
Что выбрать: встроенный модуль, OCR-платформу или no-code-конструктор
Выбор зависит от объёма документов, качества сканов, требований к контролю и доступных интеграций. Сравнение только по цене часто обманывает. Дешёвый инструмент без очереди верификации может стоить дороже из-за ручных исправлений в конце месяца.
| Подход | Когда подходит | Сильная сторона | Ограничение |
|---|---|---|---|
| Встроенное распознавание в учётной системе | мало типов документов, стандартные формы | меньше интеграционных слоёв | хуже работает с нестандартными макетами |
| OCR-платформа | много сканов, разные поставщики, таблицы | гибкая настройка полей и проверок | нужен владелец процесса и тестовый набор |
| No-code/RPA-конструктор | нужно связать папку, почту, таблицу и учёт | быстрый пилот без разработки | сложные исключения упираются в ограничения конструктора |
| Кастомная интеграция через API | большой поток, строгие проверки, несколько систем | полный контроль логики | нужны разработка, поддержка и мониторинг |
Для малого бизнеса часто хватает связки «распознавание → таблица проверки → черновик в учёте». Для сети филиалов с сотнями документов в день уже нужны очереди, роли, журнал изменений и отчёты по качеству распознавания. Если документ приходит из мессенджера, почты и сканера одновременно, добавляется задача нормализации входящего потока.
С бытовыми голосовыми помощниками такую задачу путать не стоит. Они хороши для быстрых запросов, напоминаний и коротких справок, но работа с файлами, таблицами и проверкой полей требует другого класса интерфейса. Разницу между такими сценариями я разбирал в сравнении голосового помощника и нейросети в браузере.
Типовые ошибки при запуске
Первая ошибка, стартовать с плохого архива. Если в тестовом наборе только идеальные PDF от трёх поставщиков, пилот будет выглядеть гладко. Потом придут фото под углом, акты с печатью поверх суммы, счета на две страницы и документы с рукописной пометкой. Тестовый набор должен быть неприятным. Тогда метрики будут честнее.
Вторая ошибка, не разделять распознавание и бухгалтерское решение. Модель может извлечь «118 000,00» как итог, но не должна сама решать, к какой статье затрат отнести документ, если в компании нет правила. Такие правила лучше хранить отдельно: по контрагенту, подразделению, проекту, виду услуги.
Третья ошибка, сразу писать в рабочую базу. На пилоте безопаснее создавать черновики. Бухгалтер видит подсвеченные поля, подтверждает или правит их, а система запоминает типовые расхождения в отчёте качества. Через несколько недель уже понятно, какие документы можно пропускать быстрее, а какие лучше всегда показывать человеку.
Ещё одна частая проблема, отсутствие владельца справочников. Если в учётной системе один контрагент записан тремя способами, нейросеть не исправит управленческий хаос. Ей нужен чистый справочник или правило выбора основной карточки. Иначе часть ошибок будет выглядеть как технические, хотя причина в данных.
Финальный ориентир
Я бы запускал такой проект с узкого, измеримого участка. Один тип документа, один канал входа, понятный список полей, ручная очередь для сомнений, запись только в черновики. Через 2–4 недели пилота обычно видно, где узкое место: качество сканов, справочники, сложные таблицы, дубли или отсутствие правил по статьям затрат.
Хороший результат здесь не в том, что человек исчезает из процесса. Хороший результат, когда бухгалтер перестаёт перепечатывать очевидные поля и тратит внимание на исключения: спорную сумму, нового контрагента, странную дату, дубль документа. Тогда автоматизация не ломает учёт, а снимает повторяемую ручную работу и даёт прозрачный контроль на каждом шаге.