ИИ для чтения сканов: суммы и даты без ручного ввода в 2026
Практическая схема: от скана счёта или акта до проверенных полей в учётной системе, с контролем ошибок и понятным пилотом.
Ручной ввод документов редко ломается громко. Он просто съедает время: бухгалтер открывает PDF, ищет дату, сумму, ИНН, номер счёта, переносит данные в учётную систему, сверяет строку, возвращается к вложению. Один простой счёт может занять 2–5 минут. Пакет из 300 документов превращается в день монотонной работы, а ошибки появляются там, где человек устал или документ плохо отсканирован.
Я настраиваю такие процессы не с выбора модной модели, а с карты документа. Какие поля нужны? Откуда они берутся? Что делать, если сумма прописью расходится с суммой в таблице? Куда отправлять спорные документы? Без этих ответов нейросеть будет выглядеть умной в демо и ломаться на первой пачке реальных сканов.
Ниже разберём полный контур: подготовка сканов, распознавание текста, извлечение суммы, даты и контрагента, проверки, ручная очередь исключений и перенос в учётную систему. Для общей подготовки команды пригодится отдельный разбор о том, как внедрить нейросети в рабочие процессы, потому что автоматизация документов почти всегда упирается в регламент, а не в один промпт.
Что именно должен читать ИИ
Начните с ограниченного набора документов. Хорошая первая зона для пилота, входящие счета, акты, УПД, накладные, счета-фактуры. Не смешивайте их сразу с договорами, письмами в свободной форме и сканами рукописных заявлений. У разных типов документов разная структура: в счёте сумма обычно рядом с итоговой строкой, в акте важны номер и период, в УПД встречаются табличные части и несколько дат.
Минимальный набор полей для бухгалтерского ввода обычно выглядит так:
| Поле | Где искать | Типичная проверка | Что делать при сомнении |
|---|---|---|---|
| Дата документа | шапка, рядом с номером | формат даты, разумный период | отправить в очередь проверки |
| Номер документа | шапка, строка «Счёт №» или «Акт №» | не пустой, не совпадает с ИНН | показать оператору фрагмент скана |
| Контрагент | реквизиты продавца или исполнителя | ИНН/КПП совпадают со справочником | выбрать кандидата из 2–3 вариантов |
| Сумма | итоговая строка, иногда сумма прописью | сумма по строкам равна итогу | пометить как расхождение |
| НДС | таблица, итоговый блок | ставка и сумма согласованы | оставить поле пустым с причиной |
Самая частая ошибка на старте, просить модель «прочитать документ» без схемы результата. Нужно заранее задать формат: дата в виде ДД.ММ.ГГГГ, сумма числом с двумя знаками после запятой, ИНН без пробелов, валюта отдельным полем. Если вы уже работали с текстовыми задачами, логика похожа на подготовку ТЗ для генерации: в статье про нейросеть для генерации текста и проверку результата я разбираю, почему формат ответа часто важнее красивой формулировки запроса.
Архитектура процесса: от файла до проводки
Рабочий контур обычно состоит из семи шагов. Первый, приём файла: скан, PDF, фото из мессенджера или пакет из почты. Второй, предобработка: поворот страницы, удаление серого фона, повышение контраста, разделение многостраничного PDF. Третий, распознавание текста и координат. Четвёртый, извлечение полей по схеме. Пятый, нормализация: даты, суммы, ИНН, названия организаций. Шестой, проверки. Седьмой, запись в учётную систему через файл обмена, API или промежуточную таблицу.
Не пытайтесь перепрыгнуть через предобработку. Размытый скан под углом в 7 градусов часто даёт каскад ошибок: цифра 8 читается как 3, «ООО» превращается в «000», дата 01.04.2026 становится 07.04.2026. Если документ пришёл как фотография, полезно сначала найти область листа, выровнять перспективу, обрезать фон стола и только потом запускать распознавание.
Для разового прототипирования можно использовать чат с вложениями: в SoftChat авторизованный пользователь может прикреплять изображения и документы к сообщениям, а повторяемые формулировки сохранять как шаблоны промптов. Это удобно для проверки схемы извлечения и языка инструкций. Постоянный промышленный процесс всё равно лучше выносить в отдельный контур с журналом ошибок, правами доступа и выгрузкой в учётную систему.
Как извлекать сумму, дату и контрагента
Я делю извлечение на две части: «увидеть текст» и «понять поле». Распознавание символов отвечает за текстовый слой. Языковая модель или набор правил отвечает за смысл: какая дата является датой документа, а какая датой оплаты; какая организация продавец, а какая покупатель; какая сумма итоговая, а какая относится к отдельной строке.
Для суммы нужна иерархия кандидатов. Сначала ищем строки с маркерами «Итого», «Всего к оплате», «Сумма документа», «Всего с НДС». Затем проверяем табличные итоги. Потом сравниваем сумму цифрами и прописью, если она есть. При расхождении не надо угадывать. Надёжнее вернуть статус «нужна проверка» и показать оператору фрагмент страницы.
Дата сложнее, чем кажется. В одном счёте могут быть дата документа, дата оплаты, дата договора, дата отгрузки и дата печати. Правило «бери первую дату сверху» работает на части шаблонов, но ломается на документах с длинной шапкой. Лучше хранить рядом с датой контекст: 30–80 символов до и после найденного значения. Тогда проверка может отличить «Счёт от 12.05.2026» от «Оплатить до 17.05.2026».
Контрагент почти всегда должен подтверждаться справочником. Название может быть написано с кавычками, без кавычек, в сокращённой форме, с опечаткой после распознавания. ИНН даёт более прочную опору: 10 цифр для организации, 12 для ИП. КПП помогает отделить филиалы. Если ИНН найден, но название не совпадает со справочником, я бы не блокировал документ сразу. Лучше создать предупреждение: «ИНН найден, название отличается».
Проверки, без которых автоматизация опасна
Ошибка в тексте письма неприятна. Ошибка в сумме счёта может уйти в оплату, сверку или налоговый учёт. Поэтому проверка должна быть встроена в процесс, а не добавлена после первых проблем.
Минимальный набор контролей:
- Форматные проверки: дата существует, сумма больше нуля, ИНН состоит из нужного числа цифр.
- Арифметика: сумма строк равна итогу, НДС соответствует ставке, копейки не потерялись при округлении.
- Справочники: контрагент найден, договор активен, валюта разрешена для этого типа операции.
- Дубликаты: номер, дата, контрагент и сумма уже встречались в базе.
- Порог уверенности: если модель вернула низкую уверенность или несколько кандидатов, документ уходит оператору.
Для примера: если в потоке 1 000 документов в месяц система уверенно обрабатывает 700, а 300 отправляет на ручную проверку, это уже снижает объём ручного ввода. Но считать успехом нужно не процент автоматизации сам по себе, а долю ошибок после контроля. Иногда безопаснее автоматически проводить 60% документов и тщательно проверять остальные 40%, чем гнаться за 95% и переносить сомнительные суммы.
Хорошая практика, сохранять координаты каждого извлечённого поля. Оператор видит не просто значение «125 430,00», а подсвеченный прямоугольник на скане. Это экономит время при споре: не нужно заново читать весь документ. Для обучения команды формулировать понятные инструкции к ИИ полезен материал про искусство промптинга для нейросетей, там хорошо видна разница между просьбой «найди данные» и рабочей схемой результата.
Перенос в учётную систему
Передача данных бывает трёх типов. Первый, файл обмена: CSV, XLSX, XML или другой формат, который принимает учётная программа. Это проще для пилота, потому что не требует глубокой интеграции. Второй, API: система создаёт черновик документа напрямую. Это быстрее в ежедневной эксплуатации, но требует прав, журналирования и обработки ошибок. Третий, промежуточная очередь: данные попадают в таблицу или внутренний сервис, а бухгалтер подтверждает перенос.
Я предпочитаю начинать с черновиков, а не с автоматического проведения. Документ попадает в учётную систему со статусом «на проверке», рядом хранятся ссылка на скан, извлечённые поля, результат проверок и список предупреждений. Проведение без человека включают позже, когда накопилась статистика по типам документов и стало понятно, где система ошибается.
Для примера: в пилоте можно взять 200 документов за один месяц, разметить эталонные поля вручную и сравнить результат по каждому полю отдельно. Не смешивайте точность даты и точность суммы в один показатель. Дата может распознаваться на 98 из 100 документов, а контрагент, на 86 из 100, особенно если справочник грязный. Среднее число скроет узкое место.
Как собрать пилот без лишней сложности
Пилот должен отвечать на один вопрос: можно ли доверять этому процессу на вашем потоке документов. Для этого не нужен сразу идеальный интерфейс. Нужны папка с файлами, схема полей, эталонная разметка, журнал ошибок и понятный критерий остановки.
Я бы заложил такие этапы:
- выбрать 3–5 типов документов, а не весь архив;
- собрать по 50–100 примеров каждого типа, включая плохие сканы;
- описать поля и допустимые форматы;
- разметить эталон вручную;
- прогнать распознавание и извлечение;
- разобрать ошибки по категориям: скан, распознавание, логика поля, справочник, выгрузка;
- решить, какие ошибки исправляются правилами, какие требуют ручной очереди.
Условный пример: компания из сферы оптовой торговли, ~80 сотрудников, может начать с входящих счетов и актов за один квартал, потому что там обычно есть повторяемые контрагенты и понятные итоговые суммы. Договоры и письма лучше оставить на второй этап: свободный текст требует другой логики извлечения.
Если команда только начинает работать с ИИ-инструментами, не стоит сразу поручать им критичный финансовый участок. Сначала полезно отработать простые сценарии: классификация документов, краткое описание содержимого, поиск недостающих реквизитов. Для такой подготовки подходит материал о том, как использовать нейросети и чат-боты для повседневных задач, потому что навык постановки задачи одинаково нужен и в быту, и в документообороте.
Типовые ошибки при настройке
Первая ошибка, запускать автоматизацию на красивых тестовых PDF, а потом удивляться реальным сканам с печатями, сгибами и тенями. В тестовой выборке должны быть плохие страницы: перекос, низкое разрешение, фото с телефона, многостраничный файл, документ с двумя организациями на странице.
Вторая ошибка, не отделять распознавание от бизнес-логики. Если ИНН прочитан неверно, это проблема распознавания. Если ИНН прочитан верно, но выбран покупатель вместо продавца, это проблема извлечения. Если контрагент найден, но в справочнике два похожих юрлица, это проблема данных учётной системы. У каждой причины свой способ исправления.
Третья ошибка, не хранить исходные ответы модели и версии правил. Через месяц бухгалтер спросит, почему счёт попал в очередь проверки. Без журнала вы увидите только итоговое поле. С журналом видно: было три кандидата на сумму, итог выбран по строке «Всего», проверка НДС дала расхождение 12 копеек, документ отправлен оператору.
Четвёртая ошибка, забывать про права доступа. Документы могут содержать банковские реквизиты, персональные данные подписантов, коммерческие условия. Поток сканов нельзя отправлять в случайные сервисы без договора, политики хранения и понятного удаления файлов. Для внутреннего контура заранее определяют, кто видит сканы, кто правит результат, кто подтверждает выгрузку.
Метрики качества: что считать успехом
Процент правильно распознанных символов почти бесполезен для бизнеса. Вам нужны полевые метрики. Отдельно считайте точность суммы, даты, номера, ИНН, контрагента и НДС. Ещё полезны две операционные метрики: доля документов без ручного вмешательства и среднее время проверки одного исключения.
Я обычно смотрю на матрицу ошибок. Если сумма ошибается редко, но каждая ошибка критична, ставим жёсткий контроль и не пропускаем расхождения. Если название контрагента иногда отличается из-за кавычек, но ИНН совпадает, можно автоматически нормализовать название по справочнику. Если дубликаты находятся после выгрузки, переносим проверку раньше.
Нормальная цель пилота, не «полная замена ручного ввода», а управляемое сокращение рутины. Документы с высокой уверенностью идут в черновики, спорные попадают в очередь, плохие сканы возвращаются отправителю или оператору. Так система не притворяется безошибочной и даёт бухгалтерии контроль.
Что бы я сделал на вашем месте
Я бы начал с одного документа, например входящего счёта, и описал его как контракт данных: какие поля нужны, какой формат допустим, какие проверки обязательны, какой статус ставится при ошибке. Затем собрал бы 200–300 реальных файлов без чистки выборки. Красивые PDF, фото с телефона, перекошенные сканы, дубликаты, документы от старых контрагентов.
Дальше я бы сделал пилот в режиме черновиков. Никакого автоматического проведения в первый месяц. Только извлечение, подсветка фрагментов, проверки и очередь исключений. Через несколько циклов станет видно, где реальная проблема: качество сканов, грязный справочник, неясные правила выбора даты или слабая интеграция с учётной системой.
Если процесс выдержал пилот, расширяйте его по одному типу документов за раз. Не смешивайте счёт, акт, УПД и договор в одну «магическую кнопку». Автоматическое чтение сканов работает лучше всего там, где у системы есть схема, проверки, журнал решений и право честно сказать: «этот документ должен посмотреть человек».