Construction project management software for public owners: RFIs to pay apps

Reference article · 6 min read

A public agency that builds or renovates anything is acting as an owner, not a builder. The owner decides what gets built, commits money to it, approves changes, verifies that work exists, and pays. The contractor builds it and gets paid. Those are different jobs and they produce different records. Much of the software sold as "construction project management" was designed for the general contractor's side of that relationship: coordinating subcontractors, chasing submittals, protecting the builder's own margin. It is useful, and the owner usually needs access to it, but it is not the agency's record.

Owner-side capital project software, sometimes sold as capital planning or program management, is organized around the agency's obligations instead: an auditable chain running from appropriation or grant award through contract, change order, pay application, payment, and closeout. When that chain lives in spreadsheets, email attachments, and the contractor's portal, staff spend the rest of the project reconstructing it for auditors, funding agencies, and the governing body.

What the owner's record has to hold

• Funding sources and their rules. One project often draws on a bond series, one or more grants, a general fund contribution, and a local match. Each source carries its own eligible cost categories, period of performance, reporting cadence, and reimbursement mechanics. Cost has to be attributable to a funding source at the line level, not just at the project level, so that spend and remaining balance by source are a report rather than a reconstruction.
• Budget, commitment, and actual as three separate numbers. Authorized budget, executed commitments including approved change orders, and cash actually paid are different figures that get conflated in spreadsheets. Contingency drawdown should be visible as its own line.
• Contracts and change orders. Original value, current value, and the full change order history with the reason, the requesting party, the approval record, and the dates. Approval thresholds usually come from board policy, administrative code, or state law, and should be encoded in the workflow rather than remembered.
• RFIs and submittals. The owner's interest is narrower than the contractor's: response time, who answered, and whether an answer changed the scope. An RFI response is a common starting point for a later claim, so the owner needs its own copy with its own timestamps.
• Schedule. Owners generally track contract time, milestones, approved time extensions, and each submitted schedule update as received, rather than maintaining the contractor's full critical path logic.
• Field records. Daily reports, inspection reports, photos, material test results, non-conformance notices, and punch lists. This is the evidence that the work being invoiced actually exists.

Seats: who is actually in the system

Licensing models differ sharply, and the differences drive cost more than feature lists do. Expect at least four populations: agency staff (project managers, construction managers, inspectors, accounting, procurement, and executives who only want a dashboard), the agency's consultants such as a CM firm or design professional, contractors and their subcontractors submitting pay applications and submittals, and read-only reviewers such as auditors or grant monitors.

Ask directly whether external collaborators consume paid seats, whether licenses are named or concurrent, whether inspectors can work offline on a phone and sync later, and what happens to a contractor's account and its uploaded documents when the contract ends. A product that charges full price for every subcontractor tends to push work back into email, which defeats the point.

Pay applications, retainage, and payroll compliance

Pay application review is the workflow that justifies the system. It should carry the schedule of values, percent complete by line, stored materials, previous payments, current retainage held and any approved release, and required attachments such as lien waivers or their state equivalent, with each reviewer's action time stamped.

Two compliance areas sit next to that workflow. Federal prevailing wage requirements apply to many federally funded or federally assisted construction contracts and generally require weekly certified payrolls from contractors and subcontractors. Many states have their own prevailing wage laws, with their own coverage thresholds, forms, and in some cases a state portal for submission. Requirements change, so confirm current obligations with your counsel and the responsible labor agency rather than with a vendor's feature sheet. What software can reasonably do is collect or reference the payrolls, flag missing weeks, and make payroll compliance status visible at the moment a pay application is approved.

Retainage limits and release conditions are set by state statute and vary, as do prompt payment deadlines for owner payment and for contractor pass-through to subcontractors. Insist that retainage calculation and payment clocks be configurable, and that the system time stamp the receipt of a pay application, since that receipt date is often what a deadline runs from.

What ERP integration actually needs to do

The goal is not to duplicate the general ledger. The ERP remains the system of record for money; the project system is the system of record for project detail. A workable integration usually covers:

• Vendor identity. One vendor record, mastered in the ERP, referenced by the project system.
• Coding. Account, project, grant, and fund codes pulled from the ERP rather than typed by hand.
• Encumbrance. Executed contracts and approved change orders create or adjust the encumbrance.
• Payables. An approved pay application becomes an invoice, with retainage carried as its own line, and the payment status and date return to the project view.
• Capitalization. Construction in progress accumulates and transfers to fixed assets at closeout.

Nightly batch is usually sufficient. The failure to design against is the silent partial sync, so require a documented error queue and a reconciliation report that finance can run.

What to ask vendors and how to start

1. Demonstrate one pay application from contractor submission through approval and export to the ERP, with retainage and a cost split across two funding sources.
2. State exactly which users consume licenses, and price a realistic roster including external parties.
3. Commit in the contract to a complete export, including attachments, metadata, and audit trail, in a documented format, available at any time and at termination.
4. Explain how records are preserved against public records and retention schedules for capital projects, which are typically long, after the subscription ends.
5. Show how approval thresholds, delegations, and forms are configured by agency staff rather than by a vendor work order.
6. Confirm accessibility conformance, hosting location, and the security documentation your state review process requires.
7. Ask references in your own state, since retainage, prevailing wage, and prompt payment rules are state specific.

Start with one active project rather than the whole portfolio, and document the current approval chain before configuring anything. Automating an approval path nobody can explain simply makes the confusion faster.

HQT works with state and local agencies on systems engineering, integration, and software for enterprise and program systems of this kind.

Frequently asked questions