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

Когда бухгалтер вручную переносит данные из сканов, проблема редко в одной операции. Открыть файл, найти дату, сверить ИНН, перепечатать сумму, проверить НДС, выбрать контрагента, сохранить проводку. На один аккуратный документ уходит 1–3 минуты, на плохой скан с печатью поверх текста, исправлениями и мелким шрифтом, уже 5–10 минут. При потоке в 300 документов в месяц это превращается в десятки часов однообразной работы.

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

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

Что именно нужно извлечь из скана

В учётной задаче нас обычно интересуют не все слова на странице. Нужен ограниченный набор реквизитов:

Поле Где встречается Типичная проверка Частая ошибка
Дата документа Счёт, акт, накладная, УПД Формат даты, период учёта Путаница между датой счёта и датой оплаты
Сумма Итоговая строка, блок оплаты Сверка суммы с НДС и валютой Модель берёт промежуточную сумму
Контрагент Шапка документа, реквизиты сторон ИНН, КПП, название из справочника Перепутаны покупатель и поставщик
Номер документа Верхняя часть страницы Уникальность в периоде Пропущены буквы, слэш или дефис
НДС Итоговая таблица Ставка 0%, 10%, 20%, без НДС Сумма НДС принята за итог к оплате

Для примера: в счёте может быть строка «Итого 118 000,00», рядом «НДС 18 000,00», а ниже фраза «Всего к оплате 118 000,00». Правильный алгоритм не должен брать первое найденное число. Он смотрит на контекст, соседние слова, положение блока на странице и связь суммы с налоговой строкой.

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

Шаг 1. Подготовка скана

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

Минимальная планка для большинства деловых документов, 200–300 точек на дюйм. Если текст мелкий, лучше 300. Фотография с телефона часто имеет 8–12 мегапикселей, но это не гарантирует читаемость: документ может быть снят под углом, а мелкий шрифт в реквизитах превращается в серую полосу. Поэтому перед распознаванием применяют выравнивание перспективы, бинаризацию, удаление фона и поиск границ листа.

Для примера: если ИНН напечатан кеглем 7–8 пунктов и попал в тень от сгиба, обычное посимвольное распознавание может заменить «8» на «В» или «0» на «О». Проверка по длине ИНН, контрольным цифрам и справочнику контрагентов отлавливает такую ошибку уже на следующем шаге.

Шаг 2. Распознавание текста и разметка страницы

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

В технической схеме обычно есть две параллельные линии:

  1. Посимвольное и построчное распознавание, где оценивается точность текста.
  2. Анализ макета, где выделяются шапка, таблица, реквизиты, подписи, итоговые блоки.

Для контроля качества используют метрики CER и WER. CER показывает долю ошибок на уровне символов, WER, на уровне слов. Для счёта даже 1% посимвольных ошибок может быть болезненным, если ошибка пришлась на ИНН, дату или сумму. Поэтому рабочая система не ограничивается средней точностью по странице. Она хранит уверенность по каждому полю.

flowchart TD
    A[Скан или фото] --> B[Очистка изображения]
    B --> C[Распознавание текста]
    C --> D[Поиск реквизитов]
    D --> E[Проверка по правилам]
    E --> F{Уверенность достаточная?}
    F -->|Да| G[Запись в учётную систему]
    F -->|Нет| H[Очередь на ручную проверку]

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

Шаг 3. Извлечение суммы, даты и контрагента

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

Я обычно разделяю поля по уровню риска.

Уровень риска Поля Как проверять
Низкий Номер страницы, тип файла Технические правила
Средний Номер документа, дата Формат, период, дубль в базе
Высокий Сумма, НДС, контрагент Арифметика, справочник, контрольные цифры
Критический Банковские реквизиты, получатель платежа Сверка с карточкой контрагента, ручной контроль при расхождении

Для даты алгоритм ищет несколько кандидатов. В документе могут быть дата договора, дата счёта, дата отгрузки и дата подписи. Решение принимается по близости к словам «счёт», «акт», «УПД», по позиции в верхней части страницы и по типу документа.

С суммой похожая история. Модель выделяет кандидаты, затем проверяет арифметику. Если сумма без НДС 100 000, НДС 20 000, итог 120 000, связка проходит. Если найдено 100 000 и 20 000, но итоговая строка закрыта печатью, поле получает пониженную уверенность и уходит на проверку.

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

Шаг 4. Проверка ошибок до записи в учёт

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

Проверки нужно делать слоями:

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

Модельный кейс: компания из сферы оптовой торговли, ~120 сотрудников, обрабатывает 2 000 входящих документов в месяц и отправляет на ручную проверку только поля с уверенностью ниже 0,90. Такой порог не означает, что остальные документы «идеальны». Он означает, что люди смотрят не весь поток, а спорные места: сумму с низкой уверенностью, контрагента без совпадения в справочнике, дату вне открытого периода.

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

Шаг 5. Запись в учётную систему

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

В типовой схеме передаются:

  • тип документа;
  • номер и дата;
  • организация и контрагент;
  • сумма, ставка налога, сумма налога;
  • валюта;
  • файл-основание;
  • статус проверки.

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

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

Как настроить качество: пороги, выборка и ручная проверка

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

Для каждого поля измеряют точность отдельно. Средняя точность по документу мало говорит бухгалтеру. Если номер распознаётся в 99% случаев, а сумма в 94%, риск сидит именно в сумме. Для критичных полей задают более высокий порог ручной проверки. Для справочных полей подключают сверку по базе.

Условный пример: на выборке из 300 входящих актов модель верно нашла дату в 292 документах, сумму в 286, контрагента в 279. Это не финальный результат проекта, а карта проблем. Дальше смотрят причины: плохие сканы, разные формы документов, отсутствие контрагента в справочнике, нераспознанные печати, переносы строк.

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

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

Я не люблю схемы, где всю ответственность перекладывают на модель. В документах это рискованно. Лучше разделить работу.

Задача Лучше подходит Почему
Убрать перекос, шум, фон Алгоритмы обработки изображений Быстро и предсказуемо
Прочитать печатный текст Распознавание текста Хорошо работает на типовых шрифтах
Понять, какая сумма итоговая Языковая модель плюс правила Нужен контекст соседних строк
Проверить ИНН Жёсткое правило Есть контрольные цифры
Найти контрагента в базе Справочник и похожесть строк Названия пишут по-разному
Решить спорный случай Бухгалтер Цена ошибки выше цены проверки

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

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

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

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

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

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