Educational

OCR versus Document Understanding versus Cross-Document Validation

OCR reads the page. Document understanding names the fields. Cross-document validation checks those fields against the other documents in the case.

Saarvak · 11 November 2026 · 12 min read

Saarvak builds DocIntel AI, software that reads Indian business documents, including Hindi and Marathi pages in Devanagari, extracts fields, checks them against rules, and routes exceptions to a reviewer.

A scan is a picture until software does three different jobs with it. Teams often use one word, OCR, for all three. The outputs are different, and the later jobs cannot start until the earlier ones have finished.

What is the difference between OCR, document understanding, and cross-document validation?

OCR converts text in documents into machine-readable information.
Document understanding identifies the meaning, structure, and context of that information.
Cross-document validation compares information across multiple documents and checks it against business rules to identify inconsistencies.

These technologies solve different problems and can work together in an intelligent document-processing workflow.

OCR makes a page readable. Understanding makes it a record. Validation makes a set of records a decision.

WORKED EXAMPLE

A purchase order against an invoice

Synthetic documents. One line item, tax omitted. The invoice agrees with itself. It does not agree with the order.

Synthetic documents

Purchase order PO-2024-0187 and tax invoice INV-1048. One line, tax omitted.

Purchase order PO-2024-0187 compared with invoice INV-1048. Quantity and total mismatch. Unit price matches.
Field	Purchase order	Invoice	Result
Quantity	100	120	Mismatch
Unit price	₹500	₹500	Match
Total	₹50,000	₹60,000	Mismatch

The invoice is internally consistent: 120 × ₹500 = ₹60,000. The purchase order is also internally consistent: 100 × ₹500 = ₹50,000. The mismatch appears only when the two documents are compared.

What happens at each stage

1. OCR extracts the text. Each page becomes machine-readable characters. The invoice page yields INV-1048, 120, ₹500, and ₹60,000 as text. The purchase order yields 100 and ₹50,000. Nothing has been compared.
2. Document understanding identifies quantities, prices, and document types. One file is classified as a purchase order, the other as a tax invoice. 100 is quantity ordered. 120 is quantity billed. ₹500 is the unit price on both.
3. Cross-document validation compares the values. Quantity 100 is set beside quantity 120. Unit price ₹500 is set beside unit price ₹500. Total ₹50,000 is set beside total ₹60,000.
4. Business rules identify discrepancies. The rule “billed quantity equals ordered quantity” fails. The rule “unit price equals the order price” passes. The rule “invoice total equals purchase-order total” fails. The invoice’s own arithmetic still passes, because 120 × ₹500 = ₹60,000.
5. Human review resolves exceptions. The case goes to a reviewer with the failed fields named. The person decides whether 120 against 100 is a billing error, an amended order, or a tolerance the process allows.

ARCHITECTURE

OCR, then understanding, then validation, then a person

The worked example above is one pass through this sequence. Skip a box and the next box has nothing reliable to use.

01
OCR
Characters and words from each page.
Next: Document understanding.
02
Document understanding
Document type, fields, and tables.
Next: Cross-document validation.
03
Cross-document validation
Named fields compared under business rules.
Next: Exception handling.
04
Exception handling
Failed rules and uncertain fields go to a person.

Architecture of one document-processing pass. Business rules sit inside validation. Exception handling is the review step, not another OCR pass. Each box uses the output of the box before it.

THE DISTINCTION

Three questions, three outputs

Read the question on each card. That question is the whole difference between the layers.

01
OCR
What characters are on this page?
Returns. Text, sometimes with word positions.
Leaves open. Which document this is, and which string is which field.
02
Document understanding
What should be stored from this document?
Returns. The type, named fields, tables, and a pointer back to the page.
Leaves open. Whether the other documents in the case agree.
03
Cross-document validation
Do the documents in this case agree?
Returns. A pass or a fail, and the fields that explain it.
Leaves open. Cases a rule cannot decide. Those go to a reviewer.

Each layer uses the output of the one before it. Word positions from OCR are still text, not business fields.

A character engine can return “100”, “120” and “PO-2024-0187” and still have no role for any of them. Understanding assigns the roles inside each document: quantity ordered, quantity billed, purchase-order number. Validation places those roles side by side and applies a rule the process actually uses.

The order is fixed. Understanding needs the text, and the layout around it, before it can name a field. Validation needs named fields from more than one document before it can say they agree. Finish after the first layer and a person still names the fields and compares the files.

LAYER 01

What OCR is for

Optical character recognition turns marks on a page into text. On a clean printed page it does this well.

A GST invoice asks more of it. Devanagari labels and Latin identifiers share a line: बीजक क्र. beside INV-1048, and शर्मा ट्रेडर्स beside a quantity and a rate. Better engines also return a position for each word, so the label stays near the value instead of collapsing into a paragraph.

Positions help the next step. They are still text. The engine has not been told that one string is an invoice number and another is a date, or that a row of numbers is a table. Handwriting, stamps sitting on top of print, skew, and faint scans lower the confidence of those characters. The output is still a string.

