Research-backed calculator guide

Document Extraction Cost per Accepted Record: OCR, LLM, Validation and Human Correction

Calculate document extraction cost per accepted record by combining OCR, LLM extraction, validation, retries, human correction, and the true accepted-record denominator.

The denominator is the main modeling decision

Start by writing down what “accepted” means before collecting prices. An accepted record is not simply a response returned by an OCR or document-AI API. It is a record that meets the schema and quality conditions needed for the next step in your workflow. A claims record might need a policy number, date of service, amount, and provider ID. A contract record might need the effective date, renewal date, currency, and counterparty. A missing required field can make an otherwise readable document a failed record.

The denominator can be expressed as:

accepted records = records attempted × acceptance rate

If one document can yield multiple records, use the record yield explicitly:

accepted records = submitted documents × average records per document × acceptance rate

Keep page count out of that denominator unless your business output really is a page. A page is a useful billing unit for OCR and document intelligence, but it is usually not the business unit. Google’s pricing notes, for example, define pages differently by input format: a PDF page is one page, an image is one page, an XLSX tab is one page, and a DOCX or HTML unit can be based on character count.^[1] That distinction matters when a “document” is a multi-page PDF or a file with several spreadsheet tabs.

Acceptance rate should come from a labeled sample or production history. If you have not measured it, create a low, base, and high case rather than presenting one false-precision number. A model that assumes 98% acceptance can look cheap while quietly assigning the exception queue to operations.

What belongs in the numerator?

OCR or document reading. Include page processing for text recognition, layout reading, or an equivalent first pass. If an API bundles OCR into structured extraction, do not add a second OCR charge unless your architecture actually makes two calls. AWS states that OCR is included with several Analyze Document feature types, so the selected feature combination matters.^[2]

LLM or structured extraction. Add the model call that converts text, layout, or images into fields. Include input tokens, output tokens, image or document charges, and any repeated extraction pass. If you use a fixed per-document estimate, label it as an internal estimate rather than a vendor quote. A model price comparison can help normalize token units, but the document pipeline still needs its own record and retry measurements.

Validation. Schema checks, cross-field rules, duplicate detection, address or identifier lookups, and confidence scoring can consume compute and API calls. Validation may be cheap relative to a model call, but it changes acceptance rate. A stricter rule can increase cost per accepted record by sending more work to review; a looser rule can lower measured cost while increasing downstream error risk.

Retries and fallbacks. Count timeouts, malformed JSON, low-confidence reprocessing, alternate-model calls, and idempotency safeguards. A retry that produces a billable second request is a real cost even when the first result is discarded. Measure retry rate by stage instead of applying one blanket percentage to the total.

Human correction. Convert review minutes into money. The basic calculation is reviewed records × minutes per review / 60 × loaded hourly rate. Use a loaded rate that includes payroll burden, supervision, tooling, and the portion of paid time spent on the queue. If an external service provides a quote, use the quote and state its unit. Otherwise, this is an estimate.

Allocated fixed cost. Include recurring platform fees, queue infrastructure, observability, storage, labeling, and model hosting only when you intend to report fully loaded unit economics. Keep fixed and variable cost visible as separate lines. A low-volume pilot can have a high unit cost because a small number of accepted records carries the monthly minimum.

For a monthly view, you can also report two figures: variable cost per accepted record and fully loaded cost per accepted record. That prevents a volume change from being mistaken for a model-quality change.

Worked cost example

Assume a monthly invoice-extraction pipeline with 10,000 submitted documents. Each document averages three pages, so OCR sees 30,000 pages. The pipeline attempts one record per document. Eighty-seven percent pass the acceptance rule, producing 8,700 accepted records. The following table makes the assumptions inspectable.

The resulting fully loaded cost is:

$349.30 / 8,700 accepted records = $0.0401 per accepted record

Rounded for planning, that is about $0.04 per accepted record. The cost per submitted document is $0.0349, but that is not the same metric. The difference exists because unsuccessful attempts still consume OCR, extraction, validation, and review resources.

Only the OCR rate in this example is tied to a vendor-published rate: the AWS Detect Document Text example uses $0.0015 per page for the first million pages in US West Oregon.^[2] The LLM, validation, loaded reviewer rate, and $40 allocation are illustrative estimates. Replace them with your invoices, token usage, measured review times, and finance-approved labor assumptions. If your chosen provider bundles OCR into a higher-level feature or uses a different region, substitute that provider’s applicable quote or published price. Azure’s page table, for instance, separates Read, prebuilt, custom extraction, add-ons, and query fields rather than offering one universal document rate.^[3]

