Lien waiver tracking where no waiver means no payment

On a construction job, the subcontractors and suppliers who could file a lien send a notice to owner. Before the general contractor pays one of them for a draw, it needs a signed lien waiver back. Miss one and the owner can end up paying for the same work twice.

The client's accounts payable team ran this from one legacy Excel workbook per job and one person's memory. When we opened the workbook, the business logic was hiding in the formatting. Status was a letter plus a cell fill color, and the same letter meant different things depending on whether the cell was orange or yellow. A blank cell shaded mint green meant "release due." That was the most important state in the sheet, the one that should trigger follow-up, and only a human eye could see it.

The paper arrived as photos and scans: notices from lienors, the recorded notice of commencement for each job, and signed waivers coming back. Someone retyped all of it.

A web app that replaces the workbook. The first version was built and seeded with a real job the same day as discovery.

• Document intake from a photo or scan. The AI model reads notices to owner, recorded notices of commencement, and signed waivers into fixed fields, so it cannot return a paragraph where a date belongs.
• Matching against the recorded notice. Each notice is checked against the job's notice of commencement. Parcel number, property address, and owner are hard fails. Smaller differences are flagged, and a typo-aware comparison tells a misspelling apart from a different company.
• A draw grid that looks like the old sheet. The seven color-coded states are now real stored states, but the grid shows the original colors so nobody has to relearn anything. The Excel export reproduces the original layout cell for cell.
• Waiver generation from the client's own templates, notary block intact.
• A contractor database that imports from the accounting system and handles the messy cases: one supplier filing several notices, trade names, and lower-tier companies working under another sub.

On the first test, the model read a recorded notice of commencement (a scan with no text layer), got every field right, and transcribed a misspelling in the document exactly as printed while flagging it as low confidence. A system that reads legal documents should never quietly correct them.

The real spec came from a recorded walkthrough with the AP lead, and it changed the core loop: follow-up starts at payment, not at the notice.

AP records a payment per sub per draw by scanning the check, scanning the printed virtual check it already cuts for ACH, or typing it in. The waiver generates from that payment and goes out with the check copy attached, the way AP already did it by hand. When the signed copy comes back, it is scanned and matched to the waiver that went out, and logging it updates the grid and releases the payment in one step.

The rule that protects money lives in the server. Marking a payment paid before its signed waiver returns is refused by the API, not just hidden on screen.

Other changes came straight from that walkthrough. Direct subs and the companies working under them now show as tiers, set automatically from the notice and seeded for existing jobs by reading the workbook's actual bold and italic font flags. A notice with one detail off shows ranked candidate jobs with the reasons for each, instead of one silent guess. Insurance is tracked the way AP tracks it: the certificate, the additional insured endorsement, and the waiver of subrogation where the contract requires it. An AI chat about job progress was on the early list and was dropped, because the AP lead pointed out that the app tracks paperwork, not progress.

Access is invite-only and enforced in the database. No key in the project can bypass row-level security.

Document reading is confirmed working in production. Notices, notices of commencement, and signed waivers come in as photos instead of retyped rows. The color code is now data the app can act on, so the release-due state that used to be a mint-green blank is a trigger. The rule that a sub does not get paid without a waiver is enforced by the server instead of by memory.

When questions turned up in the client's own paperwork, such as two different company addresses across the recorded notice and the waiver templates, the app surfaced them for a person to settle instead of picking one, because each answer ends up printed on a legal document.

Read the full build notes: Lien waivers, notices to owner, and a spreadsheet that ran on cell colors.