Why use cases, not just features
A feature list tells you what an API can do; it rarely tells you whether it fits how your platform actually needs to close its coverage gap. This page is written the other way around — eight concrete situations a real treasury-management or cash-visibility platform runs into, each mapped to how the extraction API addresses it specifically, so you can find the scenario closest to your own workload rather than translating a generic feature list yourself.
Each scenario below is drawn from a recurring pattern across real treasury-platform operations, not a hypothetical. Some platforms will recognize themselves in two or three of these immediately; others will find their situation is a blend of several. Either way, the point of reading through all eight rather than just the closest match is that the underlying mechanics — batch calls, entity tagging, confidence-based review — are the same across every one, so understanding one scenario well makes the rest easy to apply.
The shape of a treasury platform's coverage problem
Most of these scenarios share an underlying shape: a corporate client whose accounts span many entities, banks and countries, some subset of which a live connection genuinely cannot reach, and a recurring or one-off moment (an onboarding, an acquisition, a forecasting project) where that gap becomes visible and needs closing. The API doesn't change per-statement extraction depending on which scenario it's used in — every use case below is the same /extractcall, applied to a different moment in a platform's workflow.
What differs between scenarios is almost entirely orchestration — when statements are collected, how they're batched, and what happens to the results afterward — rather than anything about the extraction itself. This is a useful thing to internalize early: a platform doesn't need eight different integrations, just one, applied at eight different points in its operation.
1. Onboarding a multinational client's unconnected accounts
The most common trigger: a new corporate client onboards with dozens of accounts across many countries, and a meaningful share simply can't connect through the platform's existing connector library on day one. Rather than showing a partial position and promising the rest "soon," those accounts' statements are processed in one batch during onboarding, giving the client a genuinely complete position from the start. This is covered in full, with a worked example, on the bank statement API for treasury platforms page.
For most platforms, this single scenario alone justifies the integration — it's the moment a coverage gap is most visible to a new client, and the moment where a slow or incomplete onboarding is most likely to color that client's entire relationship with the product.
2. A subsidiary that won't grant open-banking consent
A subsidiary's local finance controller, for policy or internal-review reasons, declines to authorize an aggregator connection — a gap no amount of connector engineering fixes, since it's a human decision rather than a technical one. A PDF fallback needs no consent from the bank side at all; the treasury team simply continues sending statements the same way they always have, and those statements resolve into the same structured position as every connected account.
This scenario is worth naming separately from onboarding because it can surface at any point in a client relationship, not just at the start — a subsidiary's policy can change, a consent can be revoked, and the fallback needs to be ready whenever that happens, not just during initial setup.
3. A newly acquired entity mid-integration
A client completes an acquisition, and the acquired entity's accounts need to appear in the consolidated cash position quickly — often well before any longer-term decision about bank consolidation, connector setup or consent has even been made. Processing the acquired entity's existing statements as a fallback gives the treasury team immediate visibility during the integration period, without waiting on a connector project that may take months to complete.
This scenario has a natural lifecycle: many platforms see a client eventually move an acquired entity's accounts onto a live connection once the M&A dust settles, with the fallback serving as the bridge rather than the permanent state — though for many acquired entities, especially foreign ones, the fallback simply becomes the permanent path.
4. Daily or weekly cash positioning for a treasury desk
A treasury desk managing tight liquidity needs its cash position refreshed frequently, not just monthly — and the fallback accounts need to keep pace with that cadence, not lag behind as a monthly afterthought. Statement extraction follows the exact same batch pattern regardless of cadence; the API has no concept of "monthly" or "daily" that needs adjusting for a tighter refresh schedule.
This is a good example of how the same underlying integration serves very different reporting cadences without extra engineering — a platform offering both daily and monthly refresh tiers to different clients runs one pipeline, simply triggered on different schedules per client.
5. Migrating off manual PDF-to-spreadsheet cash reporting
A platform moving its whole book of fallback accounts off a manual, analyst-driven process rarely does it all at once — the gradual, comparison-driven migration described in the rollout guide is itself a use case worth naming on its own: running the API in parallel with existing manual entry for a handful of accounts, confirming the output matches, then cutting those accounts over before moving to the next wave.
Platforms in the middle of this migration commonly run a hybrid state for months — some accounts fully automated, others still on manual entry — without any operational conflict, since each account's workflow is independent of every other account's.
6. A treasury software vendor adding fallback as a feature
A software vendor building a treasury-management or ERP treasury module can embed the same extraction API as a fallback-coverage feature inside its own product, rather than leaving each customer to build or buy its own extraction separately — the same build-vs-buy logic covered for bookkeeping platforms in the accounting-BPO cluster applies here to treasury software specifically.
This scenario differs from the others in who's doing the integrating — a software vendor rather than an operating treasury team — but the API call underneath is identical, and the resulting feature becomes something the vendor can offer every one of its own customers at once.
7. Historical statement backfill for cash-flow forecasting
A forecasting product or model needs transaction-level history reaching further back than any live feed ever covered — several years of historical PDF statements that were archived but never entered as structured data. Running that historical set through the API in one pass reconstructs usable, balance-checked data without weeks of manual re-entry to feed the forecasting model.
This scenario is often a one-off for a given account rather than a recurring workflow, which makes it a particularly clear illustration of the cost comparison — a large historical batch that would take an analyst weeks to key manually processes in the same batch pattern as any regular refresh, just larger.
8. A banking relationship change mid-year
A client closes an account at one bank and opens a new one elsewhere, or a subsidiary switches its local banking relationship — and the new account often has no live connection available immediately, even where the old one did. Rather than showing a gap in the position until a new connector or consent flow is set up, the new account's statements are processed as a fallback from day one, closing the gap the moment the account exists rather than weeks later.
This scenario is a useful reminder that the coverage gap isn't static even for an existing, fully-onboarded client — banking relationships change, and a fallback pipeline that's already built handles that change immediately rather than requiring a fresh integration project each time.
Picking the scenario closest to your platform
| If your platform... | Start with scenario |
|---|---|
| Is actively onboarding multinational clients | 1 — multinational onboarding |
| Regularly hits consent-declined subsidiaries | 2 — consent gap |
| Serves clients that acquire other companies | 3 — newly acquired entity |
| Is still fully on manual fallback entry | 5 — gradual migration |
| Is a software vendor, not an operating treasury team | 6 — embedded fallback feature |
These eight are the most common patterns, not an exhaustive list — the underlying call is the same for any workflow that starts with a PDF statement and needs structured, validated cash-position data out, so a platform whose situation doesn't map neatly onto one of these can typically still apply the same mechanics.
It's also common for a platform to recognize itself in more than one row at once — a growing platform is very often simultaneously onboarding multinational clients, running into consent gaps, and supporting an M&A-active client's integration. That overlap isn't a complication; because every scenario shares the same underlying integration, addressing one naturally puts the infrastructure in place for the others.
The ROI case, worked through
Across every scenario above, the return comes from the same two places: analyst hours redirected from manual statement entry to genuine review, and materially faster, less friction-filled onboarding for exactly the multinational clients a treasury platform most wants to win and keep. For an 80-client platform ingesting roughly 700 fallback pages a month, the extraction cost runs about €294 a year against dozens of hours a month of manual-entry time freed up — time worth considerably more than the extraction cost at any reasonable analyst rate, covered with full numbers on the ingestion API page.
This ROI compounds across the eight scenarios rather than being a one-time gain — the same freed analyst time and faster onboarding shows up whether the volume driving it is a new multinational client, a consent gap, or a historical forecasting backfill, since all of it flows through the same extraction cost line rather than a separate budget for each situation.
Measuring success over the first year
Coverage completeness is the metric worth tracking from day one — what share of tracked accounts across the client base have any data source, live or fallback, versus a known gap. A platform starting this rollout typically sees that number improve in visible steps rather than smoothly, each step corresponding to a wave of accounts migrated in the rollout guide's step 7 — which makes it a genuinely useful metric to report internally, since the improvement is concrete and attributable rather than a vague sense of "things are better now."
A second metric worth tracking, more qualitative but just as real, is how often a coverage gap comes up as a blocker in a sales conversation or a support ticket, the specific signals covered in the open-banking gap article linked above. A platform that closes this gap well should see that signal largely disappear over the following one to two quarters — not because multinational clients stop having unconnected accounts, but because the platform now has a reliable, unremarkable answer whenever one comes up, rather than a gap in the product story.
A third, more internal measure is how the extraction spend line behaves against these two — it should grow roughly in proportion to onboarded fallback accounts and stay flat per account otherwise, which is itself a useful sanity check that the pipeline is working as designed rather than degrading or over-processing somewhere in the pipeline.
The common thread across every scenario
Every scenario on this page is, underneath, the same trade: replacing the mechanical step of typing a statement's numbers into a spreadsheet with an API call, while leaving the treasury judgment that happens after extraction entirely in the hands of the client's own team. None of these use cases involve the API making a consolidation decision, a currency-conversion policy call, or a judgment about an unusual transaction — it turns a statement into structured, validated data, and everything downstream of that stays exactly as it was.
This is worth stating plainly because it's easy, reading eight different scenarios, to imagine eight different capabilities. There is really only one capability being applied eight different ways — a distinction that matters when evaluating how much new integration work each additional scenario actually requires (very little, once the first one is built).
Getting buy-in from product, sales and clients
Internally, framing matters: a product team focused on connector breadth responds very differently to "we need a lesser, secondary data source" than to "this completes the coverage story our connector library already promises." Positioning the fallback as a first-class part of the coverage roadmap, not an afterthought, builds internal support faster than presenting it as a stopgap. Externally, clients rarely need to be told anything changed at all; what they notice is a genuinely complete position, not the mechanism behind any individual account's data.
Platforms that navigate this most smoothly tend to pilot quietly on a small scenario first — scenario 2 (a single subsidiary's consent gap) is a common starting point specifically because it's low-stakes and self-contained — before discussing a broader rollout with the wider team, so the conversation starts from a working example rather than a proposal.
Rough cost per scenario, for planning purposes
Because every scenario bills at the same flat €0.035 per page, estimating cost for any of them is the same simple arithmetic: expected page volume multiplied by the rate. The figures below are illustrative, sized to a mid-sized platform, to give a sense of scale before running the numbers against your own actual volume.
| Scenario | Illustrative volume | Illustrative cost |
|---|---|---|
| Multinational onboarding (12 fallback accounts) | ~36 pages | ~€1.26 one-time |
| Monthly consent-gap accounts (5 accounts) | ~15 pages | ~€0.53/month |
| Weekly cash-desk refresh (10 accounts) | ~40 pages/week | ~€6.10/month |
| Multi-year forecasting backfill | ~1,200 pages | ~€42 one-time |
Beyond the eight: a ninth pattern worth naming
A pattern that comes up often enough to mention separately: a client that is itself a holding structure of many small operating entities — a private-equity portfolio company group, a real-estate holding structure with per-property accounts — needs statements from across the whole structure consolidated into one coherent picture. The batch mechanics are identical to the multinational onboarding scenario; what differs is that the "entity ID" tag is really a hierarchy (fund, then portfolio company, then account), which your own tagging pipeline handles the same way it would any other structured identifier.
This is worth calling out specifically because it's easy to assume a holding-structure consolidation needs its own specialized tooling. It doesn't — it needs the same extraction and the same batch pattern as every other scenario on this page, with one additional level in your own correlation logic.
What these use cases don't cover
None of the eight scenarios above involve the API making a currency-conversion decision, a consolidation-hierarchy decision, or an advisory judgment about a client's cash position — every one of them ends with structured, validated, currency-tagged data landing in your platform's own consolidation logic, not a fully autonomous treasury process. Platforms looking for a tool that also decides an FX policy or replaces a treasurer's judgment entirely are looking for something this API is deliberately not — see the limits section on the feature page for the equivalent line drawn there.
Who these use cases are written for
Product leads evaluating whether this fits their coverage roadmap
Looking for a concrete scenario that matches their actual client challenges, not a generic feature list.
Engineering teams planning an implementation
Deciding which scenario to pilot first and how to sequence a broader rollout.
Treasury software vendors
Evaluating whether to embed extraction as a fallback-coverage feature inside their own platform.
Platforms preparing for a forecasting project or historical backfill
Needing to reconstruct structured data from an archive of old statement PDFs.
If none of these four descriptions fits precisely, the underlying question is still the same one worth asking: is there a recurring point in your platform's operation where a statement arrives as a PDF and needs to become structured, trustworthy cash-position data before anyone can act on it? If so, one of the eight scenarios above is almost certainly a close enough match to start from.
Get your API key
Pick the scenario closest to your platform and run a small real pilot against it. A free plan account processes real documents at full accuracy against a smaller monthly allowance — enough to validate any of the eight scenarios above before committing to full volume.
If you're not sure which scenario to start with, multinational onboarding is the safest default — it's the most visible, highest-stakes recurring trigger at nearly every platform, and proving it out there gives you a working integration you can extend to every other scenario on this page afterward.