OCR Pricing: Per Page vs Per Document vs Per Token Explained

Last updated July 12, 2026. Rates verified from each vendor's own pricing page or price feed.

OCR vendors use four different billing units, and the unit matters more than the rate. Azure, AWS and Google bill per page. Veryfi bills per document of up to 15 pages. Nanonets bills per block run, a workflow step. Gemini bills per token. Google's own prebuilt parsers bill in 10-page blocks. Compare headline rates without normalizing the unit and you will pick the wrong vendor, because the same list price can produce a tenfold difference in your actual bill depending on how long your documents are and how you batch them.

The four OCR billing units, side by side

Why the billing unit changes who is cheapest

Take Veryfi against Azure. Veryfi charges $0.08 for a receipt and $0.25 for a bank statement, per document, up to 15 pages. Azure charges $1.50 per 1,000 pages for Read, which is $0.0015 a page.

On a 1-page receipt, Veryfi's $0.08 normalizes to $80 per 1,000 pages. That is more than fifty times Azure. On a 15-page bank statement, Veryfi's $0.25 normalizes to $16.67 per 1,000 pages, which is cheaper than Azure's Layout model at $10 per 1,000 once you account for the fact that Veryfi returns statement-native fields and Layout returns tables you still have to interpret. Same two vendors, opposite conclusions, decided entirely by document length.

This is not a trick. It is the whole reason vendors choose their unit. A per-document vendor is betting your files are long. A per-page vendor is betting they are short.

The 10-page block trap in Google Document AI

Google's prebuilt Invoice, Expense and Utility parsers bill $0.10 per 10-page block, rounded up. If you send requests containing 10 pages each, that is $10 per 1,000 pages, right in line with Azure's prebuilt rate. If you send a single 1-page invoice as its own request, it consumes an entire block, and your effective rate is $100 per 1,000 pages.

Ten times the cost, same published price, decided purely by how you batch. Most AP workflows process invoices one at a time as they arrive, which is exactly the pattern that triggers the worst case. If you are on Google's prebuilt parsers and your invoices are single pages, batching them into groups of ten before the API call is the single highest-leverage change you can make to that bill.

How do you compare a per-token OCR price to a per-page one?

You compute it, because no LLM vendor publishes a per-page rate. Google documents that each document page is equivalent to 258 input tokens for Gemini, which gives you the input side. The trap is the output side: output tokens are billed at 4 to 8 times the input rate, and a structured JSON extraction produces far more output tokens than the page produced input tokens. In practice, output is 92% to 96% of a real Gemini OCR bill.

That is why so many guides quote around $0.03 per 1,000 pages for Gemini and are roughly thirteen times too low: they counted input only. Assuming a realistic 750 output tokens a page, Gemini 2.5 Flash-Lite works out to about $0.33 per 1,000 pages, and Gemini 3.1 Pro Preview to about $9.52. Anyone quoting a Gemini page rate without stating an output-token assumption is guessing.

Which OCR billing unit should you look for?

Match the unit to the shape of your documents, then check the rate.

• Short, high volume (receipts, single-page invoices, IDs): per-page pricing wins. Avoid per-document vendors and Google's 10-page blocks unless you batch.
• Long documents (bank statements, contracts, loan files): per-document pricing can be dramatically cheaper, and a 15-page cap is generous.
• Mixed lengths: per page is the safe default, because it never surprises you. Per-document pricing on a mixed corpus means your one-page files subsidize your long ones.
• Complex multi-step workflows: watch per-block-run pricing carefully. Nanonets bills each step, and its own documentation puts a typical invoice at 4 to 6 blocks, so a $0.30 block rate is really $1.20 to $1.80 an invoice.
• LLM extraction: your cost is driven by the size of the JSON you ask for, not the size of the page. Trim the schema and the bill falls.

Does a cheaper unit mean a cheaper bill?

No, and this is where most comparisons go wrong. The unit sets the API charge, and the API charge is usually the smaller half of the real cost. A vendor that returns raw text at $0.0015 a page has handed you the job of locating, validating and exporting every field. A vendor that returns labeled, validated fields at $0.08 a document has done that work. The honest comparison is the rate plus the build against the rate plus the build, and a cheap unit that leaves you writing parsing logic for every layout is not cheap.

Finance teams feel this most acutely on statements, where the extracted rows need to land in a ledger rather than a JSON file. It is why so many bookkeepers skip the API question entirely and just convert the bank file straight into QuickBooks when the destination is an accounting system rather than a data warehouse.

Normalize before you negotiate

Before any vendor call, work out three numbers: your average pages per document, your monthly page volume, and the cost per 1,000 pages that each vendor's unit produces at that document length. Bring those to the conversation. A vendor quoting per document will not volunteer that your one-page files make their unit expensive, and a vendor quoting per page will not mention that your 40-page loan files make theirs look worse than it is.

Our OCR pricing per 1,000 pages reference does that normalization for every vendor, including the per-document, per-block and per-token ones. For the vendor-by-vendor detail, see Veryfi pricing (the main per-document vendor), Nanonets pricing (per block run), Gemini OCR pricing (per token), and the OCR API pricing comparison pillar for the buying decision.