Bank Statement OCR API — Read Scanned Statements

Send a scan, get JSON

Base64-encode the scanned PDF or image (PNG/JPG) and POST it. The `filename` helps the engine detect the type, but the OCR path triggers automatically whenever a page has no text layer. Get your key from the API dashboard.

curl -X POST https://flowparse.io/api/v1/extract \
  -H "Authorization: Bearer pf_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "file": "iVBORw0KGgoAAA...", "filename": "statement-scan.png" }'

flowparse.io

Scanned in, structured out

A scanned page returns exactly the structure a digital PDF does — so your code path is identical regardless of source quality.

{
  "type": "bank_statement",
  "pages": 2,
  "billedPages": 2,
  "data": {
    "type": "bank_statement",
    "data": {
      "bank_name": "First National",
      "currency": "USD",
      "opening_balance": 2010.00,
      "closing_balance": 3145.20,
      "transactions": [
        { "date": "2024-09-04", "description": "ACH DEPOSIT PAYROLL", "amount": 1850.00, "balance": 3860.00 },
        { "date": "2024-09-09", "description": "CARD 1124 GROCERY",    "amount": -64.80, "balance": 3795.20 }
      ]
    }
  }
}

How OCR accuracy is protected

OCR introduces a failure mode digital parsing doesn't: a misread digit. FlowParse guards against it with the same deterministic check it uses everywhere — opening balance plus the sum of transactions must equal the closing balance. On a scanned statement that equation is a powerful integrity test: if a single amount was misread, the running balance won't reconcile and the row is flagged.

Send any OCR result to `POST /api/v1/validate` to get a 0–100 score plus specific checks, then branch on the grade. Clean scans pass straight through; ambiguous ones (faint print, skewed photos) get queued for a quick human glance. This is how teams run OCR at volume without quietly importing wrong numbers — the validation engine describes every rule.

flowparse.io

Getting the best OCR results

What happens to a scanned page

flowparse.io

Scanned statements into accounting files

Once a scan is structured and validated, it's a first-class statement: pass it to `POST /api/v1/export` to produce a QuickBooks/Quicken bank feed (`.QBO`/`.QFX`/`.OFX`, OFX 1.0.2 with FITID de-duplication), a Xero/CSV import, or an XLSX. That means a folder of photographed statements can become clean, importable accounting data with two API calls each. See PDF to QBO and scanned bank statement to Excel for the same flow in the app.

Pricing and limits

Scanned extraction is billed per page, like any extraction, from your page balance; validation and export previews are free. Over-budget requests return `429` with the exact shortfall — no surprise charges. Files up to 20 MB and multi-page scans are supported; for large batches, extract each then merge. Plans and the per-page rate are on the pricing page; the full reference and live examples are in the API docs.

Where a statement OCR API fits

Why hybrid beats pure OCR

Most OCR APIs treat every page the same way: rasterise it and recognise characters. That's wasteful and lossy when a page already has a perfect text layer, because OCR can only ever approximate what's printed, while the embedded text is exact. FlowParse takes a hybrid approach — it checks each page for a text layer and reads digital pages directly from their geometry (zero OCR error), reserving AI OCR for the pages that are genuinely images. On a statement that mixes a digital cover page with photographed inserts, you get the best available method per page from a single call.

This matters most for accuracy on the numbers that count. A misread `8` as a `3` in an amount is the kind of error that quietly corrupts a ledger, so the fewer characters you OCR, the fewer chances there are to get one wrong. By only OCR-ing what truly needs it and validating the result against the balance equation, the hybrid pipeline keeps scanned-statement accuracy far closer to digital than a brute-force OCR step ever could. When a clean digital PDF exists, sending it instead of a photo is always the most accurate — and cheapest-to-trust — option.

flowparse.io

Status codes and limits

