--- title: "OCR API for scanned documents: every page read twice" description: "OCR API for scanned documents with two independent readers per page. A 15 page bench gave 0 wrong amounts and 1 missed of 326." canonical: "https://laboetie.io/products/docread" language: en --- # DocRead: OCR API for scanned documents DocRead is an OCR API for scanned documents that sends every page to two independent readers from different vendors and keeps a printed value only when both agree. In a bench on 15 scanned pages dated 25 October 2026, DocRead wrote 0 wrong amounts and missed 1 of 326. Access to DocRead is in house. Status: Live. Access: In house. A printed value is kept only when both readers agree. ## Capabilities - DocRead routes PDF, Word, Excel, PowerPoint and HTML files by format. - Scans and photos get a paired reading, and agreement is checked on printed values. - A disputed page returns both readings, or a third reader rereads it when the deployment has one. - Extraction returns your JSON schema with a confidence score per field. - DocRead runs as an HTTP service or inside your own process. ## How two OCR readers check each other DocRead compares two readings of each page from the readers of two different vendors. A printed value that only one reader writes counts as disputed. The page then comes back with the disputed values and the lines each reader wrote, or it goes to a third reader when the deployment has one. A wrong amount gets through only when both readers write the same wrong number. ## OCR accuracy: the bench of 25 October 2026 The DocRead output on 15 scanned pages held 0 wrong amounts, 1 missed amount of 326 and 229 of 237 lines. A wrong amount is a money figure in the reading that the page does not print. The output on 16 degraded scans of synthetic medical documents held 0 wrong amounts, 0 missed amounts of 154 and all 297 medical values correct. These two sets hold 31 pages, which is why we recommend a test on your own scans. ## Scanned PDF to JSON with your schema The structure call takes the text of a document and your JSON schema, then returns each field with a confidence of high, medium or low. High means the document states the value without ambiguity. Medium means the value follows from its place in the document, and low means the text is doubtful or absent. A field the document does not state comes back as null. The extraction instruction forbids computing or correcting a value. ## File formats and the 50 MB limit DocRead accepts files up to 50 MB in PDF, Word (.docx), Excel (.xlsx), PowerPoint (.pptx), HTML, JPEG, PNG and WebP. A PDF with a text layer and the office formats return their own text, so scans and photos are the files that reach the readers. In a flattened form the text layer holds every choice and the mark appears only on the page image. The ocr flag sends such a PDF to the readers. ## What the read response lists The read call returns the text of each page and names every doubt in three fields. The disputes field holds the contested values and the lines of each reader for every page. The settled field lists the pages a third reader reread, and readOnceOnly lists the pages one reader alone could read. The usage field holds the calls and tokens of each model. ## What an OCR API is An **OCR API** is a web service that takes a scanned page or a photo and returns its text. OCR stands for optical character recognition. Your application sends a file over HTTP, the service reads it, and the response carries the text in a form your code can store, search or pass to another system. Teams use an OCR API when documents arrive as images: supplier invoices, signed forms, bank statements, delivery notes, medical reports and old archives. A person can read those files on a screen. Software needs OCR to turn the pixels into characters. DocRead does that job and adds a check that most OCR services leave to you. It reads every scanned page twice, with two independent readers from two different vendors, and compares the printed values. A value that only one reader writes comes back as a dispute. ## The three kinds of OCR API The market sorts into three groups. Knowing which one you need saves most of the evaluation work. | Kind | What it returns | Typical fit | Main limit | |---|---|---|---| | General OCR API | Plain text, sometimes with word positions | Search, archives, simple text capture | The text carries no meaning, so your code must find the fields | | Document AI API | Text, tables, layout and fields from trained models | Common document types at scale | Quality depends on how close your document is to the training data | | Intelligent document processing platform | Fields, review screens and workflow | Teams that want a finished back office | You adopt a platform along with the reading engine | DocRead sits between the first two groups. It returns the text of each page and, through a second call, the fields of your own JSON schema. It ships no review screen. Your application receives the disputes and decides what a person should see. ## Where a single OCR engine falls short OCR engines fail in five common ways. **Silent errors.** An engine reads 1,280.00 as 1,230.00 and returns the wrong figure with a high confidence score. Nothing in the response marks it, so the mistake travels into your accounts. A second independent reader catches this class of error, because two engines from two vendors rarely misread the same digit in the same way. **Tables and reading order.** A multi column invoice can come back with its lines shuffled. A price can end up beside the wrong article even when every character is correct. **Scan quality.** Skewed phone photos, faxes, stamps over text and low resolution all reduce accuracy. A test set built only from clean PDFs tells you little about real traffic. **Handwriting.** Handwritten fields behave differently from print. DocRead has no published handwriting benchmark, so test it on your own forms before you rely on it. **Meaning.** Plain OCR returns characters. It cannot tell you which of three dates on a page is the due date. Structured extraction handles that job. A section further down this page covers it. ## How DocRead routes each file DocRead picks the cheapest reliable path for each file. A file that already carries its text makes no model call, and a scan gets the double reading. When a flattened form hides its ticked boxes in the page image, a flag sends it to the readers even though it has a text layer. ## How paired reading works Two independent readers from two different vendors transcribe each scanned page. DocRead compares the values that matter, such as amounts and dates. A value both readers agree on passes. A value in doubt comes back marked, and the response shows what each reader saw. Your team then sees which figure needs a human eye. ## Worked example: reading a scanned invoice The request below sends a file to the read route. The service key travels in the `Authorization` header. ```bash curl -X POST https://your-docread-host/read \ -H "Authorization: Bearer $DOCREAD_KEY" \ -F file=@invoice.pdf ``` You can also send a signed URL instead of the file. DocRead fetches it only from hosts your deployment allows, and any other host returns HTTP 403. ```bash curl -X POST https://your-docread-host/read \ -H "Authorization: Bearer $DOCREAD_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://files.example.com/signed/invoice.pdf", "filename": "invoice.pdf" }' ``` The response below is an illustration with invented values. The field names are the real ones. ```json { "filename": "invoice.pdf", "mime": "application/pdf", "sha256": "9f2c...", "textLayer": "ocr", "pages": ["Invoice 2041\nTotal due 1,280.00 EUR\n..."], "disputes": [], "settled": [], "readOnceOnly": [], "usage": {} } ``` Three fields tell you how far to trust the reading. - `disputes` lists, page by page, the contested values and the lines each reader wrote. - `settled` lists the pages a third reader reread. - `readOnceOnly` lists the pages only one reader could read, so those pages had no comparison. An empty `disputes` and an empty `readOnceOnly` mean every critical value on every page had two readers behind it. Your code can process the file without review. Any other file can go to a person with the exact values in doubt. ## Structured extraction: scanned PDF to JSON The read route returns text. The structure route returns fields from that text and a JSON schema of your own. ```bash curl -X POST https://your-docread-host/structure \ -H "Authorization: Bearer $DOCREAD_KEY" \ -H "Content-Type: application/json" \ -d '{ "text": "Invoice 2041\nTotal due 1,280.00 EUR\nDue 30 June 2026", "schema": { "type": "object", "properties": { "invoiceNumber": { "type": "string" }, "totalDue": { "type": "string" }, "dueDate": { "type": "string" } } } }' ``` The response holds `fields`, a `confidence` value per field and `usage`. Confidence takes one of three values. | Confidence | Meaning | |---|---| | High | The document states the value without ambiguity | | Medium | The value follows from its place in the document | | Low | The text is doubtful or absent | A field the document does not state comes back as null. DocRead never computes or corrects a value, so a total that does not match its lines stays as printed. Your own business rules can then catch the mismatch. A confidence score describes how the extraction read the text. It does not measure whether the source text was read correctly. Paired reading protects the text before the schema step runs. ## Error handling The error codes are explicit, so your integration can treat each failure differently: a bad request, a missing key, a file that is too large, an unreadable document or a provider that failed. ## OCR accuracy: how to read the bench The DocRead bench dated 25 October 2026 used two sets of scanned pages. | Set | Pages | Wrong amounts | Missed amounts | Other result | |---|---|---|---|---| | Scanned business documents | 15 | 0 | 1 of 326 | 229 of 237 lines correct | | Degraded scans of synthetic medical documents | 16 | 0 | 0 of 154 | All 297 medical values correct | A wrong amount is a money figure in the reading that the page does not print. We rank that metric first because a wrong amount passes silently. Born digital PDFs took the text layer path: on 29 pages that path produced 0 wrong amounts and 0 missed amounts. These two sets hold 31 pages. Test your own documents before you rely on these figures. ## How to test an OCR API before you commit A vendor's accuracy figure describes the vendor's test set. Run your own, and use the same set for every service you compare. Build the set from your real traffic and include the hard cases: skewed phone photos, low resolution faxes, mixed handwriting and print, tables that cross a page break, stamps over text, and new layouts from known senders. Choose about fifty varied documents, including your worst scans. Score these metrics, in this order. | Metric | What it tells you | |---|---| | Wrong critical values | The errors that pass silently | | Missed critical values | The gaps a person must fill | | Disputes per document | How much review the service creates | | Cost per document | The real price at your page count | | Response time at peak | Whether the service fits your workflow | Character accuracy alone hides the failures that matter. A reader can score 99% on characters and still change one digit in every total. ## What an OCR API costs OCR pricing usually runs per page, and the same job can land at very different prices depending on what the provider counts. Compare complete jobs, including retries and review time. DocRead has no public price list, because deployments are set up per client. Its cost follows a simple logic. - A file with its own text makes no model call. - A scanned page makes two model calls. - A disputed page makes a third call when the deployment names a third reader. The `usage` field of every response gives the calls and tokens of each model, and their cost at public prices when the profile holds them. You can see the cost of each document as it runs. ## Security and data handling Document pipelines carry contracts, invoices and medical data, so ask every OCR vendor these questions. Here are the DocRead answers. **Retention.** DocRead keeps no document. The log holds one line per request: method, path, status, time and page count. The body of a document, its name and its text are never logged. **Access.** Every route except `/health` needs a service key. **Signed URLs.** The service fetches a document only from hosts on the allowed list. **Antivirus.** A scan route checks a document before you read it. **Model providers.** A scanned page goes to the two model providers your profile names, so their data terms apply to that page. A file that takes the text layer path leaves your deployment at no point. ## Deployment DocRead runs as an HTTP service behind your reverse proxy, or as a library inside your own process. An idle deployment uses no memory. ## Integration checks before you go live These checks apply to any OCR API, and they catch most production failures. - Send a document your pipeline should refuse, and confirm your code handles the error. - Decide what happens to a page in `readOnceOnly`, because it had no second reader. - Store the `sha256` of each file, so a resend can be recognised. - Set a timeout that fits a long scan, because each page makes model calls. - Log the disputes per document, because a sudden rise usually means a new layout or a worse scanner. - Keep the model usage per document, so cost changes show up early. ## Who DocRead fits DocRead fits teams whose documents carry amounts or medical values that must stay exact, and who already have an application to plug it into. Accounting flows, insurance files, form intake and medical records are the natural cases. It fits less well if you want a finished review screen, a public self serve signup, or a price list today. It offers none of those. Language coverage and handwriting accuracy have no published figures, so include both in your own test. ## Preparing documents for better OCR | Input problem | Effect | What helps | |---|---|---| | Photos taken at an angle | Lines bend and characters distort | Scan flat, or use a scanner app | | Low resolution | Small digits blur together | Aim for 300 DPI | | Dark shadows | Text disappears at the edges | Even lighting | | Stamps over text | Characters get hidden | Keep the original if you can | | Several documents in one file | Fields get mixed | Split files by document | Good input costs less than any later correction, so give suppliers and staff simple capture rules. ## Human review that scales A review step should focus on the documents that carry a flag. 1. Let clean documents pass on their own. 2. Send only flagged values to a person. 3. Show the page image next to the value. 4. Record each correction. 5. Sample a share of the clean documents each month. Those corrections show where your documents fail, so your process improves over time. ## Metrics to track in production | Metric | Why it matters | |---|---| | Share of documents with no flag | How much work is automated | | Corrections per hundred documents | Real error rate | | Time to process | Effect on your workflow | | Failed files | Bad inputs or provider problems | | Cost per page | Budget control | ## Common use cases | Use | Fields often needed | Main risk | |---|---|---| | Supplier invoices | Number, date, totals, VAT, IBAN | A wrong amount paid | | Expense receipts | Merchant, date, total | Faded thermal paper | | Bank statements | Dates, amounts, balances | Column alignment | | Forms | Ticked boxes and handwriting | A choice misread | | Medical reports | Values, units, dates | A clinical error, which calls for human review | ## OCR, document AI or a language model alone Teams often ask whether a general language model can replace OCR. It can read many pages well. The risk lies in how it fails. | Approach | Strength | Weakness | |---|---|---| | Classic OCR engine | Fast, cheap and predictable on clean print | Weak on layout, handwriting and poor scans | | Trained document model | Strong on the document types it knows | Needs training data, and drifts on new layouts | | General language model | Reads messy pages and understands context | Can write a plausible value the page never printed | | Independent double reading | Exposes disagreements | Costs more per page | A wrong word in a summary is a small problem. A wrong amount in a payment run is a serious one, so match the method to the cost of an error. ## Questions to ask your finance or operations team 1. Which fields trigger a payment or a decision? 2. What does one wrong value cost? 3. How many documents arrive each month, and at what peak? 4. Who reviews exceptions today? 5. How long must originals be kept? 6. Which suppliers send the worst scans? The answers tell you which values need strict checks and how much review your team can absorb. ## Rolling out OCR in stages 1. Pick one document type with a clear owner. 2. Run the service next to your current process for a few weeks. 3. Compare results by hand on a sample. 4. Switch the clean documents to automatic handling. 5. Add the next document type. The comparison gives your finance team evidence to review. ## Next step DocRead is an in house service at La Boétie, and the studio deploys it inside client products. [Send a brief](https://laboetie.io/brief) with a few sample documents and the values that must stay exact, and the studio will tell you how a pipeline would look for your case. Two related engines are worth reading: [GateLLM](https://laboetie.io/products/gatellm) routes the model calls, and [Source Access](https://laboetie.io/products/source-access) reads public web pages for AI agents. ## Frequently asked questions ### What is an OCR API? An OCR API is a web service that takes an image or a scanned document and returns its text. OCR stands for optical character recognition. The DocRead read call takes a file upload and returns the text of each page. Its pair of readers adds one check: a printed value counts as read when both readers hold it. ### Do you need OCR when a PDF already contains text? No. DocRead returns the text layer of such a PDF and makes no model call. In the bench of 25 October 2026, that path on 29 born digital pages produced 0 wrong amounts and 0 missed amounts of 647 at a cost of 0 dollars. A flattened form is the exception, because its text layer holds every choice and only the page image shows which one is marked. ### Does a confidence score mean an extracted value is correct? No. In DocRead the field confidence is the rating of the extraction model on three levels: high, medium or low. A team uses that rating to route doubtful fields to review. The rating gives no proof of the value. The stronger check on a scan is agreement, where two readers from different vendors must hold the same printed value. Two readers can still make the same error. ### Can an OCR API read handwriting? DocRead has a form mode that transcribes handwritten answers and writes each choice as [x] when it is ticked, circled or filled and [ ] when it is empty. When the two readers count different marked choices on a page, the page goes to the third reader. DocRead has no published accuracy figure for handwriting, so test it on your own forms. ### How much does an OCR API cost? OCR cost depends on the pages that reach a model. On the scan bench of 25 October 2026, DocRead cost 11.42 dollars per 1,000 pages at public model prices, third reader included. Files that carry their own text made no model call. DocRead runs in house and has no public price list. The usage field of each response holds the calls and tokens of that read. ### Does DocRead store documents after reading them? DocRead keeps no copy of a document. The service log holds one line per request with the method, path, status and duration. The body, name and text of a document stay out of it. Scanned pages do travel to the two model vendors that read them, so the data terms of those vendors apply to each deployment. ### What is the difference between an OCR API and a data extraction API? An OCR API returns the text of a page, while a data extraction API returns named fields. DocRead does both in two calls. The read call returns the text. The structure call then returns your JSON schema filled in with one confidence per field. Two calls let a team check the disputes on a page before any field reaches a downstream system.