OCR чеков: как быстро превратить фото в данные для учета

OCR для чеков — это распознавание текста с фото, чтобы получить дату, итог, продавца и позиции в структурированном виде (например, JSON). Если на чеке есть читаемый QR, надежнее сначала использовать его, а OCR оставить как запасной вариант.

Оглавление

Когда нужен OCR, а когда хватит QR

QR-сценарий — это не OCR: вы считываете QR и получаете уже готовые структурированные данные (обычно точнее, чем распознавание текста). Он особенно удобен для авансовых отчетов и контроля расходов, где критична корректность суммы и состава покупок.

OCR нужен, если:

  • QR отсутствует, поврежден или не читается;
  • чек нестандартный (другая страна/формат) или это не кассовый чек, а квитанция;
  • требуется универсальный ввод «любой документ по фото»;
  • важна офлайн-обработка (без отправки изображения).

В продукте и в компании почти всегда выигрывает стратегия: QR как основной источник → OCR как fallback для сложных/плохих чеков.

Какие поля извлекать из чека

Чтобы OCR был полезен, заранее определите минимально нужные данные и правила проверки.

1) Поля “шапки” (summary):

  • дата и время покупки;
  • продавец (название), иногда адрес;
  • итог (TOTAL/ИТОГ), валюта;
  • налоги/НДС (если печатаются);
  • номер чека/документа (для сверок).

2) Позиции (line items):

  • название товара;
  • количество/вес;
  • цена за единицу;
  • сумма строки;
  • скидки (часто ломают разметку, их лучше учитывать отдельно).

3) Метаданные качества:

  • уверенность распознавания по ключевым полям;
  • исходный распознанный текст;
  • координаты блоков (если планируете экран “проверить и исправить”).

Пайплайн «фото → OCR → поля → JSON»

Надежный OCR для чеков — это не один вызов распознавания, а цепочка шагов с валидацией.

1) Съемка: что попросить у пользователя/сотрудника

  • ровный чек на плоской поверхности;
  • камера сверху (без перспективной “трапеции”);
  • рассеянный свет, без блика на термобумаге;
  • не обрезать низ: итог и способ оплаты часто в самом конце.

Самая частая причина плохого результата — вспышка и блики. Улучшение условий съемки часто дает больший эффект, чем замена OCR-движка.

2) Предобработка изображения (минимум для продакшена)

  • нормализация ориентации (поворот/EXIF);
  • поиск границ чека и обрезка фона;
  • выравнивание (deskew);
  • усиление контраста и подавление шума;
  • аккуратная бинаризация (адаптивный порог), при необходимости — масштабирование.

3) OCR: получить текст + геометрию

На этом этапе важно уметь получать не только “простыню текста”, но и строки/блоки с координатами — так проще находить зоны “итог”, “дата”, “позиции”.

4) Извлечение полей (extraction) и нормализация

Практика, которая быстро снижает ошибки:

  • контекстные фильтры: для суммы разрешайте только цифры и разделитель, для времени — HH:MM, для налоговых/идентификаторов — только цифры нужной длины;
  • нормализация частых замен: 0/O, 1/I, точка/запятая в дробной части, пробелы в числах (1 234,56).

5) Валидация арифметикой (обязательный “контроль здравого смысла”)

  • сумма по позициям должна совпадать с итогом (с допуском на скидки/округления);
  • кол-во × цена ≈ сумма строки;
  • если проверки не проходят — ставьте флаг needs_review и отдавайте на ручную проверку только проблемные места.

6) Результат в JSON (пример структуры)

{
  "purchase_datetime": "2026-02-09T18:43:00",
  "merchant_name": "Продавец",
  "total": 1234.56,
  "currency": "RUB",
  "items": [
    {"name": "Товар", "qty": 2, "unit_price": 45.00, "line_total": 90.00}
  ],
  "quality": {"needs_review": false, "total_confidence": 0.92},
  "raw_text": "..."
}

Сравнение подходов для задачи «распознать чек»

ПодходВыходные данныеПлюсыМинусыКогда выбирать
QR → данныеПоля и позиции сразуМаксимальная точностьРаботает не для всех чековУчет расходов, авансовые отчеты
Универсальный OCRТекст + блокиГибко, можно дешево стартоватьМного парсинга, позиции сложныНужна “шапка”, чеков немного
Специализированное “понимание чеков”Поля + позицииМеньше правил, лучше line itemsДороже и сложнее заменаБольшой поток, нужна автоматизация
On-device OCRТекст на устройствеПриватность, офлайнЗависимость от качества камерыМобильные сценарии без облака

Частые ошибки

  • Пытаться парсить позиции “в лоб” регулярками по всему тексту. Лучше сначала выделить “коридор позиций” между шапкой и блоком итогов.
  • Не разделять OCR и извлечение сущностей. OCR дает символы, а “где дата/итог/позиции” — отдельная логика (правила + проверки).
  • Не хранить сырой текст/координаты. Без них сложно разбирать спорные кейсы и улучшать качество.
  • Не закладывать ручную проверку. Правильный UX — исправлять только поля с низкой уверенностью, а не перепроверять весь чек.

FAQ

Можно ли добиться 100% точности OCR для любых чеков?
Для “любых фото любых чеков” — нет. Но можно приблизиться к почти безошибочному процессу, если использовать QR где возможно, стандартизировать съемку, добавить предобработку и арифметическую валидацию, а сомнительные случаи отправлять на точечную проверку.

Что важнее для качества: OCR-движок или подготовка фото?
В большинстве проектов выигрыш дает именно вход: свет, отсутствие бликов, выравнивание и обрезка + проверки сумм. Смена движка обычно помогает уже после того, как базовая гигиена сделана.

Как понять, что чек нужно отправить на ручную проверку?
Если не сходится арифметика (итог vs позиции), низкая уверенность по ключевым полям (дата/итог), или “итог” найден в нескольких местах — ставьте needs_review=true и показывайте пользователю подсветку спорных строк.