Receipt OCR can turn photographed or scanned receipts into structured expense data, but extracted values should be validated before they reach accounting, reimbursement, or reporting systems. This checklist explains how to check merchant, date, currency, subtotal, tax, tip, total, and line items; when to route an item for human review; and how to design a reusable validation workflow.
Overview
Receipt OCR data extraction is not the same as financial validation. An OCR API may correctly identify characters while still assigning a value to the wrong field, confusing a subtotal with a total, or missing a decimal point in a low-quality image. Validation adds business rules and context around the extracted text.
A practical workflow usually has five stages:
- Extract: Send the receipt image or PDF to a receipt OCR API and receive text, fields, coordinates, and—if supported—confidence information.
- Normalize: Standardize dates, currency codes, decimal separators, signs, and merchant names without discarding the original OCR output.
- Validate: Apply field-level rules, arithmetic checks, policy checks, and duplicate detection.
- Route: Automatically accept reliable records, hold exceptions, and send ambiguous cases to a reviewer.
- Record: Store the source receipt, extracted values, validation results, corrections, and reviewer decisions for later reconciliation.
Keep the raw image and original extracted text alongside the normalized record. This makes corrections traceable and gives reviewers enough context to resolve an exception without reprocessing the entire receipt. For broader implementation guidance, see this OCR API integration guide for image and PDF text extraction.
Checklist by scenario
Use the following field-validation table as a starting point. Rules should be adjusted for the receipt formats, countries, currencies, and expense policies in your workflow.
| Field | Validation checks | Typical review triggers |
|---|---|---|
| Merchant | Check that the name is present, readable, and not confused with a payment processor or store location. Normalize spacing and capitalization while retaining the original value. | Blank name, unusually short text, a name made mostly of symbols, or a mismatch with a known merchant record. |
| Date | Parse the date using the expected regional format. Confirm that it is a plausible transaction date and not a printed return, authorization, or loyalty-program date. | Ambiguous day and month order, future date, missing year, or a date outside the expense-reporting period. |
| Currency | Identify the currency from an explicit symbol, code, receipt context, or configured user location. Store the currency separately from the numeric amount. | Unrecognized symbol, multiple currencies, conflicting account settings, or a conversion requirement that has not been defined. |
| Subtotal | Compare the subtotal with line-item amounts when line items are available. Confirm that it is not the same printed value as the total unless tax and other charges are zero or absent. | Subtotal is greater than total, cannot be reconciled, or appears in a visually unclear section. |
| Tax | Check whether tax is present, absent, included, or split into multiple amounts. Use arithmetic validation rather than assuming one universal tax format. | Tax does not reconcile with the receipt totals, multiple tax fields are merged, or the tax rate is unexpected for the configured region. |
| Tip | Look for tip, gratuity, service charge, or similar labels. Keep tips and service charges distinct when the accounting system treats them differently. | Tip is mistaken for tax, handwritten tip is unreadable, or the tip appears after a revised total. |
| Total | Confirm the final amount is present and compare it with subtotal, tax, tip, discounts, fees, and rounding adjustments. | Total is missing, appears more than once, is lower than a component, or fails the arithmetic tolerance. |
| Line items | Check item descriptions, quantities, unit prices, discounts, and extended amounts. Treat line-item extraction as optional if the use case only requires the payable total. | Rows are merged, quantities are confused with prices, negative discounts are lost, or line items do not add up. |
Scenario: a clean receipt for straight-through processing
Automatically accept a receipt only when required fields are present, confidence signals meet your configured thresholds, arithmetic checks pass, and no duplicate or policy exception is detected. A threshold is a workflow choice, not a universal accuracy guarantee. Set it using representative receipts and measure both false approvals and unnecessary reviews.
Scenario: a low-quality image
Before rejecting the record, try a controlled preprocessing step such as rotation correction, cropping, contrast adjustment, or removal of excess background. Preserve the original image and record which processing step was used. If the result remains uncertain, route it to a reviewer rather than guessing at a financial value.
Scenario: handwritten additions or revised totals
Handwritten tips, manual discounts, and amended totals deserve a separate path because they may be harder to distinguish from printed content. Require a reviewer to confirm the final payable amount when handwriting affects the total or when two competing totals are visible.
Scenario: a receipt with multiple currencies or tax types
Do not force every amount into one currency or one tax field. Capture each identifiable amount with its label and currency, then apply a documented conversion or accounting rule. If the destination system supports only one value, pause the record until the conversion basis is available.
What to double-check
Arithmetic consistency
Use a configurable reconciliation rule such as: subtotal minus discounts, plus tax, tip, fees, and rounding adjustments should equal the final total within an allowed tolerance. The tolerance should reflect the currency’s precision and the way the source receipt rounds values. Never silently overwrite a value simply because the equation fails; flag the discrepancy and retain the evidence.
Confidence versus business risk
Confidence scores can help prioritize review, but they should not be the only decision input. A high-confidence total may still be the wrong total if the receipt contains several amounts. Conversely, a low-confidence merchant name may not matter if the total and date are reliable for the intended workflow. Assign stricter controls to fields that affect payment, tax treatment, reimbursement, or fraud detection.
Duplicate receipts
Compare combinations such as merchant, date, currency, total, receipt identifier, image hash, and employee or cardholder. Exact matching is useful but insufficient: the same receipt may be uploaded with a different crop or filename. Treat near matches as review candidates, especially when the transaction amount and date are the same.
Human-review routing
A useful exception record tells the reviewer what failed and why. Include the receipt image, extracted value, confidence or evidence location, failed rule, suggested correction, and a clear accept-or-edit action. A simple exception template can include:
- Record ID: unique receipt or expense identifier
- Failed rule: for example, total does not reconcile
- Fields affected: subtotal, tax, tip, and total
- OCR output: original extracted values
- Reviewer decision: accept, correct, reject, or request a new image
- Reason: short explanation retained for audit and workflow improvement
For a broader approach to measuring extraction quality on real documents, use the OCR accuracy testing and benchmarking framework as a companion checklist.
Common mistakes
- Sending raw OCR output directly to accounting: Extraction should be separated from posting. Add validation and an exception state between the OCR API and the destination system.
- Assuming the largest number is the total: Receipts often contain subtotal, tax, savings, payment, change, and balance values. Use labels, layout, and arithmetic together.
- Discarding source evidence: Keep the original image, raw response, normalized record, and correction history according to your organization’s retention requirements.
- Using one threshold for every field: Merchant, date, tax, and total have different business consequences. Apply field-specific confidence and review rules.
- Ignoring regional formats: Decimal separators, date order, currency symbols, tax labels, and receipt layouts vary. Test with the document types your workflow actually receives.
- Making line items mandatory unnecessarily: If the business only needs merchant, date, and total, requiring perfect line-item extraction can create avoidable review volume.
- Failing to measure reviewer corrections: Track recurring errors by field, merchant format, image quality, and language. Use those findings to improve capture instructions, preprocessing, and rules.
When to revisit
Review this workflow before seasonal planning cycles, monthly or quarterly reconciliation, and any change to expense policy or accounting integration. Revisit it sooner when the receipt OCR API, preprocessing pipeline, destination schema, or human-review tool changes.
Also test the rules when your organization expands into a new region, adds currencies, introduces new tax treatments, or begins accepting new receipt formats such as emailed PDFs and mobile screenshots. Maintain a small validation set containing clean receipts, difficult images, handwritten additions, multiple tax patterns, duplicate uploads, and receipts with missing fields. Re-run it after configuration changes and compare field-level accuracy, exception rates, duplicate detection, and reviewer corrections.
As a practical next step, document your required fields, define field-specific acceptance thresholds, implement arithmetic and duplicate checks, and create one review queue for exceptions. Then process a representative sample before enabling automatic posting. If you are selecting or changing an OCR API, compare accuracy, error handling, security requirements, and processing cost together; the OCR API comparison checklist for invoices and receipts can help structure that evaluation.
