Why a bookkeeping BPO's document problem is different
A single company's bookkeeping is a manageable document problem: one chart of accounts, a handful of bank connections, a predictable monthly stack of statements and invoices. An outsourced bookkeeping or accounting BPO firm faces the same problem multiplied across every client on its roster at once — sixty, two hundred, sometimes a thousand clients, each with their own banks, their own invoice formats, their own monthly volume, arriving on their own schedule rather than a single predictable feed.
That multiplication is what breaks tools built for a single company's books. A live bank-feed connection scales to one company's accounts reasonably well; it does not scale to reconnecting and maintaining feeds for hundreds of clients' banks, many of which change owners, close accounts or simply never had a live feed available in the first place. What a bookkeeping BPO actually needs is a way to turn whatever document a client sends — a PDF statement, a scanned invoice, a photographed receipt — into structured, reconcilable data, regardless of which client or which bank it came from, and to do that at the volume a growing client roster demands.
What the API actually does
One endpoint, POST /extract, accepts a bank statement, an invoice or a receipt and returns a classified, structured result. There is no separate configuration step per document type and, critically for a BPO, no configuration step per client — the same call handles client one's statement and client two hundred's invoice identically.
{
"type": "bank_statement",
"pages": 4,
"data": {
"bank_name": "Regions Bank",
"account_last4": "8842",
"period": { "start": "2026-08-01", "end": "2026-08-31" },
"opening_balance": 18420.55,
"closing_balance": 21118.02,
"transactions": [
{ "date": "2026-08-03", "description": "ACH DEPOSIT - CLIENT INVOICE 4471", "amount": 3200.00 },
{ "date": "2026-08-05", "description": "PAYROLL - GUSTO", "amount": -6140.18 }
],
"balance_check": "passed"
},
"price": { "eur": 0.14, "perPageEur": 0.035 }
}Batch processing across many clients at once
Nothing in the API distinguishes one client's documents from another's — that separation lives entirely in your own system, the same way your practice-management software already keeps client folders separate today. A firm's own ingestion pipeline typically queues every document collected for a monthly close — from every client, in whatever order they arrived — and fires concurrent calls to /extract, so a batch of several hundred statements finishes in minutes rather than being processed one at a time in sequence.
This matters specifically at a BPO's scale, where the bottleneck is rarely a single document — it is the aggregate volume across the whole roster arriving in the same few days around a monthly or weekly close. A pipeline that processes one document at a time, waiting for each to finish before starting the next, simply cannot keep pace once a firm passes a few dozen clients; concurrent batch calls are what make the volume tractable.
Keeping client data separate at scale
Because the API is stateless and holds no concept of "client," separation is enforced entirely by whatever identifier your own system attaches to each request and stores alongside the result — the same discipline a firm already applies to keeping client ledgers, working papers and engagement letters apart. Nothing about calling the API for client A exposes anything about client B, since each call is an independent request with no shared state between them.
For firms operating under client confidentiality agreements or regulatory requirements around data segregation, this statelessness is a practical advantage: there is no shared multi-tenant database on the extraction side to configure permissions around, because there is no persistent client data on the extraction side at all — see the security section later on this page for what happens to a document after it is processed.
| Separation layer | Where it lives |
|---|---|
| Client identifier | Your own system — attached to the request, never sent to or stored by the extraction API |
| Document storage | Your own storage/practice-management system; originals are deleted from FlowParse shortly after processing |
| Extracted results | Returned directly to your call and stored wherever your pipeline writes them — never retained centrally by FlowParse |
| Access control | Enforced entirely inside your own practice-management or GL software, exactly as it is today |
The staffing math this replaces
A trained bookkeeper keying transactions from a PDF statement into ledger software manually takes roughly one to two minutes per page for a straightforward statement, longer for a dense invoice with many line items or a statement layout the bookkeeper hasn't seen before. For a firm processing a few thousand pages a month across its client roster, that arithmetic adds up to dozens of hours of pure data-entry time every month — time billed against overhead rather than client advisory work, which is where a bookkeeping firm's actual margin comes from.
Automating the typing does not automate the judgment a bookkeeper applies — categorizing an ambiguous transaction, spotting a duplicate, flagging something that needs a client conversation. What it removes is the mechanical re-keying step underneath that judgment, freeing staff hours to move toward the review and advisory work a client is actually willing to pay a premium for, rather than the typing a client assumes is already automatic in 2026.
What manual data entry actually costs per client
Put in dollar terms rather than minutes, a mid-sized client sending an average of forty pages a month (a few bank and card statements, a handful of vendor invoices) costs a firm roughly forty to eighty minutes of bookkeeper time purely on data entry, before any actual bookkeeping judgment is applied. At a fully loaded staff cost of $25–$40 an hour, that is $17–$53 of pure typing cost per client, per month — before counting the cost of correcting the inevitable transposition errors that manual entry introduces at volume.
| Cost driver | Manual entry, per client/month | FlowParse API, per client/month |
|---|---|---|
| Bookkeeper typing time (40 pages) | 40–80 minutes | 0 — data entry removed |
| Fully loaded labor cost | $17–$53 | €1.40 (40 pages × €0.035) |
| Error-correction time | Variable, often 10–20% of entry time | Near-zero — arithmetic pre-validated |
Multiplied across a full roster, this is the same gap the blog post linked at the end of this page, why outsourced bookkeeping firms need an extraction API, not more staff, walks through in the context of hiring decisions specifically — a firm considering whether its next hire should be another data-entry bookkeeper or whether that same budget is better spent elsewhere.
Pricing: flat €0.035 per page, at any volume
Every page — statement, invoice or receipt, from any client — bills at the same flat €0.035, with no enterprise tier to negotiate before high volume becomes economical and no per-client minimum. The full mechanics are on the flat-rate pricing page; for a BPO specifically, the relevant property is that the rate never steps up as the roster grows — client 500's pages cost exactly what client one's did.
This predictability matters for a firm that prices its own services per client — the extraction cost for onboarding a new client is knowable in advance, before their first statement even arrives, which is difficult to say about a staffing decision that only pays off once utilization is high enough to justify it.
Turnaround and SLA at production volume
A single document typically returns in a few seconds. At batch scale — several hundred documents queued for a monthly close — concurrent processing means the practical limit on turnaround is how many requests your own pipeline issues in parallel, not a queue on FlowParse's side. Most firms running a full monthly close batch see the entire batch complete well inside a same-day window, which comfortably supports both monthly and weekly close cycles.
| Batch size | Typical turnaround, concurrent calls |
|---|---|
| One client's monthly documents (~40 pages) | Under a minute |
| A 60-client monthly close batch (~2,400 pages) | Well under an hour |
| A 300-client month-end batch (~12,000 pages) | Same-day, spread across the close window |
A worked example: a 60-client bookkeeping firm's monthly run
A firm managing sixty small-business clients, each averaging one bank statement (3 pages), one card statement (2 pages) and roughly six vendor invoices (1 page each) a month, processes:
| Document type | Volume × pages | Monthly cost |
|---|---|---|
| Bank statements | 60 × 3 = 180 pages | €6.30 |
| Card statements | 60 × 2 = 120 pages | €4.20 |
| Vendor invoices | 60 × 6 = 360 pages | €12.60 |
| Monthly total | 660 pages | €23.10 |
Against the roughly 40–80 minutes of bookkeeper time per client the same volume would otherwise need — 40 to 80 hours across the whole roster — €23.10 a month is the entire extraction cost line, freeing that staff time for exception review, client calls and the advisory work a growing firm actually wants more of.
Accuracy and validation your reviewers can trust
A bookkeeping firm's reputation depends on numbers that reconcile, not just numbers that look plausible. Every bank and card statement's closing balance is checked against the sum of its own transactions before the result comes back; every invoice's line items are checked against its printed subtotal and tax. A statement whose numbers don't reconcile internally is flagged rather than returned as if it were clean — the same discipline a careful bookkeeper applies by hand, automated at the point of extraction.
This matters more at BPO scale than it does for a single company's books, precisely because the volume makes manual spot-checking every document impossible. A confidence and validation signal on every result lets a review team focus its limited attention on the documents that genuinely need a human eye, rather than re-checking work that is already internally consistent.
Document types a bookkeeping firm actually receives
| Document | What comes back |
|---|---|
| Bank statements | Every transaction as a signed, dated, described row, opening/closing balance checked |
| Card statements | Transaction-level detail with merchant, date and amount for expense categorization |
| Vendor invoices | Vendor, invoice number, date, line items, tax and total, mapped to a payable-ready shape |
| Receipts | Merchant, date, subtotal, tax, tip, total and line items for expense reports and reimbursement |
Document type is detected automatically on every call, so a firm's intake pipeline doesn't need to pre-sort a mixed batch of statements and invoices before sending it — the API tells you what it received.
How to integrate into an existing production pipeline
Get an API key
Free plan accounts get a real key and full accuracy against a smaller monthly allowance — enough to run a genuine pilot batch.
Point your intake queue at POST /extract
Whatever collects client documents today — a shared drive, an upload portal, an inbox parser — feeds the same endpoint, one document per call.
Fire calls concurrently for batch volume
Most BPO integrations issue many requests in parallel from a queue, rather than processing documents one at a time in sequence.
Attach your own client identifier to each result
The API returns no client concept of its own — your pipeline tags each result with whichever client/engagement ID it already tracks.
Route low-confidence results to review
A confidence signal on each response lets staff focus on the documents that actually need a second look.
A full walkthrough, including how a firm structures a concurrent batch job specifically, is in the guide how BPO firms scale document processing with an API.
Feeding extracted data into practice-management and GL software
Structured JSON maps cleanly onto most practice-management and general-ledger import formats — the same field names a bookkeeper would type by hand (date, description, amount, vendor) come back pre-populated rather than needing a second parsing pass. XLSX and CSV export in the same call cover the firms whose workflow still runs through a working-paper spreadsheet before anything is imported.
Onboarding a new client without new engineering work
Because nothing about the API is configured per client, adding client two hundred and one to the roster requires zero extraction-side setup — no new bank template to build, no model to retrain, no integration ticket for engineering. The only onboarding work is what a firm already does internally: assigning the client an ID, setting up their chart of accounts, and pointing your existing intake pipeline at their documents the same way it already handles every other client.
This is a meaningfully different growth model than a firm relying on live bank-feed connections, where each new client can mean confirming their specific bank is supported and re-establishing a feed — work that scales roughly linearly with headcount. A document-based pipeline scales flat: the thousandth client's onboarding looks exactly like the first's.
Where human review still belongs
Extraction removes the typing, not the accounting judgment — categorizing an ambiguous transaction against a client's chart of accounts, deciding whether a large unexplained deposit needs a client conversation, catching something that looks like fraud rather than a coding error. Those decisions still belong with a trained bookkeeper, and a confidence signal on every extracted document is designed to direct that attention efficiently rather than replace it — flagging the small fraction of documents that are genuinely ambiguous instead of asking a reviewer to re-check everything.
Who this is built for
Outsourced bookkeeping firms and accounting BPOs
Processing statements and invoices for dozens to hundreds of clients every month.
Firms scaling past what manual entry can keep up with
Where a growing client roster is outpacing the data-entry hours available to type it.
Practice-management platform builders
Adding document extraction as a feature inside a broader bookkeeping or accounting workflow product.
Firms evaluating IDP vendors for the first time
Comparing a flat, volume-agnostic API rate against per-seat or per-document vendor pricing.
Common objections, answered honestly
"Our clients' documents are too varied for an automated tool" is the most common objection a bookkeeping firm raises, usually based on experience with an older, template-driven OCR tool that genuinely did struggle outside a narrow set of layouts. A classification-first pipeline built across a broad range of real bank and invoice formats, rather than tuned to a handful of templates, handles that variety by design — it is the specific problem the pipeline is built to solve, not an edge case bolted on afterward.
A second objection is data security — sending client financial documents to a third party feels like a compliance risk. In practice, documents are processed and deleted shortly afterward, nothing uploaded is used to train models, and the API itself never stores a client identifier — the security section later on this page covers the specifics a firm's own compliance review will want.
A third, quieter objection is staff concern about job security. In practice, the firms that adopt this kind of tool most successfully use it to shift staff time toward higher-value review and advisory work rather than eliminating roles outright — a data-entry bookkeeper whose typing load drops is the person best positioned to become the reviewer catching the exceptions the API flags.
What changes as the firm scales past 100 clients
Below roughly a hundred clients, many firms still get by on a mix of live bank feeds and manual entry, because the volume is survivable with the staff on hand. Past that point, the math tends to flip: the hours needed to keep pace with manual entry grow linearly with the client count, while the extraction cost per client stays flat and small. Firms crossing this threshold are the ones most likely to see immediate, measurable relief from moving statement and invoice entry onto an API — not because smaller firms don't benefit, but because the staffing pressure becomes acute enough to force the decision.
Migrating from manual entry or a legacy scanning tool
Most firms migrate gradually, running the API alongside existing manual entry for a subset of clients first — commonly the clients generating the highest document volume, since that is where the time savings show up fastest — before extending it to the full roster 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 client documents are deleted shortly after processing.
Nothing uploaded is ever used to train AI models.
The API holds no client identifier or persistent client record of its own.
Full details are on the security page.
Get your API key
Run a real batch of client statements and invoices through /extract and compare the output against what your current process produces. A free plan account uses the exact same accuracy as a paid one, just against a smaller monthly allowance — enough for a genuine pilot.