Распознавание счетов и накладных с помощью ИИ: как проверять результат

Менеджер открывает PDF-счёт от поставщика и перепечатывает в CRM номер, дату, реквизиты и двадцать строк позиций. Завтра придёт ещё десяток таких файлов, фото накладной и прайс в Excel. Распознавание счетов и накладных с помощью ИИ снимает большую часть этой работы при одном условии: результат модели проверяют до записи в вашу систему. Ниже — что модель читает уверенно, где ошибается, как устроен процесс с проверками и что провайдеры делают с данными, отправленными через API (программный интерфейс: ваша система обращается к модели напрямую, без окна чата).

Какие счета и накладные ИИ читает уверенно

Распознавание документов с помощью ИИ работает на моделях, которые понимают изображения (мультимодальных). Они читают те же файлы, что приходят в обычный рабочий день:

• PDF с текстовым слоем. Счета на оплату из учётных программ и интернет-банков. Текст уже есть, извлечение данных из PDF сводится к поиску нужных полей.
• Сканы и PDF без текстового слоя. Страницу модель читает как картинку, поэтому качество скана решает почти всё. (Claude, например, каждую страницу любого PDF превращает в изображение и, если текст в файле есть, передаёт его рядом.)
• Фото с телефона. Накладная на капоте машины, акт с печатью. Читаются хуже: тень, наклон и блики портят результат сильнее, чем кажется человеку.
• Excel и CSV разной структуры. У одного поставщика прайс начинается с шапки на пять строк, у другого артикул спрятан в названии товара, у третьего на каждом листе своя категория.
• Письма с вложениями, где часть реквизитов в тексте письма, часть в файле.

Если контрагенты присылают документы через сервис электронного документооборота, сначала узнайте, отдаёт ли сервис данные в структурированном виде (через API или выгрузку). Если отдаёт, распознавать такие документы не нужно, модель остаётся для остального: PDF из почты, сканов, фото и прайсов.

Классический OCR по шаблонам (программа, которая превращает картинку в текст по заранее размеченным полям) требует разметки под каждого поставщика: он видит «15.10.2026» и без правила не знает, дата это счёта или срок оплаты. Модель обычно понимает разницу по смыслу и соседним подписям, поэтому новый поставщик с непривычным макетом не требует отдельной настройки. Его первые документы всё же стоит проверить вручную.

Шаблоны при этом не устарели: если крупный поставщик годами присылает счета в одном макете, шаблон для него дешевле и предсказуемее модели. Рабочие системы часто совмещают оба способа: типовые документы идут по шаблонам, нестандартные — через модель.

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

Почему результат нужно проверять

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

Простой расчёт. Модель правильно извлекает 97% полей, в счёте 15 полей. Вероятность, что все 15 верны, — 0,97 в пятнадцатой степени, около 63%. Примерно каждый третий документ содержит хотя бы одну ошибку.

Провайдеры дают режим структурированного ответа: модель возвращает данные строго по заданной схеме (номер, дата, код ЕДРПОУ поставщика, список позиций), и ваш код не ломается на неожиданном формате. Схема гарантирует только форму. Документация Google к Gemini API говорит прямо: ответ будет синтаксически правильным JSON (стандартный формат данных для обмена между программами), а значения нужно проверять в приложении. OpenAI и Anthropic обещают то же: соответствие схеме, обязательные поля и типы данных. О правильности самих значений в документации всех трёх провайдеров ничего не сказано.

Процесс распознавания с проверками

Модель читает документ, код проверяет и считает, человек подтверждает спорное. По шагам:

1. Приём. Документы приходят на выделенный почтовый ящик, через форму в личном кабинете или в Telegram-бот, куда сотрудник отправляет фото накладной со склада.
2. Подготовка. Код делит сшитые PDF на отдельные документы. Модель определяет тип каждого (счёт, накладная, акт, договор), под тип выбирается схема полей. Из файлов с текстовым слоем код берёт готовый текст, страницы без текста (сканы, фото) отправляет модели как изображения.
3. Извлечение. Модель возвращает поля по схеме: реквизиты сторон, номер и дату, позиции с количеством, ценой и суммой, итоги.
4. Проверка кодом по правилам из следующего раздела.
5. Подтверждение. Документы без замечаний идут дальше автоматически (когда вы к этому готовы), документы с замечаниями — сотруднику на экран сверки.
6. Запись. Данные уходят в CRM, интернет-магазин, Google-таблицу, учётную систему или вашу собственную базу. Исходный файл, извлечённые значения и правки сотрудника сохраняются в журнале: по нему видно, где модель ошибается чаще всего.

