Распознавание счетов и инвойсов с помощью ИИ: как контролировать ошибки в цифрах

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

Главное условие простое. ИИ отвечает за чтение документа, а решение «принять или остановить» принимают правила, которые вы можете проверить. После этой статьи вы сможете определить, какие проверки нужны именно вашему потоку счетов, где установить порог автоматической обработки и как сосчитать, сколько будет стоить ручная проверка исключений. Мы не обещаем нулевой ошибки распознавания. Мы объясняем, как не пропустить ошибку дальше в учетную систему.

Почему ошибка в цифрах опаснее опечатки

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

Вот типичные ошибки, встречающиеся в нестандартных сканах:

• Смещение десятичного разделителя. «1 440,00» превращается в «144 000» или «14 400», потому что модель восприняла запятую как разделитель тысяч или потеряла ее на нечетком скане.
• Потерянный знак. Корректировочный счет с отрицательной суммой становится обычным счетом к оплате.
• Неправильная валюта. Символ валюты стоит в шапке, а в строках его нет. Модель подставляет валюту по умолчанию.
• Спутанные поля. «Сумма без налога» записывается в поле «К уплате», или предыдущий долг прибавляется к текущей сумме.
• Банковские реквизиты. Одна измененная цифра в IBAN не влияет на арифметику, но деньги пойдут не туда.
• Перепутанные даты. «03.04» может означать 3 апреля или 4 марта в зависимости от формата страны поставщика. От даты зависят срок оплаты, отчетный период и поиск дублей, поэтому ошибка тянет за собой другие.
• Цена за единицу вместо суммы строки. В таблицах без четких границ колонок модель иногда берет соседнее число. Итог строки выглядит тогда правдоподобно, но не совпадает с произведением количества на цену.

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

Извлечение и нормализация: сохраняйте исходный фрагмент рядом со значением

Первый шаг процесса: модель или специализированный сервис распознавания извлекает поля. Готовые модели для счетов уже могут находить типовые реквизиты. Например, готовая модель обработки счетов в Microsoft AI Builder может извлекать номер счета, дату, поставщика, сумму без налога, сумму налога, общую сумму, сумму к оплате, платежные реквизиты, например IBAN, и строки товаров с количеством и ценой за единицу. Для этих полей модель также возвращает показатель уверенности (confidence).

Второй шаг часто упускают из виду: нормализация. Распознаваемую строку «1 440,00 грн» нужно превратить в число 1 440,00 и валюту UAH. Именно здесь рождается много ошибок, поэтому рекомендуем хранить три вещи одновременно:

1. Исходный фрагмент, как он прочитан из документа: «1 440,00 грн».
2. Нормализованное значение: 1 440,00 UAH.
3. Ссылка на место в документе: страница, область, строка таблицы.

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

Отдельно о структурированном выводе. Если вы используете языковую модель и просите ее вернуть JSON по схеме, Structured Outputs гарантирует соответствие схеме только для успешно завершенного ответа, который не является отказом и не оборван из-за лимита токенов: все обязательные ключи будут на месте, типы будут совпадать. Но это не гарантирует, что в поле total указана верная сумма. Отказы и оборванные ответы нужно отдельно обрабатывать кодом. Правильный JSON означает только правильную форму, а не правильное содержание.

Арифметические проверки: счет сам себя проверяет

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

Базовый набор проверок:

• Строка: количество × цена за единицу = сумма строки.
• Промежуточный итог: сумма всех строк = сумма без налога.
• Скидки: промежуточный итог минус скидка = налогооблагаемая база, если скидка применяется к налогу.
• Налог: база × ставка = сумма налога, с учетом правил округления.
• Итого: база + налог = общая сумма.
• К оплате: общая сумма ± предыдущий баланс или аванс = сумма к оплате, если эти поля есть в документе.