OCR adds one error path the digital flow doesn't: an unreadable scan. If no text can be recovered the API returns `422` and the call isn't billed for a file, so you can safely prompt the user to re-scan at higher quality. Otherwise the codes are the same across the API — `200` success, `400` for a malformed request, `401` for a bad key, `429` when the page budget is exhausted (with the exact shortfall), and `503` for a transient issue to retry with backoff. No call ever returns unbilled data.

Scanned PDFs and images up to 20 MB are supported, multi-page included. OCR is billed per page like any extraction, from your page balance; validation and previews are free, so you can prove out scan quality and the validation gate before spending anything. For big archives, extract each scan — parallelised across workers with a concurrency cap — then consolidate with Smart Merge. Plans and the per-page rate are on the pricing page.

Integrating scanned-document capture

Scanned input usually arrives through channels you don't fully control — a customer emails a phone photo, a branch scans a page, a mailroom digitises a batch — so the integration needs to be forgiving. The call itself is the same plain-JSON POST as any extraction: base64-encode the image or scanned PDF, send it to `/api/v1/extract`, read the structured `data`. What changes is the surrounding flow: because scan quality varies, you should always pair extraction with a validation gate and a clear path for the cases that need a human, rather than assuming every scan is perfect.

At volume, run capture behind a queue with worker processes that call extract, then validate, then either auto-accept on a good grade or route the document to a small review queue. Keep jobs idempotent on a file hash so a re-sent photo doesn't create a duplicate, cap worker concurrency so a big import can't drain your page budget at once, and handle a `429` by pausing and resuming after a top-up. This is the same robust shape as the digital flow — the only addition is that you expect a slightly higher review rate for genuinely poor scans, and you design the UI so a reviewer can fix a flagged row in seconds.

Because the output schema is identical to a digital statement, none of your downstream code needs to know whether a document was scanned or digital. The same rows feed your ledger, the same reconciliation engine matches payments, and the same export produces accounting files. Scanned capture becomes just another source into one consistent pipeline.

flowparse.io

Best practices for OCR at volume

Three practices separate a reliable OCR integration from a fragile one. First, capture quality matters more than any setting: nudge users toward 300 DPI scans or sharp, well-lit, deskewed photos, and crop to the page where you can — every bit of clarity directly reduces digit errors. Second, prefer the original digital PDF whenever one exists; OCR is for when there is genuinely no text layer, not a default. Third, never skip validation on scanned output — the balance-reconciliation check is your single best defence against a silent misread, so gate auto-acceptance on the score and review the rest.

Operationally, treat scanned extraction like any billed call: it's per page, so cap concurrency for predictable spend, log `billedPages` and the validation grade with every document for a clean audit trail, and build and test the whole flow for free against validation and previews before enabling billed extraction. For an archive of historical scans, extract each then consolidate with Smart Merge into one reconciled workbook. These habits let you process photographed and faxed statements at scale with the same confidence as clean PDFs.

Monitoring usage and controlling cost

Running extraction at volume means watching two things: spend and quality. Every API key tracks its own request count, page total and cost, visible in the dashboard, so you can see exactly what each integration or customer is consuming and spot anomalies — a sudden spike usually means a retry loop or a malformed batch. Setting a budget that matches your plan, and capping worker concurrency so a single run can't exhaust it, keeps cost predictable rather than surprising.

On the quality side, log the validation grade and `billedPages` with every document and chart the auto-accept rate over time. A falling auto-accept rate is an early signal that input quality has dropped — a new scanner, a worse photo flow, a new bank format — and lets you act before bad data reaches the books. Together these two habits turn the API from a black box into an observable, controllable part of your pipeline; the per-page rate and plan limits are on the pricing page.

flowparse.io

Build it end to end

Start with a key from the dashboard, send one scanned page to `/api/v1/extract`, and confirm the JSON and the validation score. For the full integration — batching, error handling, exporting and reconciliation — follow the guide to parsing bank statements with an API. For digital documents and the generic schema, see the bank statement API, PDF to JSON API and document extraction API.

flowparse.io

Frequently asked questions

Related