Research-backed calculator guide

OCR Retry Cost: When a Second Pass Beats Human Correction

A practical expected-cost model for deciding whether low-confidence OCR should be retried or sent directly to human correction.

● First-party sources checked▧ Original calculation examples◌ Estimate, not a vendor quote

Quick answer

A second OCR pass beats human correction when its incremental expected cost is lower than the correction work it avoids. For one low-confidence item, compare:

retry cost + expected residual correction cost with direct correction cost.

A useful document-level version is:

retry path = first-pass OCR + retry rate × second-pass cost + residual-error rate × correction cost

direct-review path = first-pass OCR + review rate × correction cost

Do not treat a confidence score as a universal probability or a vendor-independent price signal. Microsoft describes a confidence value as an estimated probability for a prediction in its Document Intelligence output, while AWS documents a 0–100 score and says the right threshold depends on the use case. Those scales are not interchangeable, and the threshold still needs local validation. [1] [2]

The break-even question is therefore operational: how many minutes does correction take, what does one OCR retry cost in your meter, what share of flagged items improves after the retry, and how often does a human still need to intervene? If you do not have those measurements, label the result as a scenario estimate rather than a quote.

What “low confidence” should trigger

A low-confidence result is a routing signal, not an automatic instruction to retry. It says that the system is less certain than your acceptance policy allows. Microsoft notes that confidence may exist at word, field, selection-mark and other levels, and recommends checking the relevant extraction and read results rather than assuming one score describes the whole document. [1]

That distinction matters for cost. A low-confidence word inside a non-critical address may be cheaper to correct immediately. A low-confidence total on an invoice may justify a second pass, a business-rule check or a human review because the consequence of a wrong value is larger. A page-level score can also hide a critical field error. A 99% page result does not mean every business field is 99% reliable; the field and risk unit must match the decision.

A practical low-confidence workflow has five gates:

  1. Score the result at the decision unit. Use a field, line item, table cell or document unit that matches downstream risk.
  2. Apply a validated threshold. Keep separate thresholds for different fields or document families when their error patterns differ.
  3. Choose the cheapest safe branch. Compare retry, direct correction, escalation or rejection.
  4. Re-score the retry. A second pass is not successful merely because it returned text. It must meet the acceptance rule or reduce correction effort.
  5. Log the outcome. Record original score, retry result, final truth, elapsed review time and all billed processing units.

This is consistent with AWS guidance: applications sensitive to detection errors should enforce a minimum threshold and either discard low-confidence results or flag them for more human scrutiny. AWS gives 90% or higher as an example for some financial decision processes, not as a universal OCR rule. [2]

The expected-cost model

Let the following variables describe one document or one field batch:

  • C1: first-pass OCR cost per item.
  • r: proportion of items sent to a second pass because of low confidence.
  • C2: incremental cost of the second pass, including its OCR or model meter.
  • e1: proportion of items sent straight to human correction.
  • e2: proportion of retried items still requiring correction.
  • t: average human correction time in minutes for a directly reviewed item.
  • tr: average correction time after a retry, in minutes.
  • w: fully loaded reviewer cost per hour.
  • F: fixed cost allocated per item for queueing, tooling, or oversight, if you want to include it.

The direct-correction path is:

D = C1 + e1 × (t / 60) × w + F

The retry path is:

R = C1 + r × C2 + r × e2 × (tr / 60) × w + F

The first-pass term and any identical fixed term cancel when comparing branches. Retry is cheaper when:

r × C2 + r × e2 × (tr / 60) × w < e1 × (t / 60) × w

This formulation forces a useful discipline. It does not claim that an OCR API has a particular price. C2 is an input from your current invoice, rate card or measured unit cost. It also does not assume every flagged field needs a full document re-run. If the provider prices per page, set C2 to pages retried. If it prices per image, set it to images. If the retry calls a vision-capable language model, include its input and output token cost and any image or request charge.

A retry can be economically attractive even when it does not eliminate all review. It only needs to reduce the expected human minutes enough to pay for itself. Conversely, a cheap retry is not automatically sensible if it adds latency, creates duplicate records or produces a second plausible but wrong value that takes longer to adjudicate.

Worked cost example

Assume an invoice pipeline processes 10,000 documents per month. The following are planning assumptions, not vendor quotes:

  • First-pass OCR is already required and costs $0.010 per document.
  • 30% of documents have a low-confidence field, so r = 0.30.
  • A second pass costs $0.012 per retried document, so C2 = $0.012.
  • If the item goes directly to a reviewer, average correction time is 2.5 minutes.
  • After a retry, only 35% of retried items still need a human, so e2 = 0.35.
  • A post-retry correction takes 1.5 minutes.
  • Fully loaded reviewer cost is $24 per hour.
  • For the direct-review comparison, every low-confidence item is reviewed, so e1 = 0.30.

The direct correction work is:

0.30 × (2.5 / 60) × $24 = $0.300 per original document on average.

The retry work is:

0.30 × $0.012 = $0.0036 of retry processing, plus

0.30 × 0.35 × (1.5 / 60) × $24 = $0.063 of residual correction.

Add the same first-pass OCR cost to each path:

StepDirect correction branchConditional retry branchAssumption or output
First-pass OCR$0.0100$0.0100Required for both paths
Flagged share30% reviewed30% retriedLow-confidence rate
Second-pass processing$0.0000$0.003630% × $0.012
Human correction$0.3000$0.0630Minutes × $24/hour
Expected cost per original document$0.3100$0.0766Sum of expected components
Expected monthly cost at 10,000 documents$3,100$766Scenario estimate, before other overhead

Under these assumptions, the retry branch is $0.2334 cheaper per original document, or $2,334 per month at 10,000 documents. That is not a forecast of savings. It is the result of the stated rates, and it changes quickly if retry quality or review time changes.

