Why payout reconciliation is still mostly manual
Reconciling a payout or settlement statement against an internal order ledger sounds like a solved problem — the marketplace or payments platform already knows what it sold, and the processor sends a statement saying what it paid out. In practice, the two rarely line up on their own, and closing that gap is still, at a striking number of platforms in 2026, a manual process: an ops analyst opening a PDF or CSV settlement report, reading fee categories and adjustment lines by eye, and typing figures into a spreadsheet next to the platform's own order data. That's true even at platforms processing serious transaction volume, where the reconciliation team's headcount scales with merchant growth rather than staying flat.
This page is about the API that removes the typing from that process: a payout or settlement statement, in whatever format a processor actually sends it, goes in — a classified, structured, validated set of line items comes out, ready to feed whatever matching logic a platform already runs against its own order data. Chargebacks alone run into the hundreds of millions a year industry-wide, and every one of them shows up as a line on a settlement statement somebody still has to read.
What the API actually does
One endpoint, POST /extract, accepts a payout or settlement statement PDF, scan or CSV export and returns a classified, structured, validated result — the processor, the statement period, the currency, and every line item as a typed, dated, described row: gross sales, processing fees, refunds, chargebacks, adjustments, and the net payout figure the statement actually settles to. There is no separate configuration step per processor and, critically for a platform serving many merchants, no configuration step per merchant.
{
"type": "settlement_statement",
"pages": 4,
"data": {
"processor": "Adyen",
"merchant_id": "MER-88213",
"currency": "EUR",
"period": { "start": "2026-08-01", "end": "2026-08-31" },
"gross_sales": 184220.55,
"lines": [
{ "category": "processing_fee", "reference": "ORD-40218", "amount": -142.10 },
{ "category": "chargeback", "reference": "ORD-39871", "amount": -89.00 },
{ "category": "refund", "reference": "ORD-40190", "amount": -54.20 }
],
"net_payout": 176812.90,
"balance_check": "passed"
},
"price": { "eur": 0.14, "perPageEur": 0.035 }
}Where reconciliation actually breaks at scale
At a handful of merchants, reading a settlement statement by hand once a month is survivable. The math stops working long before a platform reaches enterprise scale: merchant count grows, each merchant's statement has its own mix of fee categories and layout quirks depending on which processor they're on, and the reconciliation team's headcount either grows in step or the backlog quietly grows instead. Reconciliation stalling into a permanent backlog, rather than a solved monthly task, is the normal state at a striking share of platforms handling meaningful settlement volume — not a symptom of a badly run finance team, but a predictable consequence of a manual process that doesn't scale with transaction growth.
| Growth driver | Effect on manual reconciliation | What fixes it |
|---|---|---|
| More merchants onboarded | Linear growth in statements to read by hand each cycle | Extraction cost per statement, not per analyst-hour |
| More processors in the mix | Each new layout needs its own manual familiarity | One pipeline generalizes across processor layouts |
| Chargeback and dispute volume rising | Individually re-keyed lines buried in a fee wall | Every line typed and extracted the same way |
None of these growth drivers reverse on their own — a platform doesn't stop adding merchants or processors to make reconciliation easier. A statement-extraction pipeline is the piece that lets reconciliation scale with the extraction budget rather than with headcount.
Every settlement line, extracted and typed
A settlement statement is rarely one clean number — it's gross sales minus a wall of individual deductions: processing fees, currency-conversion fees, refunds, chargebacks, reserve holds, adjustments from a prior period, sometimes advertising or subscription fees bundled into the same report. Each of those lines is extracted individually, typed by category, and tagged with whatever order or transaction reference the processor printed on it — not folded into one opaque "deductions" total the way a naive text-extraction tool would leave it.
This line-level structure is what makes the output actually useful for matching against an order ledger. A single "deductions: €7,412.30" figure tells a platform nothing about which order each euro belongs to; a typed, referenced line per deduction is the structured input a matching engine — yours, or the one covered on the settlement line matching feature page — actually needs to trace a discrepancy back to its source.
Validation against the statement's own totals
A reconciliation pipeline's entire value rests on the extracted numbers being trustworthy — an ops team acting on a wrong figure is a real, costly mistake, not a cosmetic bug. Every statement's printed net payout is checked against the sum of its own gross sales, fees, refunds and adjustments before the result comes back; a statement that doesn't reconcile internally is flagged rather than folded silently into a merchant's ledger.
This matters specifically for settlement data because a settlement report is, by its nature, a document with dozens of individually small line items that all have to sum correctly to one net figure — a single misread fee line is easy for a human eye to miss and easy for arithmetic validation to catch immediately.
Pricing: flat €0.035 per page, at any volume
Every page — from any processor, any currency, any merchant — bills at the same flat €0.035, with no enterprise tier to unlock before volume becomes economical and no per-merchant minimum. Full mechanics are on the flat-rate pricing page; for a marketplace or payments platform specifically, the relevant property is that settlement volume grows directly with merchant and transaction growth, and a flat rate means that growth never turns into a pricing renegotiation.
This also removes a procurement friction platforms run into with volume-tiered document vendors: a merchant cohort with an unusually high chargeback or dispute rate — and therefore a longer, more complex statement — doesn't suddenly cost the platform more per page than a cohort with a clean, short statement; the rate is identical either way.
Turnaround at platform volume
A single statement typically returns in a few seconds. At batch scale — a full merchant roster's settlement statements processed for a daily or weekly close — concurrent processing means turnaround is bounded by how many requests your own pipeline issues in parallel, not by a queue on FlowParse's side.
| Batch size | Typical turnaround, concurrent calls |
|---|---|
| A single merchant's monthly statement (~4 pages) | A few seconds |
| A 200-merchant weekly settlement close (~800 pages) | A few minutes |
| A platform-wide daily close across many processors | Well under an hour, at modest concurrency |
A worked example: 40,000 settlement pages a month
A mid-sized marketplace platform processes settlement statements across roughly 1,200 active merchants and six payment processors, averaging around 4 pages per merchant per month, plus a small share of longer statements for merchants with heavier chargeback or dispute activity — roughly 40,000 pages a month in total.
| Volume | Monthly cost | Annual cost |
|---|---|---|
| 40,000 pages/month | €1,400 | €16,800 |
Against the staffing cost of a reconciliation team reading the same 1,200 merchants' statements by hand every month — realistically several full-time analyst roles at this volume — €16,800 a year is a small fraction of the equivalent labor cost, and it's the line item that turns reconciliation from a growing backlog into a process that scales flat with extraction spend instead of headcount.
What kind of statements actually arrive
| Source | What comes back |
|---|---|
| PDF settlement statement from a processor dashboard | Full statement — every line item, typed and referenced |
| CSV settlement export | Same structured shape, parsed directly from the export |
| Emailed monthly payout summary PDF | Same result, automatically classified as a settlement statement |
| Scanned or photographed printed statement | Same output, read at real-world scan quality |
Format is detected automatically on every call, so a platform's intake doesn't need to pre-sort clean PDF exports from CSVs or rougher scans before sending them — the API handles all three through the same endpoint and tells you what it received. A statement from Stripe, from a smaller regional processor, or a payment facilitator's consolidated multi-merchant report are all handled the same way.
How to integrate into a reconciliation pipeline
Get an API key
Free plan accounts get a real key and full accuracy against a smaller monthly allowance — enough to pilot against real settlement statements.
Identify where settlement statements land today
A shared inbox, a processor's API pull, a merchant-facing upload portal — wherever they arrive, that's your intake.
Point your intake at POST /extract
Every statement, from any processor, goes through the same endpoint regardless of format.
Tag each result with your own merchant and order identifiers
The API returns no merchant concept of its own — your platform attaches whichever ID it already tracks.
Feed the typed line items into your own matching logic
A validated, referenced line item is structurally ready to match against your order ledger — your engine shouldn't need a special code path for it.
A full step-by-step walkthrough, including how to build the batch worker and review queue around this, is in the guide how to reconcile marketplace payouts with an API.
Feeding structured data into a ledger or ERP
Structured JSON maps cleanly onto the fields a ledger or order-management data model already expects — merchant, currency, period, gross sales, a typed line-item array and net payout — so a settlement result doesn't need a separate ingestion path from anything else your platform already processes. Platforms built on top of an ERP's finance module, or a standalone marketplace back-office product, both see the same shape.
Onboarding a new processor without new engineering work
Because nothing about the API is configured per processor, onboarding a new payment provider's settlement statements requires zero extraction-side setup — no new statement template to build, no processor-specific model to add. The only onboarding work is what a platform already does internally: mapping the new processor into its merchant and ledger data, and pointing the intake pipeline at its statements.
This is a meaningfully different growth model than building a parser per processor, where covering a new payment provider is itself an engineering project. A statement-based pipeline scales flat across processors — the sixth processor's onboarding looks exactly like the first's.
Where human review still belongs
Extraction removes the typing, not an ops analyst's judgment — deciding whether an unusual adjustment line needs a note before a merchant's ledger is closed, catching a statement that looks like it's missing a page, flagging a chargeback pattern worth escalating. A confidence signal on every result is built to direct that limited attention efficiently, surfacing the small fraction of statements that are genuinely ambiguous rather than asking a reviewer to re-check every one.
Who this is built for
Marketplace platforms
Reconciling payouts across many sellers and processors against an internal order ledger.
Payment platforms and PSPs
Processing settlement data for merchants at volume, with reconciliation as a core operational function.
Marketplace and payments ops tooling teams
Building the internal reconciliation pipeline their finance team relies on every close.
Platforms serving a growing, multi-processor merchant base
Where a fixed list of supported processor templates is already a structural bottleneck.
Common objections, answered honestly
"Our processors' 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 supported processors. A classification-first pipeline built across a broad range of real statement formats, not a fixed processor list, is designed for exactly this variety — a major processor's statement and a smaller regional provider's CSV export are handled by the same generalized model, not a per-processor template that has to be built and maintained separately.
A second objection is data security — sending merchant settlement data to a third party feels like added exposure on top of an already sensitive dataset. In practice, documents are processed and deleted shortly afterward, nothing uploaded is used to train models, and the API itself never stores a merchant or platform 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 an extraction dependency complicates an already careful reconciliation pipeline. In practice, a validated result from this API is structurally simpler than the unstructured PDF it replaces; the integration work is almost entirely in wiring the intake, not in how downstream matching logic treats the data once it arrives.
What changes as processor and merchant count grows
Below a modest merchant base, many platforms tolerate a manual reconciliation process — an ops analyst reading a few dozen statements a month is survivable. Past a certain merchant and processor count, the math tends to flip: statement volume grows roughly with merchant count while the extraction cost per statement stays flat and small. Platforms adding processors to serve new geographies specifically — where each new processor brings its own statement layout — are the ones most likely to see this threshold arrive early rather than late.
Migrating away from manual settlement-report reconciliation
Most platforms migrate gradually, running the API alongside an existing manual reconciliation process for a subset of processors or merchant cohorts first — commonly the highest-volume processor, 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
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.
The API holds no merchant, processor or platform identifier of its own.
Full details are on the security page.
Get your API key
Run a real statement from one of your platform's processors through /extract and compare the output against what an ops analyst would enter by hand. A free plan account uses the exact same accuracy as a paid one, just against a smaller monthly allowance.