Bank statement API for treasury platforms

What the API actually does

One endpoint, POST /extract, accepts a bank or card statement PDF or scan and returns a classified, structured, validated result — the account, its currency, the statement period, opening and closing balances, and every transaction as a signed, dated, described row. There is no separate configuration step per bank and, critically for a platform serving many corporate clients, no configuration step per client or entity.

{
  "type": "bank_statement",
  "pages": 3,
  "data": {
    "bank_name": "DBS Bank",
    "account_last4": "7734",
    "currency": "SGD",
    "period": { "start": "2026-08-01", "end": "2026-08-31" },
    "opening_balance": 412880.00,
    "closing_balance": 468212.55,
    "transactions": [
      { "date": "2026-08-04", "description": "INTERCO TRANSFER - APAC HOLDCO", "amount": 82000.00 },
      { "date": "2026-08-11", "description": "SUPPLIER PAYMENT - REGIONAL LOGISTICS", "amount": -18420.10 }
    ],
    "balance_check": "passed"
  },
  "price": { "eur": 0.11, "perPageEur": 0.035 }
}

The specific accounts open banking doesn't reach

Three account types account for most of the gap a treasury platform runs into in practice. The first is geographic: open banking is a regulatory mandate in the EU, UK and a handful of other markets — it simply doesn't exist as a requirement across most of Africa, large parts of Asia and Latin America, and much of the Middle East, so a subsidiary banking locally in one of those markets has no aggregator route at all, regardless of how sophisticated the platform is.

The second is institutional: even inside a market with open banking regulation, a smaller regional or cooperative bank sometimes simply hasn't built the API, or built one with limited coverage that excludes the specific account type a corporate client actually holds. The third is organizational, not technical — a subsidiary's local finance team, a joint venture partner, or a newly acquired entity's controller declines to grant aggregator consent for policy, security review, or plain inertia reasons, and no amount of platform engineering fixes a consent decision made by a person outside the platform's control.

None of these three gaps close on their own as a treasury platform's connector library grows — a bigger library of live integrations helps with the second cause but does nothing for the first or third. A statement-extraction fallback is the one route that works regardless of which of the three is actually blocking a given account.

Multi-entity, multi-currency extraction

A treasury platform's actual data model is rarely one company with one bank account — it's a corporate group with dozens or hundreds of legal entities, each holding accounts at several banks, often in several currencies at once. The API is built around that shape from the start: every call is a single statement in, a single structured result out, tagged with whatever currency is printed on the document itself rather than any assumption about the client's reporting currency.

Nothing about the API needs to know the corporate hierarchy above an account — entity, subsidiary and group structure live entirely in your own platform's data model, the same way it already handles that structure for accounts arriving through a live feed. A statement from a Brazilian real account and one from a Japanese yen account are processed identically and independently; your platform is the layer that knows they both roll up into the same treasury desk's consolidated position.

flowparse.io

This is covered in full, with the request/response shape for a multi-entity batch, on the multi-entity cash position extraction feature page.

Balance validation across every account

A cash-visibility platform's entire value proposition rests on the position it shows being correct — a treasurer making a funding or investment decision off a wrong number is a real, costly mistake, not a cosmetic bug. Every statement's closing balance is checked against the sum of its own transactions before the result comes back; a statement that doesn't reconcile internally is flagged rather than folded silently into the consolidated position.

This matters more for fallback accounts specifically than it does for live-feed accounts, precisely because a live feed's numbers come from the bank's own system of record, while a PDF fallback's numbers come from a document that could, in principle, be a partial extract or an interim statement. Balance validation is what lets a platform trust a fallback account's number with the same confidence as a connected one's, rather than treating every PDF-sourced figure as inherently suspect.

flowparse.io

Pricing: flat €0.035 per page, at any volume

Every page — from any bank, any currency, any entity — bills at the same flat €0.035, with no enterprise tier to unlock before volume becomes economical and no per-client minimum. Full mechanics are on the flat-rate pricing page; for a treasury platform specifically, the relevant property is that fallback volume is inherently unpredictable — it depends entirely on how many of a given client's accounts happen to lack a live connection — and a flat rate means that unpredictability never turns into a pricing surprise.

This also removes a procurement friction many platforms run into with volume-tiered OCR vendors: a client with an unusually high share of unconnected foreign accounts doesn't suddenly cost the platform more per page than a client whose accounts are mostly live-fed — the rate is identical either way.

Turnaround at treasury-platform volume

A single statement typically returns in a few seconds. At batch scale — a full client roster's fallback accounts refreshed for a daily or weekly cash-position update — concurrent processing means turnaround is bounded by how many requests your own pipeline issues in parallel, not by a queue on FlowParse's side.

