Bulk PDF Data Extraction: Processing 10,000+ Documents Without Per-Page Billing

Bulk document extraction has a pricing problem before it has a technical one. Most document AI platforms meter by the page — and the moment your volume is real (10,000 invoices, a quarter's worth of bank statements, a client backlog of tax forms), per-page billing turns a simple pipeline into an unpredictable line item that someone in finance wants explained every month.

This post covers both halves of running bulk extraction well: the cost model, and the architecture. The examples use Dokyumi's real prices because they're the ones we can speak to precisely; the per-page comparison is described structurally, because metered pricing varies by vendor, volume, and feature flags — which is exactly the problem.

Why per-page billing hurts at bulk volume

Per-page metering — the model used by the big cloud OCR services and many parsing tools — sounds fair: pay for what you use. At small volume it is. At bulk volume, three properties work against you:

• Documents aren't one page. Invoices average 1–3 pages, bank statements routinely run 5–15, and consolidated tax packets can hit dozens. Your "10,000 documents" is 25,000–40,000 billable pages, and you won't know which until after processing.
• Feature multipliers. Metered platforms typically price base OCR, table extraction, forms/key-value analysis, and custom-model queries as separate per-page rates. Turning on the features you actually need for structured output multiplies the base rate — and the multiplier is different per vendor and per feature combination.
• No natural ceiling. A duplicate batch, a retry loop, or one oversized backlog import lands directly on the bill. Metered pricing means your worst engineering day and your worst billing day are the same day.

The practical consequence: teams doing bulk extraction on metered platforms end up building internal cost-tracking dashboards for their document pipeline. That's engineering time spent on watching a meter rather than on the pipeline itself.

The flat-tier alternative, with real numbers

Dokyumi sells page-weighted credits in flat monthly tiers. One credit covers a document up to five pages; longer documents use another credit for each five-page block, up to the 50-page self-serve cap:

• Free — $0: 25 credits/month, 2 schemas, 1 upload site; configured site submissions can use webhooks. Enough to benchmark quality on your real documents.
• Starter — $99/month: 500 credits, 10 schemas, 5 upload sites; configured site submissions can use webhooks.
• Growth — $499/month: 3,000 credits, 50 schemas, 25 upload sites; configured site submissions can use webhooks.
• Enterprise — quoted: custom credit volume, longer documents, unlimited schemas and upload sites, and contract-specific limits.

Three things fall out of that structure at bulk volume:

Page count is bounded and predictable. A 1-page receipt uses one credit; an 8-page bank statement uses two. Count pages in five-page credit blocks, and keep every self-serve document within the 50-page cap.

The unit price is knowable in advance. At Growth, $499 buys 3,000 credits, or about 16.6¢ per credit. One credit covers up to five pages; longer documents use multiple credits, while table extraction and schema validation do not add feature multipliers. Enterprise volume is quoted against the actual document mix.

Budgeting is a sentence, not a spreadsheet. "We pay $499 a month for 3,000 page-weighted credits" is the entire finance conversation. If a batch goes over quota, the failure mode is a conversation about the next tier — not an invoice spike.

To be fair about the trade-off: metered pricing can be cheaper at very low or wildly spiky volume, and if you only need raw OCR text, a bare OCR meter is the cheaper primitive. Flat tiers can fit sustained volume when the workflow needs structured output with confidence and validation details. For the full build-vs-buy and cost framing, see our guide to calculating document parsing ROI.

Architecting the bulk pipeline

With pricing predictable, the engineering is refreshingly boring. A bulk pipeline that holds up at 10,000+ documents a month has four parts.

1. Ingestion and queueing

Documents arrive from email attachments, SFTP drops, portal uploads, or a backlog export. Do not extract at arrival time — enqueue. A simple queue (SQS, a Postgres jobs table, or whatever you already run) decouples arrival spikes from processing rate and gives you resumability when anything downstream hiccups. New API keys default to 60 requests per minute, while the configured per-key limit applies; pace the worker to that value and honor Retry-After on a 429 response.

2. Process API batches with bounded concurrency

POST /api/v1/extract returns each result synchronously. Send file and the optional schema slug; this endpoint does not accept a per-request webhook_url.

curl -X POST https://dokyumi.com/api/v1/extract \
  -H "Authorization: Bearer dk_live_your_api_key" \
  -F "file=@statement-0042.pdf" \
  -F "schema=bank-statement-parser"

Your worker sends requests at a steady rate and records each response idempotently. Use the top-level id as the dedupe key. Webhook delivery is separate: it applies to documents submitted through a configured upload site, with its URL set under Sites → Settings.

3. OCR caching for the re-run problem

Bulk jobs get re-run: schema changed, a bug in your handler dropped results, someone re-imports last quarter. Dokyumi caches OCR results by file hash, so re-extracting a document it has seen skips the OCR pass entirely — re-runs are faster and don't burn your patience. Design for re-runs on your side too: keep source files addressable by hash so "reprocess March" is a command, not a project.

4. Confidence-based review at scale

At 10,000 documents, even excellent extraction leaves you with a review pile — the question is whether it is targeted. Successful API responses include structured data, a confidence map, and validation details, with status completed or review. For review results, inspect both validation.low_confidence_fields and validation.errors. Non-2xx error envelopes belong in the worker's retry or dead-letter handling.

• completed → apply your business checks, then persist to your database or ERP
• review → show the source document plus validation.low_confidence_fields and validation.errors to a human
• non-2xx error → retry only eligible failures; otherwise record the error envelope for intervention

Add deterministic cross-checks where the document allows them — invoice subtotal + tax = total, statement opening balance + transactions = closing balance — and your bulk pipeline verifies itself more rigorously than manual entry ever did. More on this in validating and improving extraction accuracy.

Worked example: a 12,000-document month

Say you're clearing an AP backlog: 12,000 vendor invoices, mixed 1–4 pages each. On a per-page meter you'd first need to answer "how many pages is that?" (you don't know) and "which analysis features do we need?" (table extraction, so the multiplied rate) before you could even estimate the bill.

On flat tiers the plan is: price the backlog in five-page credit blocks, use Growth when 3,000 monthly credits fit, or request an Enterprise quote for a larger or longer-document run. Either way the number is fixed before you start, and the invoice parser guide covers the schema and integration details end to end.

The pipeline: enqueue all 12,000 and process at a steady clip within the configured API-key limit. At 30 requests per minute, issuing 12,000 requests takes about 400 minutes (6 hours 40 minutes) before document latency, retries, and review work. Write each synchronous API response into your AP system, and request an approved limit change before increasing the drain rate. For multi-document-type backlogs, add a classification pass and route by type — the approach in multi-document processing at scale.

Common bulk-extraction mistakes

Testing on clean documents. Your pilot batch should be your ugliest fifty files — the faxed-then-scanned statements, the phone photos, the 2014 backlog. If the pipeline holds up there, the clean majority is free. If you validate on pristine PDFs, you discover your review-queue sizing in production.

Extracting fields nobody consumes. Every field in the schema costs extraction attention and review time when flagged. Bulk pipelines should carry the minimal schema the downstream system actually reads; you can always add fields and re-run against cached OCR later.

No idempotency in the webhook handler. Webhooks can be delivered more than once; batches get partially re-run. Handlers that blindly INSERT create duplicate rows at exactly the volume where deduping by hand is impossible. Upsert on the extraction ID from day one.

Treating review as failure. Do not automatically retry or discard a successful review result. Show a human the source document, validation.errors, and validation.low_confidence_fields, then apply your workflow's acceptance rules.

Ignoring the schema limit dimension. Bulk operations often involve several document types (a lending backlog has statements, W-2s, and pay stubs). Plan schemas per type up front — Starter includes 10, Growth 50 — rather than forcing one mega-schema to stretch across types.

The takeaway

Bulk extraction is two problems, and the pricing one is upstream of the engineering one: teams on metered billing design their pipeline around the meter (batching to avoid features, skipping re-runs, capping retries), which makes the engineering worse. A flat tier makes cost a constant, which frees the pipeline design to be whatever is most reliable.

If you're staring at a backlog, the free tier's 25 credits are enough to validate quality on your ugliest documents before you commit to anything — start there.