Per-document vs per-page pricing for document extraction

Extraction pricing usually comes in one of two shapes: a flat rate per document, or a rate per page. Per-page looks cheaper on the pricing page — smaller number, easier to feel good about — and that’s exactly why it’s worth doing the multiplication before picking a vendor on sticker price alone.

The 300-page report problem

Say a per-page vendor charges what looks like a trivially small amount per page. Run a two-page invoice through it and the bill is basically nothing. Run a 300-page annual report, a compliance filing, or a technical manual through the same pricing, and that “trivially small” number gets multiplied by 300 — a single document now costs as much as a hundred two-page ones did. Per-document pricing charges the same amount whether the file is two pages or three hundred, because the unit being priced is “a document ingested,” not “a page rendered.”

For any pipeline that ingests real-world business documents — reports, contracts, manuals, filings — page count varies enormously across the document set, and it’s the long documents, not the short ones, that dominate the bill under per-page pricing. A handful of 300-page filings can cost more than the rest of your entire archive combined.

Where per-page pricing actually wins

This isn’t a case against per-page pricing everywhere — it’s a case for knowing which shape matches your workload. If your document set is genuinely single-page — receipts, one-page forms, individual invoices — then per-page and per-document pricing converge to roughly the same number, and whichever has the lower headline rate for that page count wins outright. Per-page pricing is worse specifically in proportion to how many multi-page documents you have, not in general.

Estimating your own mix

The number that predicts your actual bill isn’t “average page count” — a mean gets dragged around by a handful of huge outliers, the same way it would for anything with a long tail. What matters is the shape of your document distribution: mostly-short documents with an occasional long one behave very differently under per-page pricing than a mix that’s evenly spread across page counts. Before comparing vendors, it’s worth pulling the page-count distribution of a representative sample of your actual archive rather than guessing from a handful of documents you happen to have open.

# rough page-count histogram for a local PDF archive
for f in *.pdf; do pdfinfo "$f" | grep Pages; done | awk '{print $2}' | sort -n | uniq -c

txtfetch prices per document, not per page, specifically because of this — a 300-page report and a 2-page memo cost the same to ingest, so growing your average document length doesn’t grow your bill. If you want to run the exact numbers against your own archive, the interactive pricing comparison walks through it with a real page-count distribution instead of a single averaged estimate.

Once the pricing model is settled

Cost predictability matters most at the volumes covered in the batch ingestion guide — a pricing model that’s fine for occasional single documents can surprise you once a backfill runs a few thousand files through it. See our pricing page for the current plans, or the specific vendor comparisons — starting with txtfetch vs Unstructured.io — if you’re evaluating alternatives on cost as well as extraction quality.

Want to run your own document mix against both pricing models? Get in touch and we’ll set you up with an API key.