The Correct-Page Billing Model as Leverage When Negotiating OCR Accuracy Commitments

Correct-page billing gives buyers a concrete way to negotiate a contractual per-field accuracy SLA for document extraction APIs. The vendor earns payment only when extraction meets an agreed standard, making accuracy a commercial obligation. That leverage works only when the contract defines correctness, how it is measured, and what happens when a page fails.

How mainstream OCR vendors price their services and what that structure omits

Most major OCR and document-AI vendors charge for input volume, measured in pages submitted or processed. The rate may change with the capability being used, from basic text recognition to structured extraction. The billing unit stays the same.

Azure Document Intelligence charges for the capability used, whether or not the extraction is correct. It has usage-based and commitment-based pricing tiers, and the price is generally based on the number of pages processed. Its Read model covers plain text recognition and basic layout extraction, rather than structured fields, key-value pairs, or semantic document understanding. Full document analysis is a different capability with different pricing.

Under submitted-page pricing, an invoice page generates the same charge whether its total is extracted correctly or silently misread. The rate itself does not specify a refund, correction obligation, or right to terminate when the output is wrong. Those terms require a separate contractual commitment. Where accuracy appears only in marketing copy, the buyer still absorbs correction labor, downstream system errors, and compliance exposure.

Why extraction errors are more expensive than the per-page rate suggests

That omission leaves the buyer comparing only part of the cost. An extraction error creates work elsewhere. A wrong field can trigger manual review, an ERP correction, a compliance check, or a failed loan decision. The processing fee is only the beginning. Correction labor and exception handling can cost far more than the extraction that caused them.

In accounts payable, invoice exceptions require someone to intervene where the workflow was meant to run without a person. The gap between touchless processing and full automation therefore represents work that the per-page price does not capture. Mortgage lending exposes the same problem across a large, varied document set. When a pipeline extracts many fields from each application, even a modest shortfall in field-level accuracy can create a substantial correction burden. That burden translates into staffing needs.

Silent errors are especially costly because they do not announce the need for correction. A value can look entirely valid and still be wrong. A date drawn from the wrong date cell may pass format validation because it has the expected date format. Confidence scores can help identify uncertainty, but they are not proof that a value came from the right field.

A useful cost comparison therefore needs field-level error rates as well as page prices. Otherwise, a cheaper service can appear economical while pushing more work into review queues and downstream systems. A higher page rate paired with a genuine accuracy commitment can cost less overall than a lower rate paired with weaker output. The lesson for buyers is to compare the cost of usable extraction, including the errors the rate card leaves out. If those errors drive the buyer’s costs, the commercial agreement needs to reflect them.

What correct-page billing actually means and how it realigns vendor incentives

Correct-page billing makes payment contingent on extraction meeting a predefined, field-level accuracy threshold. A failed extraction becomes failed revenue for the vendor. This changes the incentive from processing more input to producing more output that meets the agreed standard.

The phrase “correct page” cannot do that work by itself. The contract has to name the fields that must be present and the method used to judge whether their values are correct. It also has to define the confidence threshold below which a page enters human review. These are payment terms. They establish which part of the vendor’s output the buyer has agreed to purchase.

Correctness is judged against ground truth, while confidence determines which extractions need review. A high confidence score does not settle whether a field is right, as a well-formatted value from the wrong source cell demonstrates. For that reason, a confidence gate cannot replace the agreed accuracy test. Both belong in the contract because they govern different parts of the same billing boundary.

Pages that enter review represent a partial vendor contribution. The contract should specify whether they receive a reduced rate or remain unbilled until the correction loop closes. That choice determines how the cost of unfinished extraction is shared. It also stops a vendor from calling the deal correct-page billing while charging the full rate for output that still needs repair.

This model gives failure an agreed commercial consequence. The vendor has a direct financial reason to maintain quality, reduce uncertain output, and improve extraction instead of earning the same revenue regardless of the result.

What must a contractual per-field accuracy SLA specify?

An enforceable accuracy standard has to apply to named document types, named fields, and a defined measurement method. Document quality changes the difficulty of extraction substantially. Performance on clean digital documents does not establish performance on scanned receipts or degraded images. An SLA that leaves those conditions unstated leaves the buyer’s actual workload unresolved.

