Extracting Escrow Instructions From a Real Estate Closing Document

Escrow instructions are a list of things the escrow holder must do, and almost none of them are unconditional. “Disburse $12,400 to the county tax collector” and “Disburse $12,400 to the county tax collector upon recording of the deed” are different instructions, and a schema with a flat instructions[] array of strings cannot tell them apart.

What the document is and what it is not

In a real estate closing, the escrow holder is a neutral third party holding funds and documents until the conditions of the transaction are met. The instructions are the parties’ directions to that holder: what to collect, what to pay, what to record, in what order, and on what conditions. They are frequently mutual — signed by both buyer and seller — and they may be supplemented by separate lender instructions which the escrow holder must also satisfy.

It is worth being precise about which document you have, because the closing file contains several and they carry different content. A Closing Disclosure or settlement statement is a numbered accounting of who pays what; its extraction problem is that the columns must foot. Escrow instructions are prose, and their extraction problem is conditional logic. If you are looking at numbered lines that add up, you are not looking at instructions.

Note also that this page is about parsing the document. Nothing here is advice about how a closing should be conducted, and an extraction pipeline should never be the thing that decides whether a condition has been met.

An instruction without its condition inverts

This is the specific hazard. Consider a real fragment shape:

7. You are authorized to record the Deed when, and only when,
   you are in a position to issue the Policy of Title Insurance
   described in Paragraph 4, with Exceptions 3 and 7 deleted.

8. Do not disburse the loan proceeds until you have received
   written funding authorization from Lender.

9. Withhold from Seller's proceeds the sum of $12,400.00 and
   disburse the same to the County Tax Collector upon recording.

Summarise those into a list and you get “record the deed”, “disburse the loan proceeds” and “disburse $12,400 to the tax collector”. Every one of those is a directive to do immediately what the document says to do only in specified circumstances, and item 8 has been inverted outright — the document prohibits an act and the extraction authorises it. The failure is not a confidence problem and it is not a schema-validity problem. The output is well-formed, plausible and the opposite of the source.

Language models are good at this kind of paraphrase and that is exactly the risk: asked for “a list of instructions”, a model will produce clean imperative sentences, because clean imperative sentences are what lists of instructions look like. The instruction to the model has to make the condition a first-class part of the requested structure, not something it may optionally mention.

Modelling trigger, ordering and negation

The minimum shape that survives this document type is nested rather than flat:

{
  "item_number": "8",
  "modality": "prohibition",       // directive | prohibition | authorisation
  "action": "disburse",
  "object": "loan proceeds",
  "conditions": [
    {
      "type": "receipt_of_document",
      "text": "written funding authorization from Lender",
      "polarity": "until"          // upon | until | unless | only_when
    }
  ],
  "depends_on_items": [],
  "verbatim": "Do not disburse the loan proceeds until you have
               received written funding authorization from Lender."
}

Four things there are doing real work. modality separates “you shall”, “you are authorised to” and “do not”, which are three different states and not two. polarity on the condition distinguishes a trigger that starts an obligation (upon) from one that blocks it (until, unless) — the same words with the polarity dropped produce the inversion above. depends_on_items captures cross-references, which are frequent (“the Policy described in Paragraph 4”) and which mean an item cannot be understood alone. And verbatim is non-negotiable: this is a document where the exact wording is what a dispute turns on, so the parsed structure is an index into the text rather than a replacement for it.

Condition types worth having as an enum, because they recur across almost every file: recording of an instrument, receipt of funds, receipt of a document or authorisation, issuance of a title policy, satisfaction of a title requirement, expiry of a period, and written mutual instruction. Anything you cannot classify goes to other with its text preserved — a category you should expect to be well populated, and which is the right place to sample from when checking the extraction, in the way described in setting a human review rate.

Ordering is a separate axis from conditionality. “Record the deed before disbursing” is a sequencing constraint between two items rather than a condition on either. Where the document states a sequence, capture it as edges between item numbers; where it only implies one through conditions, do not invent the edge.

Amendments supersede, and they are separate files

Escrow instructions are amended, often several times, by short numbered documents that change one or two items and leave the rest. The operative set of instructions is the original as amended, and no single PDF contains it.

So the unit of extraction is not a document, it is a transaction — an escrow number with an ordered set of documents. Each amendment needs: its own date, its sequence number if it has one, and the item numbers it touches. Then the current state is computed by replaying them in order. Two practical hazards in that replay. Amendments sometimes renumber rather than referencing (“Paragraph 8 is deleted in its entirety and the following substituted” leaves the numbering intact, but “the following paragraphs are added” may collide with existing numbers). And amendments are frequently undated in the body and dated only in the signature block, so the ordering key may have to come from the signatures — the same extraction described in pulling signatories and dates out of a signed PDF.

Record which document each currently-effective item came from. A reviewer asked to check the instruction set will want to see the amendment that changed it, and a pipeline that outputs a merged list with no provenance forces them to re-read everything.

Where it breaks

Boilerplate outnumbers the operative terms. General provisions — the escrow holder’s limitations of liability, cancellation terms, the statement that it has no duty to notify anyone of anything — can run to several pages and are near-identical across every file from the same company. They are not instructions and extracting them dilutes the output. Classify them out by matching against a template of the company’s standard provisions, and treat a deviation from the boilerplate as a finding in itself, because a modified general provision is unusual and someone negotiated it.

Amounts appear as words, figures, or a reference. “the sum of $12,400.00”, “the amount shown on line 1204 of the settlement statement” and “the balance remaining” are all valid ways of specifying a disbursement. Only the first is a number. Model the amount as a union of a literal, a reference to another document, and a computed residual, and never coerce the last two into null.

Signature requirements are themselves conditions. Mutual instructions are only operative when both parties have signed, and a page in the file with one signature is a proposal. Extract the execution state alongside the content.

Handwritten interlineations. Closings are edited in the room: a figure struck through and rewritten by hand with initials beside it. The typed value is what OCR reads and the handwritten value is what governs. Detect strike-through as a layout feature rather than hoping the model mentions it, and route any page with visible manuscript edits to a human — this is one of the small number of cases where the right answer is not to extract at all.