Why month-end close takes construction controllers two weeks — and how to cut it

Ask a construction controller how long month-end close takes and you'll usually hear a number between eight and fifteen working days. Ask a controller in almost any other industry and the answer is five or fewer. The difference isn't competence — it's that a construction close carries a second workload most industries don't have: percentage-of-completion accounting, job-cost reconciliation, and a WIP schedule that the bank and the bonding company both read like a credit report. Most of that second workload is assembled by hand, in Excel, from data that already exists in the accounting system. That's the part you can cut.

The anatomy of a construction close

Strip a typical mid-sized GC's close down to its phases and it looks like this:

• Days 1–3: getting the data to sit still. Chasing late AP invoices and sub pay apps so job costs are complete. Cutting off payroll and equipment allocations. Posting the last of the owner billings. Nothing downstream is trustworthy until cost cutoff is real, so everything waits on this.
• Days 3–6: job-cost rollups and reconciliation. Exporting job-cost detail from Sage (or whichever system holds it), pivoting it into cost-code and division summaries per job, and reconciling the job-cost ledger back to the GL. In firms running Procore or another PM system alongside Sage, this phase includes reconciling committed costs and change orders between the two systems — the same numbers, entered twice, agreeing rarely.
• Days 6–10: the WIP schedule. For each open job: current contract value including approved change orders, revised cost budget, cost to date, estimated cost to complete, percent complete, earned revenue, billed to date — and from those, the over/under billings that drive the revenue adjustment. Every PM gets chased for cost-to-complete estimates. Every number gets keyed or pasted into the WIP workbook. Then the arguments start: a job showing sudden fade gets three meetings before anyone will sign the schedule.
• Days 10–14: statements and packaging. Post the over/under entry, run financials, build the management package, produce the versions the bank and surety want. By the time the package lands, the month it describes ended two weeks ago — and the next close starts in two more.

Notice what's actually consuming the days. It isn't accounting judgment — the judgment moments (is this job really 62% complete? do we book the fade now?) total a few hours. The days go to assembly: exporting, pivoting, pasting, tying out, and chasing people for inputs.

The linked-workbook trap

Most controllers have already optimized this once. The result is usually a master WIP workbook with external links to per-job tabs, SUMIFS against pasted Sage exports, and a few decades' worth of inherited formulas. It works — until it doesn't, and it fails in ways every controller will recognize:

• Structure drift breaks the links.A new cost code, a renumbered job, an extra column in this month's export — and a range reference silently grabs the wrong rows. The workbook doesn't error; it just becomes quietly wrong, which is worse.
• Refresh order matters and nobody wrote it down. Paste the job-cost export before the billing export and half the lookups resolve against stale data. The person who knows the ritual is the single point of failure for the entire close.
• Versions multiply.WIP_June_v3_FINAL_bankcopy. The PM has one version, the CFO another, and the number the surety saw doesn't tie to the GL because it was exported two revisions ago.
• It can't answer “why.”When a job's percent complete jumps, the workbook shows the result but not the cause. Tracing it means re-opening the exports and rebuilding the pivot — an hour per question, during the busiest week of the month.

What a self-assembling close looks like

The fix is not a new ERP, and it is not asking your team to learn new software. It's automation that does the assembly the workbook was doing — directly from the systems of record, on a schedule, with the outputs landing in the formats your team already uses. Our founder built and ran exactly this pattern inside the data function of a national home builder, where the same Sage-to-Excel assembly work consumed entire roles before it was automated. The pattern transfers to any firm on a Sage-plus-Excel stack:

1. Job-cost data lands reconciled, not exported

Instead of a human exporting Sage job-cost detail and pivoting it, a pipeline pulls cost, commitment, billing, and change-order data on a nightly schedule, rolls it up by job and cost code, and — critically — reconciles it as it lands: job-cost ledger to GL, Sage commitments to Procore commitments, billed-to-date to the owner billing module. Mismatches surface as an exception list on day one of close, not as a mystery on day six.

2. The WIP schedule builds itself, except the judgment

Every mechanical field on the WIP — contract value, approved COs, cost to date, billed to date, prior-period comparisons — populates automatically. The only human inputs left are the ones that genuinely require judgment: cost-to-complete estimates and any manual revenue decisions. PMs get their jobs pre-filled with current actuals and last month's estimate, and enter one number per job instead of assembling a tab. The over/under calculation, the earned-revenue math, and the journal entry draft all follow mechanically from there.

3. Movement gets explained automatically

Because the pipeline keeps history, every WIP line can carry its own bridge: percent complete moved because costs booked $312K against a budget that grew $80K in approved COs. The three-meeting argument about a fading job becomes a ten-minute review of a variance that arrives pre-explained.

4. Outputs are generated, not maintained

The management package, the bank WIP format, and the surety format are all renderings of the same underlying table — generated fresh each close, guaranteed to tie to each other and to the GL, because there is exactly one source. The version-control problem doesn't get solved; it gets deleted.

The honest result at most firms is a close that runs in three to five days instead of ten to fifteen — not because anyone works faster, but because the assembly days disappear and only the judgment days remain. The controller's job gets better, not smaller: the hours move from pasting to analyzing.

What to fix first

Don't automate the whole close at once. The sequence that works, in order of leverage:

• First: the job-cost extract and reconciliation. Everything downstream consumes this data, and it's the piece with zero judgment content — pure assembly. Automating it typically recovers two to three days on its own and makes every later step easier.
• Second: WIP assembly. Pre-populated mechanical fields, PM inputs collected through a simple structured request instead of emailed workbooks, over/under computed from the data. This is the biggest single block of days for most firms.
• Third: report generation. Bank and surety formats generated from the reconciled table. Lower savings in hours, high savings in errors and version pain.
• Last, if ever: the cutoff chase.Late invoices and pay apps are a process and vendor-behavior problem more than a data problem. Automation can flag what's missing versus commitments, but shortening cutoff is mostly management. Don't let it block the pieces above — you can automate around a soft cutoff with accrual flags.

If you want to see what this looks like as an engagement, our month-end close automation page walks through the fixed-price build. And if you first want the business case in dollars — what those ten assembly days actually cost per year at your loaded rates — the free 60-second workflow cost calculator will give you the number to put in front of your CFO.