Does Batch OCR Cost Less? What Each Vendor Actually Charges

Last updated July 12, 2026. Verified against Microsoft's official Azure Retail Prices API, the AWS Textract pricing page and the Google Document AI pricing page.

Batch OCR does not cost less at Azure, AWS or Google. All three meter batch and asynchronous analysis at exactly the same rate as a real-time call. Azure's own price feed lists batch Read at $1.50 per 1,000 pages, batch Layout at $10, batch prebuilt at $10 and batch custom extraction at $30, which are the identical pay-as-you-go rates. The only vendors that genuinely discount batch are the LLM providers: Mistral cuts batch inference by 50%, and Gemini Batch is also half price. On the cloud OCR services, batch buys throughput and simpler code, not a smaller bill.

Batch OCR pricing by vendor

The split is not an accident. The cloud OCR services run fixed inference on purpose-built models, so a queued page costs them about what a live page costs them. The LLM providers have genuinely elastic GPU capacity and can fill idle time, so they can afford to pay you to wait.

Then why use batch OCR at all?

Because it removes limits, not cost. On Google Document AI, the online endpoint caps a request at 15 pages and 40 MB, and exceeding it raises PAGE_LIMIT_EXCEEDED. Batch raises that to 1 GB a file, up to 1,000 pages a file depending on the processor, and 5,000 files a batch. If your documents are long, batch is not an optimization, it is the only path that works.

Batch also simplifies your code. Instead of a queue, a retry loop and a rate limiter, you hand the service a storage container and collect results. And it protects your rate limits: Azure's default analyze throughput is 15 transactions a second, and a batch operation manages that pacing for you rather than making you back off on every 429.

Does batching pages into one request make OCR cheaper?

On per-page vendors, no. Azure, AWS, Mistral and Google's page-metered processors all count pages, so ten pages cost the same whether they arrive in one request or ten. On Google's prebuilt Invoice, Expense and Utility parsers, batching absolutely does change the bill, and dramatically. Those parsers charge $0.10 per 10-page block, rounded up. A single 1-page invoice sent as its own request consumes a whole block, so it costs $0.10, or $100 per 1,000 pages. Ten single-page invoices sent as one 10-page request cost that same $0.10 in total, or $10 per 1,000 pages.

That is a tenfold saving, from batching alone, with no discount involved. It is the only place in cloud OCR where request shape, rather than page count, drives the price, and it catches out almost every AP team processing invoices one at a time as they arrive.

How to actually reduce an OCR bill

If batch is not the lever, these four are, roughly in order of impact.

• Use the cheapest model that answers your question. Read is $1.50 per 1,000 pages. Custom extraction is $30. If a prebuilt model covers your document type, moving off custom extraction cuts that line by two thirds.
• Check whether your volume clears a commitment tier. Azure's Read commitment at 500,000 pages a month is $375, the same as 250,000 pages pay-as-you-go. If you are near the floor, the commitment doubles your allowance for nothing.
• Fill Google's 10-page blocks. A tenfold saving on prebuilt parsers for the cost of a queue.
• Trim your LLM output schema. On token-priced extraction, output is 92% to 96% of the bill. Asking for fewer fields, or terser ones, is a direct discount.

What none of that touches is the review cost. No vendor refunds a wrong read, so an inaccurate model bills exactly the same as an accurate one and then hands you the correction work. Teams that already know this pick on output quality and treat the rate as a tiebreak. If your extracted rows end up in a ledger, the destination matters as much as the engine: many finance teams skip the parsing project entirely and push the PDF statement straight into QuickBooks rather than building a pipeline around a cheap per-page rate.

What "batch" actually means at each OCR vendor

The word covers three different things, which is part of why teams expect a discount that is not there.

• Azure AI Document Intelligence has a batch analysis operation that points at an Azure blob container and processes every document in it, writing results back to storage. It exists so you do not have to write a loop, a queue and a retry handler. Microsoft's price feed carries separate batch meters, and they are set to the identical rates as the synchronous ones.
• AWS Textract splits its API into synchronous and asynchronous operations. The asynchronous ones (StartDocumentAnalysis, StartDocumentTextDetection) exist because multi-page PDFs cannot go through the synchronous path at all. Async is a capability, not a pricing tier, and AWS publishes one rate per feature.
• Google Document AI draws the hardest line. Its online endpoint is capped at 15 pages and 40 MB. Its batch endpoint takes 1 GB a file, up to 1,000 pages a file on Enterprise Document OCR, and 5,000 files a batch, with 5 concurrent batch requests a project. If your documents are long, batch is mandatory, and it is priced the same.
• Mistral and Gemini use "batch" the way LLM providers do: you submit a job, they run it whenever capacity is free, and you get 50% off for accepting the delay. This is the only real discount in the category.

Does batch OCR change accuracy?

No. The same model weights run on a batch page and a live page, so a document that extracts correctly through the synchronous endpoint extracts identically through the batch one. What batch changes is latency: a synchronous call returns in seconds, and a batch job returns in minutes to hours depending on queue depth and size. That trade is fine for archive digitization, month-end statement runs and overnight invoice loads. It is not fine for a user waiting on an upload, which is why most production systems end up running both paths against the same model.

Should you use batch OCR?

Use batch when your documents are longer than the synchronous limits allow, when you are processing a backlog rather than live traffic, when you want the vendor to handle pacing instead of writing your own rate limiter, or when you are on Mistral or Gemini and the 50% discount is real money. Stay synchronous when a person is waiting for the result, or when your volume is low enough that the operational simplicity of a single API call beats managing job state. What should not appear in the decision at all, on Azure, AWS or Google, is the expectation of a cheaper page.

The short version

Batch OCR at Azure, AWS and Google costs exactly what real-time OCR costs. Use it because it lifts the page and file-size ceilings and makes your code simpler, not because you expect a discount, and do not build a business case on savings that do not exist. If you want a real batch discount, it lives at Mistral and Gemini, both at 50%. And if you are on Google's prebuilt parsers, go fill those 10-page blocks, because that one is worth 10x.

For the full normalized rate table, see OCR pricing per 1,000 pages. For the page and file-size ceilings that make batch necessary, see OCR API limits compared, Google Document AI limits and Azure Document Intelligence limits. If you are processing archives rather than live traffic, batch OCR software covers the workflow side.