Stop Making Decisions with Bad Numbers

A contractor calls. They can’t see their cash. They don’t know which jobs are actually profitable. Their controller keeps saying the WIP doesn’t tie out. The instinct is to assume the software is the problem and start shopping for a replacement.

Almost always, it isn’t.

The real problem is they’re making decisions with bad numbers. Margins that aren’t there. Percentages complete that aren’t accurate. WIP schedules that don’t reflect reality. A more expensive system won’t fix any of that. It just moves the bad numbers to a more expensive platform.

Scott Franchini, Partner at RedHammer, has seen the pattern repeat across hundreds of construction companies. In his assessment, 92% of contractors haven’t configured their existing accounting system to get what they actually want out of it. They jump to a $3,000/month ERP with a $150,000 implementation and nine months of pain, when the underlying problem (cost codes embedded in the chart of accounts, indirect costs falling into G&A, no real WIP discipline) follows them to the new platform.

On this episode of Builders, Budgets, and Beers, Scott walks through what “misconfigured” actually means, the fake profit hiding inside most contractors’ books, and the order of operations that prevents most expensive software mistakes.

Here’s the playbook.

What does “misconfigured” actually mean in construction accounting?

Misconfiguration is rarely one big mistake. It’s a stack of small ones that compound:

• Cost codes embedded in the chart of accounts. When you can’t segment cost codes from financial accounts, you can’t measure gross profit on anything. It just becomes a cluttered mess.
• Nested accounts three or four levels deep. Pretty on a financial statement, brutal at the entry level. Coders end up choosing the wrong account because the dropdown is half a mile long.
• Hundreds of accounts when 120 would do. RedHammer’s standard is 120 accounts or fewer. Most QuickBooks files they walk into have far more.
• No real budget management. Estimators bid at one level of detail, the budget gets entered at another, and the actuals never match up to either.
• No commitments or POs. If nobody is pre-coding the spend, no one is comparing actuals to budget at the right level.

None of these are software problems. They’re setup problems. And they’re the reason WIP doesn’t tie out, why financials feel approximate, and why owners don’t trust their own numbers.

The expensive mistake: shooting for the moon

The pattern Scott sees: a contractor hits $5M to $7M in revenue, the spouse who’s been running the books wants out, the owner wants to chase commercial work or government contracts that need bonding. Suddenly visibility matters and they panic.

They go shopping. They look at NetSuite, Acumatica, Sage Intacct. The pitch sounds good. The demo looks clean. They sign for $3,000+/month with a six-figure implementation fee, after coming from QuickBooks at $275/month.

What happens next:

1. Nine months of brutal implementation.
2. Two of their best people quit in frustration.
3. They land on the new platform with the same broken processes, the same cost code mess, and the same WIP problems.

The underlying issue wasn’t the software. It was the configuration of the software, the chart of accounts, the workflow, and the discipline. Migrating doesn’t fix any of that. It just moves it.

The four pillars of WIP that most builders are missing

Scott’s view: most contractors treat WIP like a bonding requirement or a year-end chore. It’s actually a monthly profitability tool, and it only works when four things are managed together:

1. Contracts. Originals plus every change order, tracked in the system in real time.
2. Budgets. Detailed enough to be useful, structured the same way you cost the job.
3. Actual costs. Coded correctly, posted timely, with indirect costs allocated back in.
4. Billing. Inside the period, not deferred to the fourth of the next month.

Miss any one of these and the WIP isn’t a tool, it’s a guess. Most contractors are missing two or three.

The “fake profit” problem hiding in every job

This is the insight that should rattle most owners. Here’s the math.

A contractor budgets a job at $100,000 of direct cost. Their actual overhead burden on that job (the project manager’s time, the company truck, fuel, equipment) is roughly $10,000. If those costs aren’t allocated back to the project (if they fall into G&A on the P&L) the project looks like it made an extra 10%.

It didn’t. The 10% is buried somewhere else on the income statement.

Now layer in that most construction teams are incentivized on project gross profit. The team gets paid bonuses on margin that doesn’t exist. The owner is bleeding cash without realizing it. The percentage complete looks higher than it actually is. At closeout, profit fade hits. The bonding company notices. The bank notices.

Scott’s term for it: project gain is fake. And it’s everywhere.

How to allocate indirect costs without losing your mind

The instinct when contractors learn about indirect allocation is to start spreading every individual transaction by hand. Scott has seen clients spend $800,000 worth of overhead allocations doing exactly that, line by line.

There’s a better way: model it.

Pick the allocation method that best represents how overhead actually gets consumed across your business. The options:

• Labor hours. If a project consumes 25% of monthly labor hours, it absorbs 25% of overhead.
• Percentage of direct cost. Larger jobs absorb more.
• Percentage of subcontracts. Useful for GCs running mostly subs.
• Percentage of revenue. Simple and defensible for smaller companies.

You can use AI to find patterns in your historical data and pick the method that fits best. The key constraint: don’t make it overly complicated. The juice has to be worth the squeeze. A simple allocation method run consistently beats a precise allocation method that no one updates.

