## TL;DR

OCR engines confuse visually similar characters on invoice totals: 1 becomes 7, 0 becomes O, 5 becomes S. The fix is a validation layer, not better OCR: recompute the total from line items plus tax, compare against the extracted total, and flag mismatches for a targeted re-read of the total region at higher DPI. Never trust a raw OCR total without the arithmetic check.

## Error

```text
Extracted total: $7,450.00
Actual total on invoice: $1,450.00
```

## Steps

1. Recompute the expected total from extracted line items, subtotal, tax, and discounts.
   Expected: A computed total you can compare against the OCR total.
2. If the two differ, crop the total region of the page and re-run OCR at 300 DPI minimum.
   Expected: A second read of just the total, often with a different character result.
3. Apply a character-confusion map to the total field: swap 7/1, O/0, S/5, B/8 and re-validate.
   Expected: One of the swapped variants matches the computed total.
4. If no variant matches, route the invoice to human review with both values shown side by side.
   Expected: A reviewer confirms the correct total in one glance.
5. Log the confusion pair and the vendor so the map improves for that sender.
   Expected: Repeat invoices from the same vendor stop hitting the same error.

## When to use

- Extracted invoice total differs from the computed total by digit substitution
- Totals contain characters like 7, O, S in suspicious positions
- Low-quality scans where character shapes blur

## When not to use

- The total is missing entirely (not a misread)
- Line items fail to parse (different problem)
- The invoice is a digital PDF with embedded text (no OCR needed)

## Compatibility

Tesseract 5.x, AWS Textract, Google Document AI, Azure Document Intelligence, PaddleOCR. Applies to scanned/image PDFs; not needed for text-layer PDFs or Factur-X/ZUGFeRD XML.

## Variant phrasings

### invoice total OCR reads 7 instead of 1

### OCR confuses O and 0 on invoice amounts

### extracted total has wrong digits

## Root cause

OCR character classifiers rank shapes by visual similarity, and at low resolution the differences between 1/7, 0/O, and 5/S collapse. Invoice totals are usually large bold numerals, which paradoxically render with thicker strokes that blur these distinctions at 150 DPI.

## Edge cases

- Totals with currency symbols glued to digits ($1450) confuse segmentation; strip symbols before the confusion map
- Handwritten corrections near the total poison the crop; expand the crop margin
- Some vendors print totals in outlined/fancy fonts; fall back to line-item arithmetic as the source of truth

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JK0zO0rq7TDc5Io56ONg0w