The finance side of a construction job runs on documents other people generated: pay applications, SOV breakdowns, budget-config exports, open-invoice reports, subcontracts with overhead clauses buried in them. Before you can tell a PM or an owner where margin is landing, you have to pull numbers out of all of it and reconcile them against the budget. That reconciliation is the work that keeps a controller at the desk after the field goes home.
This is new behavior in the data, and it’s real: several contractors ran finance and project-controls work through the agent this week, cost forecasting, margin projection, pay-app scans, SOV population. At a fully loaded ~$65/hr (a real customer’s own math: $50/hr plus 30% burden), a controller spending even a day a week rebuilding forecasts by hand is roughly $500 a week going to spreadsheet reconstruction instead of analysis. Here’s what they actually asked for.
A cost-and-margin forecast you can toggle
The biggest finance pull is a live project cost forecast built off real job-cost data:
“build me a total project cost forecast workbook that shows me weekly cost (AP+payroll) and add weeks in there that will allow me to project out total project costs.”
“now i want you to project out total net margin. Assume that OH allocation is going to be 14.5% of total project cost. Approved change orders totalling 55,000…”
“need to include an additional 10,000 in subs, and 6,500 in materials that haven’t been posted yet in the net margin calcs.”
The controller feeds it the cost data and the assumptions, OH allocation percentage, approved change orders, subs and materials not yet posted, and gets a weekly cost curve and a net-margin projection they can adjust as postings land. One follow-up captures exactly why this matters: “to get a true picture of net margin, we need to assume the AP and equipment postings for that week and copy the payroll expense from the week ending…” That is the reconciliation a controller does by hand every week, and it’s now a toggle instead of a rebuild.
One detail from the same account matters: “you have access to the budget config docs, so verify based on budgets and cost codes.” The forecast is tied back to the budget codes in the accounting system, not floated on its own.
Overhead and markup, computed the way your template actually stacks
The second pattern is getting the overhead math right, which is fussier than it looks:
“How do I create an overhead template where Material Tax %, Overhead %, and Waste % are applied first, and then Income % is applied to the resulting subtotal?”
Order of operations on markup is where margin quietly leaks. Applying income before overhead, or vice versa, changes the number. The agent builds the template so the percentages stack in the right sequence, which is the difference between a bid that holds its margin and one that gives it away in the arithmetic.
Pay apps and SOV, scanned and populated
The third finance pattern is pulling numbers out of pay applications and schedules of values:
“can you scan the attached file and let me know if there is a pay application from [subcontractor], and if so on what page”
“add the values in the Proposed Bid section to the attached SOV breakdown, guided by the trade description, and highlight what has been added.”
“I need the original contract amount, billed to date from their pay apps, paid to date from the open invoice reports.”
A 300-page pay app becomes “this sub is billing on page 214,” and an SOV gets populated from the bid with the additions flagged. This is the AP/AR reconciliation that eats an accounting day, compressed to a scan and a review.
The overhead-on-change-orders question
One more worth flagging, because it’s finance protecting the contract:
“what overhead percentages are subcontractors tied to on their change orders”
“please review this contract and tell me what percent of overhead they can charge on change orders.”
The agent reads the subcontract and tells you the overhead cap a sub can charge on a change order. On a job with a stack of COs, that clause is real money, and it’s usually buried on page 40 of a contract nobody re-reads.
What this changes for you
Finance work on a construction job is reconciliation before it’s analysis. Every ask this week is the same move: the agent pulls the numbers out of the documents and ties them to the budget, so the controller’s hours go to the judgment, is this margin real, is this pay app right, does this CO overhead match the contract, instead of to rebuilding the spreadsheet that answers those questions. This is emerging behavior, concentrated in a few accounts, but it’s genuine controller and project-controls work, not estimating with a finance label.
If you’re on the finance side, the fastest test is a pay app you already closed: drop it in and ask which subs are billing and on what page. Then ask for the billed-to-date and paid-to-date pulled against your open-invoice report.
