What "embedded" actually means here
Most marketplace platforms already have an internal ops tool — an admin panel where support and finance staff look up merchants, check payout status, and investigate disputes. Embedded extraction means settlement statement processing becomes a feature inside that existing tool, rather than a separate reconciliation product staff have to switch to and cross-reference manually. A support agent looking up a merchant's recent payout sees the same structured, validated line items a finance analyst working a full reconciliation cycle would.
This page focuses on the ingestion pipeline itself — the throughput, validation and format-coverage properties that matter once a platform has decided settlement data belongs inside its own tooling rather than in a separate system, and needs that pipeline to be reliable enough to embed without becoming its own maintenance burden.
What the API returns for an ingested statement
POST /extractaccepts a settlement statement PDF, scan or CSV and returns every line item as a typed, dated, described row, with the statement's printed net payout checked against the sum of those line items before the result is returned — the same shape whether the statement is one page or twenty, and whichever processor or currency it came from.
The response also includes the processor name and merchant identifier when printed on the statement, along with the statement period, so an embedded ops-tool view can group and display results by merchant 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 bolt-on tool breaks
A separate, standalone reconciliation tool that ops staff have to open alongside their main admin panel introduces exactly the friction embedding is meant to remove — a support agent investigating a merchant's payout question has to leave the tool they're already in, open a second system, and manually cross-reference what they find. At a handful of merchants, this friction is invisible; at real scale, it's the specific reason ops staff stop checking settlement data proactively and only look at it once a merchant complains.
What embedding specifically needs is an API a platform's own engineering team can call directly from inside its existing admin tool's backend, producing results structurally identical to whatever else that tool already displays — covered in the integrate section below.
Balance validation on every statement ingested
Every single statement — the first ingested and the ten-thousandth — gets the same treatment: line items summed and checked against the printed net payout before the result comes back. This is what lets an embedded ops view trust an ingested merchant's number with the same confidence as anything else the tool already displays, 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 an embedded feature trustworthy rather than merely convenient.
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 marketplace platform whose ingestion volume depends on merchant growth, processor mix and dispute activity — inherently unpredictable, and different every month — 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 the merchant base 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 merchant roster's settlement volume in well under an hour, leaving room for a daily or even intraday refresh inside an embedded ops view rather than a once-a-month batch.
A worked example: 15,000 settlement pages a month
A marketplace platform embeds settlement extraction into its admin tool and ingests roughly 15,000 statement pages a month across its full merchant roster and processor mix:
| Volume | Monthly cost | Annual cost |
|---|---|---|
| 15,000 pages/month | €525 | €6,300 |
Against the staffing cost of manually keying the same volume across a reconciliation or support team — a meaningful fraction of a full-time role at this volume — €6,300 a year is a small fraction of the equivalent labor cost, and it's the line item that lets every ops screen show accurate, current settlement data instead of a stale or manually-updated placeholder.
Processor and layout coverage at ingestion scale
A marketplace serving a diverse merchant base rarely deals with just a handful of processors — dozens of different processors, countries and statement layouts show up across a real ingestion pipeline as merchants choose whichever provider suits them. The extraction model generalizes across real-world statement structure rather than matching a fixed list of supported processors, so a merchant on a smaller regional provider is processed the same way as one on a major global processor, 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 merchant processor choice diversifies — a platform serving ten merchants might tolerate one unsupported processor; a platform serving merchants across thirty processors almost certainly has several, and each one becomes a manual- processing exception that undermines the whole point of embedding automated 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 fifteen thousand of a monthly ingestion run gets exactly the same classification, extraction and balance-check logic as statement one. Volume changes how much a platform 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 reconciliation
Scaling manual entry to match rising ingestion volume means hiring, training and managing more ops or finance 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 merchant is trusting for a real payout. Scaling an API-based ingestion pipeline to the same volume means, in practice, adjusting a concurrency setting.
Versus a standalone reconciliation tool
A dedicated, standalone reconciliation product works well for a platform whose finance team is happy to work in a separate system for that purpose. Embedding extraction directly into an existing admin tool is the better fit specifically when settlement data needs to be visible to more than just finance — support agents answering a merchant's payout question, account managers reviewing a merchant's recent activity — without training every one of those roles on a second system, covered in more depth in why marketplace payout reconciliation breaks at scale.
How to embed the pipeline into your own ops tool
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 settlement line matching 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, and the results simply appear as a new panel or field inside the existing admin tool's merchant view.
Feeding ingested data into internal ops dashboards
Structured JSON maps cleanly onto the fields an internal dashboard's merchant-detail view already needs — processor, currency, period, gross sales, a typed line-item array and net payout — so an embedded settlement panel doesn't need a bespoke data model. A support tool's merchant-lookup page and a finance team's reconciliation dashboard can both read from the same underlying extraction results.
This is a specific, high-value use of the same ingestion mechanics described above — a live, continuously-updated view inside an existing tool rather than a periodic exported report, 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 processor or an unfamiliar layout has entered the 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 merchant 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 merchant 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 into the embedded ops view: does an extraction for this merchant 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 processor, 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 admin tool's data store, is simpler and more reliable than trying to prevent duplicate submissions upstream.
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 embedded pipeline serving a meaningful merchant 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 embedding 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
Marketplace platforms building their own admin/ops tooling
Where settlement data needs to be visible to support, finance and account management alike.
Payments platforms with an internal merchant-ops console
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.
Platforms whose bottleneck is specifically statement ingestion
Rather than the full matching-logic build — see the settlement line matching page for that case.
Across all four, the common thread is a platform that has already accepted a standalone reconciliation system can't be its whole ops story — not a product just starting out, but one whose merchant base has outgrown what a separate tool alone can deliver, and needs settlement data to live inside the same tooling every other role already uses.
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 settlement 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.