Как перенести данные из сканов счетов в таблицу с ИИ и проверить суммы

Подготовьте исходники

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

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

Как выглядит рабочая цепочка

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

Если счёт содержит несколько валют или скидку, простая формула «количество × цена» может не совпасть с итогом. Ошибка расчёта — повод проверить условия, а не автоматически исправлять документ.

Проверка на небольшом пакете

Возьмите 20 разных счетов: качественный PDF, телефонное фото, несколько страниц, таблицу с длинными наименованиями и документ без части реквизитов. Сравните извлечённые поля с ручной разметкой. Отдельно посчитайте ошибки критичных полей, а не только среднюю точность по всем ячейкам. Пропущенный телефон поставщика менее опасен, чем неверный счёт для оплаты.

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

До платежа нужен второй контроль

Даже идеально перенесённая сумма не доказывает, что счёт следует оплатить. Сверьте заказ, поставку, договор, получателя и утверждение расхода. ИИ может подготовить несоответствия, но не должен проводить платёж из-за успешного OCR. NIST AI RMF предлагает связывать оценку системы с риском её применения; для финансовых документов это означает более строгую проверку полей, влияющих на деньги.

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

Что делать с дублями документов

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

Как устроить ручную проверку без повторного ввода

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

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

В счёте две позиции: три единицы по 1200 рублей и одна по 450 рублей. До дополнительных условий сумма позиций равна 4050 рублей. Если распознавание прочитало количество «8» вместо «3», проверка сразу покажет расхождение с итогом. Но совпавшая арифметика не доказывает правильность всех данных: реквизиты и номер счёта могут быть ошибочными независимо от суммы.

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

Если счёт исправили после выгрузки

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

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

Извлечённый счёт нужно отдельно сверить с заказом и поставкой до платежа.