A sensitivity check shows why the denominator matters. If acceptance falls from 87% to 75% while all costs remain unchanged, only 7,500 records pass and the unit cost becomes $349.30 / 7,500 = $0.0466. If acceptance rises to 93%, 9,300 records pass and the unit cost becomes about $0.0376. Improving extraction quality can therefore lower unit cost even when the provider rate does not change.

A practical measurement worksheet

Create one cost ledger row per processing attempt. At minimum, store a document ID, page count, extraction attempt count, validation outcome, acceptance outcome, review minutes, and each billable provider meter. Join those rows to the invoice period. This lets you answer whether a cost increase came from more pages, a larger model, more retries, or a lower acceptance rate.

Track these ratios monthly:

• Pages per submitted document: total billable pages divided by submitted documents.
• Records per document: attempted records divided by submitted documents.
• Acceptance rate: accepted records divided by attempted records.
• Exception rate: records routed to correction divided by attempted records.
• Review minutes per exception: total review minutes divided by corrected exceptions.
• Retry rate by stage: repeated billable calls divided by first-pass calls.
• Cost per accepted record: all included costs divided by accepted records.

When comparing providers, normalize the same workload. AWS publishes examples for text detection, forms, tables, queries, signatures, expenses, IDs, and lending; the feature mix changes the page price.^[2] Google separates digitization, structure and entity extraction, chunking, classification, and hosting.^[1] Azure similarly separates Read, prebuilt models, custom classification, custom extraction, add-ons, and query fields, and notes that displayed prices are estimates rather than quotes.^[3] A fair comparison should specify pages per document, feature calls per page, region, monthly tier, acceptance rule, and whether human review is included.

If the pipeline uses embeddings or retrieval after extraction, model that downstream layer separately rather than hiding it in OCR. The RAG, embedding and vector database cost calculator is useful for that part of the system. For model selection and normalized input/output pricing, use the Model pricing comparison. For a broader monthly budget that includes other agent steps, use the AI Agent Cost Calculator | Model Full Monthly Spend.

Common mistakes that understate cost

The most common mistake is using documents as the denominator when the service charges pages. The next is treating every successful API response as accepted. A third is omitting manual correction because review happens in a separate team or spreadsheet. That makes the extraction service look efficient by moving cost outside the system boundary.

Another mistake is mixing estimates and quotes. A provider’s public price can change by region, tier, feature, contract, currency, or commitment. Azure explicitly says its displayed prices are estimates and that actual pricing depends on agreement, purchase date, and exchange rate.^[3] Google and AWS also present multiple tiers and feature-specific examples rather than a single universal rate.^{[1] [2]} Record the checked date, region, currency, and unit whenever you save a rate.

Finally, do not optimize only for acceptance rate. A permissive rule can increase acceptance by allowing incomplete or inconsistent records. Pair the rate with field-level precision, downstream rejection, audit findings, and correction time. The economically useful target is the lowest cost per record that meets the required quality threshold, not the highest possible pass percentage.

FAQ

Is cost per accepted record the same as cost per document?

No. Cost per document divides spend by submitted documents, while cost per accepted record divides spend by records that pass the acceptance rule. They are equal only when every document yields exactly one accepted record and no meaningful work is spent on failures. In most production pipelines, retries, exceptions, and human correction make the accepted-record denominator more informative.

Should OCR be priced per page or per document?

Use the provider’s billing unit for the numerator and your business output for the denominator. If OCR costs $1.50 per 1,000 pages, multiply by actual pages processed. Then divide the full pipeline cost by accepted records. Do not turn a page price into a document price without specifying average pages per document and any page-range or bundled-feature behavior.

How do I include human-in-the-loop document processing cost?

Measure exception volume and review time. Multiply corrected records by average minutes per correction, divide by 60, and multiply by the loaded hourly rate. Add reviewer tooling or vendor review fees if they are separate. Keep reviewer assumptions visible because a small change in minutes per exception can outweigh the OCR charge in a high-error workflow.

What if one document creates several records?

Measure record yield directly. Use submitted documents multiplied by average attempted records per document, then multiply by acceptance rate. For example, 10,000 documents producing 1.4 attempted records each at an 85% acceptance rate produce 11,900 accepted records, before considering duplicate suppression or batch-level rejection.

Should fixed platform fees be included?

Report both views when possible. Variable cost per accepted record helps compare processing choices at a stable volume. Fully loaded cost per accepted record allocates platform, storage, monitoring, and minimum commitments and is better for a budget or margin decision. State the allocation period and volume so readers can reproduce the result.

How often should the calculation be refreshed?

Refresh provider rates when a pricing page, contract, region, model, or feature changes. Refresh measured acceptance, retry, and review inputs at least monthly once the pipeline is in production. A quarterly review can be adequate for a stable low-volume workflow, but a new document class or model change should trigger a new sample and sensitivity check.