That string is the right result when someone needs to search a notice, a certificate, or a letter. It is the raw material when a system needs an invoice number it can post.

LAYER 02

What document understanding adds

Understanding uses the text and the layout together and returns a record: a type, named fields, and tables that stay tables.

01The page

कर बीजक

TAX INVOICE · SAMPLE

बीजक क्र. / Invoice No.: INV-1048
दिनांक / Date: 18/04/2024
क्रय आदेश / PO No.: PO-2024-0187
विक्रेता / Supplier: शर्मा ट्रेडर्स

One line item on the sample invoice
Item	Qty	Amount
स्टील ब्रैकेट	120	₹60,000

p.1

02OCR returns text

कर बीजक TAX INVOICE बीजक क्र. / Invoice No. INV-1048 दिनांक / Date 18/04/2024 क्रय आदेश / PO No. PO-2024-0187 विक्रेता / Supplier शर्मा ट्रेडर्स सामग्री विवरण 1 स्टील ब्रैकेट / Steel bracket 120 नग ₹500 ₹60,000 कुल राशि / Total ₹60,000

Hindi labels and Latin values land in one stream. A position for each word still does not name the field.

03Understanding returns fields

Invoice No.INV-1048
Date18/04/2024
PO No.PO-2024-0187
SupplierSharma Traders
ItemSteel bracket
Qty120
Rate₹500
Total₹60,000

On this page, 120 × ₹500 = ₹60,000. The invoice agrees with itself.

Simplified sample, one line, tax omitted. शर्मा ट्रेडर्स is stored as Sharma Traders. The page total matching its own line is a check inside one document.

Classification comes first, because the type chooses the fields. An invoice, a goods receipt, a delivery challan, a discharge summary, a claim form, and an FIR do not share a field list. A bilingual label pair such as विक्रेता / Supplier is one field. In the sample, the name printed as शर्मा ट्रेडर्स is stored as Sharma Traders.

स्टील ब्रैकेट, 120, ₹500, ₹60,000 is a row with a description, a quantity, a rate, and an amount. Flattened into the text stream, that row cannot be checked or posted. Kept as a row, it can.

Each value should point back to the page it came from, so a reviewer can look at the source instead of trusting a number with no origin. On this invoice the line also checks itself: 120 × ₹500 is ₹60,000, and the printed total says the same thing. The page is internally consistent. That is worth knowing. It still says nothing about whether the purchase order asked for 100.

Unseen layouts, nested tables, and a date that could be the invoice date, the purchase-order date, or the date of supply should travel with a confidence score. Uncertain fields wait for a person. A confident wrong field is a worse input to the next layer than a blank one, which is why the source page stays attached.

VALIDATION RULES

The checks behind the table

Comparison lines the fields up. Rules decide match, mismatch, and whether the case can move on.

On the synthetic packet, the rules are:

Billed quantity equals ordered quantity. 120 against 100 fails.
Invoice unit price equals the purchase-order unit price. ₹500 against ₹500 passes.
Each document’s total equals its own quantity times unit price. Both documents pass this check on their own.
Invoice total equals purchase-order total. ₹60,000 against ₹50,000 fails, which follows from the quantity mismatch when the price matches.
The purchase-order number printed on the invoice, PO-2024-0187, is the order being checked.

A tolerance is a business choice written into the rule, not a property of the scan. Some processes allow a short delivery. This example allows none: 120 against 100 is a hard fail. Adding a goods receipt makes the same idea a three-way match: ordered, received, and billed. The rule is still “these named quantities agree”, with one more document in the set.

The same shape shows up outside accounts. Incident date and place can be compared across an FIR, a claim form, and a surveyor report. A diagnosis on a discharge summary can be compared with the prescription and the bill. A file that arrives without a document the checklist expects is flagged because the expected field has no source page.

FAILURE CASES

Where the stack gets the wrong answer

A failed rule is useful. A passed rule built on a misread field is not.

The scan is misread

Handwriting, stamps over print, skew, and faint pages lower OCR confidence. If 120 is read as 100, the quantity rule passes and the billing error disappears.

The wrong field is named

A page can carry an invoice date, a purchase-order date, and a supply date. Understanding that assigns the supply date to the invoice date stores a clean, wrong record.

The page agrees with itself

This invoice does. 120 × ₹500 = ₹60,000. A within-document check passes, and the cross-document check is the one that matters.

A document is missing

There is nothing to compare. The checklist rule fails because the purchase order, the invoice, or another expected file never arrived.

Header and lines disagree

A header total can match while one line does not, or the reverse. Rules have to say whether they compare headers, lines, or both.

The same order is billed twice

Two invoices can each match the purchase order on price and still duplicate the quantity. A rule that only compares one invoice to one order will not see the second bill.

SIDE BY SIDE

How the three differ

OCR answers what the page says. Understanding answers what should be stored. Validation answers what should happen to the case.

