ИИ читает счета и заносит данные в учётку в 2026

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

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

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

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

Где в обработке счёта появляется ИИ

В реальном процессе нет одного универсального шага «прочитать счёт». Есть несколько операций, и каждая ломается по-своему.

Первая операция, это приём файла. Документ может прийти как скан в JPG, PDF из бухгалтерской программы, фото с телефона, архив с несколькими вложениями. Для OCR качество сильно зависит от разрешения. Практический минимум для уверенного распознавания печатного текста, около 300 dpi. Фото с перекосом в 8–12 градусов уже заметно ухудшает результат: строки распадаются, таблица номенклатуры смешивается с реквизитами, печать или подпись попадает в текстовый слой.

Вторая операция, это OCR. Система получает текст, координаты слов на странице и иногда оценку уверенности по каждому фрагменту. Координаты нужны не ради красоты. По ним можно понять, что сумма «125 400,00» стоит рядом с подписью «Итого к оплате», а не относится к строке товара в таблице.

Третья операция, это извлечение сущностей. Здесь языковая модель получает распознанный текст и возвращает структурированный JSON. Не «вроде бы сумма такая-то», а строгое поле total_amount, дата в ISO-формате, ИНН отдельной строкой, номер счёта без лишних слов. Для таких задач качество промпта решает много. Если вы не формализовали запрос, модель может вернуть красивое объяснение вместо данных. Подход к формулировке можно взять из статьи про правильные запросы к нейросетям, а затем ужесточить его под JSON и проверки.

Четвёртая операция, это валидация. Она не должна быть творческой. ИНН физлица содержит 12 цифр, ИНН организации, 10 цифр, КПП, 9 цифр. Дата не может быть «32.13.2025». Сумма с НДС должна сходиться с базой и ставкой, если в документе есть эти поля. Номер счёта может содержать буквы, слэши и дефисы, но не должен превращаться в полный заголовок документа.

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

Рабочая архитектура: от файла до статуса

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

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

Модельный кейс: компания из сферы оптовой торговли, ~80 сотрудников, получает 120–180 входящих счетов в неделю, и на первом этапе автоматизация закрывает только 6 полей: номер, дату, сумму, валюту, ИНН поставщика, наименование контрагента. Такой узкий старт снижает риск, потому что бухгалтер видит документ целиком и правит только расхождения, а команда собирает статистику ошибок по каждому полю.

Как должен выглядеть JSON, чтобы его можно было проверить

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

Пример структуры:

{
  "document_type": "invoice",
  "invoice_number": "42",
  "invoice_date": "2025-04-15",
  "supplier": {
    "name": "ООО Ромашка",
    "inn": "7701234567",
    "kpp": "770101001"
  },
  "buyer": {
    "name": null,
    "inn": null,
    "kpp": null
  },
  "total_amount": 125400.00,
  "vat_amount": 20900.00,
  "currency": "RUB",
  "confidence": 0.91,
  "warnings": []
}

Если покупатель не найден, поле остаётся null. Нельзя подставлять догадку из старого письма или имени файла. Если сумма есть словами и цифрами, валидатор сравнивает оба варианта. Если в таблице несколько строк с НДС 10% и 20%, а в шапке документа только итог, лучше отправить документ на ручную проверку.

Для извлечения я обычно разделяю промпт на четыре части: роль, список полей, правила null, формат ответа. Например, правило для пустых значений звучит так: «Если поле отсутствует в документе или распознано неуверенно, верни null и добавь причину в warnings». Это проще проверять, чем разбирать фразу «данные, вероятно, не указаны».

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

Проверки, без которых автоматизация опасна

ИИ хорошо справляется с неодинаковыми формами документов, но бухгалтерский контур требует скучной дисциплины. Я бы закладывал проверки до первой интеграции, а не после первой ошибки в оплате.

Базовый набор проверок выглядит так:

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

Порог уверенности не стоит выбирать вслепую. Гипотетический пример: на выборке из 500 счетов порог 0.95 может отправить на ручную проверку слишком много документов, а порог 0.70 пропустит больше спорных дат и сумм. В нормальном пилоте считают ошибки по каждому полю отдельно. Сумма и дата обычно важнее наименования файла, поэтому для них порог можно сделать строже.

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

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

Где ломаются проекты OCR и NLP

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

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

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

Четвёртый сбой, дубли. Один и тот же счёт могут прислать в PDF и в виде фото. Хэш файла не совпадёт, но номер, ИНН поставщика, дата и сумма будут одинаковыми. Значит, дедупликацию надо делать по набору реквизитов, а не только по имени файла.

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

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

Как провести пилот без лишнего риска

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

Нормальный пилот помещается в 3–5 недель. На первой неделе собирают 200–500 исторических документов разных поставщиков: чистые PDF, сканы, фото, многостраничные файлы. На второй неделе описывают целевой JSON, правила null, список обязательных полей и пороги уверенности. На третьей неделе прогоняют документы через OCR и извлечение, считают точность по каждому полю. Дальше настраивают валидацию и дают бухгалтеру интерфейс подтверждения.

Для примера: если из 300 документов поле «сумма» корректно извлечено в 291 случае, это 97%. Но для автоматической оплаты даже 3% ошибок, это много. Такой результат годится для предзаполнения карточек, а не для полной автозаписи без просмотра. Для поля «номер счёта» допустимость ошибки зависит от дедупликации: один неверный символ может создать дубль.

После пилота я смотрю не на общий процент, а на матрицу ошибок:

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

Роль человека в процессе

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

Хороший интерфейс показывает не 40 технических полей, а только то, что влияет на решение. Например: исходный файл слева, извлечённые реквизиты справа, предупреждения сверху. Если ИНН не найден в справочнике, кнопка записи неактивна. Если сумма и НДС не сходятся на 1 копейку, система просит подтвердить вручную. Если документ уже есть, показывается похожая запись.

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

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

Я бы начал с узкого маршрута: входящие счета от поставщиков, один тип документа, 5–7 обязательных полей, черновик в учётной системе вместо прямой записи. Затем собрал бы 300–500 реальных документов без персональных лишних данных, описал JSON и правила null, прогнал пилот и посчитал точность по каждому полю.

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

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