Phone-Photo Receipts in Claude: 61% → 93% With 15 Lines of

By Lazar Milicevic · Published June 14, 2026 · 8 min read

A small business owner snaps a paper receipt on a cheap Android, drops it into Claude, and asks for line items and a total. The answer looks right. It isn't — four of ten lines are wrong and the total is off by a few euros. Multiply that by 200 receipts a week and you have a bookkeeping problem that costs more to fix than to do by hand.

The failure mode nobody demos

Every "PDF to Claude" tutorial uses a clean digital invoice exported from Stripe or QuickBooks. Of course it works. The advice everyone repeats — convert your PDF to markdown first — is useless here, because you don't have a PDF. You have a JPEG from a phone camera with skew, shadow, and compression artifacts. Three things break extraction in the real world:

• Skew. Phone photos are almost never straight. 5–15° rotation is normal.
• Uneven lighting. A shadow across the top half, glare on the total line.
• Compression. JPEG noise around text edges, especially on thermal paper.

When you upload that file directly, Claude's vision encoder has to reason through noise. It doesn't fail loudly — it hedges. Output looks plausible. The errors are subtle and quietly poison your books.

I tested this on 250 real phone-photo receipts pulled from a client's expense pipeline. Raw uploads to Claude scored 61% line-item accuracy. That number alone should end the conversation about "just send the photo and write a better prompt."

Why a better prompt won't save you

Before the OpenCV path, I burned a week trying to fix this at the prompt layer. Bigger model. Few-shot examples. Structured JSON schema with strict validation. Chain-of-thought with explicit "double-check the total" instructions. Every one of those moved accuracy by 2–4 points and added tokens.

Here's why none of it worked: vision models don't have magic. When the input is ambiguous, they generate longer internal reasoning to decide whether that smudge is a 3 or an 8. You pay for that hedging in output tokens and in silent errors. A smarter prompt tells the model what to extract — it doesn't make a faded "2.40" stop looking like "2.49".

The fix isn't a better prompt. It isn't a bigger model. It's image preprocessing before Claude ever sees the file. Two real steps that take about 15 lines of Python with OpenCV.

The 15-line preprocessor

Three operations: grayscale, deskew, adaptive threshold. Save the cleaned image and send that to Claude instead of the raw photo.

import cv2
import numpy as np

def clean_receipt(path_in: str, path_out: str) -> None:
    img = cv2.imread(path_in)
    gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)

    # Deskew via Canny + Hough
    edges = cv2.Canny(gray, 50, 150, apertureSize=3)
    lines = cv2.HoughLines(edges, 1, np.pi / 180, 200)
    angles = [(theta * 180 / np.pi) - 90 for rho, theta in lines[:, 0]]
    angle = np.median([a for a in angles if -45 < a < 45])
    h, w = gray.shape
    M = cv2.getRotationMatrix2D((w // 2, h // 2), angle, 1.0)
    rotated = cv2.warpAffine(gray, M, (w, h),
                             flags=cv2.INTER_CUBIC,
                             borderMode=cv2.BORDER_REPLICATE)

    # Adaptive threshold kills shadow + glare
    cleaned = cv2.adaptiveThreshold(
        rotated, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C,
        cv2.THRESH_BINARY, 31, 15
    )
    cv2.imwrite(path_out, cleaned)

What each step actually does:

• Grayscale. Color carries no signal for text extraction. It also inflates the encoded image. Drop it.
• Canny + Hough deskew. Canny finds edges. Hough fits straight lines through them. The median angle of those lines is your rotation error. Rotate by -angle and the text runs horizontal. Claude's vision model stops burning reasoning tokens mentally rotating the page.
• Adaptive threshold. A global threshold blows out shadowed areas — you get a black blob where the top of the receipt was. Adaptive threshold looks at each local neighborhood (the 31 block size) and binarizes against its own background mean (offset by 15). Shadow disappears. Glare disappears. You end up with crisp black text on a clean white background that looks like a fax.

That's it. No model, no API, no GPU. Runs in roughly 80–150 ms per receipt on a laptop CPU.

Real numbers on 250 receipts

Same prompt, same model (Claude with vision), same expected JSON schema. Only difference: raw JPEG vs. preprocessed PNG.

Two things matter here. Accuracy jumped 32 points. And token cost dropped 41% at the same time. That's not a tradeoff — it's the same root cause solved twice. Cleaner input means Claude isn't hedging, isn't generating long internal reasoning to disambiguate a smudge, isn't padding output with uncertainty.

The 7% failure tail after preprocessing was mostly receipts where the paper was physically damaged — torn corners, ink smeared by water. No preprocessor fixes that. At that point a human checks the photo.

Where the wins came from

• Deskew alone bought ~14 accuracy points. Skew is the silent killer.
• Adaptive threshold bought ~16 points by erasing shadow and glare.
• Grayscale was worth ~2 points but ~18% of the token savings.

Wiring it into the Claude call

The preprocessor goes in front of the API call, not behind it. Don't try to fix bad extraction with a smarter prompt downstream.

import base64, anthropic

def extract_receipt(raw_path: str) -> dict:
    cleaned_path = raw_path.replace(".jpg", "_clean.png")
    clean_receipt(raw_path, cleaned_path)

    with open(cleaned_path, "rb") as f:
        b64 = base64.standard_b64encode(f.read()).decode()

    client = anthropic.Anthropic()
    resp = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{
            "role": "user",
            "content": [
                {"type": "image", "source": {
                    "type": "base64",
                    "media_type": "image/png",
                    "data": b64,
                }},
                {"type": "text", "text":
                    "Extract line items and total as JSON. "
                    "Schema: {items:[{desc,qty,price}], total, currency}."
                },
            ],
        }],
    )
    return resp.content[0].text

