Разделите процесс на два шага: сначала извлеките поля как есть, потом прогоните их через отдельные детерминированные правила. Проверка должна опираться на арифметику, форматы и справочники, а не на ту же модель, которая читала документ. Тогда каждое поле получает понятный статус: прошло, не прошло или уходит человеку с конкретной причиной.
Что значит «с проверкой»: схема пайплайна
Извлечение отвечает за то, чтобы достать значение из PDF или скана. Проверка отвечает за то, чтобы решить, можно ли этому значению доверять. Смешивать их в одном проходе опасно: ошибка распознавания проходит дальше без следа.
Рабочая последовательность выглядит так:
- Загрузка файла и определение типа документа: текстовый PDF, скан или фотография.
- OCR или парсинг текстового слоя, при возможности — с координатами блоков.
- Извлечение полей в JSON по заранее описанной схеме.
- Нормализация: даты, суммы, валюта, пробелы и кавычки приводятся к единому виду.
- Валидация отдельным набором правил.
- Маршрутизация: принят автоматически, отправлен на ручную проверку или отклонён.
Валидатор не должен «додумывать» значение. Его задача — сказать, сходится ли оно с другими данными и форматами. Если модель вернула уверенность по полю, она помогает расставить приоритет ручной проверки, но не заменяет арифметику.
Для аудита сохраняйте исходный файл, версию модели или шаблона, сырой текст и список сработавших правил. Без этого нельзя понять, почему счёт ушёл на проверку и что нужно поправить.
Какие поля извлекать и как их нормализовать
Проверять можно только то, что описано. Зафиксируйте минимальный набор полей и тип каждого до настройки извлечения.
| Поле | Тип | Что делать до проверки |
|---|---|---|
| Номер счёта | Строка | Убрать лишние пробелы, сохранить как текст |
| Дата счёта | Дата | Привести к ISO, проверить диапазон |
| Поставщик и покупатель | Строка | Унифицировать кавычки и пробелы |
| ИНН и КПП | Строка | Оставить только цифры, проверить длину |
| Сумма без НДС | Число | Убрать пробелы и знак рубля, заменить запятую на точку |
| НДС | Число | Привести к числу, отдельно хранить ставку |
| Итог с НДС | Число | Привести к числу |
| Позиции | Список | Проверить, что колонки сопоставлены верно |
Нормализация решает типовую проблему: «сумма» приходит то числом, то строкой вида «1 200,00 ₽». Если не привести её к числу заранее, правила сравнения будут спотыкаться на каждом счёте.
Табличную часть извлекайте отдельно. Сумма позиций должна сходиться с промежуточным итогом — это ловит ошибки, когда модель перепутала строки или склеила две позиции в одну.
Правила проверки: что валидировать автоматически
Начните с арифметики. Проверьте три равенства: сумма позиций равна промежуточному итогу, НДС равен сумме без НДС, умноженной на ставку, итог равен сумме без НДС плюс НДС. Допуск на копейки обычно около 0,01–0,02, если в документе есть округление по строкам.
Дальше форматные проверки. ИНН проверяйте по контрольной сумме и длине, КПП — по структуре, дату — на попадание в допустимый диапазон и отсутствие будущего. Валюту сверяйте со справочником кодов.
Перекрёстные проверки отсекают подмену цифр. Сравните извлечённый ИНН поставщика со справочником контрагентов. Если ИНН не найден, отправьте счёт на ручную проверку, а не подставляйте ближайший похожий. Проверьте уникальность номера счёта в базе, чтобы не провести дубликат.
Обязательные поля не заполняйте догадками. Если значение не найдено, статус должен быть «не извлечено», а не «подставлено по шаблону».
Пример настройки: PDF-счёт превращается в JSON со статусом
Возьмём учебный счёт с тремя позициями и НДС 20%. Модель извлекла: позиция 1 — 1 200,00, позиция 2 — 800,00, позиция 3 — 500,00, промежуточный итог — 2 500,00, НДС — 500,00, итог — 3 000,00. ИНН поставщика найден в справочнике, дата в допустимом диапазоне.
Валидатор считает: 1 200 + 800 + 500 = 2 500, совпадает. НДС: 2 500 × 0,20 = 500, совпадает. Итог: 2 500 + 500 = 3 000, совпадает. Все правила прошли, счёт можно отправлять в учёт автоматически.
Если бы НДС извлекли как 480,00, разница 20 рублей превысила бы допуск. Счёт ушёл бы на ручную проверку с пометкой «НДС не сходится». Оператор видит подсветку поля и исходный фрагмент документа, а не просто сообщение об ошибке.
Инструменты: когда хватает шаблонов, OCR или модели
Если счета приходят от одного поставщика в стабильном шаблоне, начните с правил и координат. Текстовый PDF часто разбирается без OCR. Сканы и фотографии требуют OCR, а нестандартные layouts — модели извлечения с JSON-схемой.
В схеме задайте обязательные поля, типы и допустимые значения. Запретите свободный текст в реквизитах: ИНН и КПП должны быть строками цифр, а не описанием. Вероятностное извлечение всегда дополняйте детерминированной валидацией.
Перед внедрением сверьте по документации выбранного OCR или API, возвращает ли он уверенность по полям и координаты. От этого зависит настройка порога. Версии библиотек и моделей фиксируйте на дату запуска: технические детали быстро устаревают.
Ошибки и риски, которые ловит проверка
Частая путаница — НДС «включён» или «сверху». Если документ показывает сумму с НДС, а модель считает её суммой без НДС, арифметика развалится. Проверка равенств это покажет, но лучше сразу описать в схеме, какое поле вы ждёте.
Дата может сломаться из-за локали: 03/04/2026 читается по-разному. Нормализация к ISO и проверка диапазона снижают риск. Склейка позиций таблицы ловится сверкой суммы строк с итогом.
Модель может «придумать» реквизит, особенно если поле плохо видно. Поэтому запрещайте автопринятие без валидации. Ведите тестовый набор счетов и прогоняйте его при смене модели или шаблона. Данные счетов чувствительны: ограничьте доступ и проверьте политику хранения, особенно если используете внешний API.
Чек-лист внедрения и метрики качества
- Опишите схему полей с типами и обязательностью.
- Соберите набор правил: арифметика, форматы, справочники, уникальность.
- Задайте порог уверенности и правила эскалации на человека.
- Настройте очередь ручной проверки с подсветкой полей и исходным фрагментом.
- Включите журнал аудита: файл, версия модели, сработавшие правила.
- Сформируйте тестовый набор счетов для регрессии.
Смотрите на долю автопринятых, точность по полям, долю ложных отклонений, среднее время ручной проверки и стоимость обработки. Каждое ручное исправление добавляйте в тест-кейсы. Периодически пересматривайте правила и сверяйтесь с актуальной документацией источников.
Нужно ли проверять каждое поле вручную?
Нет. Направляйте человеку только те счета, где сработало правило или уверенность ниже порога. Остальные проходят автоматически, но с записью в журнале.
Можно ли доверять уверенности модели?
Как подсказке для приоритета проверки — да. Как замене арифметики и справочников — нет. Порог подбирайте по своим образцам.
Что делать, если ИНН не найден в справочнике?
Отправьте счёт на ручную проверку. Не подставляйте похожий ИНН автоматически: это создаёт ложные проводки.
Какой допуск использовать при сверке сумм?
Около 0,01–0,02, если в документе есть округление по строкам. Точное значение согласуйте с правилами учёта, если счёт идёт в проводки.