How OCR Pricing Counts a Page (and Why Your Bill Is Higher Than You Estimated)

Every major OCR vendor quotes a price per 1,000 pages. Almost none of them mean the same thing by the word page. A page can be a physical sheet, a 3,000-character block of text, one worksheet in a spreadsheet, one slide, a ten-page billing block, or a document of up to fifteen pages. Which definition applies decides your bill, and it is the single most common reason a real invoice comes in above the estimate.

Here are the rules the four services actually use, verified in July 2026 from vendor documentation and price feeds.

What counts as a page in OCR pricing?

A page is whatever the vendor's billing meter says it is. For scanned files it is almost always one physical page. For everything else, vendors apply page-equivalent rules: Azure counts 3,000 characters of text as one page and one Excel worksheet as one page, Google's prebuilt parsers bill in ten-page blocks regardless of how many pages you send, and Veryfi bills per document of up to fifteen pages rather than per page at all. The unit, not the rate, usually determines which vendor is cheapest for your documents.

Azure: 3,000 characters is a page, and hidden sheets are billed

Azure Content Understanding publishes the most explicit page-equivalent rules of any vendor, and they are worth knowing even if you use a different service, because the same logic quietly applies elsewhere.

The hidden-worksheet rule is the one that produces surprising invoices. A workbook that looks like three tabs to a human can carry a dozen hidden sheets left over from someone's pivot table, and every one of them counts as a billable page. If you process spreadsheets in volume, auditing them for hidden sheets before you send them is a real line-item saving, not a micro-optimization.

The 3,000-character rule cuts the other way and is usually good news. A short email is one page. A long email thread with quoted history can be five or six. Emails are one of the few document types where the billed page count has no relationship at all to what anyone would call a page.

Azure AI Document Intelligence, the older service, applies the same 3,000-character and one-sheet-per-page logic for Office files on its Read and Layout models. It is the only Azure service that accepts Office files, and only on those two models.

The digital-file trap: paying for OCR that never ran

Here is a cost difference almost nobody accounts for. Azure Content Understanding bills a Minimal meter of $0.01 per 1,000 pages for digital files such as DOCX, XLSX, HTML and TXT, because no OCR is performed on a file that was never a scan. Azure AI Document Intelligence has no equivalent meter and charges the full Read rate of $1.50 per 1,000 pages for the same file.

That is a 150-fold difference on identical input, and it is invisible until you look at which meter fired. If a meaningful share of your pipeline is digital rather than scanned, it is very likely the largest single saving available to you, and it costs nothing but a service swap. The full rate card is on our Azure Content Understanding pricing reference.

The general lesson generalizes past Azure: check whether your vendor charges you for OCR on files that did not need OCR. Many do.

Google: the ten-page billing block that swings costs tenfold

Google Document AI's prebuilt Invoice, Expense and Utility parsers do not bill per page. They bill $0.10 per ten-page block, and a block is consumed whole whether you fill it or not.

Send ten-page batches and you pay $10 per 1,000 pages. Send a one-page invoice as its own request and it still consumes an entire ten-page block, which works out to $100 per 1,000 pages. Same published rate, a tenfold cost difference, driven entirely by how you batch your requests. If you process one-page invoices one at a time, which is exactly what a naive integration does, you are paying ten times the advertised price and the pricing page will never tell you.

Google's own Enterprise Document OCR does bill per page at $1.50 per 1,000, so the block rule is specific to the prebuilt parsers. Its other per-document rates, such as $0.75 for a bank statement and $0.30 for a W-2, are billed per document, which is a third unit again.

Google Cloud Vision: a page is a feature on an image

Cloud Vision is priced per unit, and a unit is one feature applied to one image. Each page of a PDF or TIFF counts as one image. Ask for two features on the same page and you are billed two units. This rarely bites on plain OCR, where you request one feature, but it doubles quietly the moment someone adds a second detector to the call.

Veryfi: a page is a document of up to fifteen pages

Veryfi bills per document, not per page, and a document means up to fifteen pages. This inverts the entire comparison depending on how long your files are.

The same vendor is either fifty times more expensive than Azure Read or cheaper than Azure Layout, and nothing about the rate card changed. Only the length of your documents did. Per-document pricing rewards long files and punishes short ones, which is precisely why a receipt-heavy workload and a statement-heavy workload should not use the same shortlist.

Nanonets: a page is not a unit at all

Nanonets bills per block run, where a block is a step in a workflow rather than a page of a document. Its own documentation gives a typical invoice as four to six blocks. Because the number of blocks depends on how you build the workflow and not on how many pages you send, there is no honest way to convert Nanonets into a per-1,000-pages figure. Any site publishing one has invented it. We say so on our OCR pricing per 1,000 pages reference rather than making a number up.

How to estimate what you will actually pay

Three steps, in this order.

Count your pages the vendor's way, not yours. Take a representative sample of 100 real files. Count physical pages for scans, worksheets for spreadsheets (open the hidden ones), 3,000-character blocks for text and email, and billing blocks for Google's prebuilt parsers. That number, not your file count, is what gets multiplied by the rate.

Check whether batching changes the unit. If you are on a Google prebuilt parser, how you group requests is worth up to ten times the bill. If you are on Veryfi, document length is worth up to five times. Neither is visible on a pricing page.

Check whether you are paying for OCR you do not need. Digital PDFs, Word files and spreadsheets should not cost the same as scanned paper, and on at least one service they no longer do.

And if the destination for all of this is a spreadsheet anyway, it is worth asking whether you need an OCR API in the loop at all: for many finance workflows the shortest path is to turn the PDF straight into a clean Excel file and skip the integration work entirely.

The rule underneath all of this

Vendors choose their billing unit strategically, and the unit that makes a vendor look cheapest is usually the unit that matches their own best-case document. Per-document pricing looks brilliant until you send one-page receipts. Per-block pricing looks brilliant until you send single invoices. Per-page pricing is the only one that behaves the way you expect, and even then a page might be a hidden worksheet you did not know existed.

Normalize everything to dollars per 1,000 real pages of your documents before you compare anything. It routinely changes the ranking.

Rules verified July 2026 from Microsoft Learn, the Azure Retail Prices API, and the Google, Veryfi and Nanonets pricing pages. Vendors change billing units, not just rates, so re-check before committing.