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

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

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

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

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

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

Архитектура процесса: от скана до проводки

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

Этап Что происходит Что проверять
Приём файла Скан, фото или PDF попадает в очередь Формат, размер, дубли
Подготовка изображения Выравнивание, обрезка полей, улучшение контраста Поворот страницы, читаемость
Распознавание текста OCR извлекает текстовые блоки и координаты Доля нераспознанных символов
Анализ структуры Система ищет шапку, реквизиты, таблицу, итоги Наличие обязательных зон
Извлечение полей ИИ выделяет сумму, дату, контрагента Уверенность по каждому полю
Валидация Правила сверяют формат и логику НДС, дата, справочник контрагентов
Экспорт Данные уходят в учёт через API, CSV или очередь Статус загрузки, журнал ошибок

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

Шаг 1. Подготовьте сканы так, чтобы их можно было читать машинно

Качество входа решает больше, чем кажется. Для сканов бухгалтерских документов я беру базовые параметры: 300 dpi, формат PDF или PNG, ориентация страницы без поворота, контрастный текст, поля без обрезанных реквизитов. Для фото с телефона добавляю проверку перспективы: если документ снят под углом, суммы внизу страницы часто распознаются хуже, чем шапка.

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

  • размер файла до заранее заданного лимита, например 20–30 МБ для пачки PDF;
  • количество страниц, чтобы одностраничный счёт не приехал как 40-страничный архив;
  • хэш файла для поиска дублей;
  • ориентация страницы, обычно 0, 90, 180 или 270 градусов;
  • доля тёмных пикселей и размытость, чтобы отсечь нечитаемые фото.

Условный пример: если бухгалтерия получает 600 первичных документов в месяц, а 8% сканов приходят повёрнутыми или размытыми, то без входного фильтра в ручную очередь будет попадать около 48 документов ещё до проверки реквизитов. Исправить это проще на этапе загрузки, чем после неудачного распознавания.

Шаг 2. Настройте распознавание текста и координат

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

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

На этом этапе не надо заставлять ИИ угадывать бухгалтерскую проводку. Его задача уже: понять, где сумма, дата и контрагент. Чем уже задача, тем проще тестировать качество.

Шаг 3. Опишите схему данных до настройки промптов

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

Для примера: документ «счёт № 241 от 05.06.2026» можно привести к записи, где дата хранится как 2026-06-05, сумма как 12500.00, валюта как RUB, а контрагент проходит нормализацию по справочнику. Маркер «для примера» здесь нужен именно потому, что это учебная запись, а не реальная выгрузка клиента.

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

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

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

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

Сумма часто путается между «Итого», «НДС», «Без НДС», «К оплате» и строками таблицы. Для неё нужны правила приоритета: брать итоговую сумму к оплате, если она есть; не брать цену единицы; не брать сумму прописью без числового подтверждения; сверять НДС с общей суммой. Допуск округления обычно ставят в 0,01 для рублей и копеек.

Дата может означать дату документа, дату оплаты, дату отгрузки или срок действия счёта. В промпте надо назвать нужную дату. Формат лучше сразу нормализовать до ISO 8601, например 2026-06-05, а исходное значение хранить рядом: «05.06.26». Это помогает при споре с оператором.

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

Шаг 5. Добавьте проверки до отправки в учётную систему

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

Практичная схема выглядит так:

  • поле с уверенностью ниже 0,85 уходит на ручную проверку;
  • сумма с расхождением НДС больше 0,01 помечается как спорная;
  • дата позже даты загрузки более чем на 1 день требует подтверждения;
  • новый контрагент не создаётся автоматически без проверки ответственного;
  • документ с тем же номером, датой и ИНН попадает в очередь дублей.

Условный пример: компания из сферы оптовой торговли, ~80 сотрудников, может начать с правила «автоматически загружать только документы, где сумма, дата и ИНН прошли проверки, а остальные отправлять оператору». При 1000 документов в месяц даже 70% автопрохода убирают 700 ручных карточек, но спорные 300 остаются видимыми, а не растворяются в учёте.

Шаг 6. Передайте данные в учётную систему безопасно

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

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

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

Шаг 7. Протестируйте процесс на реальной выборке документов

Тест на пяти красивых PDF ничего не доказывает. Для пилота я бы собрал минимум 100–200 документов за разные месяцы: сканы, фото, многостраничные PDF, документы от постоянных и новых контрагентов, варианты с НДС и без НДС. Если документов мало, лучше честно признать ограничение выборки, чем объявлять качество по десяти примерам.

Метрики нужны простые:

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

Гипотетический пример: на выборке из 200 входящих документов система верно извлекла сумму в 188 случаях, дату в 181 случае, контрагента в 176 случаях. Это не повод сразу включать полную автоматику. Разумнее разобрать 24 ошибки по контрагенту: часть может быть связана с несколькими юридическими лицами в одном шаблоне, часть с плохими сканами, часть с отсутствием ИНН в справочнике.

Где в этом процессе помогает ИИ-чат

ИИ-чат полезен на подготовительном и экспертном уровне. В нём удобно сравнить варианты промптов, попросить модель объяснить, почему она выбрала одну дату вместо другой, превратить распознанный текст в таблицу, составить чек-лист валидации. В SoftChat ответы отображаются с поддержкой Markdown, включая таблицы и блоки кода, поэтому схемы полей удобно обсуждать прямо в диалоге. Для повторяемых задач можно использовать шаблоны промптов, а длинные обсуждения сохраняются в истории внутри организации.

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

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

Чек-лист запуска на 2–4 недели

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

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

На третьей неделе добавьте проверки. Начните с суммы, даты, ИНН и дублей. Порог уверенности можно поставить консервативно, например 0,85. Пусть часть документов уйдёт оператору, зато команда увидит реальные причины отказов.

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

Заключение: что изменилось после обновления

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

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