Every dollar CRI touches moves through the same five stages, in the same order, with a human decision at the center of it. Here's what actually happens at each one.
CRI scans job records, RFIs, field logs and daily reports for line items that describe work but were never converted into a change order — comparing what was logged in the field against what actually shows up in the billing system. "Unbilled" here means work with a paper trail — a daily log entry, an RFI response, a field note — but no matching invoice or change order in the accounting system.
A flagged item in the Revenue Ledger, linked to the source documents it came from — which field log, which RFI, which date — so the reviewer can check it against the original rather than take CRI's word for it.
Connects to Protect: once flagged, the item needs a permanent record before the underlying paper trail disappears.
CRI creates a timestamped, versioned record of the detected item — the original field note, who logged it, and when — before the underlying paper trail disappears. Site logs get overwritten, RFIs get closed and archived, and the person who remembers the conversation moves to the next job. This step happens before anyone reviews or acts on the item.
A locked record in the audit ledger, tied to the flagged item from the same ledger entry, that stays referenceable even if the source system later changes or archives the original.
Connects to Approve: with the record locked in, it's ready to be routed to whoever owns sign-off.
The protected item routes to the person who owns approval for that job — a PM, a Controller, or whoever the organization designates — along with the full context: what was found, why, and the underlying documentation. Nothing is a form letter; the reviewer sees exactly what CRI saw.
An approval queue with Approve, Reject, or Request more info. Whatever they choose is recorded — who decided, and when — in the same immutable ledger as the original detection.
Connects to Bill: only after a human signs off does an item become billable.
The approved item becomes a billable change order, formatted for the system already in place — Procore, Sage, Autodesk, Viewpoint or CMiC — rather than a new invoice format someone has to translate by hand.
The change order appears inside their existing PM or accounting system, tagged with a reference back to the CRI record it came from, so the audit trail runs unbroken from field note to invoice line.
Connects to Collect: getting billed doesn't mean getting paid.
CRI tracks the change order through the owner's or GC's approval and payment cycle, flags it when it stalls, and surfaces aging claims before they cross the point where owners typically stop honoring late paperwork.
A running list of outstanding change orders with days-outstanding on each, and an alert when one is at risk of aging out of collectible.
This closes the loop opened at Detect — from a line in a field log to cash in the bank.
CRI reads from the project management and accounting systems you already use, finds the revenue slipping through the cracks between them, and routes it back into your existing billing workflow. No new system of record, no migration, no rip-and-replace.
That's deliberate. The pipeline above only works because it plugs into where your team already does its work — field logs and RFIs where the work gets recorded, PM and accounting systems where it gets billed. CRI is the connective layer that watches the gap between them, not a new place to check.