Once the method is set, the magic happens at bid time. If you’ve been allocating 10% overhead but the actuals over the last year show 8%, you’ve got 2% you can trim from future bids to compete more aggressively.

The right order of operations: reporting first, software last

Scott’s biggest critique of how most contractors evaluate software: they do it in the wrong order.

The wrong order looks like this:

1. Feel pain.
2. Decide the software is the problem.
3. Buy bigger software.
4. Figure out reporting after migration.

The right order:

1. Define the reports you need. What do you have to see to run the business? What divisions, segments, geographies, project types do you need to measure?
2. Map the configuration that produces those reports. Cost codes, accounts, segments, allocations, billing structure.
3. Evaluate whether your current software can do it. Most of the time, with proper setup, it can.
4. Document a requirements list. Current needs first, then future needs.
5. Only then consider migrating.

Roughly half of contractors who go through this exercise discover they don’t need to migrate at all. They needed to fix the setup. The same software they were ready to throw away ends up doing the job once the configuration is right.

What the right tech stack actually looks like

When configuration alone isn’t enough, the stack Scott recommends for mid-market construction:

• Core ledger. QuickBooks Online or Intuit Enterprise Suite for most companies. He’s a fan of IES for its API depth, AI integrations, and the familiarity of QuickBooks. Sage 100 or 300 for companies that have already invested there.
• AP, corporate cards, and AIA billing. Adaptive. Scott specifically calls out Adaptive’s “big three” coverage (AP, credit cards, and physical cards with budget guardrails) plus AIA billing as the most complete construction-specific stack on the front end.
• Project management. Knowify for specialty subs. Buildertrend for residential GCs (especially for client communication). Procore for larger commercial GCs.

The total cost on a stacked solution like this runs roughly $1,000 to $1,200/month for a mid-market contractor. Compare that to $3,000+/month going upmarket, plus six figures of implementation. The stack approach is cheaper, faster, and more flexible.

The critical thing to look for in any tool: bilateral integration. When you do something in the AP system, it should reflect in the GL automatically. One-way pushes create the same reconciliation problems that misconfiguration creates in the first place.

Scott’s three-word playbook

When asked what one thing he’d send contractors away with, Scott boiled it down:

1. Slow down. The instinct to throw money and technology at the problem is the wrong instinct.
2. Ask for help. There are firms (RedHammer included) and software partners who will help you map your needs before you buy.
3. Document your requirements. Half the contractors who do this realize the answer was inside the software they already had.

The 92% problem isn’t a software problem. It’s a discipline problem dressed up in a software costume. And every day it goes unfixed is another day you’re making decisions with bad numbers: on jobs that look profitable but aren’t, on a WIP that doesn’t tie out, on cash flow you can’t predict.

The fix isn’t a $150,000 migration. It’s the discipline to slow down, document what you need, and configure what you already have.

FAQ

What does it mean for accounting software to be “misconfigured” in construction?

Misconfigured means the chart of accounts, cost codes, budget structure, or billing workflow aren’t set up to produce the reports the business needs. Common signs: cost codes embedded in the chart of accounts, deeply nested accounts, indirect costs falling into G&A instead of being allocated to jobs, and WIP that doesn’t tie out month over month.

Why do contractors keep buying new software when their real problem is configuration?

Because the pain feels like a software problem. They can’t see what they need to see, so they assume the tool is the issue. In reality, roughly 92% of contractors have a configuration problem that follows them to the new platform. Documenting reporting requirements first usually reveals that the existing software can do the job.

What is WIP and why do contractors struggle with it?

Work in Progress (WIP) is a real-time profitability schedule that compares earned revenue to actual costs across all open projects. Most contractors treat WIP as a year-end or bonding requirement instead of a monthly management tool. To work, WIP needs four things managed in sync: contracts, budgets, actual costs, and billing.

What are indirect costs in construction and why do they matter?

Indirect costs are expenses that are part of a job but can’t be cleanly traced to a single line item. Project manager salaries, company vehicles, fuel, and shared equipment are common examples. If they’re not allocated back to jobs, project profitability looks higher than it really is, and the gain shows up later as profit fade.

How do you allocate indirect costs?

Model it instead of allocating transaction by transaction. Pick an allocation method (labor hours, percentage of direct cost, percentage of subs, or percentage of revenue) that reflects how overhead actually gets consumed. Apply it consistently. Use it to refine future bids.

What’s the ideal tech stack for a $5M to $30M construction company?

A core ledger (QuickBooks Online, Intuit Enterprise Suite, or Sage), an AP and AIA billing layer (Adaptive), and a project management tool (Knowify for subs, Buildertrend for residential GCs, or Procore for commercial). Total cost runs roughly $1,000 to $1,200/month. The critical requirement: bilateral integration between the layers.

How long does it take to remediate a misconfigured construction accounting setup?

RedHammer’s implementations typically take four to 12 weeks. Four-week projects are clean rebuilds. Twelve-week projects involve remediation of prior years, reclassing transactions, and unwinding nested accounts or embedded cost codes.