AIA Progress Billing: From Job Progress to a Payment Application

Underneath the software question sits something simpler and more dangerous: a lost-file risk and a one-person risk, both parked on the one process that gets the company paid.

When Pearl Street Systems, an electrical and lighting contractor running multi-building commercial jobs, brought us in, the owner did not describe an AI problem. He described an invoice control problem. The workbook holding the billing chain was a spreadsheet, maintained by hand, by whoever had been doing it.

That creates two failure modes 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, which is the company's ability to get paid, is bounded by one person's availability.

There was a third constraint underneath, and it decides whether any software is usable here at all. The general contractor had been accepting Pearl Street's billing file for years. So the real requirement went past correct numbers. They had to receive a document identical to the one they had accepted for years, or the software became the conversation instead of the invoice.

One rule sits under the whole build: a model can read, but it never counts. Every dollar is computed in tested code, because money math has to be right every single time and a model is only ever probably right.

A language model is genuinely good at one part of this. The money for a job lives in a single tab of a seven-tab workbook exported from SnapCount, the estimating and takeoff software, and turning that messy export into clean, structured line items is exactly the kind of reading a model does well.

Everything numeric after that runs in tested functions, never in the model. Adding up the schedule of values, computing retainage, reconciling this application against the last one: plain code with tests behind it does all of it, and then a person reviews the finished pay application and signs it. The model reads, the code counts, the person signs, and that order is the whole safety design, because the last place you want a wrong number caught is the general contractor's accountant.

Correct totals were never enough here, because the requirement was a document identical to the one the general contractor had accepted for years. So an automated parity gate checks 1,290 printed cells for value and 2,816 for style on every build, and it reported 0.0000% drift from the company's own file.

Correct totals were never going to be enough, because the requirement was a document identical to the contractor's own. So we proved the document itself, cell by cell, with an automated parity gate that runs on every build.

Set the two workbooks side by side and the only difference is that there is none. And because the parity gate lives inside the build, any later change that breaks the format fails before it ships, instead of after a general contractor's accountant finds it. That is what an eval is: a fixed, automated test of the exact thing you promised, run on every change, for the life of the project.

Before the engine touched a live invoice we ran five simulated months of a real job through it, notice to proceed forward, applications and change orders and retainage. That found a real change-order bug in a sandbox, in front of us, instead of on a pay application in front of a general contractor's accountant.

Before the engine touched a live invoice, we ran five simulated months of a real job through it, a full lifecycle from notice to proceed forward: applications, change orders, retainage, month after month. 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 a general contractor's accountant.

That is the entire case for testing in one line. The simulation is where you want the bug to show up, months before a real invoice could carry it out the door.

If your billing is a handful of simple invoices a month, you do not need any of this. A spreadsheet is fine right up until the chain gets long enough, and the people involved get busy enough, that reconstructing it becomes a real risk. That is the signal to act, not a tool being available.

The honest counterweight: if your billing is a handful of simple invoices a month, you do not need any of this. A spreadsheet is a fine tool right up until the chain gets long enough, and the people involved get busy enough, that reconstructing it becomes a real risk. The signal to act is a billing chain that has grown that long, with people that busy. A tool being available is not that signal.

And if a vendor tells you their AI generates your invoices end to end with no deterministic layer and no human signature, ask them two questions. Who computes the retainage? And who signs? The answers should be code and a person, in that order. More on how we run builds like this is on the construction industry page, and the measured results live in the case study.