Why parsing real estate contracts with LLMs is ten times harder than tutorials claim

NovAsia Estate — Sun, 18 Oct 2026 04:52:15 +0000

When we started building the data pipeline for NovAsia (a property catalog and market tool for Southeast Asia), the plan looked embarrassingly simple on paper:

Grab property PDFs and developer contracts (SPAs).

Run them through a modern vision LLM.

Dump structured JSON into PostgreSQL.

Call it a day.

Two weeks in, the pipeline was completely broken. Here is why standard tutorial advice fell apart in production, and what we had to change to get reliable data out of scanned documents.

The stuff tutorials don't warn you about
Most LLM document parsing demos use crisp, born-digital PDFs with clean typography. In emerging markets like Cambodia and Thailand, reality looks very different:

Phone scans: Half the documents are multi-generation scans or photos taken with a phone camera under uneven lighting.

Dual-language layout: Khmer or Thai text mixed with English, often in adjacent table columns where line baselines don't match.

Physical stamps: Red rubber stamps, signatures, and notary seals placed directly over critical numbers (payment milestone dates, sinking fund fees, transfer taxes).

The 40-page prompt trap: If you shove a 35-page PDF into a long-context model and ask for "all fees and payment dates", it will extract 80% correctly and quietly hallucinate the rest with total confidence.

Three practical changes that fixed it
Instead of trying to find one magic model that does everything, we broke the pipeline down into smaller, boring steps:

Aggressive image cleanup before text extraction

Before any model sees the page, we run basic OpenCV passes: deskewing, binarization, and contrast normalization. Removing phone-scan shadows did more for extraction accuracy than upgrading to a larger model tier.

Section-level chunking with rigid schema validation

We stopped asking the model to parse whole documents at once. We chunk by specific section (e.g., "Schedule of Payments", "Maintenance Obligations") and enforce strict Pydantic schemas. If a field fails validation or falls outside expected bounds, the pipeline flags it for manual check rather than guessing.

Treating tables and narrative text as separate problems

Vision models are great at answering qualitative questions ("under what conditions is the deposit refundable?"), but notoriously sloppy with columns in financial tables. We split table extraction into dedicated passes with explicit row-by-row checks.

The takeaway
If you're building with LLMs on messy, physical-world paperwork, raw context window size won't save you. Most of the reliability comes from image hygiene and strict schema boundaries.

Happy to trade notes if anyone else here is wrestling with noisy scans and table extraction.

DEV Community: NovAsia Estate

Why parsing real estate contracts with LLMs is ten times harder than tutorials claim