Turn transaction packets into data your team can check

A residential transaction is a stack of filled forms: the sale contract, riders, disclosures, inspection notices, the walk-through. The numbers that matter (price, earnest money, deadlines, who pays for what) are scattered across checkboxes, handwriting, and per-form layouts, and someone on your team re-keys them into whatever runs the back office.

Thresh reads the filled packet and returns the fields you asked for as structured data, with the source page attached to every value so a coordinator can verify any number against the document in one click.

Built on real paperwork, not sample invoices

Our published benchmark corpus includes five complete REALTOR transaction packets: contracts, riders, disclosures, inspection notices, and walk-through forms, filled the way agents actually fill them. Across the full 37-document corpus we measure 98.6% field accuracy and 97.2% table cell F1, with the methodology public. Checkbox states come back as explicit true/false, and a missing value says so instead of silently vanishing.

What a brokerage does with it

• One deal, one object. Group a transaction's documents into a deal and get a single synthesized summary: parties, financials, key dates, and cross-document discrepancy checks. If the contract references a rider that is not in the packet, the deal flags it.
• Review without re-reading. Every extracted field carries its source page and a confidence flag. Review mode shows the value next to the highlighted spot on the original form; accepting or correcting is one click, and corrections are recorded.
• Agents who never see JSON. Member seats get a two-step console: pick the saved template, upload the packet, read the results. API keys, webhooks, and developer surfaces stay with your admin.
• It ends in your system of record. Signed webhooks push completed extractions wherever your back office lives. Our worked Follow Up Boss example turns a signed contract into the buyers, a deal with the price and close date, a note with every field and its page, and tasks for the key dates; the Salesforce example lands fields as native records. The same pattern fits any CRM or TMS with an API; see integrations.

What we do not claim

Extraction is as-written: if the seller's name is spelled two different ways on two pages, you get what the document says, because flagging that inconsistency is your leverage in the transaction, not something software should quietly normalize. And no model reads handwriting perfectly, which is why every value links back to its page instead of asking for your trust.