Skip to content
Case dossier  /  Client win

A loan tracker that reads the closing binder and proves every date

Closing binders go in, every dated obligation comes out with its page and clause, and reminders reach the right people before a window closes.

2,310pages measured

Across the first four closing binders, before any design work. About 55 percent were scans.

9 of 10rows matched

Of the client's hand-kept tickler for one loan, plus a requirement the spreadsheet had never tracked.

161 of 161quotes located

Cited clauses that open and highlight on their page, up from 138, scanned pages included.

$5per binder

Approximate model usage to read a 348-page closing binder end to end.

01

The problem

Every loan the client carries arrives with a closing binder: the note, the loan agreement, the mortgage, guaranties, reserve agreements, and sometimes a swap. Spread across those documents are dozens of obligations per loan. Financial statements due a set number of days after quarter end. Insurance evidence at renewal. Covenant tests. Reserve deposits. Extension notices with windows that open and close on specific dates.

The client tracked all of it in a hand-kept spreadsheet per loan. It was evaluating an off-the-shelf loan management platform for document imaging and deadline tracking, and asked whether we could build that part instead.

One clause showed why the spreadsheet was a risk. An extension option required notice no more than 180 days and no less than 60 days before the original maturity date. Miss the near edge of that window and the option is gone. A maturity column does not catch that. A system that models the window does.

02

What we built

A web app that replaces the document and deadline side of that platform. It does not replace the platform's covenant math, and we said so before writing any code.

First we measured the documents. The first four real binders held 164 documents and 2,310 pages, and about 55 percent of those pages were scans with no text at all. One binder reported itself as a single page while holding 92 embedded documents. Any tool that trusted the page count would have silently dropped a large share of that deal.

The core loop has four steps:

  1. Upload a binder. It goes straight from the browser to storage, because binders run 40MB and up.
  2. Read it. The AI model reads the documents in batches and proposes every obligation with its document, section, page, and exact clause. A second reviewer pass re-reads key documents and returns corrections, additions, and gray areas worth a lawyer's eye.
  3. Schedule it. A separate scheduling engine turns obligations into dated deadlines and emails reminders at 30, 14, 7, and 1 day out, with a weekly nudge on anything past due.
  4. Prove it. Click any date's citation and the source document opens to that page with the quoted language highlighted.

Around that loop sit a portfolio calendar, a review queue, team roles, and per-person notification settings.

03

How it works

The rule that carries the weight: the model reads, and deterministic code decides dates. The AI proposes obligations. It never decides whether something is late. The scheduling engine has no AI in it and is pinned to specific dates by tests. When it was ported from the prototype, both versions ran over the same loan and produced 264 deadlines, identical on every field.

The companion rule: undated obligations are flagged, never guessed. When a binder leaves a date blank, the app asks once in plain language, and every obligation tied to that fact dates itself from the answer.

Scanned pages are read with OCR, and the position of every word is stored so the viewer can draw a highlight on a picture of a page. Long binders are read in batches on the server, so closing the browser tab loses nothing, and the "your loan is ready" email waits until every job has finished. A binder uploaded as one combined PDF is cut into its documents along the PDF's own bookmarks: one 367-page file became 35 documents. When a loan modification shows up later, an Add documents button reads it against the existing schedule and changes only what it amends.

Staff can also ask Claude what is due, what is overdue, and why a date is what it is, through a connector that answers with document, section, page, and clause.

04

The result

On one loan, the client's hand-kept tickler had 10 line items. The tracker matched or beat 9 of them, most with more precise dates, and caught a quarterly guarantor reporting requirement that the spreadsheet's own notes said had never been tracked. The one miss was a letter agreement that was never in the binder. A test harness that replays the viewer across every loan took located quotes from 138 of 161 to 161 of 161. Reading a 348-page binder cost about five dollars in model usage.

The scope line held. The tracker extracts covenant definitions word for word and reminds the team when each test is due, but it does not compute lender-adjusted coverage ratios, model rate curves, or value hedges. Our recommendation was to use the tracker for binder reading and date compliance, and to price covenant analytics on its own if it matters. That is a different product with a much higher accuracy bar.

Read the full build notes: Replacing a loan management platform with a tracker that reads the loan documents.

Fix it until every quote on every loan maps up correctly.
John McIntoshFounder, Salvus AI

Your turn

Same problem? Different industry?

We work with one client per vertical at a time. If your shape matches one of our dossiers, we’ll tell you straight.