Receipt & statement extraction API for expense platforms

What the API actually returns

One endpoint, POST /extract, accepts a receipt, a statement or an invoice and returns a classified, structured result — the document type is detected automatically, so your integration doesn't need a separate upload flow per document type.

{
  "type": "receipt",
  "pages": 1,
  "data": {
    "merchant_name": "Blue Bottle Coffee",
    "date": "2026-08-14",
    "currency": "USD",
    "subtotal": 18.50,
    "tax": 1.62,
    "tip": 3.00,
    "total": 23.12,
    "payment_method": "VISA ...4471",
    "line_items": [
      { "description": "Cold Brew (L)", "quantity": 2, "unit_price": 5.50 },
      { "description": "Almond Croissant", "quantity": 1, "unit_price": 7.50 }
    ]
  },
  "price": { "eur": 0.035, "perPageEur": 0.035 }
}

Receipt extraction — the fields expense platforms need

Every field an approval workflow, a policy engine or a general-ledger export actually consumes is returned directly — not just raw OCR text that still needs a second parsing pass on your side. This matters more than it might first appear: a general OCR API hands back a block of unstructured text and leaves the work of finding the total, separating tax from tip, and identifying the merchant entirely to your own parsing logic — logic that then has to be maintained against every new receipt layout a merchant introduces. Classification and field extraction happening in the same call removes that entire layer of homegrown parsing from your codebase.

flowparse.io

Card and bank statement extraction

A spend platform's second recurring document, alongside the receipt, is the statement it reconciles receipts against — a corporate-card statement, a virtual-card provider's monthly export, or a connected bank account's PDF when no live feed exists. The same /extract call reads a multi-page statement and returns every transaction as a signed, dated, described row, with the statement's own closing balance checked against the sum of its transactions before the result is returned — see the bank statement API for the full schema.

For a spend platform specifically, this is what makes automated reconciliation possible in the first place: a receipt's merchant, date and amount can be matched against a statement line without a human comparing two PDFs side by side — the subject of the feature page on line-item matching linked throughout this page.

What building this in-house actually costs

A first-year in-house build for receipt-and-statement OCR — a labeled training set, a model (or a fine-tuned wrapper around a general OCR engine), a review UI for low-confidence results, and the engineering time to integrate and maintain it — commonly lands in a $120,000–$160,000 range before the product ships a v1, and that figure doesn't include the ongoing cost of the team that keeps accuracy from degrading as new receipt formats, banks and edge cases arrive.

The blog post linked at the end of this page, why expense-management SaaS stop building their own OCR, walks through this comparison in full, including the opportunity cost of the engineering time spent on OCR instead of the product's actual differentiators.

How FlowParse compares to Veryfi, Textract and Document AI

None of these figures are a criticism of those vendors — Textract and Document AI are general document-AI platforms with a much broader scope than receipts and statements, and Veryfi is a genuine receipt-OCR specialist. The comparison here is specifically about what an expense or spend platform needs: one call, one flat rate, both document types it actually receives, classified without extra client-side logic.

Pricing: flat €0.035 per page

Every page — receipt, statement or invoice — bills at the same flat €0.035, with no per-document-type premium and no complexity tier. A single-page receipt costs €0.035; a 4-page card statement costs €0.14. The full mechanics, including how a multi-format export in the same call is priced, are on the flat-rate pricing page.

For an expense platform specifically, this means the cost of processing a receipt is knowable before a single user uploads one — useful when deciding whether to pass the cost through as part of your own pricing tier or absorb it as an infrastructure cost.

Total cost of ownership over three years

A single year's comparison already favors embedding for most teams, but the gap widens further across a three-year horizon, which is the timeframe most infrastructure decisions are actually judged against internally. An in-house build's first-year cost — $120,000 to $160,000 — is followed by two more years of maintenance at $40,000 to $70,000 each, bringing a realistic three-year total to roughly $200,000 to $300,000 before accounting for the engineering time spent on it that could have gone toward the product itself.

An API-based approach spreads its cost as usage grows rather than front-loading it, and the per-page rate never resets or renegotiates upward on its own. For a platform growing from an early pilot to meaningful production volume over three years, the cumulative API cost commonly lands well below the in-house maintenance line alone, even before counting the avoided build cost — the worked volume-tier comparison later in this page makes that concrete with real numbers rather than a general claim.

There's a second, less obvious cost worth including in a three-year view: the cost of being wrong about accuracy. An in-house model that plateaus below the accuracy a finance team needs produces silent downstream costs — reimbursement errors, policy violations that slip through, hours spent manually correcting what should have been automatic — that rarely show up as a clean line item anywhere, but are real all the same.

How to integrate

A full walkthrough, including a worked mobile-capture example, is in the guide how to embed receipt OCR in an expense app.

A worked example: a mid-size expense platform's monthly cost

