What "cash visibility" actually depends on
A cash-visibility tool's entire value proposition rests on one property: the position it shows is complete and current. That promise is easy to keep for the accounts a live feed reaches and quietly breaks for every account it doesn't — a foreign subsidiary, a smaller regional bank, an account whose owner hasn't granted aggregator consent. Ingestion, for the purposes of this page, is the pipeline that closes that gap: turning whatever PDF or scanned statement a team already has for an unconnected account into the same structured, validated shape a live feed produces.
This page focuses on the ingestion pipeline itself — the throughput, validation and format-coverage properties that matter once a cash-visibility product has accepted that some meaningful share of its accounts will always arrive as documents rather than live connections, and needs that path to be as reliable as the live-feed path it sits alongside.
What the API returns for an ingested statement
POST /extractaccepts a statement PDF or scan and returns every transaction as a signed, dated, described row, with the statement's printed opening and closing balance checked against the sum of those transactions before the result is returned — the same shape whether the statement is one page or twenty, and whichever currency it's denominated in.
The response also includes the bank name and account's last four digits when printed on the statement, along with the statement period, so a downstream cash-visibility dashboard can group and display results by account without a separate lookup step. Nothing about the response shape changes based on ingestion volume — the thousandth call in a session returns the same structure as the first.
Where a live-feed-only pipeline breaks
A cash-visibility tool designed around live connections alone typically has no ingestion story at all for the accounts a feed doesn't reach — those accounts simply don't appear, or appear as a manually maintained placeholder someone on the client's treasury team updates by hand. At a handful of accounts, this gap is invisible; once a client's footprint spans a dozen countries, it becomes the specific reason a "complete" cash position quietly isn't.
What high-quality ingestion needs specifically is an API a product's own pipeline can call concurrently, at whatever rate its infrastructure supports, producing results structurally identical to what a live feed already writes into the same dashboard — covered in the throughput section below.
Balance validation on every statement ingested
Every single statement — the first ingested and the ten-thousandth — gets the same treatment: transactions summed and checked against the printed closing balance before the result comes back. This is what lets a cash-visibility tool trust an ingested account's number with the same confidence as a live-fed account's, rather than treating every document-sourced figure as inherently less reliable.
At low ingestion volume, a team spot-checking a handful of statements by hand is a minor inconvenience. At thousands of pages a month, that same manual re-check would consume more time than the extraction itself — which is precisely why per-statement validation, not just per-statement extraction, is the property that actually makes high-volume ingestion trustworthy rather than merely fast.
Pricing that doesn't punish an unpredictable ingestion volume
The flat €0.035 per page holds at any scale — there is no enterprise negotiation required to unlock a lower rate at high volume, and no minimum monthly commitment. For a cash-visibility product whose ingestion volume depends entirely on how many of a given client's accounts lack a live connection — inherently unpredictable, and different for every client — this removes a real budgeting headache: this month's ingestion volume costs exactly what last month's did per page, with nothing to renegotiate as client mix shifts.
Full mechanics are on the pricing page; the rate quoted there is the rate at ten pages a month and at a hundred thousand.
Real throughput numbers
| Concurrency | Approx. pages/hour |
|---|---|
| 10 concurrent requests | ~9,000 pages/hour |
| 25 concurrent requests | ~22,000 pages/hour |
| 50 concurrent requests | ~45,000 pages/hour |
Figures are approximate and depend on document complexity and page count; the practical takeaway is that a modest concurrency setting clears an entire client base's fallback ingestion volume in well under an hour, leaving room for a daily or even intraday cash-position refresh rather than a once-a-month batch.
A worked example: 8,000 fallback pages a month
A cash-visibility tool serving a mix of mid-sized and larger corporate clients ingests roughly 8,000 fallback statement pages a month across accounts its live-feed connectors can't reach:
| Volume | Monthly cost | Annual cost |
|---|---|---|
| 8,000 pages/month | €280 | €3,360 |
Against the staffing cost of manually keying the same volume across a treasury-ops or customer- success team — multiple full-time roles at that page count — €3,360 a year is a small fraction of the equivalent labor cost, and it's the line item that lets the product genuinely claim complete coverage rather than a partial one.
Bank and layout coverage at ingestion scale
A cash-visibility tool serving a diverse client base rarely deals with just a handful of banks — dozens or hundreds of different banks, countries and statement layouts show up across a real ingestion pipeline. The extraction model generalizes across real-world statement structure rather than matching a fixed list of supported banks, so a client on a smaller regional or foreign bank is processed the same way as one on a major global bank, without a separate template needing to exist first.
This matters more than it might first appear at ingestion scale specifically, because a template-based tool's coverage gaps compound as client geography diversifies — a tool serving ten domestic clients might tolerate one unsupported bank; a tool serving clients across thirty countries almost certainly has dozens, and each one becomes a manual-processing exception that undermines the whole point of automating ingestion.
Why quality doesn't degrade as ingestion volume grows
Each statement is extracted and validated in complete isolation — there is no shared processing state, no queue-position effect, no accuracy curve that dips under load. Statement eight thousand of a monthly ingestion run gets exactly the same classification, extraction and balance-check logic as statement one. Volume changes how much a product pays and how long a run takes; it does not change per-document accuracy.
This is a meaningfully different guarantee than what a human review process can offer at the same scale — a reviewer's attention and accuracy genuinely do degrade across a long queue, which is exactly the failure mode automated, per-document validation is designed not to have.
Versus scaling manual entry for fallback accounts
Scaling manual entry to match rising ingestion volume means hiring, training and managing more treasury-ops or support staff, with all of the ramp-up time and turnover risk that involves — and it introduces a quality risk of its own, since manual entry under time pressure at high volume is exactly the condition most likely to produce transposition errors in numbers a client is trusting for real cash decisions. Scaling an API-based ingestion pipeline to the same volume means, in practice, adjusting a concurrency setting.
Versus relying purely on live feeds
Live feeds work well for the accounts they cover, but coverage is never complete — smaller banks, accounts in markets without open-banking regulation, and consent that account owners decline all fall back to needing a PDF statement processed some other way. Ingestion is exactly where that fallback path earns its keep: it's the answer to "what happens when the live feed doesn't cover this account," at whatever scale that gap turns out to be for a given client base — covered in more depth in what open banking still can't reach in treasury.
How to integrate an ingestion pipeline
The integration itself is identical at any volume — the only high-volume-specific decision is concurrency: how many requests your pipeline issues in parallel. Most teams start at a modest concurrency and increase it as their own infrastructure and monitoring prove comfortable with the load — see multi-entity cash position extraction for the worker-pool pattern this is built on.
Teams building this for the first time typically don't need to change how statements arrive — the same intake process that fed statements to a manual reviewer one at a time can feed a queue instead, with the difference invisible to whoever is collecting the documents.
Feeding ingested data into cash-flow forecasting
A forecasting model is only as good as the transaction-level history it's trained or tuned against — and for accounts that only ever existed as PDF statements, that history simply doesn't exist in a structured form until it's extracted. Running a historical archive of statements through the same pipeline reconstructs the transaction-level detail a forecasting product needs, often reaching further back than any live feed ever covered for that account.
This is a specific, high-value use of the same ingestion mechanics described above — a one-time or occasional large batch rather than a recurring monthly run, but processed through the identical endpoint with the identical balance validation on every statement.
Monitoring ingestion quality over time
At a few statements a week, a team simply notices if something looks off. At thousands a month, quality monitoring needs to be a deliberate, lightweight habit rather than an incidental side effect of familiarity with the documents — tracking the rate of low-confidence or unreconciled flags over time is the single most useful signal, since a rising rate almost always means a new bank or an unfamiliar country has entered the ingestion mix and is worth a quick look.
| Metric | Why it's the right one to watch |
|---|---|
| Low-confidence flag rate | Rising trend signals a new or unfamiliar document format |
| Unreconciled-balance rate | Isolates statements needing an actual second look |
| Monthly spend vs. volume | Should track linearly — a mismatch is worth investigating |
Handling duplicate and re-submitted statements
A real ingestion pipeline eventually receives the same statement twice — a client re-uploads a file they weren't sure went through, an inbox parser picks up a forwarded copy of an email it already processed, or a corrected version of a statement arrives after the original. The API itself has no cross-request memory to detect this, by design — deduplication is a decision that depends on your own data model (what counts as "the same" statement for a given account and period), which is exactly the kind of business logic that shouldn't be baked into a stateless extraction call.
In practice, most pipelines handle this with a simple check before writing a result: does an extraction for this account and statement period already exist, and if so, does the new one differ materially from it? A near-identical duplicate is safely ignored; a statement that differs — a corrected re-issue from the bank, for instance — replaces the earlier one, with the old version kept for audit purposes rather than silently discarded. Building this check once, at the point results are written into your cash-position store, is simpler and more reliable than trying to prevent duplicate submissions upstream, where a well-meaning client re-upload is impossible to distinguish from a genuinely new statement without already knowing the answer.
How a product or ops team runs this day to day
Once the pipeline is live, day-to-day ownership usually splits cleanly into two habits. The first is the review queue itself — whoever is assigned to it works through flagged statements as they arrive, typically a handful a week once the confidence threshold has settled, rather than a large recurring task. The second is the periodic coverage check described in the monitoring section above — a brief, scheduled look at whether ingestion volume and flag rates are behaving as expected, not a constant watch.
Teams that run this well tend to treat both habits as genuinely lightweight rather than a new full-time responsibility, because that is what the numbers actually support once a pipeline has stabilized: a well-tuned ingestion pipeline serving a meaningful client base typically needs well under an hour of human attention a week, split between the two habits above. The bulk of the original engineering investment goes into building the pipeline once; the ongoing cost is mostly the small, steady trickle of genuinely ambiguous statements the confidence threshold correctly declines to auto-approve.
Where this tends to go wrong is when ownership is left ambiguous — nobody specifically checks the review queue, and flagged statements quietly age without a decision. Assigning the queue explicitly to a role, even if it's a shared rotation, is a small process decision that prevents ingestion quality from silently drifting once the initial rollout excitement has passed.
Who this is built for
Cash-flow forecasting and cash-visibility SaaS
Where account-level history and current position both need a document fallback.
Cash-pooling and liquidity dashboards
Needing genuine concurrent throughput instead of one-at-a-time manual entry.
Products with a strong seasonal or onboarding-driven ingestion spike
Wanting cost and capacity that scale with actual volume, not fixed provisioning.
Treasury platforms whose bottleneck is specifically statement ingestion
Rather than the full multi-entity structure — see the treasury-platform page for that case.
Across all four, the common thread is a product that has already accepted a live-feed-only pipeline can't be its whole coverage story — not a product just starting out, but one whose client base has outgrown what connectors alone can deliver, and needs ingestion mechanics themselves to stop being the constraint on how complete its cash visibility can be.
Security and data handling
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original statements are deleted shortly after processing.
Nothing uploaded is ever used to train AI models.
Full details are on the security page.
Get your API key
Run a real batch of fallback statements through /extract and check the balance-validation output against your own records. A free plan account uses the exact same accuracy as a paid one, against a smaller monthly allowance.
A useful first test is a statement your team already processed manually this month — run it through the API and compare the extracted totals against what was entered by hand. Seeing the balance check pass on a document you already know the answer for is usually the fastest way to build confidence before committing production ingestion volume.