Что проверяет код

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

• Арифметика. Количество × цена = сумма строки. Сумма строк = итог. Итог без НДС + НДС = итог с НДС. Если хотя бы одно равенство не сходится с точностью до копейки, документ уходит на проверку: неверно прочитанная цифра почти всегда ломает одно из равенств. Суммы считает код, модель только читает цифры.
• Реквизиты. У кода ЕДРПОУ есть контрольный разряд, поэтому большинство опечаток видно простым расчётом, без обращения к реестру. Украинский IBAN состоит из 29 символов и содержит две контрольные цифры, так что большинство опечаток в номере счёта тоже видно расчётом. У налоговых номеров других стран правила свои, их добавляют под ваших контрагентов.
• Справочники. Контрагент с таким кодом есть в базе? Артикул есть в каталоге? Единица измерения совпадает с карточкой товара? Неизвестный поставщик или товар — повод показать документ человеку.
• Сверка с заказом. Позиции и цены в счёте должны совпадать с заказом поставщику, количество в накладной — с принятым на склад. Расхождение останавливает оплату или оприходование до решения сотрудника.
• Дубли. Документ с тем же номером, датой и контрагентом уже загружали: поставщик переслал счёт повторно или два сотрудника загрузили один файл. Без этой проверки оплата или оприходование проходят дважды.
• Правдоподобие. Дата документа не в будущем и не двухлетней давности. Цена отличается от прошлой закупки не больше чем на заданный вами процент. Количество не на порядок больше обычного.

Что остаётся человеку

Экран сверки устроен просто: слева документ, справа извлечённые поля, спорные подсвечены с пояснением («сумма строк не совпадает с итогом на 120,00»). Сотрудник исправляет одно поле и подтверждает документ, а не перепечатывает его целиком.

Мы советуем начинать с ручного подтверждения каждого документа. Через несколько недель журнал покажет, какие поля модель читает без ошибок, а какие сотрудник постоянно правит. Тогда автоматическое принятие включают по типам документов и полей: например, счета постоянных поставщиков в PDF с текстовым слоем проходят сами, фото накладных по-прежнему смотрит человек. Часть автоматически принятых документов и после этого проверяют выборочно — только так видна реальная точность. «Уверенность», которую сообщает сама модель, для этого не подходит.

Прайсы поставщиков: цены и остатки в магазине

Частый отдельный случай — обновление цен из прайса поставщика. Магазин работает с десятком поставщиков, и каждый присылает файл по-своему: у одного остатки числом, у другого «есть / нет / под заказ», у третьего «>10». Один пишет артикул производителя, другой — свой внутренний код, третий только название вида «Смеситель д/кухни хром Ф40 гусак».

Модель закрывает две задачи, которые раньше требовали ручной настройки под каждый файл:

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

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

В интернет-магазине на WooCommerce или другой платформе цены и остатки обновляются по расписанию. Контент-менеджер разбирает только исключения.

Готовый сервис или разработка

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

Разработка оправдана в четырёх ситуациях:

• Свои документы. Спецификации к заказам, акты замеров, заявки дилеров, сертификаты, прайсы — всё, для чего у готового сервиса нет схемы полей.
• Свои правила. Минимальная маржа, лимиты по контрагентам, сверка с заказом в вашей CRM, особые единицы измерения.
• Данные идут не в бухгалтерию, а в CRM, интернет-магазин, складскую таблицу, корпоративный портал или самописную систему без готового коннектора.
• Данные нельзя выпускать наружу: договоры, персональные данные, коммерческие условия. Тогда нужен контроль над маршрутом каждого файла, вплоть до модели на своём сервере.

