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

Когда бухгалтерия получает 50, 200 или 1000 сканов в неделю, ручной ввод быстро превращается в узкое место. Один счёт может выглядеть аккуратно, другой приходит как фотография под углом, третий состоит из трёх страниц PDF, а в четвёртом сумма закрыта печатью. ИИ в такой задаче не «угадывает» документ целиком. Рабочая схема прозаичнее: сначала изображение приводят в порядок, затем OCR извлекает текст, языковая модель находит смысловые поля, после этого правила проверяют реквизиты и только затем данные попадают в учётную систему.

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

Что изменилось в обновлённой версии

В старых описаниях автоматического распознавания документов часто всё сводилось к OCR: отсканировали лист, получили текст, положили его в таблицу. В 2026 году такой подход уже выглядит неполным. OCR хорошо превращает картинку в символы, но сам по себе не понимает, что 118 000,00 может быть суммой к оплате, 98 333,33 может быть суммой без налога, а 19 666,67 относится к НДС. Ещё сложнее с датами: на одном документе есть дата счёта, дата договора, дата отгрузки и дата оплаты.

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

Шаг 1. Подготовить скан, чтобы OCR не боролся с мусором

На вход обычно попадают PDF, JPEG, PNG или TIFF. Для OCR важны четыре параметра: разрешение, контраст, ориентация и шум. Практический минимум для скана: 300 dpi, ровная страница, тёмный текст на светлом фоне. Фотография со смартфона часто требует выравнивания перспективы, обрезки краёв, удаления теней и поворота на 90, 180 или 270 градусов.

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

Для примера: если скан повернут на 2–3 градуса, OCR может спутать 8 и 0, а в суммах это превращает 180 000 в 100 000. Малый наклон кажется безобидным человеку, но для машинного чтения строка перестаёт быть ровной. Поэтому предобработка не украшение, а способ снизить число ложных символов до того, как в работу войдёт языковая модель.

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

OCR должен вернуть не только распознанный текст, а набор блоков с координатами. Для каждого слова или строки полезны x и y на странице, ширина, высота и показатель уверенности. Эти координаты помогают понять, что относится к одной строке, где начинается таблица, а где расположен итог.

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

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

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

После OCR начинается извлечение сущностей. Здесь языковая модель получает текст документа и задачу: вернуть конкретные поля в JSON, например номер документа, дату документа, контрагента, ИНН, сумму без налога, налог, сумму к оплате, валюту и признак уверенности. Чем точнее схема ответа, тем меньше вольности.

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

С датой похожая история. В документе может быть 01.06.2026 как дата счёта, 05.06.2026 как срок оплаты и 15.05.2026 как дата договора. Система должна вернуть тип даты. Если тип не определён, поле не стоит отправлять в учёт автоматически. Лучше положить документ в очередь проверки.

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

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

Шаг 4. Проверить результат правилами, справочниками и арифметикой

ИИ хорошо находит кандидатов на поля, но финальное решение должны принимать проверки. Я делю их на три группы: форматные, арифметические и справочные.

Форматные проверки ловят очевидные сбои. Дата должна быть календарной датой, а не строкой из договора. Валюта должна совпадать с допустимым списком. ИНН, КПП, БИК и счёт должны иметь ожидаемую длину. Если OCR прочитал букву О вместо нуля, проверка подсветит ошибку.

Арифметика проверяет суммы. Если в документе есть строки с количеством, ценой и ставкой налога, система пересчитывает итог. Расхождение на 1–2 копейки иногда возникает из-за округления, но разница в 100 рублей уже требует ручного просмотра. Для счёта с налогом 20% можно проверить связку: сумма без налога плюс налог равна итогу. Для ставки 10% и 0% правила будут другими, поэтому ставка должна быть отдельным полем.

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

Шаг 5. Присвоить уверенность и решить, что делать дальше

Каждому полю нужен показатель уверенности. Я бы не ограничивался общей оценкой документа. Сумма может быть распознана с высокой уверенностью, а контрагент с низкой из-за печати поверх реквизитов. Поэтому оценка должна быть полевой: дата 0,96, сумма 0,91, ИНН 0,74, контрагент 0,68. Порог зависит от риска операции.

Условный пример: для компании из сферы оптовой торговли, ~80 сотрудников, можно отправлять в автозапись документы, где сумма, дата и ИНН имеют уверенность выше 0,9, а расхождение арифметики не превышает 1 копейку. Всё ниже порога попадает в интерфейс проверки. Оператор видит скан слева, распознанные поля справа и подсветку зоны, откуда взято значение.

Такой сценарий экономит время не за счёт слепой автоматизации, а за счёт сортировки. Простые документы уходят без ручного набора. Спорные документы показываются человеку уже с заполненными полями и объяснением, где система сомневается.

Шаг 6. Передать данные в учётную систему

Когда поля прошли проверки, их надо передать в учётную систему. Обычно используются три варианта: REST API, обмен через XML или CSV, либо промежуточная очередь. Для 1С часто встречается обмен файлами или HTTP-сервис. Для крупных ERP чаще применяют API и журнал событий.

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

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

Частые ошибки в таких проектах

Первая ошибка: пытаться распознавать всё одним запросом без схемы ответа. Модель возвращает красивый текст, но интеграции нужен JSON с фиксированными полями. Вторая ошибка: доверять OCR без координат. Без координат сложно объяснить, откуда взялась сумма. Третья ошибка: запускать автозапись до того, как накоплена статистика по ошибкам.

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

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

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

Как выглядит рабочий конвейер

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

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

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

Заключение к обновлению

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

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