Of everything printed on a receipt, one number does real work in your books: the amount you actually paid. The store name tells you who, the date tells you when, but the total is the figure that lands in your expense record, rolls up into your quarterly numbers, and has to reconcile against the bank line at year-end. Get the store name slightly wrong and it's a cosmetic annoyance. Get the total wrong and your books are wrong.
Which is a problem, because the total is also the single hardest thing on a receipt for OCR to pin down. Not because the characters are hard to read — a printed "54.00" is easy — but because a receipt is crowded with numbers that look like the total, and picking the right one takes judgment, not eyesight. This is a close look at that one field: why the amount is the tricky one, where it slips, how Starlog handles it, and the two-second habit that catches every miss.
Reading a number and choosing a number are different jobs
It helps to separate the two things going on when OCR "reads the amount," because they fail for completely different reasons. (The full version of this split is in how receipt OCR actually works, but the short form is what matters here.)
The first job is recognition — turning the pixels of "54.00" into the characters 5, 4, ., 0, 0. On a clean receipt this is largely solved; on a faded or crumpled one it can misfire, which is its own photo-quality problem. The second job is selection — out of the dozen numbers on the slip, deciding which one is the total. This is the hard part, and it's hard even when every character was read perfectly.
Because here's what a typical receipt actually hands the parser: a price for each line item, a subtotal, one or more tax lines, sometimes a tip or service charge, a grand total, the amount tendered, and the change given. Ten or fifteen numbers, several of them close in value, one of them the answer. Recognition got them all right. Selection still has to choose.
The numbers that pretend to be the total
Once you know to look, you can see exactly where the amount field goes wrong. A handful of impostors trip it up again and again:
- The subtotal. Sitting right above the real total, often a round, confident-looking number. Grab the subtotal instead of the total and you've quietly dropped the tax off every expense.
- A tax line. On a receipt with a big tax component, the tax figure can be large enough to look like a plausible total on its own.
- Amount tendered and change. Pay for a 54.00 meal with three twenties and the slip shows 60.00 tendered and 6.00 change. Now there are three more numbers in play, and the cash you handed over is not what you spent.
- The tip and service charge. On a restaurant bill the printed total is frequently the pre-tip figure, with the tip written in by hand below it. OCR reads the printed number; the number you actually paid is higher. (That's one reason the restaurant receipt is the hardest everyday slip to capture.)
- Rounding. Some point-of-sale systems print an exact total and a rounded cash total a line apart. Which one is "the amount" depends on how you paid.
None of these is a reading error. Every character is correct. The mistake, when it happens, is a choice — and that's precisely the kind of confident, plausible error you won't notice at a glance months later, when the number is already in your books and the receipt is filed. It's the same failure mode I wrote about in what OCR still gets wrong: the wrong-but-believable total is far more dangerous than the obviously-garbled one, because nothing flags it.
How Starlog handles the amount
Our approach follows directly from all of that. Starlog runs OCR on your device with Google's ML Kit, and it's deliberately narrow about what it claims: it pre-fills the store name and the amount, and nothing else. The date and the category are yours to set. Every field it fills — including the amount — stays editable, in any currency.
That narrowness is the point. We pre-fill the amount because it's the field worth drafting for you, but we treat it as a draft, not a verdict. The number lands in the field already typed, so most of the time you're confirming rather than keying — but it's sitting there for you to check against the slip, not buried in a total you'll never see again. And whatever the draft says, the original receipt image is kept and filed into your own Google Drive, so the amount is a convenience and the picture is the record. If a figure is ever in question, the source that settles it is one tap away.
The design principle is simple: let OCR do the typing, and keep you as the one who owns the number.
The tax line is not the total (US and India)
Two region-specific notes, because the amount field intersects with tax rules in ways worth flagging.
In the US, the figure you record is generally the full amount you paid, tax included — but the deductible portion isn't always the whole thing. A business meal is commonly 50% deductible, for instance, so the total on the slip and the number that helps you at tax time aren't the same figure. Capture the real total; let the treatment get sorted later, and confirm the current rules with your CPA. (Deductible vs. not, with examples walks through where these lines fall.)
In India, the tax line on a receipt is a genuine trap for the amount field. If you're claiming GST input tax credit, what you can claim hinges on the document being a proper tax invoice and the credit not being blocked — the tax printed on a slip is not automatically tax you can claim. So the total you record and the ITC you're entitled to are two different numbers, and the receipt only shows one of them. Record the amount you paid, and check what actually qualifies for ITC separately — with your CA.
The through-line: the amount field captures what you spent. What's deductible or claimable is a second question the receipt can't answer on its own.
A note on currency
OCR reads the digits; it doesn't know the currency, and it certainly doesn't convert. If a chunk of your receipts are in another currency — a subscription billed in dollars, a hotel abroad — the amount Starlog drafts is the number as printed, in whatever currency the slip is in. Record it as-is and note the currency; the conversion is a separate reckoning, and the defensible move is to keep the original figure and the original receipt rather than baking in a rate you'll want to revisit.
The one habit that catches everything
You don't need to understand any of this at capture time. You need exactly one habit: glance at the amount before you move on.
Two seconds, receipt still in hand, comparing the drafted number against the total you actually paid — tip included, right currency, not the subtotal or the change. That single glance is the entire quality-control step, and it works because it happens at the one moment you have both the number and the ground truth in front of you. The alternative is discovering the mismatch next spring, when the receipt is filed, the memory is gone, and the only thing left is a number in a column that won't reconcile.
Catch it now and the whole chain downstream just works: the total rolls into your trip and project totals correctly, and it turns up right in the year-end export your accountant relies on. The amount is the number your books are built on. Let OCR draft it, and spend the two seconds to own it.
The takeaway
The amount is the most important field on a receipt and the hardest for OCR to choose, because a slip is full of numbers that look like the total and only one of them is. Recognition rarely fails on a decent photo; selection is where the confident, invisible errors hide — the subtotal, the tax line, the cash tendered, the pre-tip figure. So use OCR for what it's good at, drafting the number so you're not typing it, and keep the one job that stays yours: a two-second glance to confirm the total before it becomes a line in your books.