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

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

Я разбираю такую задачу как конвейер, а не как «магическую кнопку». ИИ здесь полезен на нескольких этапах: распознать текст на скане, выделить нужные поля, проверить их по правилам и подготовить структурированную запись. В SoftChat удобно быстро отработать сам сценарий: можно вести диалог, прикреплять к сообщениям изображения и документы, если выбранная модель поддерживает такие вложения, сохранять повторяемые стартовые запросы как шаблоны и настраивать отдельного ассистента под типовую проверку документов. Промышленную загрузку в учётную систему обычно делает уже интеграционный слой: API, RPA-сценарий, CSV-импорт или штатный модуль обмена.

1. Определите, какие поля нужны учёту

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

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

Поле Где искать на скане Типовая ошибка Проверка
Дата документа Шапка, блок «от», строка номера Нейросеть берёт срок оплаты Дата не позже даты загрузки, формат ГГГГ-ММ-ДД
Сумма к оплате «Итого», «Всего к оплате», нижняя часть Подставлена сумма налога Сумма больше 0, совпадает с прописью или итогом строк
Контрагент Реквизиты поставщика или исполнителя Перепутан покупатель и поставщик Сверка по ИНН, КПП, названию
Номер документа Рядом с датой или названием формы Потеря символов «/», «-» Проверка на пустое значение и дубликаты
Валюта Рядом с суммой или в договоре Рубли приняты за условные единицы Белый список валют

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

2. Подготовьте сканы до распознавания

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

  • разрешение от 200–300 dpi для сканов;
  • один документ в одном файле, если нет пакетного разбиения;
  • ориентация страницы исправлена до OCR;
  • имя файла содержит источник или дату загрузки, но не заменяет данные из документа;
  • многостраничный PDF хранится целиком, чтобы не потерять приложения.

Условный пример: если в папке «Входящие счета» лежит 1 200 файлов за месяц, даже 2 минуты ручного ввода на файл дают 40 часов работы. Автоматизация не обязана сразу закрывать весь поток. Часто выгоднее начать с 60–70% типовых документов, где форма повторяется, а сложные сканы отправлять на ручную проверку.

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

3. Разделите OCR и извлечение смысла

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

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

{
  "document_type": "invoice",
  "document_number": "154/26",
  "document_date": "2026-06-15",
  "counterparty_name": "ООО Ромашка",
  "counterparty_tax_id": "7700000000",
  "total_amount": 15840.00,
  "currency": "RUB",
  "confidence": {
    "document_date": 0.92,
    "counterparty_name": 0.86,
    "total_amount": 0.95
  },
  "needs_review": false
}

Для примера: в строке «Итого к оплате: 15 840,00 руб.» модель должна вернуть число 15840.00, а не строку с пробелами и валютой. В строке «Счёт №154/26 от 15 июня 2026 г.» дата должна стать «2026-06-15». Такие правила кажутся мелкими, но именно они позволяют передавать запись в учётную систему без копирования руками.

4. Дайте модели строгую инструкцию

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

Пример промпта для прототипа:

Ты извлекаешь данные из бухгалтерского документа.
Верни только JSON без пояснений.
Найди сумму к оплате, дату документа и контрагента-поставщика.
Если в документе есть покупатель и поставщик, контрагентом считай поставщика.
Если сумма к оплате не найдена, верни null и needs_review: true.
Дату верни в формате ГГГГ-ММ-ДД.
Для каждого поля добавь confidence от 0 до 1.

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

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

5. Постройте валидацию до загрузки в учётную систему

Без валидации автоматизация просто ускорит появление ошибок. Минимальный набор проверок я делю на синтаксис, бизнес-правила и сверку с внешними справочниками.

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

Модельный кейс: для компании из сферы логистики, ~200 сотрудников, можно задать порог ручной проверки так: confidence ниже 0.85 по сумме, расхождение суммы цифрами и прописью, новый ИНН в справочнике или дата старше 180 дней. Такой набор не гарантирует идеальный результат, зато резко сокращает риск тихой ошибки. Часть документов уйдёт оператору, но оператор будет смотреть спорные места, а не перепечатывать всё поле за полем.

6. Передавайте данные без ручного ввода

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

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

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

7. Что делать с ошибками и спорными документами

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

Спорные документы лучше показывать оператору с подсветкой: исходный фрагмент, извлечённое значение и причина проверки. Например: «сумма к оплате: 15 840,00, но сумма прописью не найдена». Так человек принимает решение быстрее и не ищет проблему с нуля.

Условный пример: если поток содержит 300 актов в неделю, а 25% из них приходят как фото с телефона, разумно сразу отделить фото в очередь качества. Попытка прогнать их тем же маршрутом, что и чистые PDF, даст больше ручных исправлений. Здесь помогает простое правило: плохой вход не должен попадать в автоматическую загрузку без дополнительной проверки.

8. Где границы такого подхода

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

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

Финальная схема работы

На вашем месте я бы запускал процесс в четыре прохода. Сначала выбрал бы один тип документа, например входящие счета, и описал 8–12 полей. Затем собрал бы 50–100 реальных сканов без персональных лишних данных для теста, разделил чистые PDF и проблемные фото. После этого настроил бы извлечение в JSON и валидацию: дата, сумма, контрагент, дубликаты, справочник. Только потом подключал бы загрузку в учётную систему.

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