Photograph a receipt, get a filled-in transaction. It is the single most requested feature in every expense app, and it sounds like a solved problem — the models are good now, you just point one at the image.
Then you look at actual receipts.
Receipts are a hostile format
There is no standard. A receipt is whatever the shop's printer decided to emit, and the variety is remarkable:
The total is not the largest number. It competes with the cash tendered, the change given, the loyalty points balance, and last month's spend summary.
There are often several totals. Subtotal, total before tax, total after tax, total after discount, amount charged to card. Which one is "the bill"? The one the payer is out of pocket for — which is not always the one printed biggest.
Tax is sometimes included and sometimes added, and the receipt often does not say which.
Service charges hide. A 12% service line sits in the middle of the item list looking exactly like an item.
Line items wrap. A long product name breaks across two lines, and the price sits on the second one, orphaned.
Thermal paper fades, gets creased down the middle, and is usually photographed at an angle in bad restaurant lighting.
Each of these is individually solvable. The difficulty is that they arrive in combination, and a scan that gets four of five fields right is still a scan you have to check.
Extract structure, not just numbers
We settled on pulling out a specific, bounded set: title, total, currency, date, line items — and tax, tip and service fee as their own fields.
That last part is the design decision that mattered most, and it took us a while to get to.
The naive version treats a receipt as a flat list of lines and lets people claim them. But tax and service are not things anybody ordered. If they arrive as ordinary line items, somebody has to volunteer to claim "SERVICE 12%", which is both absurd and unfair — it lands on whoever is most agreeable rather than being spread across the table.
So they come out as shared costs instead, split across everyone either proportionally or equally. Extracting them separately is what makes a fair split possible downstream. Get the parsing shape wrong and no amount of good splitting UI can recover.
The currency field is worth dwelling on too. Getting it from the receipt itself — the symbol, the tax nomenclature, the number formatting, the language — matters enormously for the case where scanning is most valuable, which is travelling. That is precisely when you are least likely to notice that a €48 dinner was logged as $48. So we read it off the document rather than assuming your account default.
Dates are the other quiet trap. 03/04/2026 is two different days depending on which country printed it. Regional format conventions and the receipt's own language are strong evidence, and we would rather use them than default to one hemisphere's convention.
We never save automatically
This is the design decision we are most confident about, and the one users occasionally push back on.
A scan produces a draft. It opens in the normal transaction form, populated, with everything editable. You look at it, fix anything wrong, and save. HiBill does not write a transaction to your ledger on the strength of a photograph.
The reasoning: the cost of the two failure modes is wildly asymmetric. A draft you have to correct costs you five seconds of mild annoyance. A wrong number that saved silently costs you a wrong balance with a friend that neither of you notices for a month — and by then nobody can reconstruct what really happened.
Ledgers are trust infrastructure. An expense app that is occasionally, invisibly wrong is worse than one that asks you to glance at things, because the whole value is that both people believe the number.
So the scan does the typing. The confirmation stays with you. We think that is the correct division of labour even as the models keep improving, because the issue is not model accuracy — it is that you are the only one who knows whether the number on the paper is the number you actually care about.
Scans are metered
AI scanning has a real per-call cost, so it is quota'd rather than unlimited:
Plan | Scans per month |
|---|---|
Free | 5 |
Pro | 100 |
Ultra | 500 |
Five a month is deliberately enough to cover the cases where scanning genuinely wins — the long restaurant bill, the big supermarket run — without being a trial that expires. Typing in a €4 coffee is faster than photographing it anyway.
What it pairs with
The scan is most useful when it feeds something else. Two combinations we reach for:
Scan then itemize. The line items come out of the receipt already separated, with quantities, so assigning them to people is a few taps. Good for small groups with a detailed bill.
Scan then share. Get an accurate total with no typing, then let everyone claim their own share. Good for large groups, where you do not want to be the person interpreting a receipt on behalf of nine others.
Receipt scanning is on every plan including free. It is in the transaction screen behind the camera icon.