How AI Reads a Sale Deed: Inside Document Extraction for Indian Property Verification

When you upload a sale deed, an encumbrance certificate, and a Record of Rights to a title verification tool, something has to read them. Not skim them. Read every party name, every survey number, every boundary, then check those values against each other across documents that may span thirty years. This post walks through how that reading happens, using one fictional 1998 sale deed from coastal Andhra Pradesh as the test case. We follow it from a blurry scan to a finished legal opinion, and we are honest about where the machine stumbles.

What AI property document extraction in India actually means

AI property document extraction is the process of converting scanned or photographed property records into structured, machine-readable fields, then validating those fields against each other and against external registers. It takes a sale deed image and returns named values: seller, buyer, survey number, extent, consideration, stamp duty paid, registration number, and date. It does the same for an encumbrance certificate, a Record of Rights, a link document, and a tax receipt.

The word "extraction" undersells it. A scanner converts ink to pixels. Extraction converts pixels to meaning. The system has to know that "Sy. No. 142/3A" is a survey number, that "Ac. 0-20 cents" is an extent measurement, and that the Telugu text above the English block is the same clause repeated. Then it places each value in the right slot so a later step can compare it to the same value in a different document.

LegiScore pulls more than 150 distinct data points from a complete document set. Some are obvious, like sale consideration. Some are quiet but decisive, like whether the executant's father's name matches across the chain. Each point is a field a human title examiner would normally copy by hand into a checklist, one document at a time, with a tired eye at 9 p.m.

What Indian property documents look like in practice

Before any model can read a deed, it has to survive the document. Indian property paperwork is not clean.

A typical set arriving for verification is a stack of photocopies of photocopies. The original 1998 sale deed was typed, registered at the sub-registrar office, and stamped on the back of each page with a violet registration endorsement written by hand. Over twenty-eight years it has been photocopied for a bank loan, again for a mutation application, and again for the current sale. Each generation loses contrast. By the time it reaches us, the registration number on page 6 is a grey smudge.

The language layer is its own problem. India recognizes 22 languages under the Eighth Schedule of the Constitution, and property records are written in regional scripts. Our test deed is bilingual: the operative clauses appear in Telugu, with an English translation block alongside. The handwritten endorsement at the foot of each page is in Telugu only. A document set from Tamil Nadu, Karnataka, or West Bengal would carry Tamil, Kannada, or Bengali instead.

Then there are the physical artifacts. Stamp impressions bleed across two pages. A revenue stamp covers part of the consideration figure. The schedule of boundaries sits in a column that got cut off when someone photocopied the page at the wrong size. None of this is unusual. All of it is what the extraction step actually faces.

How extraction reads the 1998 sale deed, step by step

Take our fictional deed. Seller: Koteswara Rao, son of Venkata Subbaiah. Buyer: a joint purchase by two brothers. Property: Sy. No. 142/3A, extent Ac. 0-20 cents, in a village in Krishna district. Consideration: Rs. 2,40,000. Registered 1998 at the local sub-registrar.

The first pass is image handling. The system checks scan quality before it trusts a single character, measuring resolution, skew, and contrast per page. If page 6 is below a legibility threshold, that page is flagged now, not after a wrong value has entered the report. Pages get deskewed and the contrast normalized so faint typewriter ink becomes readable.

The second pass is language detection and text recognition. The model identifies which script each block is in, runs recognition tuned for that script, and aligns the Telugu clause with its English counterpart. Where both languages state the same fact, agreement between them becomes a confidence signal.

The third pass is field extraction. This is where pixels become the 150 points. From the sale deed the system pulls the parties and their parentage, the survey number and any sub-division, the extent, the four boundaries, the consideration, the stamp duty, the document number, and the registration date. Each extracted value carries a confidence score and a pointer back to the spot on the page it came from, so a reviewer can see the source.

What each document type contributes

Extraction is not one model run on one file. Each document type yields a different slice of the picture.

The sale deed gives you the transaction itself: who sold, who bought, what was sold, for how much, and the boundaries that define the parcel. The encumbrance certificate gives you a transaction list, every registered entry against that property over the search period, which is how you reconstruct the chain of ownership and spot mortgages or attachments. The Record of Rights, the RoR or pahani in Andhra and Telangana, gives you the recorded holder, the land classification, and the extent as the revenue department sees it.

Put together, these answer different questions. The deed says a sale happened. The EC says the seller had the right to sell because the chain leads to them. The RoR says the revenue record agrees. When all three line up, you have a clean parcel. When they disagree, you have a finding. Reading an encumbrance certificate by hand to extract that transaction list is slow, error-prone work, exactly the kind of task a machine does without getting bored.

Where machines beat tired humans: cross-document checks

A single document can be read correctly and still hide a problem. The problem only appears when you compare documents. This is the part of title work where consistency matters more than brilliance, and consistency is where software has the edge.

Three checks do most of the work. The first is name-drift detection. Across a thirty-year chain, "Koteswara Rao" becomes "Kotaiah" in one deed, "K. Rao" in a bank record, and a slightly different Telugu spelling in the RoR. A human examiner reading at the end of a long day may not notice these should be the same person. The system holds every spelling variant from every document side by side and flags the drift for a human to confirm or reject.

The second is extent reconciliation. The 1998 deed says Ac. 0-20 cents. The RoR says 0-19 cents. That one-cent gap could be a rounding artifact, a survey correction, or an encroachment. The system surfaces the mismatch. It does not decide what it means. The third is boundary conflict: if the northern boundary in the old deed names a neighbor who, per a later document, also claims part of the same survey number, that conflict gets raised. In documents we have processed from AP sub-registrar offices, extent mismatches of a few cents between the deed and the pahani are common and almost always worth a second look.

