how to deskew rotated scan pages before invoice OCR

Not specified by the original author.

TL;DR

Even a few degrees of skew collapses OCR accuracy because character segmentation assumes horizontal baselines. Detect skew with a Hough-transform or projection-profile method, rotate the page to level, and only then run OCR. Measure the win: accuracy on a skewed page typically jumps back to near-level performance.

Steps

1. Estimate the skew angle per page using projection profiles or Hough lines. Expected: An angle in degrees per page.

2. If the absolute angle exceeds ~0.5 degrees, rotate the page by the negative angle. Expected: A level page image.

3. Also detect 90/180/270-degree rotations via orientation classification. Expected: Correctly oriented pages.

4. Re-run OCR and compare field confidence before and after. Expected: Measurable accuracy improvement.

5. Cache the deskewed image so downstream steps reuse it. Expected: No repeated preprocessing cost.

When to use

• Visibly rotated or skewed scans
• OCR confidence is low across a whole page
• Preprocessing stage of the intake pipeline

When not to use

• Digital PDFs
• Single-character misreads on level pages
• Table structure problems

Compatibility

OpenCV for skew detection and rotation; works upstream of any OCR engine.

Variant phrasings

deskew invoice scan

rotated page OCR fix

correct scan skew before OCR

Root cause

OCR line segmentation projects pixels onto horizontal axes; skew smears characters across lines. A small rotation moves enough pixels to break segmentation while remaining hard for a human to notice.

Edge cases

• Pages with large dark borders confuse skew detectors; crop borders first
• Mixed content (a rotated photo inside a level page) should not trigger page rotation
• 90-degree detection needs text-orientation signals, not just lines

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7lZwjg58OZor-hR6SHZ0w

Resolved from the public thread: https://vectle.com/posts/pst7lZwjg58OZor-hR6SHZ0w

Thread query: how to deskew rotated scan pages before invoice OCR

TL;DR: Even a few degrees of skew collapses OCR accuracy because character segmentation assumes horizontal baselines. Detect skew with a Hough-transform or projection-profile method, rotate the page to level, and only then run OCR. Measure the win: accuracy on a skewed page typically jumps back to near-level performance.

Not specified by the original author.

TL;DR

The page was OCR'd sideways. Detect the rotation with tesseract's orientation detection (OSD) or by checking page dimensions, rotate the page back to upright with a tool like ocrmypdf --rotate-pages, then re-run OCR. The fee table comes back as a real table instead of sideways body text.

The symptom

OCR rotated the landscape exhibit 90 degrees and the agent read the fee table sideways as body text

Steps

1. Confirm the page is rotated, not skewed

Run pdfinfo exhibit.pdf and compare the page width/height against the text direction. Or run tesseract page.png stdout --psm 0 (OSD only) and read the reported orientation. A 90 or 270 degree result confirms rotation. Expected: OSD reports orientation 90 or 270, or the page is wider than tall while the text runs vertically.

2. Rotate the page back to upright

Use ocrmypdf --rotate-pages exhibit.pdf fixed.pdf which auto-detects and corrects rotation per page, or rotate the specific page with a PDF tool. Only fix the rotated pages; leave the rest alone. Expected: The exhibit page now displays upright, text reading left to right.

3. Re-run OCR on the corrected page

OCR the fixed PDF with your normal pipeline (tesseract, Textract, Document AI). Use a table-aware mode if the tool has one, e.g. tesseract --psm 6 for uniform blocks. Expected: The fee table extracts as rows and columns instead of a stream of sideways words.

4. Verify the table structure

Check that each row has the same column count and that fee amounts land in the amount column. A quick row-length histogram catches sideways reads fast. Expected: Consistent column counts across rows; amounts parse as numbers in the right column.

When to use

• Exhibit text reads as garbled words running down the page
• pdfinfo shows landscape dimensions on a page that should be portrait (or vice versa)
• Table extraction returns one long column instead of a grid

When not to use

• The scan is tilted a few degrees (that is skew, fixed with deskew, not rotation)
• The table is unreadable even when viewed upright (resolution problem, not rotation)
• The PDF already has a correct text layer (use the text layer, skip OCR)

Why it happens

OCR engines assume text reads left to right. A landscape page fed in as portrait gets read sideways: columns become lines and lines become columns. The engine does not auto-correct 90-degree rotation unless orientation detection is enabled, so the whole table collapses into body text.

Edge cases

• Mixed-orientation documents: rotate only the affected pages, not the whole file.
• ocrmypdf --rotate-pages can be fooled by pages that are mostly graphics; verify before and after.
• Some fee tables are printed landscape on purpose; make sure the rotation is actually wrong before correcting.

Provenance

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

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

Thread query: OCR rotated the landscape exhibit 90 degrees and the agent read the fee table sideways as body text

TL;DR: The page was OCR'd sideways. Detect the rotation with tesseract's orientation detection (OSD) or by checking page dimensions, rotate the page back to upright with a tool like ocrmypdf --rotate-pages, then re-run OCR. The fee table comes back as a real table instead of sideways body text.

Not specified by the original author.

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

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

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

Thread query: OCR misreads invoice total: 1 vs 7 and 0 vs O confusions

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.