OCR, document understanding, and cross-document validation compared
Capability	OCR	Document understanding	Cross-document validation
What you get	Characters and words	Fields, tables, and a document type	A pass or a fail, with the reason
Document type	Not identified	Classified	Used to choose the rules
Named fields	Not assigned	Invoice number, date, party, totals	Compared across the packet
Tables	Often flattened into the text	Kept as rows and columns	Matched row by row
120 × ₹500 on one invoice	Not checked	Checked against the printed total	Checked, then set beside the other documents
120 billed against 100 ordered	Not compared	Not compared	Compared, and failed
A document missing from the packet	Not detected	Not detected	Flagged against the checklist
What a reviewer still does	Reads the page	Confirms low-confidence fields	Decides the failed rules

Engines differ in how much layout they return with the text. Boxes around words are still a layout. They become fields only when something assigns them a name, a type, and a check.

IN PRACTICE

Which layer you need

Searchable text

A pile of notices, certificates, and letters, where people are looking for words. OCR, with the reading order kept, is the job. Fields are optional.

A record another system can take

An invoice, a claim, or an FIR posted as data. That is document understanding. An API needs a quantity, a rate, and a total as fields. A paragraph will not book them reliably.

A decision on a packet

Pay, hold, or send back. That is cross-document validation, and it runs after the fields exist. The useful output is a pass, a fail, and the fields that caused the fail.

Most document-heavy teams need all three, in that order. A project that stops at the first layer still pays people to do the naming and the comparing by hand. The pages get read. The case stays unchecked until someone opens the files side by side.

Where a person stays in the loop

Confident, consistent cases can go through. A failed rule or a low-confidence field goes to a reviewer with the source page in view. The queue should say “quantity ordered does not match quantity billed”, with 100 and 120 already named, so the person is deciding the exception.

DOCINTEL AI

How DocIntel brings these capabilities together

DocIntel AI is one pipeline for Indian business documents: read the page, name the fields, check them, and send exceptions to a person. It does not publish an accuracy rate. Results depend on the documents and the rules for that engagement.

Sample result

Review queue

Case: PO-2024-0187
Quantity: 100 ordered, 120 billed
Unit price: ₹500 matches
Status: Exception, pending review

Illustrative DocIntel output for the synthetic packet on this page. It shows the shape of a result: named fields, a failed rule, and a review status. It is not a measured performance claim.

Try the chat Book a demo

The same pipeline covers Hindi and Marathi pages in Devanagari, and document types such as invoices, purchase orders, FIRs, and claim files. Ask a question of a sample document in the chat, or bring your own packet to a demo.

FAQ

Common questions

Is OCR the same as document understanding?

No. OCR converts the characters on a page into machine-readable text. Document understanding uses that text, together with the layout, to decide the document type and which strings are fields, such as a quantity, a unit price, or a purchase-order number.

What is intelligent document processing?

Intelligent document processing is a workflow that reads a page, classifies the document, extracts fields and tables, checks the values against rules, and sends exceptions to a person. OCR is one step in that workflow.

Can OCR compare two documents?

No. OCR reads each page into text. It does not know that a number on a purchase order and a number on an invoice are both quantities, so it cannot decide that 100 and 120 disagree. Comparison starts after the fields have been named.

What is cross-document validation?

Cross-document validation compares named fields from two or more documents in the same case and checks them against business rules. A purchase order for 100 units and an invoice for 120 units is a mismatch. The check returns a pass or a fail, and the fields that explain it.

How does AI validate an invoice against a purchase order?

The system reads both documents, labels the quantity, unit price, and total on each, and applies rules. In the synthetic example on this page, quantity 100 against 120 fails, unit price ₹500 against ₹500 passes, and total ₹50,000 against ₹60,000 fails. A person reviews the failed rules with both pages in view.

Why is human review important in document processing?

Extraction can misread a character, and a rule can only compare the values it was given. A reviewer checks low-confidence fields and failed rules against the source page and decides the exception. That oversight is part of using document AI in an operational process.

What happens when two documents contain conflicting information?

The conflict is recorded as a failed rule. The case is held out of the automatic path and sent to review with the conflicting fields named, for example quantity ordered 100 and quantity billed 120. The reviewer accepts, corrects, or rejects the case under the organisation’s own tolerance.

About the author

This article is credited to Saarvak, the company, because individual job titles are not published on this site.

Sources

Tesseract OCR user manual
Tesseract is an open-source OCR engine. Its manual describes the job as extracting printed text from images. Output can be plain text, or text with word positions (hOCR or TSV). Positions are still text, not named business fields.
LayoutLM: Pre-training of Text and Layout for Document Image Understanding
Xu, Li, Cui, Huang, Wei, and Zhou, KDD 2020. The paper treats document understanding as a joint problem of text and layout, for tasks such as information extraction from scanned forms and receipts. Text alone is not enough when the meaning depends on where a value sits on the page.
NIST AI Risk Management Framework (AI RMF 1.0)
NIST AI 100-1, January 2023. The framework says processes for human oversight should be defined and documented, and that human roles in decision making need to be clear. A review queue for failed document checks is one way to keep that role explicit.

KEEP GOING

Bring a packet, not a single scan

A purchase order, a goods receipt, and the invoice that should match them. We will show what each layer returns.

Book a Demo See pricing