Solutions · Expenses
Receipt OCR and expense extraction
Thermal paper in, structured expense data out — merchant, date, totals, payment method and every line item.
Receipts are the worst documents anyone processes: narrow thermal paper, dot-matrix fonts, abbreviations, and they fade. Yet expense claims, VAT records and reimbursements all depend on reading them correctly.
Receipt extraction returns the fields an expense system wants — merchant, date and time, currency, subtotal, tax, total, payment method and itemised lines — ready to import rather than retype.
Measured on the format receipts actually use
We benchmarked the awkward case — 80mm thermal layout, condensed mono type — then the same slip faded, creased, photographed at an angle and shrunk to a phone crop.
Measured 2026-08-03
- Field accuracy
- 14 of 14 scored fields exact on our thermal-layout benchmark receipt — merchant, receipt number, date, time, currency, subtotal, tax, total, card payment and all five lines — and exact again under five degraded conditions. On an itemised A4 receipt with a unit-price column, a named customer and a 20% VAT line: 18 of 18.
- Dates read the way your region writes them
- The benchmark receipt wrote 02/08/2026 and it came back as August 2nd, not February 8th. Ambiguous dates are also exactly what the model flags for review when it cannot be sure — the honest behaviour, since a wrong-but-plausible date is the worst kind of error.
- Same engine, same checks as invoices
- Receipts run through the identical pipeline: schema-bound output, arithmetic validation on totals, a stated document type, and named low-confidence fields. One credit per receipt.
- Where your documents live
- Processed on our own servers in Frankfurt, Germany. Originals are deleted within an hour of processing, results within 30 days, and nothing is ever used to train models — ours or anyone else’s. The security page and DPA spell out the rest.
Method and raw results: how we measure. Every figure is dated and reproducible.
How you use it
- In the browser
- Drop a photo of a receipt on the extraction workbench — HEIC straight from an iPhone works, no conversion. Fields and checks come back in seconds.
- Over the API
- POST the image with type=receipt; JSON in the response. Batch a folder of receipts with a loop and a key from your dashboard.
- Into your expense flow
- The schema is fixed and documented, so mapping to your expense tool’s import is one afternoon, once.
What to know before you commit
The limits, stated here rather than discovered in your evaluation.
Faded thermal paper eventually beats everything. Thermal print disappears with heat and time. A receipt that is barely legible to you will be barely legible to the model — photograph receipts when they are fresh, and the low-confidence flags will tell you when a field deserves a second look.
Crumpled phone photos are about the camera, not the format. Perspective, shadow and focus cost accuracy on any document. Flatten the receipt, shoot from above, fill the frame — the difference is measurable.
Questions buyers ask
- Does it handle iPhone photos of receipts?
- Yes — HEIC is decoded server-side with no conversion step, a path we measured at 100% on our format benchmark. Photograph the receipt flat and well-lit for best results.
- Can it split items for VAT or category coding?
- Every line item returns separately with its amount, so category rules run on real lines rather than one lump total. VAT and subtotal come back as their own fields.
- What about receipts in Arabic or other scripts?
- The engine is multilingual. We publish per-script measurements on the language pages — check the honest figure for your script before committing a workflow to it.
- How do we try it on our own receipts?
- A free account plus a $15 credit pack gives you 2,000 OCR pages, API keys and enough to test a real batch. No subscription required.
Prefer a conversation first? Write to the people who built it
Related: Try the receipt scanner · Invoice OCR · The OCR API · API documentation