Reconciling 12 closing documents in 20 seconds: an OpenClaw use case
Twelve documents from five parties, reconciled into a single defensible view before the call ends. The OpenClaw Deal Closer workflow, and the schema-first design that keeps it audit-proof.
Michael Pansolini
Operator and Co-Founder
Every closing has the same shape. Too many documents. Too many parties. A deadline that does not care.
By the time a deal hits closing, you have a settlement statement, a wire confirmation, a title commitment, two amendments, a payoff letter, an HOA estoppel, an insurance binder, and three emails arguing about who pays for the survey. The numbers on those documents are supposed to agree. On the first pass, they almost never do.
The Deal Closer is the OpenClaw workflow that turns that pile into a single reconciled view in under twenty seconds. This post walks through what it actually does, why we made it deterministic on the math even though it uses an LLM for the reading, and where it breaks down.
What is closing statement reconciliation?
Closing statement reconciliation is the process of cross-checking every dollar amount on the closing documents against every other document, and surfacing discrepancies before the wire goes out. The settlement total has to match the sum of line items. The wire amount has to match the settlement total. The payoff letter has to match the loan line on the statement. Prorations have to match contract dates.
Done by hand on a normal closing, this is thirty to sixty minutes of cross-referencing per deal. Done badly, it produces phone calls a month later when the bookkeeper finds a discrepancy nobody caught.
Why doing this with an LLM alone is a bad idea
Closing reconciliation looks like a text problem. It is a structured-data problem hidden inside text. That distinction matters because LLMs are good at the reading half and unreliable at the math half.
The first version of this we built used a model end-to-end: feed it the documents, ask for the reconciliation, trust the output. It worked maybe 70% of the time. The 30% it got wrong was where it confidently produced a clean summary that quietly disagreed with the actual documents on a $4,200 line item.
For a workflow that touches money, 70% is unacceptable. We rebuilt it with a hard split.
How OpenClaw's Deal Closer runs
The trigger is a folder, an email thread, or a chat with the closing documents attached.
-
Ingest. Every PDF and image in the working set gets pulled in. We preserve the original filenames so the audit trail stays intact.
-
Schema-first extraction. Each document goes through a structured extraction pass. The model is not allowed to summarize. It is given a fixed reconciliation schema (party names, property identifier, line items, totals, dates, signatures) and forced to fill it out. Anything outside the schema is ignored.
-
Normalize. Money is converted to a canonical decimal. Party names are matched against a known list (buyer, seller, agent, lender, title) so "John A. Smith" and "John Smith" do not show up as two different parties.
-
Cross-check with rules, not the model. This is the make-or-break step. The reconciliation engine runs a fixed set of deterministic checks. Settlement total equals sum of line items. Wire amount equals settlement total. Payoff letter matches the loan line. Prorations match the contract dates. Each check produces a pass, fail, or "missing input."
-
Cite every number. Every value in the final report carries a back-pointer to its source: "page 3 of buyer-settlement.pdf, line 207." This is what makes the workflow defensible. When a discrepancy surfaces, you can show your work in seconds.
-
Report. A single document drops into the thread with the reconciled totals, the discrepancies in priority order, the source citation for every number, and a one-line recommendation per issue.
End to end, on a normal closing, this is twenty seconds.
What we figured out the hard way
Three lessons from running this against real closings before it was reliable.
Free-form vendor names are the silent killer. Title companies write the same party as "Mike Pansolini," "Michael H Pansolini," and "Pansolini, Michael" across three documents. Without normalization, those become three parties and the reconciliation reports a phantom buyer. We added a fuzzy-match step against the contract's named parties to collapse them.
The model loves to hallucinate "missing" line items. Asked "is anything missing from this settlement statement?", it would invent plausible-sounding fees. We changed the prompt: it can only flag missing items if a referenced amount appears in another document but is absent from the statement. No referenced amount, no flag.
Confidence scoring matters more than accuracy. We used to just output the result. Now every cross-check carries a confidence score, and anything below 90% gets pushed into a "needs human review" section. That single change cut downstream phone calls by roughly 80%.
When Deal Closer is the right tool
This workflow earns its setup cost when:
- You are closing more than two deals a week
- Documents arrive from multiple parties with no standard format
- The discrepancies you find are usually small but recurring (typos, prorations, late amendments)
It is the wrong fit if your closings are simple enough that one statement covers everything. At that volume, a manual review by an experienced closer is faster than the agent setup, and the rare discrepancy is cheaper to catch by hand.
The numbers
For an operator running 4 to 8 closings a week:
- 30 to 60 minutes of cross-referencing per closing, eliminated
- Roughly 75% of the "why does this number not match" phone calls, eliminated
- Discrepancies that used to surface a month later (when the bookkeeper does the close) caught before the wire goes out
That last one is the compounding win. Catching a $4,000 mismatch at closing costs nothing. Catching it a month later costs a phone tree, an amendment, and a bookkeeping correction.
FAQ
What document formats does it handle? PDFs (text and scanned), images of paper documents, and Word docs. Scanned PDFs go through an OCR pre-pass before extraction.
Does it work with non-real-estate closings? Yes. The reconciliation schema is configurable. We have run this on M&A closings, settlement agreements, and complex invoice reconciliations. The rules engine cares about line items and totals, not about what kind of deal generated them.
Can the LLM see sensitive PII? Only inside the agent runtime. Extracted values are stored, but the source PDFs are not retained beyond the reconciliation run unless you configure long-term archival.
What if a document is missing entirely? The reconciliation report flags it as "expected but missing" and skips the checks that depend on it. It does not silently pretend the rule passed.
Try it on your own closings
If you want Deal Closer wired into your title, escrow, or transaction-management stack, browse more community use cases or book a white-glove install.