That's the whole pipeline. No queue, no retry logic, no fallback model. For a solopreneur processing 50–500 receipts a week, this is the production path.

A few things I learned shipping this to actual clients:

• Don't downscale before preprocessing. Resize after adaptive threshold if you need to. Threshold on a small image loses edge detail.
• Save as PNG, not JPEG. JPEG re-introduces the compression artifacts you just removed.
• Cap image dimension around 1600 px on the long edge. Larger doesn't help accuracy and costs tokens.
• Keep the raw file. When a total is disputed, you need the original photo, not the cleaned binarized one.

When this approach breaks

I'm not selling this as universal. It works for receipts, invoices, delivery notes, and most phone-shot paperwork where the goal is text extraction. It does not work for:

• Receipts with logos or photos you need to keep. Adaptive threshold destroys photographic content.
• Handwritten notes. Hough deskew fails when there are no straight lines.
• Multi-column layouts where you need to preserve geometry. Rotation can subtly shift column boundaries; you'd want a perspective-warp step first.

For those cases the pipeline grows — perspective correction via contour detection, then crop to the document, then threshold. Same idea, more steps. The 15-line version covers maybe 85% of real small-business paperwork.

Why bizflowai.io helps with this

This preprocessor is the kind of thing I drop into client pipelines at bizflowai.io — the receipt-to-bookkeeping flows we build for small businesses already include image cleanup, schema validation, and a confidence threshold that routes ambiguous receipts to a human review queue instead of silently writing bad data into the books. Most of the cost savings clients see come from exactly these unglamorous fixes in front of the model, not from prompt engineering behind it.

The takeaway

If you're processing receipts, invoices, or any phone-shot paperwork through Claude in your business, put the preprocessor in front of the API call. Grayscale, deskew, adaptive threshold. Fifteen lines. 32 points of accuracy. 41% token reduction. Same model, same prompt.

Don't try to fix bad extraction with a smarter prompt. Fix the pixels first.

Frequently asked questions

Why does image preprocessing matter for Claude receipt extraction?

Phone-photo receipts have skew, shadows, and glare that force Claude's vision model to hedge — generating extra reasoning tokens to guess ambiguous characters. On a benchmark of 250 real receipts, raw uploads scored 61% line-item accuracy while preprocessed images hit 93%. Token cost also dropped 41%. Cleaner input means Claude reads instead of reasoning through noise, so you pay less and get better accuracy simultaneously.

How do I preprocess a phone-photo receipt before sending it to Claude?

Use about 15 lines of Python with OpenCV in three steps. First, load the image and convert to grayscale since color adds no value for text. Second, deskew using a Canny edge detector and Hough line transform, taking the median angle and rotating so text runs horizontal. Third, apply adaptive threshold to binarize against local backgrounds, removing shadows and glare. Save the cleaned image and send that to Claude.

Why use adaptive threshold instead of global threshold for receipts?

A global threshold applies one cutoff value across the entire image, which blows out shadowed areas and loses text in dark regions. Adaptive threshold examines local neighborhoods and binarizes each region against its own background. This means shadows and glare disappear, leaving crisp black text on a clean white background — similar to a fax — which is ideal input for Claude's vision model.

When should I fix prompts versus preprocess images for Claude OCR?

If you're extracting text from phone-shot paperwork — receipts, invoices, delivery notes — fix the pixels first, not the prompt. A smarter prompt cannot recover information lost to skew, shadow, or compression artifacts. Preprocessing with grayscale, deskew, and adaptive threshold belongs in front of the API call. Prompt engineering only helps once Claude is receiving a clean, readable image.

What accuracy improvement does receipt preprocessing deliver?

On a benchmark of 250 real phone-photo receipts pulled from production, raw uploads to Claude scored 61% line-item accuracy. After applying grayscale conversion, deskew, and adaptive threshold preprocessing, accuracy rose to 93%. Token cost simultaneously dropped 41% because Claude no longer needed extended reasoning to disambiguate noisy characters like distinguishing a 3 from an 8 in shadowed or skewed regions.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.