An OCR receipt scanner turns a receipt photo into data in two passes. Optical character recognition (OCR) first converts the image into lines of text with positions. A second step then decides which line is the merchant, the date, the subtotal, the tax, the tip and the total. Most receipt errors happen in that second step.
Fields an OCR receipt scanner pulls off a receipt
An OCR receipt scanner pulls a short list of fields off a receipt: merchant name, transaction date, total, sales tax, tip, payment method and the last digits of the card used. Some also read the subtotal, the time and individual line items. Each field comes from a printed line the software has to find and label.
Those fields line up with what the IRS says expense records should show. The IRS page on what kind of records to keep says supporting documents for expenses should identify the payee, the amount paid, proof of payment and the date incurred, and include a description of the item or service. A receipt scan that captures merchant, date, total, payment method and line items covers most of that list. Whether a given expense is deductible is a separate question the receipt alone does not answer.
Not every receipt carries every field. A parking ticket stub may show a date and an amount and nothing else. A cash receipt has no card digits, so payment method reads as cash or comes back empty. A gas station receipt may print the station's brand in a logo and the legal business name in small type further down, and the two do not match. A good scanner records an empty field as empty instead of filling it with a guess, so the reviewer knows what to look for.
The merchant field causes more trouble than its simplicity suggests. The name printed on the receipt is often not the name that appears on the card statement. A restaurant may trade under one name and bill under its parent company, so a receipt reading "Harborview Kitchen" can match a statement line reading "HBV HOSPITALITY LLC". Matching receipts to statement lines therefore leans on date and amount more than on the merchant name.
Card digits help with that matching. When a client uses several cards, the last four digits on the receipt show which statement the charge belongs on.
An example restaurant receipt, field by field
The receipt below is fictional. The restaurant, amounts and card digits are made up for the example.
HARBORVIEW KITCHEN
118 Example Street
10/03/2026 7:42 PM
Table 12 Server: Example
2 Grilled fish 38.00
1 House salad 11.50
2 Iced tea 7.00
SUBTOTAL 56.50
TAX 8.25% 4.66
TOTAL 61.16
VISA XXXX-4821
TIP ______
TOTAL ______
The customer wrote a tip of $11.00 and a total of $72.16 by hand on the last two lines. Here is what a receipt OCR pass should produce:
| Field | Printed line | Extracted value | Note |
|---|---|---|---|
| Merchant | HARBORVIEW KITCHEN | Harborview Kitchen | Top line, often in a logo font |
| Date | 10/03/2026 | 2026-10-03 | Month first on US receipts |
| Subtotal | SUBTOTAL 56.50 | 56.50 | |
| Sales tax | TAX 8.25% 4.66 | 4.66 | The rate is not the amount |
| Printed total | TOTAL 61.16 | 61.16 | Confused line 1: not the amount charged |
| Payment method | VISA XXXX-4821 | Visa ending 4821 | |
| Tip | TIP (handwritten 11.00) | 11.00 | Handwriting, often missed |
| Final total | TOTAL (handwritten 72.16) | 72.16 | Confused line 2: the amount charged |
The two marked lines are the ones receipt OCR most often confuses. Both say TOTAL. The printed one is clear and machine-made. The handwritten one is the amount that will appear on the card statement. A scanner that grabs the first TOTAL it can read cleanly records $61.16, and the receipt no longer matches the charge.
How does receipt OCR differ from invoice OCR?
Receipt OCR differs from invoice OCR in layout, paper and identifiers. A receipt is a short, narrow strip with one column of text, often printed on thermal paper that fades. It has no invoice number, no bill-to address and often no vendor tax ID. Invoices are full pages with labelled fields and a reference number to match against.
Layout. An invoice has a header block, a bill-to block, a table of line items and a totals block. Software can learn where each block sits. A receipt is one column, top to bottom, with item names abbreviated to fit a narrow printer. "GRLD FISH" and "HS SLD" are typical. Line items are harder to read and rarely worth extracting for bookkeeping.
Paper. Many receipts are printed on heat-sensitive thermal paper. A 1996 National Archives bulletin on thermal paper, now kept as a historical reference, said such papers are sensitive to heat and light and that their images are extremely unstable. A faded receipt gives OCR pale grey text on an off-white background, which is harder to separate than black print on white paper.
Identifiers. An invoice number lets software spot the same invoice arriving twice. A receipt has no equivalent. Duplicate detection has to compare merchant, date, time and total together, and two genuine purchases at the same coffee shop on the same morning can look alike.
Dictionaries. General OCR engines favour real words. The Tesseract guide to improving quality notes that for text such as receipts and price lists, turning off its built-in word lists can help, because abbreviations and codes are not dictionary words.
Invoice OCR has its own approaches, from fixed templates per vendor to layout-aware models; the post on template-based versus layout-aware invoice OCR compares them.
Receipt OCR API or a scanner app for firm work?
A receipt OCR API suits a firm that has developers and wants receipt data inside its own software. A scanner app or upload tool suits a firm that wants staff and clients to send receipts and get a spreadsheet back. Most accounting firms are in the second group, because the hard part is collection, not code.
A receipt OCR API is a web service that accepts an image and returns the extracted fields, usually as structured data. The firm's own code sends each image, stores the response and handles errors. That is a good fit when the firm already runs an internal system and wants receipts to flow into it, or when it processes receipts at a volume that justifies building around them.
An API leaves several jobs to the firm:
- Collecting the images from clients in the first place.
- Keeping each client's receipts separate.
- Deciding what to do when a field comes back empty or uncertain.
- Spotting duplicates across uploads.
- Producing a file a bookkeeper can review.
Open-source OCR is the do-it-yourself end of the same choice. The Tesseract command-line documentation shows that it can output plain text, hOCR or TSV, which includes the position of each word. That gives a developer raw text and coordinates, not merchant, total and tip. Every field-labelling rule above would still have to be written.
A scanner app or upload tool handles the collection and review side. The questions that matter for firm use, such as separate folders per client and an export the firm can check, are covered in the post on choosing a receipt scanner for accountants.
Receipt totals, tips and tax: where receipt OCR misreads amounts
Receipt OCR misreads amounts in three predictable ways: it takes the subtotal or the printed total as the amount paid, it misses a tip written in after printing, and it splits tax out of prices that already include it. Each one produces a number that is real but wrong, which makes it hard to spot.
Subtotal taken as total. Subtotal and total sit a line or two apart, in the same font, with similar values. If the total line is faded, creased or cut off at the bottom of the photo, software may fall back to the nearest amount it can read. Checking that subtotal plus tax equals total catches most of these, and a careful tool runs that check itself.
Tip added after printing. On restaurant, bar and taxi receipts, the printed total is often the pre-tip amount. The tip and the final total are written by hand on blank lines, as in the example above. OCR engines trained on print read handwriting poorly. The result is a receipt recorded at the pre-tip amount and a card charge that is higher. When a receipt has a TIP line, a person should look at it.
Tax-inclusive prices. Some receipts show prices that already include tax and print the tax portion as a note, such as "Includes tax 1.52". Software that adds that figure to the total double-counts the tax.
Other amounts that look like totals. "Amount tendered" and "Change due" on a cash receipt, "You saved" on a discount receipt, and a loyalty balance near the bottom can all be mistaken for the total. So can a second copy of the total printed for the card slip.
Foreign formats. A comma used as the decimal separator, as in 61,16, can be read as sixty-one thousand sixteen. A date like 03/10/2026 means 3 October in many countries.
Most of these errors get worse with a poor photo. The checklist in the post on receipt photo quality for clients covers how to get a capture that keeps the bottom lines readable. Clients who send a whole camera roll at once create a sorting job before any of this begins; sorting phone photos of receipts by client, month and vendor covers that step.
Reading client receipts with Schema CPA
Schema CPA reads client receipts as part of its expenses category, alongside vendor invoices. Receipts arrive through the client's single upload link, whether as phone photos, email attachments or scanned PDFs, and each page is classified with the rest of that client's documents. The extracted rows export to Excel or CSV for review.
A receipt rarely arrives alone. It comes in a batch with bank statements, a W-2 and a credit card statement, and the first job is knowing which pages are receipts at all. Schema CPA sorts each page by document type, issuer and period, so a 30-page upload becomes a list of what it contains. A receipt photographed twice, or emailed and then uploaded, is flagged as a duplicate rather than counted again.
The export is a spreadsheet, so the checks from this post can run as formulas: subtotal plus tax against total, and receipt totals against the card statement for the same month. The document categories on the homepage list every type Schema CPA reads. It does not decide how an expense should be treated for tax; that remains the firm's call.