Если документов десяток в неделю и они однотипные, автоматизация не окупится. Проект окупается там, где ручной ввод занимает заметную часть чьего-то рабочего дня или где ошибки ввода уже стоили денег. В расходы, кроме разработки, входят оплата API за каждую страницу (или сервер для своей модели) и поддержка правил проверки после запуска. Экономия есть, только когда сэкономленное время сотрудников стоит больше этих расходов.

Куда уходят данные: API или свой сервер

Использует ли провайдер ваши счета для обучения, зависит от способа подключения. Ниже — что написано в официальных политиках трёх провайдеров (проверено 21.10.2026; условия меняются, перед запуском перечитайте их).

• OpenAI API. Данные, отправленные через API, с 1 марта 2023 года не используются для обучения моделей, если вы сами не дали согласие. Журналы для контроля злоупотреблений хранятся до 30 дней. Режим без хранения данных (Zero Data Retention) и обработка в европейском регионе доступны после одобрения OpenAI. Источник — страница Your data в документации OpenAI.
• Anthropic API. Входные и выходные данные коммерческих продуктов, к которым относится API, по умолчанию не используются для обучения; исключение — когда вы сами отправили отзыв или дали согласие. На серверах данные удаляются в течение 30 дней, если не заключено иное соглашение (например, о нулевом хранении). Запросы, которые автоматическая система отметила как нарушающие правила использования, хранятся до 2 лет. Источники — статьи Privacy Center о сроках хранения и об обучении моделей.
• Google Gemini API. Условия зависят от уровня: бесплатного или платного. На бесплатном Google использует запросы и ответы для улучшения своих продуктов, их могут читать люди-ревьюеры, и условия прямо просят не отправлять конфиденциальные и персональные данные. На платном запросы для обучения не используются и хранятся ограниченное время только для выявления нарушений. Для Европейской экономической зоны (страны ЕС плюс Исландия, Лихтенштейн и Норвегия), Швейцарии и Великобритании условия платного уровня распространяются и на бесплатную квоту. Украины, Казахстана и других стран СНГ в этом списке нет: их бесплатная квота работает на условиях бесплатного уровня. Источник — Gemini API Additional Terms of Service.

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

Если документы приходят через Telegram, учитывайте устройство мессенджера. Переписка с ботом — обычный облачный чат: шифрование работает между клиентом и сервером, сквозного шифрования нет. Для договоров и сканов паспортов надёжнее форма загрузки на вашем сервере (её можно открыть внутри Telegram как мини-приложение). Ещё одно ограничение: через стандартный Bot API бот скачивает файлы до 20 МБ. Многостраничные сканы бывают больше, и тогда нужен собственный сервер Bot API, где лимита на скачивание нет.

Нейросеть на своём сервере

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

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

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

С чего начать пилот

1. Выберите один поток документов, где ручной ввод отнимает больше всего времени: входящие счета, накладные склада или прайсы.
2. Соберите реальные документы за несколько месяцев, включая плохие сканы, фото и самые неудобные макеты. Пять «красивых» PDF ничего не скажут о работе на обычном потоке.
3. Подготовьте эталон: правильные значения полей, внесённые человеком. На этой выборке модель не настраивают, на ней только проверяют.
4. Считайте точность по документам целиком: документ верен, только если верны все его поля. Отдельно смотрите критичные поля — суммы, реквизиты, количество.
5. Запишите правила проверки, которые сотрудники сейчас держат в голове. Они станут основой кода.
6. Решите, куда и в каком виде попадают данные: черновиком на подтверждение или сразу рабочей записью.

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

Как с этим помогает RIVERIT

Предлагаем разработку ИИ-автоматизации бизнеса под ваши документы: извлечение данных из счетов, накладных, прайсов и других файлов с проверками по вашим правилам. Подключаем модели OpenAI, Anthropic и Google через API или разворачиваем открытую модель на вашем сервере, если данные не должны уходить наружу. Решение пишем кодом и интегрируем с CRM, интернет-магазином, таблицами или собственной базой. Приём документов можно организовать через Telegram-бот с панелью управления. Подробнее — на странице ИИ-автоматизации бизнеса.