The retry branch has a simple break-even condition here. The retry plus residual correction cost per flagged item is:

$0.012 + 0.35 × (1.5 / 60) × $24 = $0.222.

Direct correction per flagged item costs:

(2.5 / 60) × $24 = $1.00.

So the retry remains cheaper while its total expected cost per flagged item stays below $1.00. If the second pass costs $0.30 rather than $0.012, the retry total becomes $0.51, still cheaper. If the retry leaves 90% of cases for a full 2.5-minute correction, the total becomes $0.012 + 0.90 × $1.00 = $0.912, leaving little headroom for queue overhead or a second reviewer.

How to measure the inputs

Start with a sample that includes document types, scan quality, layouts and fields seen in production. For every low-confidence event, store the score scale and provider, the threshold, the first output, whether a retry ran, the second output, the final human-verified value, billed units and review duration.

Measure r from the actual routing rule, not from a marketing accuracy figure. Measure e2 as the share of retried items that still require correction. A retry that changes text but does not improve truth should not be counted as a success. Measure t and tr with timestamps or a review-tool event log, excluding idle queue time if your question is labor cost alone. If queue delay, re-open rates or second-review work matter, add those components separately.

Confidence calibration deserves special attention. An academic study comparing OCR systems found that incorporating OCR confidence generally improved or maintained error-detection F1 scores, but the gains varied by OCR and dataset. It also notes that low-granularity confidence can be non-local, so a score attached to a large box may not reveal a character-level error. [3] In cost terms, that means the model should be tested at the same granularity you price and review.

AWS also recommends a high-quality input document and says 150 DPI is ideal in its best-practice guidance. Better capture quality may lower the low-confidence rate, but do not convert that recommendation into a guaranteed savings percentage. [2] Treat preprocessing as another branch with its own cost and measured effect on r, e2 and review minutes.

When a retry is the wrong choice

Send the item directly to a human when the field is high risk and the retry has poor historical precision, when the first output is structurally unusable, or when the second pass cannot preserve the required audit trail. Direct review may also win when a reviewer can correct a short value in seconds but a full-page retry consumes many billed pages.

Avoid retry loops. Set a maximum number of attempts, keep the original output, and route unresolved cases to a human or exception queue. A retry policy should also consider latency and user experience. A lower dollar cost can be unacceptable for a synchronous workflow if it pushes the response beyond its service-level target.

Finally, separate extraction cost from error cost. A wrong invoice total can create payment, reconciliation or customer-service work that dwarfs the OCR charge. Include that consequence only if you can estimate it from incident data, and label it as an expected loss rather than a processing fee. For broader retrieval and downstream generation budgets, see the RAG, embedding and vector database cost calculator and the model pricing comparison. To reconcile modeled units with provider invoices, use the AI API invoice reconciliation calculator.

Run your scenario

Turn this framework into an editable estimate.

Use dated, source-linked assumptions and see cost per request, successful task and month.

Mistral and Groq API cost calculator

FAQ

Is OCR confidence a probability of being correct?

Not always. The meaning and calibration depend on the OCR system, output level and training data. Microsoft documents its field confidence as an estimated probability between 0 and 1 for Document Intelligence, while AWS uses a 0–100 confidence score. [1] [2] Even within one system, a word, field, table row and document score can answer different questions. Validate the score against human-verified outcomes before using it as a routing probability.

What is the best OCR retry threshold?

There is no universal threshold. Choose a candidate from a labeled sample, then compare precision, missed errors, retry volume, correction minutes and business risk by field or document family. A threshold that is economical for invoice dates may be unsafe for tax totals or identity fields. Treat vendor examples such as 90% as context, not as a drop-in policy. [2]

How do I compare an OCR retry with human correction?

Use expected cost per original item. Multiply the retry rate by the incremental second-pass cost and add the retry rate times the residual correction rate times post-retry labor cost. Compare that result with the share sent directly to review times direct correction labor cost. Keep first-pass cost in both branches for total budgeting, even though it cancels in the branch comparison.

What if the retry produces a different answer but no clear winner?

Route the disagreement to a human or a business-rule check. Do not choose the second answer merely because it is newer or has a higher confidence score. Keep both outputs, their scores and the final adjudication so that you can estimate e2 and detect systematic disagreement.

Can preprocessing be cheaper than re-running OCR?

Often it can be, but the answer depends on your capture pipeline and workload. Test operations such as de-skewing, resolution preservation, cropping or contrast adjustment against a holdout sample. Price the preprocessing compute, storage and latency, then measure whether it reduces retries or correction time. Do not assume a document-quality recommendation guarantees a particular cost reduction.

Limitations and assumptions

This model excludes provider-specific taxes, minimum commitments, storage, network transfer, reviewer benefits beyond the stated loaded rate, downstream payment errors and the value of latency. It assumes the first pass is already required and that retry costs are incremental. It also assumes that the retry rate, residual correction rate and review times are stable enough for a planning period; production drift can invalidate that assumption.

The worked example uses hypothetical inputs stated in US dollars. They are estimates for demonstrating the calculation, not vendor quotes, current rate-card claims or a promise of savings. Recalculate after any provider pricing change, model migration, threshold change or staffing-cost change.

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.

  1. Interpret and improve accuracy and confidence scores
  2. Best Practices - Amazon Textract
  3. Confidence-Aware Document OCR Error Detection

About the Author

Zunair Ali Syed is a doctoral researcher in Management Sciences at Minhaj University Lahore and a research consultant with experience in academic research and editing since 2011. He runs QuickEduHelp, with professional interests in digital learning, research methods, and evidence-based academic support.