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 firm actually works. This page is written the other way around — eight concrete situations a real outsourced bookkeeping or accounting BPO firm 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 bookkeeping and BPO operations, not a hypothetical. Some firms 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, client 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 bookkeeping BPO's document workload
Most of these scenarios share an underlying shape: many clients, an unpredictable but recurring flow of statements and invoices, and a periodic crunch (a monthly close, a tax season, a new client's onboarding) where the volume spikes above what manual entry can comfortably absorb. The API doesn't change per-document extraction depending on which scenario it's used in — every use case below is the same /extractcall, applied to a different moment in a firm's workflow.
What differs between scenarios is almost entirely orchestration — when documents 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 firm doesn't need eight different integrations, just one, applied at eight different points in its operation.
1. The monthly close, run as a batch
The most common use case: every client's statements and invoices for the month, collected over several weeks, processed in one concurrent batch run in the days before close, with balance-checked results feeding straight into review and GL import. This is the scenario covered in full, with a worked example, in the document extraction API for bookkeeping firms page.
For most firms, this single scenario alone justifies the integration — it's the highest-volume, most time-pressured recurring event in the operation, and the one where a slow manual process is most visible to everyone, from staff working late to a principal explaining a delayed deliverable to a client.
2. Onboarding a new client with historical catch-up
A new client often arrives with six or twelve months of un-entered statements — the backlog that has to be cleared before their books are current enough to take over ongoing bookkeeping. Rather than working through that backlog manually week by week, it's processed as one large batch on day one, giving the firm a current, reconciled starting point almost immediately instead of weeks into the engagement.
This scenario has a secondary benefit worth naming: a fast, clean onboarding is itself a strong first impression for a new client evaluating whether they made the right choice of firm. A backlog cleared in days rather than weeks signals competence in a way a new client notices immediately.
3. A seasonal volume spike, like tax season
Document volume at many firms isn't flat across the year — tax season, year-end close, or a client's own busy period can multiply monthly volume several times over. Because extraction cost and throughput scale directly with volume rather than fixed staffing, a firm doesn't need to hire seasonal temps or run staff into overtime to absorb a spike; it simply processes more pages at the same flat rate.
Firms that have historically relied on seasonal temporary hires to absorb this spike often find the training overhead for a role lasting only a few months is, itself, a meaningful cost — one this scenario removes entirely rather than just shifting.
4. Weekly bookkeeping for a high-transaction client
A retail, restaurant or e-commerce client generating high transaction volume often needs weekly rather than monthly bookkeeping to keep cash-flow visibility current. Weekly statement extraction for a client like this follows the exact same batch pattern as a monthly close, just run on a tighter cadence — the API has no concept of "monthly" that needs adjusting for a different schedule.
This is a good example of how the same underlying integration serves very different cadences without extra engineering — a firm offering both monthly and weekly service tiers to different clients runs one pipeline, simply triggered on different schedules per client.
5. Migrating off manual entry, client by client
A firm moving its whole roster off manual entry rarely does it all at once — the gradual, comparison-driven migration described in the scaling guide is itself a use case worth naming on its own: running the API in parallel with existing manual entry for a handful of clients, confirming the output matches, then cutting those clients over before moving to the next wave.
Firms in the middle of this migration commonly run a hybrid state for months — some clients fully automated, others still on manual entry — without any operational conflict, since each client's workflow is independent of every other client's.
6. Vendor invoice processing for AP-heavy clients
Some clients generate more vendor invoices than bank transactions — a construction or professional services client managing many subcontractor or supplier bills, for instance. The same API extracts vendor, invoice number, line items, tax and total from each invoice, matched to the fields an accounts-payable workflow actually needs, rather than only handling statements.
For a client like this, statement and invoice extraction typically run through the same batch process, tagged and routed by document type on the receiving end — a firm doesn't need a separate integration for AP-heavy clients versus statement-heavy ones.
7. A practice-management platform adding batch import
A software vendor building a practice-management or bookkeeping platform for BPO firms can embed the same extraction API as a batch-import feature inside its own product, rather than leaving each customer firm to build or buy its own extraction separately — the same build-vs-buy logic covered for expense-management platforms in the SaaS-embedding cluster applies here to practice-management software specifically.
This scenario differs from the others in who's doing the integrating — a software vendor rather than a services firm — but the API call underneath is identical, and the resulting feature becomes something the platform can offer every one of its own customer firms at once.
8. Audit preparation across a multi-year document set
An audit or a client's records request sometimes needs structured transaction data reaching further back than any live bank feed ever covered — several years of historical PDF statements that were archived 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 prepare for the audit.
This scenario is a one-off for most firms rather than a recurring workflow, which makes it a particularly clear illustration of the cost comparison — a large historical batch that would take a team weeks to key manually processes in the same batch pattern as any monthly close, just larger.
Picking the scenario closest to your firm
| If your firm... | Start with scenario |
|---|---|
| Runs a monthly close across many clients | 1 — the monthly close batch |
| Is actively adding new clients | 2 — onboarding with historical catch-up |
| Sees a sharp seasonal volume spike | 3 — seasonal volume spike |
| Is still fully on manual entry | 5 — gradual migration |
| Is a software platform, not a services firm | 7 — embedded batch import |
These eight are the most common patterns, not an exhaustive list — the underlying call is the same for any workflow that starts with a PDF and needs structured, validated data out, so a firm whose situation doesn't map neatly onto one of these can typically still apply the same mechanics.
It's also common for a firm to recognize itself in more than one row at once — a growing firm is very often simultaneously running monthly closes, onboarding new clients, and approaching a seasonal peak. 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: staff hours redirected from typing to higher-value review and advisory work, and avoided seasonal or growth-driven hiring that would otherwise be needed purely to keep pace with volume. For a 60-client firm processing roughly 2,000 pages a month, the extraction cost runs about €840 a year against 40–80 hours a month of manual-entry time freed up — time worth considerably more than the extraction cost at any reasonable bookkeeper billing rate, covered with full numbers in the staffing comparison.
This ROI compounds across the eight scenarios rather than being a one-time gain — the same freed staff time and avoided hiring shows up whether the volume driving it is a monthly close, a seasonal spike, or a new client's onboarding backlog, since all of it flows through the same extraction cost line rather than a separate budget for each situation.
The common thread across every scenario
Every scenario on this page is, underneath, the same trade: replacing the mechanical step of typing a document's numbers into a system with an API call, while leaving the accounting judgment that happens after extraction entirely in the hands of the firm's own staff. None of these use cases involve the API making a categorization decision, a client-relationship decision, or a judgment call — it turns a document 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 staff and clients
Internally, framing matters: staff who currently spend their days on data entry respond very differently to "we're automating your job" than to "we're removing the tedious part of your job so you can spend more time on the parts that actually use your training." Involving the team that will use the review queue in setting its initial confidence threshold — see the scaling guide's step on this — builds trust in the system faster than presenting it as already decided. Externally, clients rarely need to be told anything changed at all; what they notice is faster turnaround and more attentive service, not the mechanism behind it.
The firms that navigate this most smoothly tend to pilot quietly on a small scenario first — scenario 2 (a single new client's onboarding) 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 firm, to give a sense of scale before running the numbers against your own actual volume.
| Scenario | Illustrative volume | Illustrative cost |
|---|---|---|
| Monthly close (60 clients) | ~660 pages | ~€23/month |
| New client onboarding (12-month catch-up) | ~120 pages | ~€4.20 one-time |
| Tax-season spike (3× normal volume) | ~2,000 pages | ~€70/month |
| Multi-year audit prep | ~1,000 pages | ~€35 one-time |
Beyond the eight: a ninth pattern worth naming
A pattern that comes up often enough to mention separately: a firm managing a client that is itself a small group of related entities — several LLCs under one owner, a franchise operator with multiple locations, a property manager with per-building accounts — needs statements from every entity consolidated into one coherent picture. The batch mechanics are identical to the monthly close scenario; what differs is that the "client ID" tag is really a two-level tag (client, then entity within that client), 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 multi-entity consolidation 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 field in your own correlation logic.
What these use cases don't cover
None of the eight scenarios above involve the API making a categorization or advisory decision — every one of them ends with structured, validated data landing in front of a person, not a fully autonomous bookkeeping process. Firms looking for a tool that also decides how to categorize an ambiguous transaction against a specific chart of accounts, or that replaces a reviewer'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
Firm principals evaluating whether this fits their workflow
Looking for a concrete scenario that matches their actual day-to-day, not a generic feature list.
Operations leads planning an implementation
Deciding which scenario to pilot first and how to sequence a broader rollout.
Practice-management software builders
Evaluating whether to embed extraction as a feature inside their own platform.
Firms preparing for an audit or a large historical catch-up
Needing to reconstruct structured data from an archive of old statement 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 operation where a document 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 firm 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, the monthly close is the safest default — it's the highest-volume recurring workflow at nearly every firm, and proving it out there gives you a working integration you can extend to every other scenario on this page afterward.