A worked example: onboarding a 40-account client

A mid-sized multinational client onboards onto a treasury platform with 40 bank accounts spread across 12 countries. Of those, 28 connect through live open-banking or aggregator feeds; the remaining 12 — three foreign subsidiaries banking locally, four accounts at smaller regional banks with no API, and five accounts where a subsidiary controller hasn't yet granted consent — need a PDF fallback for the platform to show a genuinely complete cash position from day one.

A little over a euro a month is what separates "28 of 40 accounts visible" from "a genuinely complete cash position" for this client — a gap that, without a fallback, shows up as a treasurer manually re-keying twelve statements every reporting cycle instead.

What kind of statements a treasury platform actually receives

Format is detected automatically on every call, so a platform's intake doesn't need to pre-sort clean digital exports from rougher scans before sending them — the API handles both through the same endpoint and tells you what it received.

flowparse.io

How to integrate into a cash-position engine

A full step-by-step walkthrough, including how to build the batch worker and review queue around this, is in the guide how to add a PDF statement fallback to a treasury platform.

flowparse.io

Feeding structured data into a treasury or ERP module

Structured JSON maps cleanly onto the fields a treasury data model already expects from a live feed — account, currency, period, opening/closing balance, and a transaction array — so a fallback result doesn't need a separate ingestion path from a connected account's data. Platforms built on top of an ERP's treasury module, or a standalone cash-management product, both see the same shape.

flowparse.io

Onboarding a new client entity without new engineering work

Because nothing about the API is configured per bank or per entity, onboarding a new client's fallback accounts requires zero extraction-side setup — no new bank template to build, no country- specific model to add. The only onboarding work is what a platform already does internally: mapping the new entity into its hierarchy and pointing the intake pipeline at its statements.

This is a meaningfully different growth model than expanding a connector library, where covering a new country or a new regional bank is itself an engineering project. A statement-based fallback scales flat across geography — the thousandth account's onboarding, regardless of which country its bank is in, looks exactly like the first's.

Where human review still belongs

Extraction removes the typing, not a treasury analyst's judgment — deciding whether an unusual intercompany transfer needs a note before the position is reported, catching a statement that looks like it's missing a page, flagging something worth a call to a subsidiary's local finance team. A confidence signal on every result is built to direct that limited attention efficiently, surfacing the small fraction of fallback statements that are genuinely ambiguous rather than asking a reviewer to re-check every one.

flowparse.io

Who this is built for

Common objections, answered honestly

"Our clients' foreign statements are too varied for an automated tool" is the most common objection, usually based on experience with an older, template-driven OCR tool tuned to a narrow list of domestic bank layouts. A classification-first pipeline built across a broad range of real statement formats, not a fixed bank list, is designed for exactly this variety — a Brazilian real statement and a Vietnamese dong statement are handled by the same generalized model, not a per-country template that has to be built and maintained separately.

A second objection is data security — sending a client's foreign subsidiary statements to a third party feels like added exposure on top of an already complex compliance picture. In practice, documents are processed and deleted shortly afterward, nothing uploaded is used to train models, and the API itself never stores an entity or client identifier — the security section later on this page covers what a platform's own compliance review will want to confirm.

A third, quieter objection is scope creep concern — a platform team worried that adding a fallback data source complicates an already careful data model. In practice, a validated result from this API is structurally identical to a live-feed transaction; the integration work is almost entirely in where the data enters the pipeline, not in how the rest of the platform treats it once it's in.

What changes as account coverage grows

Below a modest client base, many platforms tolerate a handful of manually maintained fallback accounts — a treasury analyst re-keying two or three statements a month is survivable. Past a certain client count, the math tends to flip: the number of unconnected accounts across a growing roster grows roughly with the number of clients and their geographic spread, while the extraction cost per account stays flat and small. Platforms serving multinational clients specifically — where every new client can bring several foreign subsidiaries with no live-feed option — are the ones most likely to see this threshold arrive early rather than late.

flowparse.io

Migrating away from manual PDF-to-spreadsheet fallback

Most platforms migrate gradually, running the API alongside an existing manual fallback process for a subset of clients first — commonly the clients with the highest count of unconnected accounts, since that's where the time savings show up fastest — before extending it platform-wide once the extracted output has been checked against a few cycles of known-correct manual entries.

Security and data handling

Full details are on the security page.

Get your API key

Run a real statement from one of your platform's currently-unconnected accounts through /extract and compare the output against what a treasury analyst would enter by hand. A free plan account uses the exact same accuracy as a paid one, just against a smaller monthly allowance.

Frequently asked questions

Keep reading