What "high volume" actually means for an accounting firm
A single-file converter is built around one statement at a time — upload, review, download, repeat. That model works for an individual filer once a year; it becomes the bottleneck itself once a firm is processing thousands of statement pages a month across many client accounts. High volume, for the purposes of this page, means a firm where statement processing alone — not invoices, not receipts, just bank and card statements — has grown large enough that a per-document manual step measurably slows down the close.
This page assumes that starting point — a firm that has already outgrown a single-document workflow — and focuses specifically on the properties that matter at that scale: real concurrent throughput, balance validation that holds up across thousands of statements without a corresponding increase in review time, and pricing that doesn't require a separate negotiation once volume crosses some threshold.
What the API returns for a bank or card 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.
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 system can group and file results by account without a separate lookup step. Nothing about the response shape changes based on volume — the thousandth call in a session returns the same structure as the first.
Where volume breaks a simpler tool
A tool designed around one document at a time typically has no meaningful concurrency story — it processes what's uploaded and waits for a human to review before the next one starts. At low volume this is invisible; at a few thousand pages a month it becomes the actual constraint on how fast a firm can close. What high-volume use needs specifically is an API a firm's own pipeline can call concurrently, at whatever rate its infrastructure supports — covered in the throughput section below.
The failure mode isn't always obvious from the outside — a single-document tool doesn't crash or error under volume, it just quietly becomes the thing everyone is waiting on. Staff learn to work around it, starting statement processing earlier in the month to compensate, which masks the underlying constraint rather than fixing it. Recognizing this pattern early is usually cheaper than discovering it during an unusually busy close.
Balance validation on every statement, at scale
Every single statement — the first of the month 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 firm trust a large batch's output at face value rather than manually re-checking arithmetic across every statement after the fact, which is the step that makes high volume genuinely tractable rather than just faster typing.
At low volume, a bookkeeper re-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 workable rather than merely faster.
Pricing that doesn't punish 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 firm accustomed to volume pricing that requires a sales call to access, this is a meaningfully simpler procurement decision: the rate quoted on the pricing page is the rate at ten pages a month and at a hundred thousand.
This also removes a specific budgeting headache many firms run into with volume-tiered vendors: unpredictable cost jumps when a tier boundary is crossed mid-year. A flat rate means this month's statement volume costs exactly what last month's did per page, with nothing to renegotiate as the firm grows.
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 a firm's entire monthly statement volume in well under an hour, leaving the rest of a close cycle for review and reconciliation rather than waiting on extraction.
A worked example: 15,000 pages a month
A mid-sized accounting firm processing 15,000 statement pages a month across its client base — a mix of monthly bank and card statements — pays:
| Volume | Monthly cost | Annual cost |
|---|---|---|
| 15,000 pages/month | €525 | €6,300 |
Against the staffing cost of manually keying the same volume — multiple full-time data-entry positions at that page count — €6,300 a year is a small fraction of the equivalent labor cost, covered with real hiring numbers in why outsourced bookkeeping firms need an extraction API, not more staff.
Bank and layout coverage at volume
A high-volume accounting-firm client base rarely banks with just a handful of institutions — dozens of different banks, card issuers and statement layouts show up across a real roster. The extraction pipeline generalizes across real-world statement structure rather than matching a fixed list of supported banks, so a client on a smaller regional bank is processed the same way as one on a major national bank, without a separate template needing to exist first.
This matters more than it might first appear at high volume specifically, because a template-based tool's coverage gaps compound with scale — a firm with ten clients might tolerate one unsupported bank; a firm with three hundred almost certainly has several, and each one becomes a manual-processing exception that undermines the whole point of automating the rest.
Why quality doesn't degrade as 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 batch gets exactly the same classification, extraction and balance-check logic as statement one. Volume changes how much a firm pays and how long a batch 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 shift and a large stack, which is exactly the failure mode automated, per-document validation is designed to not have.
Versus scaling manual entry to the same volume
Scaling manual entry to match rising statement volume means hiring, training and managing more data-entry 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. Scaling an API-based pipeline to the same volume means, in practice, adjusting a concurrency setting.
The staffing side of this comparison, with real hiring-cost numbers rather than a general claim, is worked through in full in why outsourced bookkeeping firms need an extraction API, not more staff.
Versus relying on live bank feeds at this volume
Live bank feeds work well for the accounts they cover, but coverage is never complete — smaller banks, closed or changed accounts, and historical months before a feed was connected all fall back to needing a PDF statement processed some other way. At high volume, that fallback path is exactly where a statement extraction API 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.
At high statement volume, the size of that gap tends to be larger than firms initially estimate — across a diverse client base, some meaningful share of accounts will always fall outside live-feed coverage, and at scale that share represents real, recurring statement volume that needs a dependable processing path of its own.
How to integrate for high-volume use
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 firms start at a modest concurrency and increase it as their own infrastructure and monitoring prove comfortable with the load — see multi-client batch extraction for the worker-pool pattern this is built on.
Firms migrating from a single-document tool typically don't need to change anything about how documents arrive — the same intake process that fed statements one at a time can feed a queue instead, with the difference invisible to whoever is collecting the documents in the first place.
Handling seasonal peaks, like tax season
Because cost and processing scale with actual volume rather than fixed provisioned capacity, a firm doesn't need to staff up or pre-provision ahead of a seasonal spike — a tax-season month with three times the normal statement volume simply costs three times as much and processes at the same per-document speed, with no separate scaling decision required on the firm's part.
This is a meaningful contrast with staffing-based scaling, where a seasonal spike either means temporary hires (with all the training and onboarding overhead that entails for a role lasting a few months) or existing staff absorbing the overflow through overtime. Neither has a real equivalent on the API side — the only adjustment needed is, if anything, a higher concurrency setting for the busier weeks.
Monitoring quality at high volume
At a few statements a week, a bookkeeper 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 a changed statement 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 |
Who this is built for
Accounting firms with statement-heavy client bases
Where bank and card statements make up the bulk of the document workload.
Firms hitting a wall with a single-document tool
Needing genuine concurrent throughput instead of one-at-a-time processing.
Firms with strong seasonal volume swings
Wanting cost and capacity that scale with actual volume, not fixed provisioning.
Bookkeeping BPOs whose bottleneck is specifically statements
Rather than the full document mix — see the broader bookkeeping-firm API page for that case.
Across all four, the common thread is a firm that has already run out of room in a workflow built for lower volume — not a firm just starting out, but one whose growth has outpaced the tooling it started with, and needs the mechanics of statement processing itself to stop being the constraint on how fast it can grow further.
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 client 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 volume.