Results can also vary by field type within the same document. Checkboxes, structured text, and free-form fields have different error profiles. When both go into one overall score, good results on checkboxes can hide poor results on handwritten fields or fields that are hard to interpret. An average can hide the field that fails. For a buyer whose workflow depends on that field, the aggregate result offers little protection.

Field-level accuracy also differs from complete-document accuracy. A system can read most individual fields correctly while producing far fewer documents that are entirely ready for downstream use. One wrong required field can break that use. The contract must therefore specify how often the model must be right and which fields must be right for the page to qualify for payment.

To make that standard usable, buyers should ask what constitutes ground truth, who constructs it, and which document sample supports the measurement. A vendor-curated gold set is not equivalent to production documents containing unusual layouts, edge cases, and degraded scans. The measurement method should be referenced in the SLA. Otherwise, the buyer and vendor can use the same word, “accuracy,” while judging different tasks.

The review threshold needs equally explicit treatment because it determines which pages qualify for billing and which require further work. It should be named in the contract. A rework clause should then state the accuracy floor that triggers correction, the turnaround for corrected output, and that the vendor pays when the miss is theirs. Without those terms, the parties have to negotiate again when the output falls below spec. It does not trigger a defined obligation.

How human-in-the-loop review functions as the billing boundary in practice

Pages below the agreed confidence threshold go into a review lane because they still need work. This is a designed part of correct-page billing. The workflow separates extraction that meets the standard from work that is still uncertain. Its usefulness depends on making that separation selective enough that people do not have to inspect every page.

A well-designed review process uses per-field confidence scores to route uncertain extractions to a reviewer. Source localization helps make the review boundary auditable by connecting output to a position on the page.

Mistral OCR 4 provides a concrete example of relevant technical infrastructure, with per-page and per-word confidence scores and bounding boxes that localize blocks on the page. These features expose where content sits and how confident the model is in a region. Evaluating whether an API supports a field-level review boundary requires distinguishing these features from per-field confidence scores, while establishing a contractual accuracy guarantee requires more than the architecture alone.

The billing treatment of reviewed pages must then match the contract’s definition of unfinished work. Pages can be billed at a reduced rate reflecting the vendor’s partial contribution, left unbilled until correction closes, or billed on correction completion. These choices give the vendor different reasons to act on the review queue. Leaving the treatment vague makes it unclear whether the buyer is paying for successful extraction or for an extraction attempt followed by additional labor.

Continuous learning gives that review work a second purpose. When human corrections feed systematically back into the model, they can improve future extraction and reduce the share of pages needing review. Under correct-page billing, that improvement also increases qualifying output and strengthens the vendor’s economics. A static tool does not gain that benefit from corrections. The presence of an effective learning loop is therefore evidence about how the vendor intends to sustain its accuracy commitment.

What buyers should verify before accepting a vendor's accuracy commitment

The practical test is whether the vendor can support its commitment with both production evidence and contract terms. Buyers should ask for per-field accuracy measurements on a sample that reflects the document types they actually use. The sample needs to reflect the conditions under which the service will be judged, including unusual layouts and degraded scans. This connects the promised result to the work being purchased.

What constitutes ground truth, who constructs it, and will that method appear in the SLA? The evidence and the contract must use the same definition of correctness. Otherwise, a dispute about performance becomes a dispute about what was promised.

Buyers should also ask whether the system exposes per-field confidence scores and whether those scores are traceable to source regions on the page. Page-level or word-level scores should not be presented as though they were field-level measurements. The distinction affects what can be reviewed and audited. A score that cannot be traced to a source location does not provide an auditable basis for the extraction, even if it looks precise.

What happens when output falls below the SLA threshold, and does the agreement provide rework, a billing adjustment, or only best efforts? The answer should be explicit before signing. Buyers should also establish how review pages are charged and whether human corrections feed systematically into the model or are discarded. A review queue without a learning loop deals with today’s mistakes but has no way to learn from them to reduce future ones.

Deployment architecture and data retention are part of this assessment because document workflows can contain sensitive financial, personal, or health information. For those documents, a zero-data-retention model is the credible default. There must be a strong technical reason to keep any document data. Otherwise, the buyer takes on compliance risk in addition to the cost of extraction errors.

Will the vendor put its accuracy claim into an SLA with commercial consequences? With submitted-page pricing and a vague promise, the buyer pays for the pages processed whether the output is good or bad. A vendor that claims high accuracy should be willing to base its price on that claim, and a buyer can learn from its refusal before signing the contract.