How anomaly detection works and what it flags

Anomaly detection is the layer that asks "does this look wrong?" rather than "what does this say?" After fields are extracted and cross-checked, the system scans for patterns that correlate with title risk.

It flags a stamp duty figure that looks low for the stated consideration and the year, because under-stamping can make a document inadmissible. It flags a document number that does not fit the format for that office and year. It flags a chain with a gap, where the EC shows the property moving from A to B to D with no recorded intermediate link. It flags a property described with one survey number on page 1 and a different one in the schedule.

None of these flags is a verdict. Each is a pointer that says "a human should look here." The system is good at noticing that two numbers disagree. It is not the authority on which number is right. That judgment stays with the legal reviewer, grounded in the property context the extraction surfaced.

Why every extracted field is visible and editable before the report runs

Here is the design choice that separates a usable tool from a black box. Before any opinion is generated, every field the AI extracted is shown to the user, and every field is editable.

This matters for three reasons. The first is accuracy. If the model misread "142/3A" as "142/3B" because a smudge bridged the gap, the person who can see the original document fixes it in one click, before the wrong survey number reaches a legal conclusion. The second is trust. A reviewer who can see the extracted value next to its source on the page, with the confidence score attached, decides for themselves whether to rely on it. A number that appears from nowhere earns no trust. A number you can trace and correct does.

The third reason is audit. When a field is edited, the change is recorded. The final opinion rests on values a human confirmed, not on whatever the model guessed in silence. For a bank operations team evaluating an AI tool, this is the difference between a system they can defend in front of a regulator and one they cannot. LegiScore builds the review step in by default: extraction proposes, the human disposes, and the report runs on confirmed inputs.

Can AI read handwritten property documents?

Partly, and you should not believe anyone who says fully. Handwritten registration endorsements, the violet ink the sub-registrar adds under the Registration Act, 1908, are the hardest single element to read reliably. Cursive Telugu or Tamil handwriting, faded over decades and photocopied repeatedly, defeats recognition more often than printed text does.

What works well is structured handwriting in a known position. The endorsement always carries a registration number, a date, and the sub-registrar's notation in a predictable spot, so the system knows where to look and what shape the data should take. What works poorly is free-form marginal notes written sideways. The committed answer: AI reads printed bilingual deed text at high reliability, reads structured handwritten endorsements at moderate reliability, and hands the rest to a human reviewer with the ambiguous region highlighted. Pretending otherwise produces confident wrong answers, which in title work is worse than an honest "please confirm this."

What happens when the input is bad

Real document sets are missing pages, blurred, and cropped. A system that only works on clean inputs is a demo, not a product. The useful behavior is to detect the gap and ask for a better input rather than guess through it.

If page 6 carries the consideration and stamp duty, and page 6 is illegible, the system does not invent a figure. It marks the field unreadable, tells the user which page and which field, and requests a clearer scan of that page. If the EC covers 2005 to 2024 but the deed is from 1998, the system reports that the encumbrance search does not reach back far enough to confirm the chain, and asks for the earlier EC period. If a regional format breaks an assumption, say a Telangana pahani laid out differently from an AP one, the field comes back low-confidence and lands in the human review queue rather than filling with a wrong value. The goal is a report built on what is actually legible, with gaps named, not a smooth-looking opinion resting on guesses.

Manual review versus AI extraction

The manual time and cost figures reflect the published range for title due diligence in India. The speed and volume figures are LegiScore platform numbers. The point is not that humans are bad. Humans and machines are good at different things, and the machine should do the copying and comparing so the human can do the judging.

Speed math: why under 15 minutes is possible

A complete title document set for a contested or long-held parcel can run past 1000 pages once you include the deed, link documents, decades of EC entries, RoR extracts, and tax receipts. LegiScore accepts uploads up to 500MB for this reason. A human reading 1000 pages, extracting every field by hand, and cross-checking them is the source of the multi-day timeline.

Extraction parallelizes. Pages are processed concurrently, fields are pulled in one structured pass, and cross-document checks run on the assembled values. The slow human steps, copying and comparing, are the ones the machine compresses most. What remains for a person is the part that should stay human: reviewing flagged fields, confirming corrections, and forming the opinion. That is how a process measured in days collapses to an opinion ready in under 15 minutes, with a human still in the loop on every value that mattered.

Frequently asked questions

Does AI replace the lawyer in title verification? No. Extraction handles the reading, copying, and cross-checking. The legal opinion, the judgment about whether a flag is a real defect, stays with a qualified reviewer. The tool removes the clerical load so the lawyer spends time on findings, not data entry.

What documents do I need to upload for a full opinion? At minimum the current sale deed and link deeds forming the chain, the encumbrance certificate covering the search period, and the Record of Rights or pahani. Tax receipts and litigation or mortgage records strengthen the result.

Can it handle documents in languages other than English? Yes. The system reads regional scripts including Telugu, Tamil, and Kannada, and aligns bilingual clauses where a deed carries both a regional language and English. Coverage is strongest where a set follows a known regional format.

What if a critical field is unreadable? The system marks the field unreadable, names the page and field, and requests a clearer scan. It does not fill the value with a guess. The opinion is built only on what is legible, with gaps stated openly.

Is the AI's reading final, or can I correct it? You can correct it. Every extracted field is shown with its source and confidence score, and every field is editable before the report runs. Edits are logged, so the final opinion rests on values a human confirmed.

Related reading

• How AI reads legal documents faster than lawyers
• Inside the AI title search engine: a 30-minute TSR
• How AI is changing property due diligence in India
• Chain of title: tracing property ownership history in India
• AI property verification versus manual due diligence
• How to read an encumbrance certificate