How to embed receipt OCR in an expense app

What you need before starting

Nothing exotic. A working expense-report or expense-line data model already in your product (even a simple one), a sample of real historical receipts — ideally including some rough phone photos, not just clean scans — and someone with the authority to sign off on a per-page cost line once the budget math in step 1 is done. No data-science background is required on your side; the extraction and structuring work happens entirely on the API side of the integration.

If your platform also handles card or bank statements, pulling together a sample of a few real statement PDFs at this stage saves a step later, since step 6 covers extending the same integration to cover them.

Before any integration work starts, put a real number on both sides. A first-year in-house build — labeled training data, engineering time, a review UI, and the first year of ongoing model maintenance — commonly lands in a $120,000–$160,000 range, not counting the opportunity cost of the engineering time spent on OCR instead of your product's actual differentiators. Against that, a flat €0.035 per page has a knowable monthly cost at any volume, worked through concretely in step 3 of this guide and in the API overview's cost section.

This decision is easiest to make honestly when it's framed as opportunity cost, not just direct spend: what else could the engineering team building and maintaining an in-house OCR pipeline be building instead, for a product whose actual value proposition probably isn't "we wrote our own receipt parser".

Write the comparison down as an actual short document, with the real numbers, shared with whoever needs to sign off. Teams that skip this and integrate first tend to revisit the same debate informally two or three times over the following months; teams that settle it explicitly at the start generally don't.

A free plan API key processes real documents at full accuracy against a smaller monthly allowance — there's no separate "demo mode" with different results than production. Before writing any integration code, pull a representative sample of your own historical receipts — a mix of clean scans and rough phone photos, several currencies if your users are international — and run them through POST /extract directly.

curl -X POST https://flowparse.io/api/v1/extract \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "file=@receipt.jpg"

Compare the returned fields against what you already know about each receipt. This step exists specifically to build confidence in accuracy on your own real document mix before any engineering commitment is made to the integration itself.

Most expense platforms already have a data model for an expense line — amount, date, merchant, category, currency. Mapping merchant_name, total, date, currency and line_items onto that existing schema is usually the fastest part of this whole integration — often under a day for a team already familiar with their own schema.

Most receipts entering an expense app are phone photos, not scans — angled, sometimes shadowed, on paper that curls or has already started to fade. Rather than assuming an idealized flatbed-scan input, design the capture UI to nudge good-enough photos (flat surface, decent light, whole receipt in frame) without demanding scanner-quality input the extraction pipeline doesn't actually need.

flowparse.io

Every extraction returns a confidence signal alongside the data. The single most common integration mistake — covered in more depth in the mistakes section below — is skipping a review path and trusting every result equally. Instead, route only results below a threshold you choose to a quick human-confirmation step, leaving the large majority of clean extractions fully automatic.

Once receipt extraction is stable, most platforms add card or bank statement extraction next — turning a monthly statement PDF into transaction rows, then matching each submitted receipt to the transaction it explains. The feature page on line-item matching covers the matching logic in detail; this step is about sequencing it correctly after receipts are already working well.

For a platform with an international user base, currency and language handling isn't optional from day one. The API returns the currency and totals exactly as printed on the receipt — a hotel folio in euros stays in euros — leaving conversion to a reporting currency to your own exchange-rate logic, applied at whatever point in your workflow makes sense (submission time, approval time, or export time, depending on how your platform already handles multi-currency expenses).

Launch isn't the end of this integration. Two things are worth tracking on an ongoing basis: the rate of low-confidence flags over time (a rising rate can indicate a new receipt format your review process hasn't adapted to), and actual monthly spend against the budget built in step 1, readable directly from GET /usage.

A simple weekly or monthly internal dashboard — total pages processed, current spend, low-confidence rate — is usually enough; this doesn't need a dedicated observability system, just a habit of actually looking at the numbers rather than assuming the integration keeps working exactly as it did on launch day.

flowparse.io

Who should own each step internally

Steps 1 and 8 — the cost decision and ongoing monitoring — are naturally shared between engineering and finance, since one estimates and builds while the other approves and tracks the resulting budget line. Steps 2 through 6, the actual integration work, sit squarely with engineering and usually don't need product or design input beyond reviewing the capture-flow and review-UI mockups that come out of steps 4 and 5. Step 7's currency handling is worth a quick check-in with whoever owns your platform's existing multi-currency logic, if you have any, so the two systems agree on conversion timing and source.

For a small team, one engineer can realistically own the whole integration end to end — nothing here requires a dedicated project manager or a cross-functional working group, which is itself part of why this integration is faster than most teams expect going in.

A note on data residency and regulatory requirements

An expense platform serving customers in regulated industries or specific jurisdictions sometimes has data-residency or processing-location requirements that need confirming before any document leaves your own infrastructure. This is worth checking early — during step 1's evaluation, not after a production integration is already built — by reviewing the current data-handling and infrastructure details on the security pageagainst your own compliance requirements or your customers' specific contractual terms.

For most expense-management use cases this isn't a blocker, but for a platform selling into specific regulated sectors, it's the kind of question worth a five-minute check before writing any integration code rather than discovering an issue during a customer's security review much later.

A full worked integration, start to finish

A five-person team at a mid-stage spend-platform startup, currently doing manual receipt entry for 600 active users, decides to automate. Volume estimate: 15 receipts/user/month at roughly 1 page each, plus one 3-page statement per user per month.

Estimated monthly cost at this volume: 600 × 15 × 1 = 9,000 receipt pages plus 600 × 3 = 1,800 statement pages, 10,800 pages total, roughly €378 a month — against the engineering time previously spent on manual review and correction, this typically pays for itself well inside the first month.

By the end of week 4, the team has replaced a fully manual process with one that only routes genuinely ambiguous cases to a human — commonly somewhere in the low single-digit percentage of total volume, depending on the mix of scan quality and receipt formats in a given user base. The remaining manual work is a fraction of what it was, and it's concentrated on the cases that actually need judgment rather than spread evenly across every single receipt submitted.

Common mistakes in this integration

Best practices for a durable integration

How long each step takes

A printable checklist

Who this guide is for

Product and engineering teams at an expense-management, spend-platform or procurement SaaS company adding or replacing receipt-and-statement recognition — whether this is the first version of the capability or a migration off an existing vendor.

Scaling from a pilot to full production volume

Nothing about this integration changes structurally between a 600-user pilot and a 100,000-user production rollout — the flat per-page rate and the same API surface apply at any volume. What does change is the value of the monitoring built in step 8: at higher volume, a small percentage low-confidence rate represents a much larger absolute number of receipts, making the review-queue capacity worth revisiting as usage grows.

One thing genuinely does need revisiting at scale that doesn't at a pilot: the review-queue staffing itself. A 2% low-confidence rate on 600 receipts a month is roughly 12 documents someone glances at; the same 2% rate on 100,000 receipts a month is 2,000 documents, which needs an actual staffed process rather than an engineer checking a queue between other work. Planning for that transition before volume forces it is the main structural change scale introduces.

A short glossary

One habit worth keeping after launch

Revisit the low-confidence rate and the actual monthly spend once a month, even after the integration feels finished. Both numbers are cheap to check and are the earliest signal that something in your receipt mix — a new merchant format, a new region, a volume spike — has changed since launch.

Frequently asked questions

Keep reading