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 reconciliation gap. This page is written the other way around — eight concrete situations a real marketplace or payments 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 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, merchant 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 marketplace platform's reconciliation problem
Most of these scenarios share an underlying shape: a growing merchant base whose payouts flow through several processors, a settlement statement that needs to be turned into structured data before it's useful, and a recurring or one-off moment (an onboarding, a spike, an audit) where the reconciliation burden becomes visible and needs handling. 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 operation.
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 new payment processor
A marketplace decides to support a new payment processor — often to serve merchants in a new region or a category with a strong preference for a specific provider. Rather than building a new parser for that processor's statement format, the same extraction pipeline handles it from the first statement, since it generalizes across layouts rather than matching a fixed list. This is covered in full, with a worked example, on the payout statement reconciliation API page.
For most platforms, this single scenario alone justifies the integration — a new processor previously meant weeks of an ops team learning to read its statements; with the API, it means pointing the existing pipeline at a new source and nothing more.
2. A seasonal volume spike overwhelming the ops team
A holiday shopping period or a major promotional event drives a sharp, temporary spike in transaction — and therefore settlement statement — volume. A manual reconciliation process has no way to flex up quickly enough; a fixed team simply falls behind for the duration of the spike and spends weeks afterward catching up. An API-based pipeline scales by adjusting concurrency, not by hiring temporary staff who need training before they're useful.
This scenario is worth naming separately from steady-state growth because it's specifically about the mismatch between a short, sharp demand curve and a manual process's inability to match it — the exact situation an API-based pipeline's flat, on-demand scaling is built for.
3. A chargeback surge in one merchant category
A merchant category — subscription services, a physical-goods vertical with higher dispute rates — sees a sudden increase in chargeback and dispute activity, and the associated settlement lines pile up faster than the ops team can read and categorize them individually. Every chargeback line is extracted and typed the same way regardless of volume, so a surge in dispute activity doesn't degrade extraction quality the way it degrades a stretched analyst's attention.
This scenario has a natural lifecycle: many platforms see dispute activity concentrate in specific periods or categories rather than spreading evenly, which is exactly when a manual process is most likely to fall behind — and exactly when an automated pipeline's flat quality curve matters most.
4. Daily or weekly settlement close for finance
A finance team needs its settlement position refreshed frequently, not just monthly — and the reconciliation pipeline needs 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 close options to different internal teams runs one pipeline, simply triggered on different schedules.
5. Migrating off manual settlement-report reconciliation
A platform moving its whole reconciliation process off a manual, analyst-driven approach 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 processors, confirming the output matches, then cutting those processors over before moving to the next wave.
Platforms in the middle of this migration commonly run a hybrid state for months — some processors fully automated, others still on manual entry — without any operational conflict, since each processor's workflow is independent of every other processor's.
6. A back-office software vendor adding extraction as a feature
A software vendor building a back-office or reconciliation tool for marketplace operators can embed the same extraction API as a core feature inside its own product, rather than leaving each customer to build or buy extraction separately — the same build-vs-buy logic covered for treasury software in the treasury API cluster applies here to marketplace back-office software specifically.
This scenario differs from the others in who's doing the integrating — a software vendor rather than an operating marketplace — 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 a finance audit
A finance audit or a due-diligence process needs transaction-level history reaching further back than any existing structured record covers — years of historical settlement statements archived as PDFs 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 satisfy the audit.
This scenario is often a one-off 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 close, just larger.
8. A merchant disputing a payout figure
A merchant contacts support questioning why a payout was lower than expected, and the support agent needs a fast, accurate breakdown of every deduction on the relevant statement — not a raw PDF the agent has to read line by line while the merchant waits. Structured, typed, referenced line items let a support tool surface the specific fee, refund or chargeback that explains the discrepancy in seconds rather than minutes.
This scenario is a useful reminder that reconciliation infrastructure isn't only a finance back-office concern — it directly shapes how quickly and confidently a support team can resolve the exact conversations most likely to affect merchant trust.
Picking the scenario closest to your platform
| If your platform... | Start with scenario |
|---|---|
| Is actively onboarding new payment processors | 1 — new processor onboarding |
| Sees sharp seasonal volume swings | 2 — seasonal spike |
| Handles a merchant category with heavy dispute activity | 3 — chargeback surge |
| Is still fully on manual reconciliation | 5 — gradual migration |
| Is a software vendor, not an operating platform | 6 — embedded extraction 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 settlement statement and needs structured, validated 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 new processors, absorbing seasonal spikes, and migrating off manual reconciliation. 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 reading to genuine review, and materially faster resolution of merchant payout questions. For a 300-merchant platform ingesting roughly 1,200 settlement pages a month, the extraction cost runs about €504 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 embedded extraction page.
This ROI compounds across the eight scenarios rather than being a one-time gain — the same freed analyst time and faster resolution shows up whether the volume driving it is a new processor, a seasonal spike, or a historical audit 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
Match rate is the metric worth tracking from day one — what share of statements processed each cycle flow straight through to matching without a review flag. A platform starting this rollout typically sees that number improve in visible steps rather than smoothly, each step corresponding to a wave of processors 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 reconciliation delay comes up as a factor in a merchant support ticket, the specific signal covered in the scale 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 merchants stop having payout questions, but because the platform now has a fast, reliable answer whenever one comes up, rather than a days-long wait for an ops analyst to read a statement.
A third, more internal measure is how the extraction spend line behaves against these two — it should grow roughly in proportion to statement volume and stay flat per statement 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 reading a settlement statement's line items by eye with an API call, while leaving the matching and dispute judgment that happens after extraction entirely in the hands of the platform's own team. None of these use cases involve the API making a matching decision, a chargeback-liability call, or a judgment about an unusual line item — 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, ops and finance
Internally, framing matters: an ops team focused on manual quality control responds very differently to "we need to replace part of your job" than to "this removes the reading step so you can spend your time on the disputes that actually need judgment." Positioning extraction as freeing the team for higher-value work, not an afterthought or a threat, builds internal support faster than presenting it as a headcount reduction. Externally, merchants rarely need to be told anything changed at all; what they notice is faster, more accurate answers to their payout questions, not the mechanism behind any individual statement's data.
Platforms that navigate this most smoothly tend to pilot quietly on a small scenario first — scenario 1 (a single new processor) 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 |
|---|---|---|
| New processor onboarding (25 merchants) | ~100 pages | ~€3.50 one-time |
| Monthly settlement close (300 merchants) | ~1,200 pages | ~€42/month |
| Seasonal spike (2× normal volume, one month) | ~2,400 pages | ~€84 one-time |
| Multi-year audit backfill | ~1,500 pages | ~€53 one-time |
Beyond the eight: a ninth pattern worth naming
A pattern that comes up often enough to mention separately: a platform-of-platforms structure — a payment facilitator with sub-merchants, or a marketplace aggregator sitting on top of several underlying marketplaces — needs statements from across the whole structure consolidated into one coherent picture. The batch mechanics are identical to the standard onboarding scenario; what differs is that the "merchant ID" tag is really a hierarchy (facilitator, then sub-merchant, then transaction), 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 multi-level structure 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 matching decision, a chargeback-liability determination, or an advisory judgment about a merchant's account — every one of them ends with structured, validated, typed and referenced data landing in your platform's own matching and dispute-handling logic, not a fully autonomous reconciliation process. Platforms looking for a tool that also decides which party is liable for a chargeback or replaces an ops analyst'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 reconciliation roadmap
Looking for a concrete scenario that matches their actual platform challenges, not a generic feature list.
Engineering teams planning an implementation
Deciding which scenario to pilot first and how to sequence a broader rollout.
Back-office software vendors
Evaluating whether to embed extraction as a reconciliation feature inside their own platform.
Platforms preparing for a finance audit or historical backfill
Needing to reconstruct structured data from an archive of old settlement 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 settlement statement arrives as a PDF and needs to become structured, trustworthy 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, migrating your existing manual reconciliation backlog is the safest default — it's the most visible, highest-time-savings 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.