OCR vs document parsing: what do you actually get back?
Searchable text, a reconstructed table and a reviewed business record solve different parts of the job. Ask to see the output.
Use OCR when people need to search or copy text from a scan. Use document parsing when the layout matters: rows, columns, headings and page relationships. Use structured extraction when the business needs named fields such as invoice number, currency and total. For a recurring invoice register, start by evaluating extraction with evidence and review; for a searchable archive, OCR may be enough.
These capabilities overlap inside products. The useful comparison is the output your next step receives and the work a person still has to do.
Reviewed September 8, 2026. The invoice and arithmetic below are fictional teaching examples. This article compares documented capabilities and attributed user experiences; it does not report our own accuracy benchmark.
Follow one invoice into three outputs
Our fictional two-page invoice is numbered INV-0042, references PO-0081 and uses US dollars. It contains these rows:
| Description | Quantity | Unit price | Line total | Page |
|---|---|---|---|---|
| Filter cartridges | 2 | $125.00 | $250.00 | 1 |
| Inspection | 1 | $80.00 | $80.00 | 1 |
| Travel | 1 | $20.00 | $20.00 | 2 |
The subtotal is $350, tax is $35 and the invoice total is $385. There is no due date or payment term. A correct result must keep the third row and leave the due date unresolved.
Fictional invoice · three illustrative outputs
The number is readable. What does it mean?
Original invoice
INV-0042 · PO-0081 · USD
Page 1: Filter cartridges, 2 × $125.00 = $250.00; Inspection, 1 × $80.00 = $80.00. Page 2: Travel, 1 × $20.00 = $20.00.
Subtotal $350.00 + tax $35.00 = invoice total $385.00. No due date or payment terms appear.
OCR: read the characters
2 · 125.00 · 250.00
Useful for finding and copying text. A documented OCR service may also return word positions and page structure.
The figures alone do not establish which value is the invoice total.
Parsing: retain the relationship
Filter cartridges | 2 | 125.00 | 250.00
Preserve quantity, unit price and line total in their columns. Keep the Inspection and page-two Travel rows.
Expected line count: 3. Do not lose the continued table.
Extraction: select the business fields
invoice_total: 385.00 · due_date: null
Expected currency: USD. Expected invoice number: INV-0042. Expected purchase order: PO-0081. Keep the missing due date unresolved.
Field definitions and supporting evidence determine whether this is a usable record.
Searchable text, reusable table structure and a reviewed invoice record solve different jobs. Judge the output at the next handoff.
Sources: Cloud Vision OCR · Reducto Parse · Reducto Extract
Invented teaching invoice and expected outputs, not screenshots or results from a provider test. Product capabilities overlap.
OCR answers “what characters are here?” A searchable text layer may be all a colleague needs to find PO-0081 and open the original page. Some OCR services also return positions and structure: Google Cloud Vision’s document mode includes pages, blocks, paragraphs and words. OCR does not necessarily mean one unstructured string. Google Cloud Vision OCR documentation.
Parsing answers “how is the content arranged?” The reader needs to know that 125 is a unit price and 250 is its line total. Reducto Parse documents structured output containing text, tables, figures and layout, organized into chunks and typed blocks with positions. Its current r-1 pipeline is a preview and the default for new Parse pipelines; older pipelines may use legacy processing. Record the version in an evaluation. Reducto Parse overview.
Extraction answers “which values belong in our record?” The invoice register needs invoice_total: 385.00 and currency: USD. Reducto Extract accepts a schema defining the fields you want. It can return citations when enabled, including source text and location information. It belongs in an extraction comparison as well as a parsing comparison. Reducto Extract overview.
Choose the least machinery that completes the job
| Your next step | Evaluate first | What still needs doing | Reject the output if… |
|---|---|---|---|
| Find a phrase in a scanned archive | OCR in your existing document software or a suitable OCR service | Check difficult scans; retain the original pages | A known reference cannot be found reliably |
| Reuse a table in another tool | A parser that preserves tables and locations | Check headers, continued rows and column assignments | $125 becomes the line total or page-two travel disappears |
| Populate a recurring invoice register | Extraction against your field definitions | Check source support, missing fields and exceptions | $350 is selected as the invoice total or a due date is invented |
| Prepare a business review | Extraction plus an owned review workflow | Assign unresolved items and retain the decision | A plausible value is treated as approved without review |
| Enter a handful of simple invoices | Your existing manual process | Enter and check the same fields | The software takes more total work than it removes |
A readable page and a reliable record are different deliverables. Ask a vendor to show the actual result that reaches your spreadsheet or application.
Give the extractor an answer key
For the fictional invoice, the key should be explicit:
invoice_number: INV-0042
purchase_order: PO-0081
currency: USD
subtotal: 350.00
tax: 35.00
invoice_total: 385.00
line_item_count: 3
due_date: null
due_date_review_reason: Not stated in the document
Preserve identifiers as text so leading zeros survive. Define which total you mean. Specify one output row per billed item and tell the tool what to do with a table continued on another page.
Request evidence for each consequential field, using the provider’s documented options. Reducto notes that normalized extracted values can differ from the wording in citation source text. A standardized date needs to agree with the original passage; normalization is not permission to invent missing information. Reducto response format.
Fictional missing field · review remains open
A missing date is a valid finding
Start with the documents
INV-0042 · page 1
Invoice identification and first two line items. No payment terms or due date stated.
INV-0042 · page 2
Travel line item and totals: subtotal $350, tax $35, invoice total $385. No payment terms or due date stated.
Keep the answer with its evidence
Open question
Due date: not stated
Keep the due-date field empty and record why it needs clarification. Do not calculate a date from payment terms that do not appear.
Make the next step clear
- Invoice reviewer
Ask the supplier to clarify the due date. Retain the reply with the original invoice and extracted record; the review stays open until resolved.
Fictional example. No automatic resolution or payment approval is implied.
The absent date is useful information. It tells the reviewer what to ask rather than sending an unsupported value downstream. Keep the original invoice, the extraction and the later clarification together. The document prompting guide includes a reusable way to define missing values and evidence requirements.
What people building with Reducto reported
Two first-person comments in an r/AI_Agents discussion show why the whole workflow belongs in the evaluation.
On October 25, 2025, u/Empty-Celebration-26 said their team had tried Reducto and saw improvements around tables and figures, but it did not meet all their needs. They also described downstream work their retrieval system still required. On February 3, 2026, u/wakipaki reported better handling of messy PDFs and less retrieval debugging, with less benefit for plain-text files. Read the first user’s comment, read the second user’s comment.
These are pseudonymous community accounts. We have not verified their identities, document samples or affiliations; no incentive disclosure was visible. Their comments predate the current documentation and are not evidence for current API formats or accuracy rates. We deliberately do not reproduce the first commenter’s unexplained percentage result.
The useful question they raise is concrete: does the output remove your next manual step, or move that step into another system? A parser can improve a document without completing the application built around it.
Calculate cost at the reviewed record
Per-page charges are one part of the bill. On September 8, Google Cloud Vision lists the first 1,000 monthly Document Text Detection units free and the next tier at US$1.50 per 1,000 units. For multipage files, each page counts as an image; other enabled features and Google Cloud services can add charges. Cloud Vision pricing.
Illustrative OCR-only calculation: 2,000 two-page invoices give 4,000 document-text-detection units. Assuming no other usage of that feature in the month, 3,000 chargeable units × $1.50/1,000 = $4.50 for that feature. This is not the cost of an invoice-processing system: it excludes storage, integration, extraction, review and exceptions.
Now add an assumed one minute of review per invoice. At a fictional staff cost of $35/hour, 2,000 minutes cost $1,166.67. That is why a small difference in processing price can matter less than how much checking remains.
For another provider, take the actual quote and record whether it meters pages, requests, credits or a subscription allowance. Specify whether parsing and extraction require separate charges and whether rerunning corrected documents consumes usage. We have not verified a comparable Reducto or Alembic quote for this workload, so this article makes no price-ranking claim.
Test a packet that can expose the wrong answer
Use a proposed ten-document evaluation: two normal digital invoices, two scans, two continued tables, two missing-field cases and two corrected or conflicting documents. Those proportions are a starting sample, not a claim about your workload. Replace them with your actual mix.
Read the originals and build the key first. Give each tool the same field definitions, using its own documented configuration fairly. Keep the first output as well as the corrected one.
Record failures separately:
- Recognition: a character or reference was read incorrectly.
- Structure: a row vanished, split or moved to the wrong column.
- Field choice: the right number was assigned to the wrong field.
- Unsupported answer: a missing value was filled without evidence.
- Review burden: the reviewer could not reach the supporting passage or understand an exception.
For each record, measure upload, setup, review and correction time. Count a document as complete only when it reaches the state your next process requires. If an invoice needs clarification, retaining that open item is a valid result; silently removing it from the count is not.
Where Alembic fits
Alembic can be configured to extract the fields and tables your review requires, apply configured checks, keep exceptions visible and route questions for review. Where a reliable source match exists, reviewers can inspect available source evidence beside extracted values. Source evidence is not available for every value or file. Alembic document workflow features.
Those checks prepare a review; they do not determine payment readiness, accounting treatment or approval. Authorized people make consequential decisions.
An API may suit a team building its own application. A configured workflow may suit a team that wants extraction and review inside its operating process. Neither is automatically the right purchase for a handful of invoices. Start with the result you need and compare the complete handoff, using the paperwork workflow guide and pilot scorecard to record the work that remains.
Useful to someone you work with?