Research-backed calculator guide
OCR Batch vs Real-Time Cost: Price Latency, Capacity and Discounts Together
Compare OCR batch processing vs real time cost with a page-meter formula, capacity check, latency trade-off, review labor, and a worked monthly example.
Quick answer
OCR batch processing is usually the better cost shape when documents are bounded, deadlines are measured in hours, and you can start workers only during a controlled window. Real-time OCR is usually worth the extra capacity and operating cost when a document starts a user-facing decision, fraud check, support action, or other workflow whose value decays within seconds or minutes. The cheapest choice is not determined by the word “batch” alone.
Start with the provider’s billable unit. For a page-metered service, the base calculation is:
OCR API cost = billable pages × price per page × feature or model multiplier
Then add the costs that the API price does not answer: reserved or always-on capacity, queueing and orchestration, storage, retries, observability, human review, and the business cost of waiting. A batch queue can have a vendor-specific discount, but asynchronous submission is not automatically discounted. Azure’s published table, for example, lists “Batch read” at the same page rates as “Read,” while its commitment tiers change the effective rate through an upfront monthly fee. [5]
As a dated reference point, the official AWS Textract page gives a US West Oregon example of $0.0015 per page for the first 1 million pages of Detect Document Text, with a 100,000-page example totaling $150. [1] Google Cloud lists Enterprise Document OCR at $1.50 per 1,000 count for the 1,000-to-5,000,000 band and $0.60 per 1,000 count above 5,000,000 under its displayed pay-as-you-go schedule. [3] These are vendor-specific examples, not a market average or a quote for your workload.
What “batch” and “real time” mean for OCR
Batch OCR collects a bounded set of files, submits them on a schedule or when a threshold is reached, and publishes a completed result set. The natural unit of planning is the window: for example, “process yesterday’s 20,000 pages by 06:00.” This model makes it easier to validate file counts, rerun a failed partition, and scale workers up for a short period.
Real-time OCR starts processing as each document arrives and returns a result quickly enough for the next application step. “Real time” should be defined as a target, not a label. A 30-second result may be real-time for a back-office alert and unusable for an interactive upload. Write down the p95 time from upload to accepted output, then include queue time, OCR time, downstream extraction, and any human handoff.
Asynchronous OCR is a transport and workflow pattern, not a pricing category. AWS describes asynchronous operations for multipage PDF and TIFF documents and says they are useful for large documents because the application can continue while processing completes. [2] That may be the right implementation for a batch job, but it does not by itself prove a lower per-page rate. Keep these questions separate:
- When is the result needed? This sets the latency service level.
- How much work arrives together? This sets the batch size and peak throughput.
- What does the provider meter? This sets the invoice calculation.
- What must be staffed or kept running? This sets fully loaded cost.
A cost model that compares the whole workflow
Use two layers so a lower API bill does not hide a higher operating bill.
Layer 1: provider charges
provider cost = pages × unit price + optional feature charges + documented request or storage charges
The unit may be a page, image, document, character, token, or a provider-specific count. Do not convert a document rate to a page rate until the provider defines how pages are counted. Google’s pricing notes that a count can cover up to 10 pages for some pretrained processors, while its footnotes define page treatment differently by file format. [3]
Layer 2: workflow cost
workflow cost = provider cost + capacity + orchestration + storage + monitoring + retry cost + review labor + delay cost
Capacity is the main structural difference. Batch can use burst capacity for a known window and release it afterward. Real-time needs baseline capacity plus headroom for arrival spikes, even when the queue is quiet. If you operate a real-time path on a managed service with per-request pricing, capacity may appear as concurrency limits, reserved throughput, or a higher service tier rather than a VM line item.
Retry cost should be calculated from the pages actually retried, not from all pages. If a 2% retry rate is an assumption, write pages × 2% × unit price and show it separately. Review labor belongs in both paths when the same documents need the same exception handling. A fast OCR result does not eliminate a low-confidence review queue.
Finally, price delay only if the business can measure it. A simple decision variable is late decisions per month × cost per late decision. If no reliable value exists, leave the term at zero in the financial comparison and report the latency trade-off qualitatively rather than inventing a benefit.
When batch OCR is the lower-cost choice
Batch is a strong default for archives, nightly indexing, invoice backfills, compliance packages, and document collections uploaded in periodic waves. These jobs have three useful properties: the input set is bounded, a failed run can be rerun, and the business can accept a completion deadline rather than an immediate answer.
The cost advantage usually comes from utilization and simplicity. You can schedule work when the source system is quiet, parallelize a known file set, and shut down temporary workers. Batch also gives you a natural checkpoint for quality controls: compare the number of input files, pages, successful outputs, rejected files, and reviewed exceptions before publishing.
Do not assume every batch implementation gets a discount. Google’s Document AI documentation says batch jobs are asynchronous and “not designed for real-time applications”; its current limits page says most jobs finish within 12 to 24 hours after they start, excluding queue time, and lists processor-specific page limits. [4] That is a capacity and deadline fact, not a promise of cheaper processing. Azure’s table similarly publishes the same per-1,000-page rate for Read and Batch read in its pay-as-you-go section. [5]
When real-time OCR earns its premium
Real-time OCR is justified when the output changes the next action and delay has a measurable cost. Examples include checking an identity document during onboarding, routing an incoming claim, extracting a purchase order before releasing inventory, or flagging a suspicious transaction while it can still be stopped.
The right comparison is not “batch is cheap, real time is expensive.” It is “what is the lowest-cost architecture that meets the response target?” A small real-time path may be cheaper than missing a service-level objective, manually re-keying urgent documents, or running a large emergency batch after a queue has grown. Conversely, an always-ready path for a nightly archive can turn idle capacity into a recurring expense with no useful outcome.
Size real-time capacity from peak arrival rate, not monthly average. If 100,000 pages arrive evenly over a month, the average is only about 139 pages per hour. If the same pages arrive in four two-hour upload waves, the peak requirement is 12,500 pages per hour before headroom. The vendor page meter may be identical, but the concurrency, queue, and operational requirements are not.
Worked cost example: 100,000 pages per month
The table below is an original planning example, not a quote. It uses Azure’s displayed US-dollar Read rate of $1.50 per 1,000 pages for the first 1 million pages and its displayed Batch read rate. [5] The other lines are explicit estimates so you can replace them with measured or quoted values.
| Step | Input or assumption | Batch path | Real-time path |
|---|---|---|---|
| 1. Billable pages | 100,000 pages/month | 100,000 | 100,000 |
| 2. OCR page rate | $1.50 per 1,000 pages, dated 2026-11-02 | $0.0015/page | $0.0015/page |
| 3. Base OCR charge | pages × rate | $150 | $150 |
| 4. Retries | 2% of pages, same rate | $3 | $3 |
| 5. Capacity estimate | Temporary batch workers: $80/month estimate; always-ready real-time capacity: $180/month estimate | $80 | $180 |
| 6. Orchestration and monitoring | Batch scheduler $20 estimate; real-time queue, alerting, and on-call tooling $90 estimate | $20 | $90 |
| 7. Storage and result retention | $20/month estimate for the same retention policy | $20 | $20 |
| 8. Review labor | 0.5% exception pages × 1 minute/page × $30/hour | $150 | $150 |
| Illustrative total before delay value | Sum of rows 3–7 | $423 | $593 |
The arithmetic is straightforward. The batch total is $150 + $3 + $80 + $20 + $20 + $150 = $423. The real-time total is $150 + $3 + $180 + $90 + $20 + $150 = $593. Under these assumptions, real-time costs $170 more per month before assigning a dollar value to faster decisions.
That difference is the break-even test. If real-time prevents more than $170 of measurable monthly delay cost, it wins on this simplified model. If the value of speed is unknown, the honest conclusion is narrower: batch is cheaper under the stated operating assumptions, while real-time buys responsiveness and peak readiness. The example excludes taxes, negotiated volume pricing, data transfer, downstream extraction, failed-request policy differences, and any contractual minimum. It also assumes that both modes process the same pages and require the same review rate.
Capacity deserves a second check. If the batch deadline is an eight-hour overnight window, the average processing requirement is 100,000 ÷ 8 = 12,500 pages/hour for that window. If the real-time service must absorb a 10-times burst over a monthly-average baseline, its provisioned concurrency must be tested against that burst rather than against 139 pages/hour. Replace those planning assumptions with a load test; they are not performance claims about any provider.
For a broader model that includes model, embedding, and OCR line items, use the Mistral and Groq API cost calculator. If OCR output feeds retrieval, the RAG, embedding and vector database cost calculator helps keep downstream costs visible. For invoice matching, usage exports, and estimates, use the AI API invoice reconciliation calculator rather than treating the API page estimate as the final bill.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
A practical decision checklist
Choose batch when the deadline is hourly or daily, files arrive in bounded collections, a rerun is acceptable, and the team can validate a completed window. Ask the provider whether the batch endpoint has a distinct price, a completion guarantee, a concurrency limit, or only an asynchronous interface. Record each answer separately.
Choose real time when a fresh result changes an immediate decision, when late documents create measurable loss, or when users will wait on the response. Set a p95 target and test the entire path from upload to accepted result. Include backpressure, duplicate delivery, provider throttling, and the cost of keeping review staff available.
Choose a hybrid when urgent documents need fast treatment but the full corpus still needs correction and reconciliation. A useful pattern is real-time processing for the first answer and a scheduled batch pass for low-confidence, late, or changed documents. The batch pass should have an authority rule: for example, it may overwrite a provisional record only after the page, document ID, and model version match.
FAQ
Is batch OCR always cheaper than real-time OCR?
No. Batch often uses capacity more efficiently, but the provider may charge the same page rate for batch and online modes. Azure’s displayed pay-as-you-go table lists the same Read and Batch read rates, so the savings in that example come from operating assumptions rather than a page discount. [5] A real-time path can also be economically rational when delay causes a measurable business loss.
Does asynchronous OCR mean the provider gives a discount?
No. Asynchronous describes how the request runs and how results are retrieved. AWS documents asynchronous multipage processing as a way to let an application continue while a long operation completes. [2] Treat a discount as real only when the provider’s current pricing or contract states the eligible queue, rate, volume, and completion terms.
How should I compare OCR throughput cost?
Use both pages per dollar and pages per required time window. First calculate pages × unit price. Then calculate required throughput as pages ÷ available processing hours for batch, or peak arrival rate plus headroom for real time. Add retry pages and review minutes. A lower page price can still miss the deadline if the allowed concurrency is too small.
What is the difference between batch OCR pricing and a volume commitment?
A batch price changes the rate for a particular submission mode or queue. A volume commitment usually exchanges an upfront or reserved payment for a stated capacity or lower effective rate. They are different levers. Azure shows commitment tiers separately from pay-as-you-go rates, including monthly fees and overage rates. [5] Model the committed fee even if the average page rate looks attractive, and check the utilization required to avoid paying for unused capacity.
How do I include human review in the comparison?
Estimate exception pages, review minutes per page, and the loaded hourly labor rate: exception pages × minutes per page ÷ 60 × hourly rate. Apply the same formula to both modes unless faster results change the exception rate or staffing schedule. Keep review labor separate from the vendor OCR line so a provider price comparison does not hide the largest workflow cost.
What limits can make a batch plan fail?
Check maximum file size, files per request, pages per document, asynchronous completion time, and quota or concurrency. Google’s limits page lists a 1 GB maximum batch request size, up to 5,000 files per batch request, and processor-specific asynchronous page limits, including 500 pages for Enterprise Document OCR. [4] These are planning constraints, not guaranteed completion speeds. Test the document mix you actually receive.
Should I use one provider’s price as the market benchmark?
No. Use provider prices to illustrate units and formulas, not to imply an industry average. AWS, Google Cloud, and Azure expose different processor names, page definitions, tiers, features, regions, and commitment options. Normalize the same document set, output requirement, region, currency, and review policy before comparing totals.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.