How to Extract Receipt Data With Python: OCR APIs, Tesseract, and What Actually Works

Last updated July 2026.

There are two ways to extract receipt data with Python, and they are not variations on a theme. You can run OCR yourself with something like Tesseract and then write code that figures out which number is the total, or you can call an OCR API that returns merchant, date, tax, total, and line items already labeled. The first is free and takes weeks. The second costs cents a document and takes an afternoon. Almost everyone who starts with the first ends up at the second, and the reason is worth understanding before you pick.

Why Tesseract alone will not extract receipt data

Tesseract is an OCR engine. Point it at a receipt through pytesseract and it hands you a string of text. That feels like success for about ten minutes.

Then you look at the string. A typical grocery receipt contains the store name, an address, a phone number, a date, a time, a register number, a cashier name, fifteen product lines, a subtotal, a tax line, a total, a payment method, a card number fragment, change due, and a loyalty points balance. Your Python code now has to decide which of those numbers is the total. Not the subtotal, not the tax, not the change due, not the loyalty balance. The total.

So you write a regex. It works on the receipt in front of you. Then you try a different merchant whose receipt says AMOUNT DUE instead of TOTAL, or puts the tax below the total, or wraps a long product name onto two lines and breaks your line-item grouping. Every merchant is a new edge case, and merchants redesign their receipts. That maintenance treadmill, not the OCR, is where these projects actually die.

Tesseract is also noticeably weaker on the documents that matter most in expense work: faded thermal receipts, phone photos taken at an angle, crumpled paper. It was built for clean scanned pages.

What an OCR API returns instead

A receipt OCR API does the OCR and the semantic layer. You post the file and get back structured JSON in which the fields are already named. Instead of a wall of text, you get something shaped like this:

{
  "merchant": "Costco Wholesale",
  "date": "2026-07-08",
  "subtotal": 184.22,
  "tax": 15.66,
  "total": 199.88,
  "currency": "USD",
  "line_items": [
    {"description": "Paper Towels 12pk", "quantity": 1, "unit_price": 21.99},
    {"description": "Coffee Beans 2lb", "quantity": 2, "unit_price": 18.49}
  ]
}

The difference is not convenience. It is that the hard problem, deciding what the words mean, has been solved for you by a model trained on millions of receipts rather than by regex you wrote on a Tuesday.

Extracting receipt data with Python in practice

The whole thing is a POST with a file and an API key. In Python:

import requests

with open("receipt.jpg", "rb") as f:
    response = requests.post(
        "https://receiptocr.ai/api/v1/extract",
        headers={"Authorization": "Bearer YOUR_API_KEY"},
        files={"file": f},
    )

data = response.json()
print(data["merchant"], data["date"], data["total"])

for item in data["line_items"]:
    print(item["description"], item["quantity"], item["unit_price"])

That is the entire integration. No image preprocessing, no deskewing, no thresholding, no regex, no per-merchant rules. Check the exact endpoints and field names in the receipt OCR API documentation before you build, since response shapes differ between vendors and any code sample you find on the web is a sketch, not a contract.

Which OCR API should a Python developer use?

The honest landscape, with July 2026 pricing taken from each vendor's own page:

The row worth staring at is Google Cloud Vision. It is the most commonly recommended answer to this question on the internet and it does not solve it. Vision has no receipt parser and no invoice parser at all, so it returns text and bounding boxes and leaves the entire semantic problem with you. Google's own OCR documentation redirects document-extraction users to Document AI for exactly this reason. If a tutorial tells you to extract receipt totals with Vision, it is telling you to write the hard part yourself.

Do I need to preprocess receipt images in Python?

With Tesseract, yes, and it is a real chunk of the work. Grayscale conversion, thresholding, deskewing, denoising, and sometimes perspective correction with OpenCV, tuned per source, because the settings that rescue a faded thermal receipt can destroy a clean PDF.

With a modern OCR API, no. The vendors handle rotation, skew, lighting, and noise inside the service, because their models were trained on exactly the phone photos that break naive pipelines. If you find yourself writing OpenCV code to make an API work, the API is the wrong one.

How do I get the extracted receipts into a spreadsheet?

If a spreadsheet is the actual deliverable, pause before you write any Python at all. Most cloud OCR services return JSON and nothing else, so a script to write CSV rows is on you. Pandas makes it short:

import pandas as pd

rows = [
    {
        "merchant": r["merchant"],
        "date": r["date"],
        "tax": r["tax"],
        "total": r["total"],
    }
    for r in extracted_receipts
]

pd.DataFrame(rows).to_csv("receipts.csv", index=False)

But be honest about who the output is for. If the answer is a bookkeeper rather than an application, you may be building a tool that already exists. The receipt to Excel converter does this in a browser with a review step, and the bulk receipt scanner handles a month of receipts at once. Writing a Python script so a colleague can email you a folder of images is a common and avoidable mistake. The same logic applies to adjacent documents: if the pile is bank statements rather than receipts, a purpose-built bank statement converter beats parsing PDFs by hand.

How accurate is receipt OCR in Python?

It depends almost entirely on which layer you use. Raw OCR engines do well on clean printed text and degrade quickly on faded thermal paper and angled photos. Purpose-built receipt models hold up far better on exactly those documents, because that is what they were trained on. But no engine is perfect, and the right design assumption is that some fields will be wrong. Build a review step, or use a tool that has one. Silently writing a misread total into your books is worse than not automating at all.

The short version

Tesseract gives you text and leaves you the hard problem. Cloud OCR without a receipt parser, Vision especially, does the same thing at a higher price. An API with a receipt model gives you named fields and turns a multi-week parsing project into a POST request. Pick based on where you want your engineering time to go, and if the honest answer is that you never wanted to write receipt-parsing code in the first place, the receipt OCR API and the browser-based receipt OCR software both exist so you do not have to.