A spend platform with 4,000 active corporate cardholders, each submitting an average of 12 receipts a month (mostly single-page) plus one monthly card statement (average 3 pages), processes:

Against a $120,000+ in-house build plus a maintenance team, €2,100 a month at this volume — roughly €25,200 a year — is the entire extraction cost line, with no separate headcount required to keep it accurate as receipt formats change.

Accuracy and validation, not just OCR text

Raw OCR text is the easy 80% of this problem — reading the pixels. The harder 20%, and the part that actually determines whether a finance team trusts the data, is knowing whether a receipt's numbers are internally consistent: do the line items sum to the subtotal, does tax plus tip plus subtotal equal the printed total. Every extraction is checked against its own arithmetic before it comes back, and a document whose numbers don't reconcile is flagged rather than returned as if it were clean.

This distinction — reading pixels versus verifying the numbers they represent — is the specific gap that separates a general OCR wrapper from a purpose-built extraction pipeline, and it's usually the gap an in-house build underestimates most. A model can read "$23.12" off a receipt correctly and still be wrong about whether that's the actual total the merchant intended, if the line items above it don't add up. Catching that discrepancy before the data ever reaches a general ledger is what turns extraction into something a finance team can actually trust without spot-checking it manually.

flowparse.io

Mobile-capture receipts vs. clean PDFs

Most expense platforms receive receipts as phone photos, not scans — angled, shadowed, sometimes on curled thermal paper that's already started to fade. The extraction pipeline is built around that reality rather than an idealized flatbed-scan input, which matters specifically for a mobile capture-first product where a clean scan is the exception, not the rule.

Multi-currency and multi-language receipts

A distributed or international workforce produces receipts in whatever currency and language the merchant printed — a taxi receipt in Tokyo, a hotel folio in Frankfurt, a client dinner in São Paulo. The currency and totals actually printed on the document are returned as-is; conversion to a reporting currency happens on your side, against whichever exchange-rate source your platform already uses, rather than baked into the extraction itself.

Embedding without exposing FlowParse as a vendor

Nothing in the API response carries FlowParse branding, and the integration is API-only — there is no hosted UI your users are redirected to. That makes it straightforward to present the extraction step as your own product's capability, with FlowParse operating entirely as infrastructure underneath it. The satellite page embedded receipt extraction for spend management software goes deeper on the white-label embedding pattern specifically.

Who this is built for

Common objections, answered honestly

"We want extraction to be a core competency" is the most common internal objection to embedding rather than building, and it deserves a direct answer rather than a dismissal. For a company whose product genuinely is document intelligence, that instinct is correct. For an expense or spend platform, the actual core competency is almost always the workflow around the money — approvals, policy, reimbursement, reporting — not the OCR step that produces the raw data feeding that workflow. Being excellent at receipt recognition specifically is rarely what a customer is buying the platform for.

A second common objection is data control — the sense that sending documents to a third party means losing ownership of them. In practice, every extracted result belongs to your platform the moment it's returned; nothing about calling an API surrenders ownership of the data, and the security section later on this page covers exactly what happens to the original document afterward (deleted shortly after processing, never used for training).

A third objection, usually from engineering leadership specifically, is the sense that buying feels like admitting the team couldn't build it. That framing rarely survives contact with the actual cost numbers above — choosing not to spend $150,000 and a year of a senior engineer's time on a solved problem is a resourcing decision, not a capability judgment.

What this frees your roadmap to focus on

The most concrete way to evaluate this decision is to look at what an engineering team spends its next two quarters on in each scenario. Building in-house, a meaningful fraction of that time goes to labeling data, tuning a model, and building the review tooling around it — work that, once done, looks identical from a customer's perspective to simply calling an API that already does the same thing. Embedding, that same time goes toward the approval workflow, policy engine, reporting and integrations that a competitor evaluating your product would actually notice and compare.

This is the argument in its simplest form: extraction accuracy is table stakes, expected to just work, while the rest of an expense platform is where real differentiation happens. Spending scarce engineering time on the former instead of the latter is, for most teams at this stage, the more expensive choice even when it looks like the cheaper one on a spreadsheet that only counts direct spend.

Migrating from an existing OCR vendor

A platform already running on Veryfi, Textract or an in-house pipeline typically migrates one document type at a time — receipts first, since they're usually the higher volume and simpler schema, then statements once the receipt path is validated in production against a sample of real historical documents. Running both paths in parallel for a short period, comparing extracted fields on the same documents, is the most common way teams confirm accuracy before fully cutting over.

Security and data handling

Full details are on the security page.

Get your API key

Send a real receipt and a real statement through /extract and compare the fields against what your current pipeline — or your current vendor — returns. A free plan account uses the exact same accuracy as a paid one, just against a smaller monthly allowance.

Frequently asked questions

Keep reading