AI receipt scanning: what it reads well and where it fails

What actually happens when you photograph a receipt

The photo is sent to a model that reads the image and returns structured values — an amount, a date, a merchant, a suggested category, sometimes a list of line items.

This is not character recognition followed by rules. A modern model is interpreting the layout: working out which of the several numbers on a receipt is the total rather than the subtotal, the tax, the change given, or the loyalty points balance.

That interpretation is why it works on receipts of wildly varying formats without anyone configuring templates. It is also why it fails in ways that a rules-based system would not — the failures are judgement errors rather than parsing errors, which makes them look plausible.

The fields it reads reliably

In practice, some fields are dependable enough that checking them is a formality, and others need a genuine look.

• Total amount — usually reliable on a clear photo. Receipts label the total prominently and models find it well.
• Date — usually reliable, with the caveat below about ambiguous formats.
• Currency symbol — generally read correctly when printed.
• Merchant name — usually identified, though often in the abbreviated form the receipt prints rather than the name you would recognise.

The fields that need checking:

• Category — this is pure inference from the merchant and items. It is a guess, and it is wrong often enough to matter, particularly for shops that sell across categories.
• Date in ambiguous formats — a receipt showing 03/04 could be March 4th or April 3rd depending on locale, and the model has to guess from context.
• Which total, when a receipt shows several — subtotal, tax, total, amount tendered, and change all appear, and a crumpled or partly obscured receipt can lead to the wrong one.
• Split payments — a receipt where part was paid on a card and part in cash, or a gift card was applied.

Where it fails outright

Some conditions defeat it regardless of model quality, and it is worth knowing them so you do not waste time retrying.

1. Faded thermal receipts. If you cannot read it, neither can the model. Photograph receipts soon after receiving them — thermal paper degrades quickly, especially in heat.
2. Severe glare or shadow across the total. The single most common cause of a failed read.
3. Extreme angles. A receipt photographed at a sharp angle distorts the layout the model relies on.
4. Very long receipts folded or photographed in sections. The total may not be in the frame at all.
5. Handwritten receipts. Variable, and often unreadable.

The practical advice is unglamorous: flat surface, good light, whole receipt in frame, taken soon after the purchase. Thirty seconds of care produces a materially better read than any amount of retrying a bad photo.

Why the confirm step is not optional

This is the part that determines whether AI capture is a genuine improvement or a new source of quiet errors.

A model's output is a proposal. It is usually right and sometimes confidently wrong, and the wrong answers look exactly as plausible as the right ones — there is no visual signal distinguishing them.

If that output posts directly to your ledger, you have an automated import you never reviewed. That is the same failure mode as an unaudited bank feed, with an additional category of error: a bank feed misreports the category but gets the amount right, while a model can get the amount wrong.

In expenie, AI capture produces drafts. A draft is explicitly not a transaction — it is a proposal you walk through one at a time and accept, edit, or skip. Nothing reaches your statement, your account balances, or your budgets until you confirm it.

That single design decision is what makes the feature safe to use, and it is the thing to check in any product that offers receipt scanning. If it posts without a confirmation step, the convenience is being paid for with accuracy you cannot audit.

What to check in two seconds

Confirming a draft should not take longer than typing it would have, or the feature has no value. A quick verification order that catches nearly everything:

1. The amount. Glance at the receipt and the draft. This is the only field where an error genuinely corrupts your books.
2. The date, if the receipt is not from today.
3. The category, which is the most likely thing to be wrong and the cheapest to correct.
4. The account, if you have several and the default is not the one you used.

Amount first, always. A wrong category is an annoyance you can fix at your weekly review; a wrong amount silently misstates your balance and your budget, and you will not find it until you reconcile.

Line items and what they are for

Some receipts produce a list of individual items alongside the total. This is useful for verification and less useful than it appears for record-keeping.

In expenie, a line breakdown can be shown on a draft for transparency — so you can see what the model read — but it does not create separate transactions. The receipt remains one expense.

That is a deliberate choice. Splitting a grocery trip into twenty categorised lines costs real time and produces category totals you will not act on. The exception is a genuinely large item inside an ordinary shop, which is worth splitting out by hand.

When typing is still faster

AI capture is not always the better path, and pretending otherwise leads to using it where it slows you down.

Typing wins for a simple cash spend you remember exactly, for anything where you already know all four fields, and for round numbers with an obvious category. "12, coffee" is faster to type than to photograph and confirm.

Capture wins for detailed receipts with awkward totals, for a backlog of receipts collected over several days, for anything where you are not sure of the exact amount, and for describing several spends at once in plain language.

The realistic pattern is using both — typing in the moment when it is quick, photographing when it is not, and confirming everything either way.