You point Tesseract at a clean PDF invoice and the text comes back almost complete. You point it at a phone photo of a thermal slip — tilted a few degrees, a little soft, saved through a chat app — and the date and total go missing, or worse, come back wrong. Nothing in the confidence score tells you which run you just had.
We measured that gap on 20 synthetic receipts. Here is what broke, and what you still have to build after the OCR engine finishes.
Is Tesseract a good alternative for receipt OCR?
For clean scans, yes enough of the time: 11 of 20 receipts came back ledger-ready (vendor, date, total, and tax all correct). For phone-quality captures, no — the same set under a phone-snap combo scored 0 of 20. Tesseract gives you text. A receipt ledger needs checked rows.
What we ran
Tesseract 5.5.0 through pytesseract, on the same 20 synthetic Q2 2026 receipts used in our OCR text is not a ledger write-up: SaaS invoices, restaurants, rideshare, office supplies, hardware. Each image went through grayscale and a 2× upscale, then a simple regex parser for vendor, date, total, and tax. A row counted as ledger-ready only when all four fields matched ground truth (totals and tax within $0.01). The ground-truth sum of totals was $2,034.43.
Caveats, stated plainly: these are synthetic receipts with simulated capture damage, not crumpled real thermal paper; n=20; and the parser on top of Tesseract is simple. A better parser would score higher on clean images. It cannot recover text Tesseract never read. We did not test Slipsheet or any paid OCR service in this run, so there are no accuracy claims here about Slipsheet, Google, AWS Textract, Azure, Veryfi, or anything similar.
Results: six capture conditions
| Condition | Vendor | Date | Total | Tax | Ledger-ready rows | Totals not found | Sum error vs $2,034.43 | Mean word confidence |
|---|---|---|---|---|---|---|---|---|
| Clean render | 19/20 | 20/20 | 20/20 | 12/20 | 11/20 | 0 | $0.00 | 94.2 |
| Tilted 4° | 17/20 | 12/20 | 17/20 | 15/20 | 7/20 | 3 | $85.44 | 91.5 |
| Chat-app JPEG (half size, quality 25) | 16/20 | 1/20 | 18/20 | 0/20 | 0/20 | 0 | $701.20 | 41.8 |
| Slight blur (Gaussian r=1.5) | 13/20 | 3/20 | 19/20 | 1/20 | 0/20 | 0 | $2,001.21 | 61.0 |
| Dim, low contrast + noise | 1/20 | 1/20 | 0/20 | 0/20 | 0/20 | 18 | $1,980.68 | 66.2 |
| Phone snap (3° tilt + blur + shading + JPEG) | 15/20 | 2/20 | 0/20 | 0/20 | 0/20 | 17 | $1,558.68 | 49.3 |
What the numbers hide
Slight blur is the clearest trap. Totals looked fine at 19/20, but the Uber receipt's true total of $24.83 came back as 2026.04 — the date fragment 2026-04 became the amount. That one wrong row pushed the column sum off by $2,001.21 against the $2,034.43 ground truth. "Mostly right" totals are not a ledger.
Tilt tells a different lie. Mean Tesseract word confidence stayed at 91.5 (versus 94.2 on clean), while ledger-ready rows fell from 11 to 7 and eight dates went wrong. Confident and wrong; nothing flags it.
Chat-app JPEG (half size, quality 25) turned Tartine's $32.60 into 812.90 and Figma's $180.00 into 100.90. Under the phone-snap combo — 3° tilt, blur, shading, and JPEG — 17 of 20 receipts produced no total at all, and ledger-ready rows were 0/20.
Does the standard preprocess fix help?
We tried autocontrast plus Otsu binarization on the four hard conditions. It made things worse or no better. Blur stayed at 0/20 ledger-ready while correct totals fell from 19 to 5 and the sum error jumped to $22,906.13. Chat-app JPEG stayed at 0/20 (totals 18→12). Dim and phone-snap each still missed 19 of 20 totals, with 0 ledger-ready rows. Preprocessing cannot invent characters the OCR engine never saw.
Tesseract vs a receipt tool
Tesseract's job ends at text. A receipt tool still has to:
- Pull vendor, date, total, and tax out of that text — and tell a total from a subtotal.
- Normalize dates and currencies so rows sort and sum.
- Surface low-confidence or contradictory rows for a human to fix.
- Export one stable row per receipt, not a pile of pages.
None of that is free work. If you only need searchable text from clean scans, Tesseract plus a script may be enough. If you need a ledger, you are buying or building the layer after OCR. Our OCR receipt scanner overview covers that gap in more detail.
When Tesseract is still the right call
Keep Tesseract when your inputs are clean scans or born-digital PDFs, when you mainly want bulk text search, and when you have time to own the parser and the review queue. Skip it as your only receipt path when the inbox is phone photos, chat-app forwards, and faded thermal slips — the conditions that scored 0 ledger-ready rows here. For capture tips before any OCR runs, see how to digitize receipts with your camera.
If you need one row per receipt
Slipsheet takes receipt photos and PDFs and turns each one into a ledger row — vendor, date, total, tax — that you review, then export as a CSV that opens in Excel or Google Sheets. It is a 14-day trial with no card. That is the soft pitch: text is not a ledger; a checked row is.
FAQ
Is Tesseract good for receipts?
On clean renders in our test, Tesseract got 11 of 20 receipts fully ledger-ready (vendor, date, total, and tax). On phone-snap images that combined tilt, blur, shading, and JPEG compression, it got 0 of 20. It is fine for clean scans; it is not enough by itself for phone photos of receipts.
Why does Tesseract misread receipt totals?
It returns text, not fields. Under slight blur, 19 of 20 totals looked right, but one Uber receipt's $24.83 total came back as 2026.04 — a date fragment treated as the total — and the column sum was off by $2,001.21. On a 4° tilt, mean word confidence stayed at 91.5 while ledger-ready rows fell from 11 to 7, so the engine can look sure while the row is wrong.
Does preprocessing fix Tesseract for receipts?
Not in this run. Autocontrast plus Otsu binarization on the four hard conditions left ledger-ready rows at 0/20 for each. Blur totals fell from 19 to 5 (sum error $22,906.13). Chat-app JPEG totals fell from 18 to 12. Dim and phone-snap each missed 19 of 20 totals.
What's an alternative to Tesseract for receipts?
If you need one checked row per receipt — vendor, date, total, tax — use a receipt tool that parses fields, flags shaky rows for review, and exports a CSV. Tesseract still fits when you have clean scans, need bulk text search, and have time to build the parsing and review layer yourself. We did not benchmark paid OCR services in this test.