Home Sale Closing & Settlement Tie-Out

Architecture

Key specifications

What it does for you

When a residential developer's home reaches close of escrow the accounting team assembles a package: a settlement statement, a balanced journal entry, a revenue-recognition line, a loan release tied to the lender's statement, and a cost-of-sale relief. Every one of those is a spreadsheet assembled under deadline, and each goes wrong in ways nobody watches. The entry does not foot, or its Accounts Receivable plug was typed rather than derived. The settlement total settlement charges, total closing costs or net to seller was keyed instead of summed, or a rate-derived fee -- the listing sales fee, the warranty reserve -- was struck at the wrong rate. Revenue lands in the wrong month, when residential sales revenue is earned only at close of escrow. The internal loan release and the lender's loan statement disagree, or the bank remittance falls short of the scheduled release price. And the rollup states a closed count, a total net to seller or a per-unit tie-out flag that nobody recomputed from the settlements and entries underneath it. None of these are judgement calls. They are equalities, thresholds, date-gates and membership checks -- a total against its re-summed components, a receivable against the derived plug, a fee against its proforma rate, a recognition month against the close date, an ending balance against the lender statement with ==, a remittance against the release price with >= -- which a deterministic control settles better than a folder of spreadsheets inherited by whoever handles closings this quarter.

The seeded demo runs every control over every closing file⁷. The CLI generates twenty-seven fictional closing files -- one clean baseline and one carrying each of the twenty-six planted defects -- then runs all twenty-five controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

The loan roll-forward and the lender tie are independent⁸. One defect file moves a home's stated loan ending balance and its lender-statement figure together, so the roll-forward from beginning plus activity no longer holds while the two ending figures still agree -- loan_ending_recomputes fails and loan_ties_lender_statement does not. A separate defect moves only the lender figure and trips loan_ties_lender_statement alone, proving the two controls catch different breaks.

The tie-out flag is recomputed, not read back⁹. A defect file flips a closed home's summary tie-out flag to false while its underlying settlement, entry, revenue line, loan release and cost-of-sale entry all still recompute. rpt_unit_tied_recomputes rebuilds the flag from that package and fails against the stated value, proving the summary is recomputed from the evidence beneath it rather than trusted as written.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: closing files are parsed and never written back, so the engine cannot introduce the break it reports.
• Integer cents throughout, compared with exact ==; there is no tolerance band on a figure, and the release-price control is a genuine threshold checked with >=.
• A figure that should be integer cents but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced into the number the engine is meant to audit.
• One settlement kernel: the controls and the generator share the primitives in closing_engine.settlement, so a determination cannot disagree with the data that produced it.
• set_complete owns the missing-artifact finding and runs first, so a missing artifact fails completeness rather than letting the controls that read it pass unread.
• Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.

Operating limits

• The engine never books an entry, files a closing, moves money, contacts a lender, or writes to a source artifact. It reads the closing file and stops.¹⁴
• It reads the nine artifacts the closing record emits. It does not connect to a general ledger, an escrow system, a lender portal or the underlying settlement documents.¹⁵
• It is a tie-out check, not an underwriting one: it proves the paper agrees with itself, not that the home should have sold for its price or that the loan should have been made. That judgement is a different engine's and a reviewer's.¹⁶
• It re-derives the fees at the proforma basis-point rates the file carries; it does not decide whether those assumed rates are the correct ones for the project.¹⁷
• It takes the closing and lender records at face value: it confirms the register, settlements and entries foot and reconcile, not that a closing actually occurred or a remittance cleared. All shipped data is fictional and the closing period is set in a fictional future.¹⁸

See it run

Integration

Distribution: public repository, MIT license.