Округление заслуживает отдельного внимания. Налог может округляться по каждой строке или один раз для всего документа. Разница между двумя способами иногда составляет несколько копеек. Поэтому проверка должна допускать определенную погрешность, например до 0,01 на строку или до нескольких копеек на документ, но не более. Правило допуска записывайте явно и согласовывайте с бухгалтерией, а не придумывайте в коде «на глазок».

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

Учебный пример: число правильного формата, которое не проходит проверку

Условный счет, придуманный для пояснения, не взят из реального проекта:

Значение 14 400 имеет корректный числовой формат, и структурированный ответ модели с ним вполне валиден. Однако арифметика документа его опровергает: 1 200 + 240 = 1 440. Документ идет в очередь исключений с отметкой «расхождение общей суммы», а бухгалтер видит исходный фрагмент «1 440,00 грн» и нормализованное значение 14 400.

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

Ни одна из этих проверок не подтверждает платежные реквизиты. Если в счете сменился IBAN, арифметика останется безупречной. Реквизиты проверяются отдельно, ниже.

Справочники и дубли: что вы уже знаете о поставщике

Арифметика ловит внутренние противоречия документа. Справочники помогают выявлять несоответствия между документом и вашими данными.

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

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

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

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

Все эти правила живут вне модели. Модель не должна решать, является ли счет дублем и не должна иметь права изменять реквизиты поставщика в справочнике.

Очередь исключений: куда попадает все сомнительное

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

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

О пороге уверенности стоит сказать точнее. В Document Intelligence поле confidence — это оценка вероятности от 0 до 1: значение 0,95 означает, что прогноз, вероятно, верен примерно в 19 случаях из 20. В сценариях, где точность критична, уверенность можно использовать как критерий: автоматически принять результат или отправить его человеку на проверку. Уверенность распознавания текста и уверенность извлечения пары «ключ-значение» — разные показатели, и проверять стоит оба.

Следовательно, порог является инструментом маршрутизации, а не гарантией. Высокая уверенность не доказывает, что сумма верна. Она лишь означает, что модель уверена. Арифметическая проверка и сверка со справочником все равно нужны для каждого документа, независимо от confidence.

Как выбрать порог? На основе измерений. Возьмите выборку документов, где правильные значения известны. Посмотрите, сколько ошибок модель совершает при разных уровнях уверенности. Порог, при котором доля проходящих дальше ошибок становится приемлемой для вашего бизнеса, и является рабочим. Для критических полей, таких как сумма к оплате или IBAN, она будет выше, чем для адреса доставки.

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

Оценка качества: три разные метрики вместо одной «точности»

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

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

Точность документа. Какая доля документов имеет правильными все критические поля одновременно. Если в документе десять критических полей и каждое распознается правильно в 98% случаев, доля полностью корректных документов заметно ниже. Если ошибки в полях независимы, вероятность получить правильными все десять равна 0,98 в десятой степени, то есть примерно 0,82. Это условный расчет для иллюстрации: на практике ошибки часто связаны между собой, потому что плохой скан портит несколько полей одновременно. Поэтому точность документа почти всегда ниже точности распознавания отдельных полей.

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

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

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

Что сделать на своем процессе

1. Соберите выборку реальных счетов, включая худшие сканы и нестандартные формы, и разметьте правильные значения критических полей.
2. Определите список критических полей и для каждого отдельно сосчитайте точность распознавания.
3. Считайте точность на уровне документа: долю документов, в которых верны все критические поля.
4. Запишите арифметические правила, допуск округления и источник ставок налога вместе с бухгалтерией.
5. Установите сверку со справочником поставщиков, проверку реквизитов и поиск дублей вне модели.
6. Установите пороги уверенности по результатам выборки, а не по умолчанию.
7. Подсчитайте долю документов, идущую в очередь исключений, и стоимость ее рассмотрения.
8. Введите журнал исправлений и ошибок, найденных позже, и просматривайте ежемесячные пороги.
9. Оставьте решение об оплате отдельному процессу с собственными полномочиями.

Часто задаваемые вопросы