An AIA pay application engine that matches the contractor's own file to the cent

The owner did not describe an AI problem. He described an invoice control problem. On a large multi-building job the company might send ten to twenty invoices over the life of the project, each one depending on the last. The workbook holding that chain is a spreadsheet, and the spreadsheet is maintained by hand, by whoever has been doing it.

That creates two failures that have nothing to do with technology. The last spreadsheet gets lost or gets hard to reconstruct, and rebuilding months of billing history from PDFs is a bad week. And the person who can do it is one person, so the company's ability to bill is bounded by their availability.

There was a second problem underneath it, and it is the one that decides whether any software is usable here. The general contractor has been accepting Pearl Street's billing file for years. Hand them something that looks different and you have created a conversation about your software instead of about your invoice. So the constraint was not just correct numbers. It was an identical document.

We built the pay application engine. It imports the export from SnapCount, which is the estimating and takeoff software the money actually lives in, builds the schedule of values from it, and generates each pay application as a draw against the contract, reconciled to the previous application.

The rule underneath the whole build: every dollar is computed by code, never by a model. A language model is genuinely good at reading a messy field note into a structured line item. It has no business adding up a schedule of values, and it has less business computing retainage. So the model reads and organizes, the arithmetic runs in tested functions, and a person signs the application before it reaches the general contractor.

Then we proved the document. Not the numbers, the document. Two renders of the same pay application, ours and theirs, compared cell by cell: 1,290 printed cells checked for value across the G702, the G703, and the schedule of values, and 2,816 cells checked for style, meaning fonts, borders, number formats, and conditional formatting. The parity gate is part of the build, so a change that breaks the format fails before it ships.

Before it touched a live invoice, we ran five simulated months of a real job through it, a full lifecycle from notice to proceed forward. That exercise found a real change-order bug. It found it in a sandbox, in front of us, rather than on a pay application in front of the client.

The engine reconciled 33 out of 33 schedule-of-values lines to the cent against a real $4,104,700 contract, and the exported workbook matched the company's own file at 0.0000% drift. You can put the two documents side by side and the only thing that differs is nothing.

What that buys is not really speed, although it is faster. It is that the invoice chain now lives in a system instead of in a spreadsheet and a person's head. The chain can be reconstructed, the draws reconcile automatically, and a second person can produce a pay application without reconstructing months of history first.

The next module is the one the owner actually asked for first: a command center across every active job that red-flags when billing and installed progress drift apart. Billed 50 percent against installed 90 percent is a conversation worth having before the general contractor has it with you. The cross-reference agent that does this passed 44 out of 44 checks, and the part we were most pleased with is that it correctly stayed quiet at 93 percent billed against 92 percent installed, because that is noise and a system that cries wolf gets ignored.