DOCUMENT TYPES
Receipt data extraction
By Sygnet Research. Written by Sygnet, sourced, checked before publication.
A receipt is a short proof-of-purchase document, usually thermal-printed or emailed as a PDF, issued by a retailer, restaurant, or service provider at the point of sale. Employees, finance teams, and expense systems process them to reimburse spending, reconcile accounts, and support tax deductions. Automated extraction pulls the merchant, amounts, and line items into structured data without anyone retyping a faded slip of paper, which matters because receipts arrive in volume and get lost fast. Done well, it also flags fraud and duplicate claims before they hit the books.
Fields to extract
| Field | Format / example | Validation check |
|---|---|---|
| Merchant name | "Café Lumière" | Match against known vendor list or business registry |
| Merchant tax ID | FR 12 345 678 901 | Format and checksum validation (see SIREN and SIRET) |
| Transaction date | 2024-03-14 | Not in the future; within expense policy window |
| Transaction time | 13:42 | Plausible business hours for merchant type |
| Receipt number | #00457812 | Non-empty, unique per merchant per day |
| Line items | "Espresso x2 – €5.60" | Sum of line items reconciles with subtotal |
| Subtotal | €42.10 | Subtotal + tax = total |
| Tax amount | €4.21 (TVA 10%) | Tax rate plausible for jurisdiction and category |
| Total amount | €46.31 | Matches payment card slip if attached |
| Currency | EUR | Consistent with merchant country |
| Payment method | Visa •••• 4021 | Matches expense report payment method |
| Category | Meals, Travel, Supplies | Present in approved category list |
| Tip amount | €3.00 | Within policy limit, if applicable |
| Card last 4 digits | 4021 | Matches employee's registered card |
Why this document is hard to process
Receipts are the messiest document type most finance teams handle. Thermal printer output fades within months, and by the time an expense report gets filed, half the ink is gone. Layouts vary wildly: a supermarket receipt lists forty items in a dense grid, while a taxi receipt has three lines and a stamp. Photos taken with a phone add glare, skew, and cropped edges. Many receipts arrive as PDFs from online orders instead of paper, doubling the format variety a system must handle.
Language and currency add another layer: an employee traveling abroad submits a receipt in Japanese with yen totals, and the same extraction pipeline needs to handle that alongside a French boulangerie slip. Handwritten additions (a scribbled tip, a corrected total) confuse naive OCR. Multi-page receipts, like itemized hotel folios, need line items linked back to the correct total across pages.
Fraud is a real concern too: altered totals, duplicated submissions, and increasingly, AI-generated fake receipts that look convincing at a glance but fail on metadata or arithmetic checks. A system built only on pattern matching from clean templates breaks the moment a receipt looks slightly unusual, which is most of them. This is why raw OCR vs VLM approaches perform so differently on receipts compared to structured invoices.
How Sygnet processes it
Sygnet starts by classifying the document (receipt, invoice, or something else) before running extraction, so downstream logic applies the right schema. Field values come with a confidence score per field, not just per document, so a fuzzy total gets flagged even if the merchant name is crystal clear. Every extracted value carries bounding-box provenance, meaning you can click a field in the output and see exactly where it appeared on the source image, which matters when an auditor asks how a number was derived (see field-level provenance).
Validation rules run automatically: arithmetic checks, date sanity, tax-rate plausibility, and cross-document checks against the linked expense report or purchase order. Low-confidence fields, damaged scans, or receipts that fail a validation rule get routed to human review; everything else flows straight through. This selective human-in-the-loop model keeps throughput high without pretending every blurry photo is machine-readable. The same architecture underlies Sygnet's invoice data extraction, adapted here for the shorter, noisier structure typical of receipts.
Validation rules worth applying
- Confirm subtotal plus tax equals the printed total, within rounding tolerance.
- Check the tax ID format and checksum against the merchant's country (SIREN and SIRET for France).
- Flag receipts dated in the future or older than the expense policy allows.
- Cross-check the payment method and last four card digits against the employee's registered card.
- Detect duplicate receipt numbers or amounts submitted more than once.
- Compare tax rate to plausible rates for the merchant's jurisdiction and category.
- Run basic document fraud detection: check for inconsistent fonts, mismatched metadata, or signs of digital alteration.
FAQ
Can Sygnet handle receipts photographed on a phone?
Yes. The system is built to handle skew, glare, and partial crops common in phone photos, not just flatbed scans. Confidence scores drop when image quality genuinely limits legibility, and those cases route to human review rather than guessing. Accuracy depends more on print condition than on capture method.
How does Sygnet detect fake or altered receipts?
It combines arithmetic and metadata checks (does the total match the line items, does the tax rate fit the jurisdiction) with pattern analysis on the document itself. This catches both crude edits and more convincing AI-generated fakes, which often fail subtle consistency checks even when they look clean visually.
Does this integrate with expense management systems?
Yes, through structured output and webhooks that push validated data into your expense or ERP system as it clears. Idempotency keys prevent duplicate submissions from creating duplicate reimbursements, which is a common failure mode when employees resubmit receipts after an error.
NEXT STEP
See it on your own documents
One email when we publish something worth your time.